Я перехожу с iptables на firewalld, используя Centos 7. Раньше я писал (постоянные) правила iptables в /etc/sysconfig/iptables , который также служил для размещения комментариев, добавленных # (чтобы напомнить нам, почему мы ограничили тот или иной ip и т. д.).
Теперь кажется, что текущая (постоянная) конфигурация считывается из /etc/firewalld/ файлы (особенно /etc/firewalld/zones/*.xml). Думаю, я мог бы добавить туда xml-комментарии, но кажется хорошей практикой не редактировать эти файлы напрямую, а через firewall-cmd (нет?)
Следовательно, я не уверен, какой способ добавления комментариев к правилам является стандартным или рекомендуемым.
Какие-либо предложения?
Отредактировано: для записи, я подтвердил, что комментарии XML не сохраняются firewall-cmd модификации.
Хотя на странице руководства firewall-cmd есть раздел Direct Options, который позволяет вам указывать параметры, чтобы вы могли сделать что-то вроде:
firewall-cmd --direct --add-rule <table> <chain> <priority> <args> -c <some comment>
Хотя, как сказал Майкл Хэмптон, наверное, не самое лучшее.
По состоянию на 2/2020, я думаю firewalld использовать достаточно широко, чтобы простота аннотирования правил либо из firewall-cmd или из firewall-config очень важно, по причинам, обсуждаемым в ОП.
Предложения о том, что мы документируем правила в CMS, через firewall-cmd --direct, через ipsets, или редактировать файлы зон вручную, все усложняет управление и препятствует firewalld, что из сделать конфигурацию межсетевого экрана более прозрачной.
Поэтому пока firewall-cmd --comment становится доступным, я буду аннотировать свои правила с помощью log prefix возможность firewall-cmd --add-rich-rule. Например,
firewall-cmd --add-rich-rule="rule family=ipv4 source address=192.168.103.225 reject log prefix='Onsite NIDS'"
firewall-cmd --permanent --add-rich-rule="rule family=ipv4 source address=192.168.103.225 reject log prefix='Onsite NIDS'"
Результирующая аннотация появляется в моем системном журнале как побочный эффект, но теперь вывод firewall-cmd --list-all-zones самодокументируется:
public (active)
target: default
icmp-block-inversion: no
interfaces: ens160
sources:
services: dhcpv6-client http https ssh
ports: 1515/tcp 1514/tcp
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
rule family="ipv4" source address="192.168.103.225" log prefix="Onsite NIDS" reject
Комментарий также записан в моем файле зоны как:
# cat /etc/firewalld/zones/public.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Public</short>
<description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
<service name="ssh"/>
<service name="dhcpv6-client"/>
<service name="http"/>
<service name="https"/>
<port protocol="tcp" port="1515"/>
<port protocol="tcp" port="1514"/>
<rule family="ipv4">
<source address="192.168.103.225"/>
<log prefix="Onsite NIDS"/>
<reject/>
</rule>
</zone>
Я понимаю что даже такой подход чрезмерно усложняет настройку путем введения богатые правила, но считаю, что польза от аннотации пока стоит.
Обдумывая это, я нахожу это firewalld-cmd вещь немного глупая. В конце концов, файлы конфигурации XML доступны для редактирования человеком. Для меня не имеет смысла изучать дополнительный уровень команд (ну, одну команду, но с тонны аргументов) только для редактирования некоторых простых и понятных файлов XML (*).
Я немного тупо набирал
firewall-cmd --permanent --zone=work --add-port=445/tcp
просто для добавления следующей строки в /etc/firewalld/zones/work.xml
<port protocol="tcp" port="445"/>
Следовательно, по крайней мере на данный момент, и учитывая, что элементы XML не включают атрибуты комментариев (есть некоторые Запросы в этом направлении) я склоняюсь к следующей стратегии: просто забудьте о firewalld-cmd (возможно, даже удалите его), отредактируйте файлы XML самостоятельно и свободно добавьте комментарии XML.
(*) Это правда, что firewalld-cmd позволяет также добавлять динамические (непостоянные) правила. Но готов поспорить, что это не очень частый сценарий.