Fail2ban recidive не работает

ИТ База знаний

Курс по Asterisk

Полезно

— Узнать IP — адрес компьютера в интернете

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Калькулятор инсталляции IP — АТС Asterisk

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Проблемы с Fail2ban FreePBX 14

3 минуты чтения

Сразу перейду к делу. Пользователями FreePBX 14 замечен крайне серьёзный баг в утилите fail2ban.

Базовый курс по Asterisk

Мы собрали концентрат всех must have знаний в одном месте, которые позволят тебе сделать шаг вперед на пути к экспертному владению Asterisk

Версия fail2ban, на которой замечен баг — 0.8.14-11 и ниже. Проверить можно командой rpm -qa | grep fail2ban :

Данный баг заключается в том, что после установки чистой FreePBX Distro 14 сервис fail2ban хоть и в активном статусе, однако никаких “тюрем» (jails) он не подгружает и их количество = 0.

Проверить можно командой fail2ban-client status , если Ваш сервер подвержен багу, то Вы увидите:

Это значит, что например, максимальное число попыток ввода пароля для доступа к вэб-интерфейсу FreePBX или попыток регистрации SIP-клиента с неверным паролем — не ограничено, а IP-адрес, с которого приходят эти запросы не блокируется. Естественно, что модуль Intrusion Detection во FreePBX также не будет работать.

«Тюрьмы» или jails — это такие секции в файле /etc/fail2ban/jail.local , в которых указано, логи какого сервиса необходимо мониторить, чтобы выявлять и блокировать несанкционированные попытки доступа к этому сервису, а также такие параметры как время блокировки, максимальное число попыток и действие, которое необходимо предпринять в случае выявления.

Например, вот секция [asterisk-iptables] :

В ней указано, что нужно мониторить лог /var/log/asterisk/fail2ban , искать в нём 5 попыток неуспешной регистрации (например SIP телефон пытается зарегистрироваться с неверным паролем) и банить IP-адрес на 30 минут. Ну и ещё можно отправку по email настроить о данном факте.

По умолчанию, в файле /etc/fail2ban/jail.local должно быть 7 таких секций — [apache-tcpwrapper], [recidive], [ssh-iptables], [apache-badbots], [pbx-gui], [asterisk-iptables], [vsftpd-iptables]. В каждой указан путь к логам соответствующего сервиса.

Решение

Итак, есть два решения данной проблемы. Первое – остановить сервис fail2ban командой systemctl stop fail2ban и внести следующие изменения в файл /usr/lib/systemd/system/fail2ban.service :

Затем запустить сервсис fail2ban командой systemctl start fail2ban и сделать так, чтобы сервис включался после ребута автоматически systemctl enable fail2ban .

И вторая – обновить сам fail2ban. Для этого вводим следующие команды:

Проверяем версию fail2ban после обновления — rpm -qa | grep fail2ban :

После данных действий, команда fail2ban-client status должна отобразить верное количество jails и fail2ban с Intrusion Detection должны вновь встать на стражу Вашего сервера:

Чтобы случайно не заблокировать свой адрес и игнорировать любые неуспешные попытки доступа к серверу с адресов, находящихся в локальной сети или других доверенных адресов, внесите их или всю доверенную подсеть в секцию [DEFAULT] в поле ignoreip в том же файле /etc/fail2ban/jail.local

Продвинутый курс по Asterisk

Концентрат редких знаний, для внедрения Asterisk в крупных предприятиях. Все это мы собрали в одном курсе для тебя.

Источник

fail2ban — работает, но не банит? Что неправильно?

В jail.local написано:

В action.d/iptables-multiport24 написано, в частности:

В /var/log/fail2ban.log строчки типа такой:

Но они продолжаются и в mail.log тоже, т.е. ничего не банится. Идея была, чтобы банил всю подсеть /24. Где что не так?

1. Идея банить всю подсеть – ебанутая, не делай так.
2. 185.36.81.242/24 – не адрес сети. Т.е. actionban и actionunban у тебя некорректны по своей сути.

Идея банить всю подсеть – ебанутая, не делай так.

Что в этом плохого? Они ж там с разных ip идут.

Ха! Это-то я понимаю 🙂 Но там в коментах у fail2ban именно так советуется делать. Могу найти то место, где я такое нарыл 🙂 И у самого fail2ban (см. выше) написано «127.0.0.1/24» Видимо он считает иначе 🙂

Что в этом плохого? Они ж там с разных ip идут.

На примере твоего ip из поста – 185.36.81.242 и вся подсеть 185.36.81.0/24 принадлежит облачному хостнгу где могут сидеть вполне нормальные клиенты которые должны иметь возможность достучаться до тебя (например почтовик твоего контрагента). Ты же банишь в том числе и его просто потому что в этой подсети засветился один спаммер…

которые должны иметь возможность достучаться до тебя

А, ну это-то очевидно. Я думал, имеется в виду нечто другое.

Ну ладно, а что не так, почему не банит-то? Поменял action просто на iptables-multiport — пока эффект ноль. Кстати, в логе fail2ban еще встречается такое:

Это вообще о чем? Пробовал гуглить, там чего-то очень длинно и непонятно. И неясно (мне) что там за проблема вообще обсуждается, вроде там не так, как у меня все: https://github.com/fail2ban/fail2ban/issues/1076

Заменил. Пока вроде в логе только разные /24 адреса. Победа? Поглядим, что будет дальше.

Про «is not a JournalFilter instance» хотелось бы понять, что за ругань такая.

Про «is not a JournalFilter instance» хотелось бы понять, что за ругань такая.

Возможно что-то не то указано в logpath значении секции-описании postfix-rbl

Выложи сюда весь блок [postfix-rbl] из jail.local

Ура! Вроде, процесс пошел!

Хотя ничего не сказано про /24, но уже и то хорошо, что банить, вроде, начал.

Выложи сюда весь блок [postfix-rbl] из jail.local

На самом деле, он про все включенные для postfix секции так пишет. Вот секция SASL:

Кстати, вот про то, что в комментарии (про mail.warn) — это как чего конкретно сделать-то? И оно действительно стоит того? Абсолютный путь указать ему типа logpath = /var/log/mail.warn или что?

Абсолютный путь указать ему типа logpath = /var/log/mail.warn или что?

Да. У меня прописано:

Никаких ошибок нет.

Смотреть надо не в логах а выхлопе iptables-save

У меня сейчас наблюдается такая картина:

Вот такие пары строк с разными ip. Это как понять? Попробую убрать «/24» и использовать «стандартный» iptables-multiport. Не понимаю, правда, надо ли ему обнулять базу или можно просто подождать?

Насчет лога, вроде, там все ок, раз он находит строки из него. А вот это:

Смотреть надо не в логах а выхлопе iptables-save

что имеется в виду?

А как ты из ip адреса собрался выделить адрес сети?

И поменяй action на использование ipset. Ну или не меняй, но при ДДоСе от 10к участников, fail2ban на твоём action просто ляжет.

Ровно только то что написано. В логе может быть что угодно, реально он к работе netfilter не имеет отношения, если хотите убедиться что все действительно работает смотрите iptables-save а не логи.

И поменяй action на использование ipset

А как ты из ip адреса собрался выделить адрес сети?

В первом посте написано. Вычитал я это в коментах на самом fail2ban-е. И я выше уже отвечал, что не понимаю, как так можно указывать подсеть, но там так пишут. За что купил. ОК, я уже обратно поменял на стандартный muliport. Но эффект пока тот же. «WARNING already banned»

смотрите iptables-save а не логи.

А оно вообще ничего не показывает. Т.е. я так понимаю, оно должно показать текущие правила, а оно просто молча срабатывает и все.

И поменяй action на использование ipset

В системе установлен ipset/stable 6.38-1.2. Мне просто заменить banaction = iptables-multiport[] на banaction = iptables-ipset-proto6[] ? Или что имеется в виду?

В общем, стер лог fail2ban и обнулил базу, после этого поставил:

Вроде, как начал банить, и никаких ошибок и предупреждений (типа, как было) не показывает. Но вырисовывается проблема общего характера — надо ставить большой findtime , поскольку адресов много, и повторяются они редко, но в пределах подсети /24 дело бы пошло быстрее, поскольку там ну очень много из одной и той же /24 подсети. Но как так сделать, чтобы банить всю подсеть, если, скажем, 10 адресов накопилось из нее, я в принципе не понял. Не обязательно же банить обязательно все 256, можно и по 64, например.

Или что, предлагаете просто смириться с таким положением дел?

Вроде, как начал банить, и никаких ошибок и предупреждений

Забей уже на лог fail2ban. чтобы проверить начал ты что-то банить или нет сделай iptables-save или ip6tables-save и посмотри что у тебя там в правилах появляется.

Но как так сделать, чтобы банить всю подсеть, если, скажем, 10 адресов накопилось из нее, я в принципе не понял.

Я сейчас попробовал своему iptables v1.6.0 скормить конструкцию вида -s 185.36.81.242/24 и как ни странно он не просто понял это, но и сам пересчитал за меня подсеть и внес правило вида -s 185.36.81.0/24. Так что бан по принципу описанному в ОП посте все же будет работать на свежих iptables.

но в пределах подсети /24 дело бы пошло быстрее, поскольку там ну очень много из одной и той же /24 подсети

Прелесть использования ipset в том, что у тебя в самом ipset может быть 254 отдельных адреса, а в iptables один –match-set src указывающий на этот сет и это будет работать так же быстро как и бан всей /24. Однако этот подход будет правильным в отличии от беспричинного бана /24 налево и направо.

Источник

Постоянная блокировка IP после n попыток с использованием fail2ban

У меня fail2ban настроен как показано ниже:

• заблокировать IP после 3 неудачных попыток
• освободить IP через 300 секунд

Это работает отлично, и я хочу сохранить его таким образом, чтобы действительный пользователь мог повторить попытку входа после истечения времени ожидания. Теперь я хочу реализовать правило, согласно которому если один и тот же IP-адрес обнаруживается как атака и блокируется, разблокируется 5 раз, навсегда блокирует IP-адрес и никогда больше не разблокируется. Может ли это быть достигнуто с помощью fail2ban или мне нужно написать собственный скрипт для этого?

Я делаю это в санто.

До 0.11 в fail2ban не было ни функции, ни настройки по умолчанию . Но, начиная с предстоящего релиза 0.11, время бана рассчитывается автоматически и экспоненциально увеличивается с каждым новым нарушением, что в долгосрочной перспективе будет означать более или менее постоянный блок.

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

Шаг 1

Нам может понадобиться создать фильтр для проверки BAN в файле журнала (файл журнала fail2ban)

Шаг 2

Нам нужно определить тюрьму , похожую на следующую .

Технически, это не постоянный блок , а только блоки на год (что мы тоже можем увеличить).

Источник

Jail Order Control: Recidive below other fail2ban rules #605

Comments

mcorrigan commented Feb 4, 2014

Generally this has never been an issue, but right now I am using fail2ban-0.8.11.-2.el6.src.rpm on cent 6.4 and despite what I do, recidive follows my ssh-jail. Due to the order of these rules, this means anyone can try over and over to gain access to the server while only suffering the smaller time penalty given by the fail2ban’s ssh jail configuration.

I’ve tried changing the order of the jails in the jail.local, but that didn’t make any difference. Is there something else that the user can do to control this or is this a software issue?

The text was updated successfully, but these errors were encountered:

grooverdan commented Feb 5, 2014

the jails end up in a dictionary so there is no explicit order control.

we could add a rulenum argument to iptables-* actions to explicitly order those however that doesn’t really solve the problem either as the order of execution of those isn’t explicit either.

A work around is to use the route action for recidive jail and iptables for ssh-jail but something better is probably needed.

kwirk commented Feb 14, 2014

@mcorrigan The recidive filter should operate completely independently to any other jail, so the order should have no impact. How is your recidive filter configured?

mcorrigan commented Feb 14, 2014

@kwirk I’m using a jail.local with ssh and recidive enabled. They look almost exactly identical to the default rules for those jails.
#jail.local

enabled = true
filter = recidive
logpath = /var/log/fail2ban.log
action = iptables-allports[name=recidive]
sendmail-whois-lines[name=recidive, logpath=/var/log/fail2ban.log]
bantime = 604800 ; 1 week
findtime = 86400 ; 1 day
maxretry = 3

enabled = true
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
sendmail-whois[name=SSH, dest=admin@domain.com, sender=fail2ban@domain.com]
logpath = /var/log/secure
maxretry = 5

I know the order here shouldn’t matter, but when I start the fail2ban service, it loads the ssh rule before the recidive rule. This order means we don’t ever block malicious users with the recidive jail, unfortunately.

kwirk commented Feb 14, 2014

@mcorrigan Thanks. Yeah, config looks fine.

What does fail2ban-regex /var/log/fail2ban.log /etc/fail2ban/filter.d/recidive.conf come back with?

mcorrigan commented Feb 14, 2014

Running tests

Use failregex file : /etc/fail2ban/filter.d/recidive.conf
Use log file : /var/log/fail2ban.log

Results

Failregex: 3 total
|- #) [# of hits] regular expression
| 1) [3] ^(\s_( )?\s_(?:\S+ )?(?:kernel: [\d+.\d+] )?(?:@vserver_\S+ )?(?:(?:[\d+])?:\s+[[(]?fail2ban.actions(?:(\S+))?[])]. |[[(]?fail2ban.actions(?:(\S+))?[])]. (?:[\d+]). )?\s(?:[ID \d+ \S+])?\s_|,\d <3>fail2ban.actions:\s+)WARNING\s+[(?!recidive])(. _)]\s+Ban\s+\s*$
`-

Ignoreregex: 0 total

Date template hits:
|- [# of hits] date format
| [27] Year-Month-Day Hour:Minute:Second
`-

Lines: 27 lines, 0 ignored, 3 matched, 24 missed
Missed line(s):: too many to print. Use —print-all-missed to print all 24 lines

kwirk commented Feb 15, 2014

@mcorrigan Looks good. I’m not clear why it shouldn’t be working. Your recidive jail should be looking for 3 bans of a single IP address across the other jails, so in case of just ssh being active, 15+ failures in 24hours. Hence the order just doesn’t come into play, as they are looking at different log files and different criteria for banning.

mcorrigan commented Feb 15, 2014

@kwirk I just noticed that when I start the service I get the following message:

Starting fail2ban: WARNING ‘ignoreregex’ not defined in ‘Definition’. Using default one: »

I’m not sure if that is helpful, but I figured I would mention it.

grooverdan commented Feb 16, 2014

Starting fail2ban: WARNING ‘ignoreregex’ not defined in ‘Definition’

Showing iptables -nvL INPUT would be useful.

mcorrigan commented Feb 16, 2014

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
185 13948 fail2ban-SSH tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
934 200K fail2ban-recidive tcp — * * 0.0.0.0/0 0.0.0.0/0

grooverdan commented Feb 17, 2014

@kwirk , see what @mcorrigan is getting at? the action recidive is instigated after SSH.

So explictly listing jail orders with numbers is a bit odd so I’m thinking just moving to a list in the processing so the instigation is the same as the jail.X order? Objections/other ideas?

kwirk commented Feb 17, 2014

Sure, I understand the fact that they are not ordered, but the order has no impact on the recidive or ssh jail functioning and the correct ban times being in place. I’m not clear what setting an order will resolve?

TomKeyser commented Nov 12, 2014

Here is an example of why you should be able to choose the order of jail creation. It may mean nothing to you, but it means a lot to me.

I’m creating jails by CIDR list. it really has no value if i cant order the jails. having the /8 chain near the bottom of the chains is like bad comedy. It obviously works ( lousily speaking ) but the entire implementation is sorely inefficient.

iptables -nvL

Chain INPUT (policy ACCEPT 196 packets, 14894 bytes)
pkts bytes target prot opt in out source destination
3780K 2966M fail2ban-BLACKLIST19 all — * * 0.0.0.0/0 0.0.0.0/0
3780K 2967M fail2ban-honeypot-tarpit all — * * 0.0.0.0/0 0.0.0.0/0
3780K 2967M fail2ban-BLACKLIST12 all — * * 0.0.0.0/0 0.0.0.0/0
3781K 2967M fail2ban-BLACKLIST13 all — * * 0.0.0.0/0 0.0.0.0/0
3781K 2968M fail2ban-BLACKLIST10 all — * * 0.0.0.0/0 0.0.0.0/0
3781K 2968M fail2ban-BLACKLIST11 all — * * 0.0.0.0/0 0.0.0.0/0
3781K 2968M fail2ban-BLACKLIST16 all — * * 0.0.0.0/0 0.0.0.0/0
3782K 2969M fail2ban-BLACKLIST17 all — * * 0.0.0.0/0 0.0.0.0/0
3781K 2969M fail2ban-BLACKLIST14 all — * * 0.0.0.0/0 0.0.0.0/0
3781K 2969M fail2ban-BLACKLIST15 all — * * 0.0.0.0/0 0.0.0.0/0
3781K 2969M fail2ban-BLACKLIST18 all — * * 0.0.0.0/0 0.0.0.0/0
3781K 2969M fail2ban-BLACKLIST32 all — * * 0.0.0.0/0 0.0.0.0/0
3781K 2969M fail2ban-portscan all — * * 0.0.0.0/0 0.0.0.0/0
3781K 2969M fail2ban-BLACKLIST23 all — * * 0.0.0.0/0 0.0.0.0/0
3781K 2969M fail2ban-BLACKLIST8 all — * * 0.0.0.0/0 0.0.0.0/0
3781K 2969M fail2ban-BLACKLIST29 all — * * 0.0.0.0/0 0.0.0.0/0
3781K 2970M fail2ban-BLACKLIST24 all — * * 0.0.0.0/0 0.0.0.0/0
3781K 2970M fail2ban-BLACKLIST22 all — * * 0.0.0.0/0 0.0.0.0/0
3781K 2970M fail2ban-BLACKLIST20 all — * * 0.0.0.0/0 0.0.0.0/0
3781K 2970M fail2ban-SSH all — * * 0.0.0.0/0 0.0.0.0/0
882K 50M fail2ban-apache-antibot-SLT tcp — * * 0.0.0.0/0 0.0.0.0/0 multiport dports 80,443
3781K 2970M fail2ban-BLACKLIST21 all — * * 0.0.0.0/0 0.0.0.0/0
228 10944 DROP all — * * 75.98.233.131 0.0.0.0/0
17G 16T ACCEPT all — * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
1 40 DROP tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x00
13372 11M DROP tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp flags:!0x17/0x02 state NEW
0 0 DROP tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x3F
1707K 102M ACCEPT all — lo * 0.0.0.0/0 0.0.0.0/0
57M 3274M ACCEPT tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
9471 530K ACCEPT tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
536 30592 ACCEPT tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:81
6836 348K ACCEPT tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
1086 45072 ACCEPT tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3306
0 0 ACCEPT tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 MAC 00:1F:E1:50:C2:AE
0 0 ACCEPT tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 MAC 00:1C:23:57:6E:17
360K 207M REJECT udp — * * 0.0.0.0/0 0.0.0.0/0 udp dpts:67:68 reject-with icmp-port-unreachable
11 532 REJECT tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:67:68 reject-with icmp-port-unreachable
2045K 149M LOG all — * * 0.0.0.0/0 0.0.0.0/0 LOG flags 7 level 5 prefix `PORT DENIED: ‘

leeclemens commented Feb 7, 2015

I have to agree with @kwirk here, the iptables chains RETURN — so their order should not matter. Once DROP or REJECT (or ACCEPT?) is encountered, the chain exists processing. If you are blocked by one, and not another (that meets all other criteria, e.g. tcp port) you’ll be blocked regardless of order.

@TomKeyser For the same reason I stated above, the order has no effect on banning, since each chain RETURNs. Saying it has «no value» and it is «inefficient» are very different. Also, I would lean towards «slightly less efficient». But then how would ordering your /8 chains increase efficiency? Do you have hard metrics? (You may wish to create a new Issue, as this ones title is specific to the Recidive jail).

It may be worth noting, by apparently blocking 18 /8’s, you are blocking

7% of the entire Internet.

yarikoptic commented Feb 7, 2015

in theory I see use cases when ordering would be needed ( eg if we have not banning but whitelisting). so might still be worth implementing sooner or later.

leeclemens commented Feb 7, 2015

for whitelisting, sure. However, one implementation could be for whitelist actions to have an attribute set and always be occur first (boolean, order within unban and ban jails respectively wouldn’t matter). Regardless, ordering isn’t relevant to the OP here (I thought there were already Issues for whitelist/unban, but found fewer than I expected.)

Источник