Я использую fail2ban 0.10.0, и с его помощью я могу инициировать некоторые действия, чтобы блокировать попытки грубой силы из данного единственного источника (с тегом HOST) .
Но предположим, что кто-то имеет контроль над целым блоком / 24 и использует его для своих брутфорс-атак на основе ботов. Раньше я писал (постоянные) правила iptables в файле / etc / sysconfig / iptables, который также служил для размещения комментариев ...
Я перехожу с iptables на firewalld, используя Centos 7.
Раньше я писал (постоянные) правила iptables в / etc / sysconfig / iptables
, который также служил для размещения комментариев с добавлением #
(чтобы напомнить нам, почему мы ограничили тот или иной ip и т. д.).
Теперь кажется, что текущая (постоянная) конфигурация читается из файлов / etc / firewalld /
(особенно / etc / firewalld / zone /*.xml
). Думаю, я мог бы добавить туда xml-комментарии, но, похоже, хорошей практикой является редактирование этих файлов не напрямую, а через firewall-cmd
(нет?).
Следовательно, я не уверен, какой стандартный или рекомендуемый способ добавления комментариев к правилам.
Есть предложения?
Отредактировано: Для записи, я проверил, что комментарии xml не сохраняются модификации firewall-cmd
.
Подумав об этом, я нахожу эту фейерволд-коммундную
штуку слегка глуповатой. В конце концов, файлы конфигурации XML редактируются человеком. Для меня это не имеет смысла, приходится изучать дополнительный уровень команд (ну, одна команда, но с тоннами аргументов). только для редактирования некоторых простых и аккуратных XML файлов (*).
Я упал немного глупо набрав
firewall-cmd --permanent --zone=work --add-port=445/tcp
просто для добавления следующей строки в /etc/firewalld/zones/work. xml
Следовательно, по крайней мере пока, учитывая, что элементы XML не содержат атрибутов комментариев (в этом направлении есть некоторые запросы), я склоняюсь к следующей стратегии: просто забудьте о firewalld-cmd
(возможно, даже удалите его), отредактируйте XML-файлы сами и свободно добавляйте XML-комментарии.
(*) Это правда, что firewalld-cmd
позволяет также добавлять динамические (не постоянные) правила. Но я бы поставил на то, что это не очень частый сценарий.
Хотя в man-странице firewall-cmd есть раздел Direct Options (Прямые параметры), который позволяет задавать параметры, поэтому вы можете сделать что-то вроде:
Хотя, как сказал Майкл Хэмптон, наверное, не самое лучшее. На 2/2020 я думаю, что Предлагается документировать правила в CMS , через Таким образом, пока Результирующая аннотация появляется в моем системном журнале как побочный эффект, но теперь вывод Комментарий также записано в моем файле зоны как: Я понимаю, что даже этот подход чрезмерно усложняет конфигурацию , вводя расширенные правила, , но считаю, что преимущества в аннотации на данный момент оправданы. firewall-cmd --direct --add-rule
firewalld
используют достаточно широко, чтобы простота аннотирования правил либо из firewall-cmd
, либо из firewall-config
очень важен по причинам, обсуждаемым в OP. firewall-cmd --direct
, через ipsets или редактировать файлы зон вручную, все усложняет управление и преодолеть цель firewalld
, цель сделать конфигурацию межсетевого экрана более прозрачной . firewall-cmd --comment
не станет доступным, я буду аннотировать свои правила с помощью параметра префикса журнала
в firewall-cmd --add-rich- правило
. Например, 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-zone
самодокументируется: 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>
Теги
Похожие вопросы