fail2ban - Фильтрация IP-адресов по блокам cidr

Я использую 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 .

1
задан 19 January 2018 в 22:32
3 ответа

Подумав об этом, я нахожу эту фейерволд-коммундную штуку слегка глуповатой. В конце концов, файлы конфигурации XML редактируются человеком. Для меня это не имеет смысла, приходится изучать дополнительный уровень команд (ну, одна команда, но с тоннами аргументов). только для редактирования некоторых простых и аккуратных XML файлов (*).

Я упал немного глупо набрав

firewall-cmd --permanent --zone=work --add-port=445/tcp

просто для добавления следующей строки в /etc/firewalld/zones/work. xml

Следовательно, по крайней мере пока, учитывая, что элементы XML не содержат атрибутов комментариев (в этом направлении есть некоторые запросы), я склоняюсь к следующей стратегии: просто забудьте о firewalld-cmd (возможно, даже удалите его), отредактируйте XML-файлы сами и свободно добавляйте XML-комментарии.

(*) Это правда, что firewalld-cmd позволяет также добавлять динамические (не постоянные) правила. Но я бы поставил на то, что это не очень частый сценарий.

.
0
ответ дан 4 December 2019 в 04:15

Хотя в man-странице firewall-cmd есть раздел Direct Options (Прямые параметры), который позволяет задавать параметры, поэтому вы можете сделать что-то вроде:

firewall-cmd --direct --add-rule

-c

Хотя, как сказал Майкл Хэмптон, наверное, не самое лучшее.

0
ответ дан 4 December 2019 в 04:15

На 2/2020 я думаю, что firewalld используют достаточно широко, чтобы простота аннотирования правил либо из firewall-cmd , либо из firewall-config очень важен по причинам, обсуждаемым в OP.

Предлагается документировать правила в CMS , через 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>

Я понимаю, что даже этот подход чрезмерно усложняет конфигурацию , вводя расширенные правила, , но считаю, что преимущества в аннотации на данный момент оправданы.

2
ответ дан 17 February 2020 в 19:11

Теги

Похожие вопросы