Firewalld.

Firewalld — брандмауэр, с поддержкой динамического управления правилами и концепцией работы с сетевыми зонами. Появился по умолчанию в CentOS 7, но на сегодняшний день особой популярности не обрёл. Многие администраторы предпочитают старый-добрый iptables и ставят на сервер именно его. Благо, сделать это совсем не сложно. Однако в рамках данной заметки, хотелось бы рассмотреть функционал и возможности firewalld, а так же обратить внимание на те возможные перспективы, к которым стремятся разработчики.

Что такое зоны?

Зона определяет уровень доверия к подключению. Каждая зона уже содержит в себе определённый набор правил, в соответствии с которыми и работает подключение. Администратор имеет возможность создавать собственные зоны с нужными ему правилами фильтрации, имеет возможность модифицировать уже существующие зоны. При необходимости, изменения всегда можно откатить до состояния по умолчанию.

public — зона, к которой чаще всего приходится обращаться администратору веб-сервера. Сеть не считается доверенной. В рамках правил этой зоны допускаются только явно указанные соединения.
drop — правилами зоны разрешены только исходящие соединения, на входящие соединения сервер не отвечает.
block — разрешены только соединения инициированные внутри системы. Внешние входящие соединения сбрасываются с ответом icmp-host-prohibited/icmp6-adm-prohibited.
home, internal, work — схожие по своему описанию соединения. Сеть считается доверенной. Допускаются только определённые входящие соединения.
dmz — в рамках этой «демилитаризованной» зоны разрешены только явные соединения. Зона предназначена для личной сети с ограниченным доступом к ней общественной;
trusted — Все соединения разрешены и считаются безопасными.

Работа с помощью firewall-cmd.

Для того что бы сделать правила постоянными, не забываем добавлять ключ —permanent к firewall-cmd.

Работаем с зонами:

firewall-cmd --state # Убеждаемся что он работает.
firewall-cmd --get-default-zone # Проверяем зону по умолчанию.
firewall-cmd --set-default-zone=home # Устанавливаем зону по умолчанию.
firewall-cmd --get-zones # Получаем список зон.
firewall-cmd --get-active-zones # Получаем список задействованных зон.
firewall-cmd --list-all # Настройки текущей зоны.
firewall-cmd --zone=home --list-all # Настройки определённой зоны.
firewall-cmd --zone=home --change-interface=ens2f0 # Применить зону home для ens2f0 интерфейса.

Работаем с сервисами:

firewall-cmd --get-services # Получаем список всех сервисов.
firewall-cmd --zone=public --list-services # Список сервисов в определённой зоне.
firewall-cmd --zone=public --add-service=http # Добавляем сервис к зоне.
firewall-cmd --zone=public --remove-service=http # Удаляем сервис из зоны.

Работа с портами.

firewall-cmd --list-ports # Вывести список всех добавленных портов.

Открываем порт, закрываем порт, открываем диапазон портов:

firewall-cmd --permanent --zone=public --add-port=2222/tcp
firewall-cmd --permanent --zone=public --remove-port=2222/tcp
firewall-cmd --permanent --zone=public --add-port=2222-3333/tcp

Маскарад (masquerade, nat), редирект:

firewall-cmd --zone=public --query-masquerade # Статус маскарада.
firewall-cmd --zone=public --add-masquerade # Добавить маскарад к зоне public.

Редирект с одного порта на другой ip:port (c 22 на 11.22.33.44:2222):

firewall-cmd --zone=public --add-forward-port=port=22:proto=tcp:toport=2222:toaddr=11.22.33.44

Как мы видим, основные функции (открыть\закрыть порт, дать доступ к сервису, сделать редирект) настраиваются очень просто, и это несомненный плюс firewalld, однако как только у нас появляется необходимость сделать что-то не стандартное, мы чаще всего встаём в тупик. В том числе и поэтому, решая какие-то не стандартные задачи, администраторы серверов предпочитают работать с привычным iptables. Разумным становится вопрос «нужности» самого firewalld, однако в этом месте я предлагаю не спешить, и познакомиться с планами разработчиков на будущее:

Обсуждается создание своеобразного режима взаимодействия с администратором, в рамках которого, запросы от приложений на установку соединения будут направляться администратору, а тот в свою очередь сможет запрещать их или разрешать (временно или постоянно). Рассматривается возможность установки некого промежутка времени, на который разрешение будет распространяться. Возможность создания шаблонов, для автоматизации процесса при повторении ситуации.

Интересной так же выглядит идея использования информации о мета-данных, для формирования вот таких вот правил:

разрешить внешний доступ к приложениям или службам, предоставляющим общий доступ к музыке
разрешить внешний доступ к приложениям или службам, предоставляющим общий доступ к файлам посредством протокола torrent

Разумеется, разработчики так же задумываются и о более гибком подходе к формированию правил. Идёт работа над поддержкой так называемых rich-rules — правил, которые позволят задавать детальные условия обработки. Например:

firewall-cmd --add-rich-rule='rule family="ipv6" source address="1:2:3:4:6::" service name="radius" log prefix="dns" level="info" limit value="3/m" reject rule family="ipv6" service name="radius" accept'

Однако относительно данного случая, у меня возникает уместное (на мой скромный взгляд) замечание о том, что синтаксис таких правил не проще синтаксиса стандартного iptables. Та простота, что привлекала чуть раньше здесь отсутствует.

На мой взгляд, у firewalld, конечно же есть будущее, более того, он уже сейчас готов для использования, в случаях, если администратору не нужно от фаервола чего-то большего чем простое управление доступом на уровне портов и сервисов. Однако если на сервере с помощью брандмауэра предстоит решать какие-то более сложные задачи, имеет смысл отказаться от firewalld в пользу iptables и работать со вторым в привычном режиме.