апр 29, 2016    |      0 комментариев

Ваш Fail2Ban вас же и забанил

Для Linux есть замечательная утилита Fail2Ban, которая позволяет банить IP-адреса за подозрительную активность, защищаться таким образом, например, от брутфорса паролей от ssh-аккаунтов, или простым способом бороться с DDOS’ом.

Если вы им ещё не пользуетесь, кратко:

1) Установить можно банально введя

apt-get install fail2ban

после чего вы «из коробки» получите разные виды фильтров для ssh, nginx, mysql, apache, asterisk, exim, postfix, squid и ещё кучи всего.
2) Документация здесь: http://www.fail2ban.org/wiki/index.php/Main_Page

Достаточно установить fail2ban и каждого кто 3 раза будет ошибаться с вводом логина/пароля в ssh будет банить на 10 минут. Такими темпами подобрать пароль быстро не получится, особенно, если он у вас имеет вид «ac5R3&pE_~0)».

Конечно, вы знаете пароль, и всегда вводите его правильно, а точнее, ваш публичный ключ шифрования записан в ~/.ssh/authorized_keys, поэтому вы заходите на хост без пароля.

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

Работая с удалённым сервером (на котором установлен fail2ban) по ssh, и подключаясь несколько раз подряд, вы можете заметить что сервер вдруг перестал отвечать, подключение не происходит, и вы ничего не можете с этим сделать.
При этом ping до сервера отлично идёт, и, если на сервере есть какой-то веб-сайт, то он успешно открывается в браузере.

Это вполне может означать, что fail2ban принял вас за «врага» и забанил. Даже несмотря на то, что вы не ошибались с паролем, или даже совсем его не вводили, подключаясь по закрытому ключу.

Как убедиться, что вас действительно забанил fail2ban, и это не какая-то другая проблема

1. Сервер пингуется
2. У вас есть возможность подключиться к серверу другим способом, например через виртуальную консоль (многие хостеры виртуальных серверов предлагают такую услугу) или даже через IP-KVM (если у вас реальный сервер)
3. Если перестать пытаться подключиться к серверу, через 10 минут он снова вас пустит (по умолчанию блокировка ssh производится на 10 минут)
4. После того, как вам всё-таки удалось подключиться к серверу, вы увидели в файле /var/log/fail2ban.log строчки вида:

2016-04-29 02:16:20,039 fail2ban.actions: WARNING [ssh] Ban 185.103.252.14
2016-04-29 02:26:20,825 fail2ban.actions: WARNING [ssh] Unban 185.103.252.14

где вместо 185.103.252.14 указан ваш IP-адрес.
5. После успешного подключения к серверу, вы обнаружили в файле /var/log/auth.log сообщения об ошибках, связанные с вашим IP-адресом. (Кстати, быстрее всего свой ip-адрес можно узнать, открыв internet.yandex.ru)

Что может послужить причиной бана

Fail2Ban работает просто — он сканирует лог-файлы соответствующих программ, например сервера sshd, и при наличии там «подозрительной активности» блокирует ip-адрес на определённое время с помощью iptables.

Следовательно, причины блокировки нужно искать в правилах fail2ban и в лог-файлах.

В нашем случае, это файл настроек /etc/fail2ban/filters.d/sshd.conf и лог-файл /var/log/auth.log.

В файле настроек нас интересует блок failregex:

failregex = ^%(__prefix_line)s(?:error: PAM: )?[aA]uthentication (?:failure|error) for .* from <HOST>( via \S+)?\s*$
            ^%(__prefix_line)s(?:error: PAM: )?User not known to the underlying authentication module for .* from <HOST>\s*$
            ^%(__prefix_line)sFailed \S+ for .*? from <HOST>(?: port \d*)?(?: ssh\d*)?(: (ruser .*|(\S+ ID \S+ \(serial \d+\) CA )?\S+ %(__md5hex)s(, client user ".*",$
            ^%(__prefix_line)sROOT LOGIN REFUSED.* FROM <HOST>\s*$
            ^%(__prefix_line)s[iI](?:llegal|nvalid) user .* from <HOST>\s*$
            ^%(__prefix_line)sUser .+ from <HOST> not allowed because not listed in AllowUsers\s*$
            ^%(__prefix_line)sUser .+ from <HOST> not allowed because listed in DenyUsers\s*$
            ^%(__prefix_line)sUser .+ from <HOST> not allowed because not in any group\s*$
            ^%(__prefix_line)srefused connect from \S+ \(<HOST>\)\s*$
            ^%(__prefix_line)sReceived disconnect from <HOST>: 3: \S+: Auth fail$
            ^%(__prefix_line)sUser .+ from <HOST> not allowed because a group is listed in DenyGroups\s*$
            ^%(__prefix_line)sAddress <HOST> .* POSSIBLE BREAK-IN ATTEMPT!*\s*$
            ^%(__prefix_line)sUser .+ from <HOST> not allowed because none of user's groups are listed in AllowGroups\s*$

В нём собраны регулярные выражения, с которыми сопоставляется содержимое файла /var/log/auth.log, и при слишком частых совпадениях, «автор» таких запросов вносится в список блокировки iptables.

Из этого списка регулярок наиболее интересная вот эта: ^%(__prefix_line)sAddress .* POSSIBLE BREAK-IN ATTEMPT!*\s*$, потому что похожие на неё сообщения попадают в /var/log/auth.log при проблемах с обратным DNS-резолвом IP-адресом подключающегося.

Например, в моём случае, в /var/log/auth.log были похожие записи:

Address 146.31.49.212 maps to z-internet.146.31.49.212.msk.rt.ru, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!

В этой записи нет ничего страшного, она лишь означает, что IP-адресу клиента (то есть меня) 146.31.49.212 соответствует доменное имя z-internet.146.31.49.212.msk.rt.ru, однако, этому доменному имени мой IP-адрес не соответствует. То есть не удалось произвести «обратный DNS-резолв«. Эту ситуацию ssh воспринимает ка опасную, однако, она является нормальной, если у вас «Серый» IP-адрес.

Способы решения проблемы

1. Изменить фильтр fail2ban. Для этого нужно удалить вышеуказанную строчку с регулярным выражением из файла /etc/fail2ban/filter.d/sshd.conf. После этого нужно перезапустить демон fail2ban командой /etc/init.d/fail2ban restart
2. Отключить обратные DNS-запросы в ssh, для этого нужно открыть настройки сервера ssh (файл /etc/ssh/sshd_config) и добавить туда директивы

UseDNS no
GSSAPIAuthentication no

в конец файла. После этого нужно перезапустить ssh-сервер: /etc/init.d/sshd restart
3. Получить у провайдера белый IP-адрес, что конечно не бесплатно.

Оставить комментарий