Назад | Перейти на главную страницу

Fail2Ban -> UFW -> IPTables (как записывать блоки)

Бег:

Я успешно настроил fail2ban для использования ufw для блокировки IP-адресов на основе сбоев аутентификации ssh. Как мы знаем, ufw - это всего лишь интерфейс для iptables. Я тестировал с другого IP-адреса и действительно был заблокирован и получил отклоненные пакеты на основе моих правил ssh. Так что я знаю, что все вроде работает.

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

UFW обычно регистрируется в /var/log/ufw.log. Я вижу массу вещей вроде:

Feb 12 12:24:01 redis-test kernel: [14337092.381436] [UFW BLOCK] IN=eth0 OUT= MAC=1e:17....:08:00 SRC=123.456.789.10 DST=10.987.654.32 LEN=40 TOS=0x18 PREC=0x00 TTL=49 ID=59823 PROTO=TCP SPT=33169 DPT=23 WINDOW=2358 RES=0x00 SYN URGP=0

Я не совсем понимаю, где хранятся журналы iptables и есть ли у них собственные журналы, отличные от журналов ufw, но, как минимум, журналы ufw, похоже, включают все, что iptables делает за кулисами.

Из того, что я прочитал, кажется, что по умолчанию ufw не будет регистрировать ожидаемые (заблокированные правилом, заданным пользователем). Из документов:

ufw поддерживает ведение журнала для каждого правила. По умолчанию, когда пакет соответствует правилу, регистрация не ведется. При указании журнала будут регистрироваться все новые соединения, соответствующие правилу, а в журнале все будут регистрироваться все пакеты, соответствующие правилу. Например, чтобы разрешить и регистрировать все новые ssh-соединения, используйте: ufw allow log 22 / tcp

Итак, в моем примере выше (из /var/log/ufw.log) у меня нет каких-либо специальных правил для порта 23 (telnet), поэтому он регистрируется и блокируется. Но поскольку у меня есть правило, специально блокирующее мой «другой» тестовый IP-адрес для ssh, он не регистрируется.

iptables -L производит следующее ...

Chain INPUT (policy DROP)
target     prot opt source               destination
ufw-before-logging-input  all  --  anywhere             anywhere
ufw-before-input  all  --  anywhere             anywhere      ****** points to below (B) ******
ufw-after-input  all  --  anywhere             anywhere
ufw-after-logging-input  all  --  anywhere             anywhere  **** where first logging occurs ****
ufw-reject-input  all  --  anywhere             anywhere
ufw-track-input  all  --  anywhere             anywhere

Chain ufw-before-input (1 references)                                   ****** (B) referenced from above ******
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ufw-logging-deny  all  --  anywhere             anywhere             ctstate INVALID
DROP       all  --  anywhere             anywhere             ctstate INVALID
ACCEPT     icmp --  anywhere             anywhere             icmp destination-unreachable
ACCEPT     icmp --  anywhere             anywhere             icmp time-exceeded
ACCEPT     icmp --  anywhere             anywhere             icmp parameter-problem
ACCEPT     icmp --  anywhere             anywhere             icmp echo-request
ACCEPT     udp  --  anywhere             anywhere             udp spt:bootps dpt:bootpc
ufw-not-local  all  --  anywhere             anywhere
ACCEPT     udp  --  anywhere             224.0.0.251          udp dpt:mdns
ACCEPT     udp  --  anywhere             239.255.255.250      udp dpt:1900
ufw-user-input  all  --  anywhere             anywhere          ****** this is where my rules from fail2ban are going ******

Chain ufw-user-input (1 references)                                     ****** the IPs coming from fail2ban (any my allow SSH rule i added via UFW) ******
target     prot opt source               destination
REJECT     all  --  555.55.55.555        anywhere             reject-with icmp-port-unreachable
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh

Первый случай регистрации, который я вижу, это

Chain ufw-after-logging-input (1 references)    
target     prot opt source               destination
LOG        all  --  anywhere             anywhere             limit: avg 3/min burst 10 LOG level warning prefix "[UFW BLOCK] "

Но поскольку это не оценивается до тех пор, пока мои правила fail2ban / ufw не отклонят соединение, ничего не регистрируется.

Итак, мой вопрос: как я могу включить ведение журнала для IP-адресов fail2ban? Кроме того, если я включу новые тюрьмы в будущем (например, для нацеливания на веб-парсеры / сканирование эксплойтов), могу ли я получить другое сообщение журнала, указывающее, что оно пришло из-за запрета SSH или запрета WebScraper?

Я попытался выяснить, есть ли параметр конфигурации, в который ufw по умолчанию вставил пользовательские правила "CHAIN" (подумал, могу ли я поместить их в нижнюю часть ufw-after-logging-input, это может сработать), но я не Не знаю, лучший ли это подход. Мне не очень нравится идея связываться с тем, как UFW взаимодействует с iptables.

Мой Actionban из ufw.conf:

actionban = [ -n "<application>" ] && app="app <application>"
            ufw insert <insertpos> <blocktype> from <ip> to <destination> $app

actionunban = [ -n "<application>" ] && app="app <application>"
              ufw delete <blocktype> from <ip> to <destination> $app

может быть, это так же просто, как добавить "журнал" в оператор вставки ufw? если да, то есть ли способ указать настраиваемое сообщение журнала, чтобы различать типы тюрем (ssh и веб-скребок)?

Примечание: ведение журнала установлено по умолчанию (низкий уровень). Я временно включил его на максимум. Я мог видеть мой «тестовый» заблокированный IP в записях [UFW AUDIT] в журнале, но даже тогда он не упоминал, что он был отклонен, просто он видел входящую попытку. поэтому изменение уровня ведения журнала не приведет к этому (и в любом случае это слишком избыточно для prod).

Спасибо!

обновление 2/12/2020 9:46 утра:

добавление «журнала» к запрету в /etc/fail2ban/action.d/ufw.conf, похоже, делает то, что я хочу. мои iptables -L теперь выглядят как ...

Chain ufw-user-input (1 references)
target     prot opt source               destination

ufw-user-logging-input  all  --  111.222.333.444       anywhere
REJECT     all  --  111.222.333.444       anywhere             reject-with icmp-port-unreachable
ufw-user-logging-input  all  --  555.666.777.888       anywhere
REJECT     all  --  555.666.777.888       anywhere             reject-with icmp-port-unreachable


Chain ufw-user-logging-input (163 references)
target     prot opt source               destination

LOG        all  --  111.222.333.444       anywhere             ctstate NEW limit: avg 3/min burst 10 LOG level warning prefix "[UFW BLOCK] "
RETURN     all  --  111.222.333.444       anywhere
LOG        all  --  555.666.777.888       anywhere             ctstate NEW limit: avg 3/min burst 10 LOG level warning prefix "[UFW BLOCK] "
RETURN     all  --  555.666.777.888       anywhere

Меня немного беспокоит добавление дополнительных записей по IP. per-IP, он пошел с

  1. сингл "REJECT"

к

  1. вызов цепочки "ufw-user-logging-input"
  2. ЖУРНАЛ по IP
  3. ВОЗВРАТ на IP
  4. "REJECT" в исходном "ufw-user-input"

Итак, для каждого IP теперь есть 4 шага. Я не уверен, сколько это накладных расходов и насколько плохо это будет с IP-адресами 10/100/1000. Неужели это быстро станет проблематичным?

кроме того, он по-прежнему использует общий [UFW BLOCK] в /var/log/ufw.log. Я хотел бы, чтобы он конкретно ссылался на правило, вызвавшее блокировку (ssh / http scraper / http malware bot / etc). есть ли способ получить какую-либо ссылку из fail2ban -> ufw -> iptables? Похоже, что в ufw есть компонент «комментарий» к инструкции вставки, а в iptables - «--log-prefix». какой способ соединить два?

Спасибо!