Fail2ban настройка для ssh apache

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

Для защиты от такого подбора пароля (такую атаку часто называют брутфорсом - см. Полный перебор) есть удачное и изящное решение - fail2ban. Этот пакет есть в репозиториях, и базовая установка очень проста:

sudo apt-get install fail2ban

В состоянии сразу после установки (во всяком случае, в 10.04) защита от брутфорса по SSH включена.

Основная идея - при превышении заданного числа неудачных вводов пароля подряд (по умолчанию - 6) бан IP, с которого были попытки подбора на заданное время (по умолчанию - 600 секунд).

Параметры можно посмотреть и поменять в файле /etc/fail2ban/jail.conf. Существующие фильтры (т.е. правила, по которым определяется неудачная попытка ввода пароля) лежат в директории /etc/fail2ban/filter.d/ (можно их править или на их основе делать свои фильтры), а существующие правила реагирования - в директории/etc/fail2ban/action.d/

заглянем-ка в файл протокола ошибок apache (/var/log/httpd/error_log):

[Sat Jan 31 12:05:49 2009] [error] [client 89.18.176.83] File does not exist: /var/www/html/bin[Sat Jan 31 12:05:50 2009] [error] [client 89.18.176.83] File does not exist: /var/www/html/mail[Sat Jan 31 12:05:52 2009] [error] [client 89.18.176.83] File does not exist: /var/www/html/webmail[Sat Jan 31 12:05:53 2009] [error] [client 89.18.176.83] File does not exist: /var/www/html/roundcube[Sat Jan 31 12:05:58 2009] [error] [client 89.18.176.83] File does not exist: /var/www/html/rc

Насколько я понимаю, данные строки лога показывают, что «некто» пытается найти в моем сервере «нечто». Не знаю, можете называть это паранойей, но мне это очень не нравится! А вдруг найдет? Или вот еще, к примеру, строка из лога:

[Mon Jan 26 22:19:46 2009] [error] [client 213.21.37.175] script '/var/www/html/azenv.php' not found or unable to stat

Может это самый лучший и самый полезный в мире скрипт, а может быть и нет. Как по мне, так лучше не надо!

Итак, решено — будем защищаться. fail2ban у меня уже установлен — ssh защищает. Но это далеко не единственная возможность программы. Просто по умолчанию сразу после установки в ней включен единственный фильтр — sshd.conf. Вернемся к сути программы fail2ban. Она постоянно анализирует файлы протоколов работы служб компьютера, пытаясь найти в них сообщения об ошибках, соответствующие установленным шаблонам. Если условие совпадает, программа выполняет указанное действие. Условия-шаблоны прописываются в файлах фильтров, расположенных в папке /etc/fail2ban/filter.d. Возможные действия представлены файлами, находящимися в папке /etc/fail2ban/action.d. Управление «включением» и «выключением» фильтров, а также выбор последующих «действий» осуществляется в файле настроек /etc/fail2ban/jail.conf. Борьбу за безопасность apache я начал с поиска подходящего фильтра в папке /etc/fail2ban/filter.d. На первый взгляд мне подошел файл фильтра apache-noscript.conf. Его я поначалу и задействовал (об этом ниже). Однако, впоследствии, сопоставляя файл протокола ошибок apache и файл протокола работы fail2ban, я заметил, что далеко не все сообщения об ошибках приводят к бану вызвавших их посетителей. Утверждать, что программа не работает, было бы неправдой — на часть ошибок она все-таки реагировала. Следовательно, «что-то не то» с шаблонами. Отличным подспорьем в «разборках» с шаблонами является программа fail2ban-regex, устанавливаемая на компьютер вместе с fail2ban. Программа позволяет проанализировать указанный лог (или просто текстовую строку) на предмет нахождения соответствий шаблону из файла фильтра (или просто текстовой строке). Именно этим я и занялся. Взял лог, взял фильтр и «скормил» их програмке — ввел в консоли команду:

fail2ban-regex /var/log/httpd/error_log apache-noscript.conf

Первый ответ, о том, что найдено аж 10 совпадений меня очень развеселил.  »Невооруженным глазом» было видно, что в логе их гораздо больше… И начал я подбирать шаблон, попутно проверяя его эффективность все той же приведенной выше командой. Число совпадений росло, сначала три сотни, потом больше тысячи, финальный результат был равен 1706. Я решил, что пока хватит, а дальше посмотрим. Теперь о произведенных мной изменениях. Изначально в файле фильтра apache-noscript.conf строка шаблона сообщения об ошибке выглядела так:

failregex = [[]client []] (File does not exist|script not found or unable to stat): .*(\.php|\.asp|\.exe|\.pl)

Результат, который в конце концов устроил лично меня, выглядит так:

failregex = [[]client []] (File does not exist|Invalid URI in request|.* not found or unable to stat)

В чем суть моих изменений? Во первых, оригинальная строка шаблона предполагает, что в логе сообщение об ошибке должно содержать что-либо из «.php», «.asp», «.exe» или «.pl». Если же в строке такого нет, шаблон не срабатывает. Но даже в той «нарезке» лога apache, что я привел выше мы видим, что нет там никаких «.php», «.asp», «.exe» или «.pl». Следовательно фильтр не сработает. По этому, окончание шаблона — (\.php|\.asp|\.exe|\.pl) — я попросту выкинул.

Ну и во вторых, та часть шаблона, которая вылавливает неправильные скрипты. В оригинале она хочет, чтобы в логе был такой текст «script not found or unable to stat» (одним непрерывным куском!!!). Но, посмотрев в свои логи я увидел, что зачастую там текст отформатирован иначе, например так: «script ‘/var/www/html/pt.php’ not found or unable to stat». Следовательно этот фильтр тоже не срабатывал бы. Пришлось его заменить на «.* not found or unable to stat«. В данном случае «.*» обозначает «любой текст». После этого фильтр начал срабатывать на сообщения об ошибках о запуске несуществующих скриптов.

Кстати, дополнительно почитать о «регулярных выражениях» или попросту говоря, шаблонах, можно по ссылке:

http://www.amk.ca/python/howto/regex/regex.html

Ну и вкратце о том, как я подключал фильтр. В файле настроек /etc/fail2ban/jail.conf я нашел раздел:

[apache-shorewall]enabled  = falsefilter   = apache-noscriptaction   = shorewall           sendmail[name=Postfix, dest=you@mail.com]logpath  = /var/log/apache2/error_log

И изменил его следующим образом:

[apache-shorewall]enabled  = truefilter   = apache-noscriptaction   = shorewall           mail-whois[name=Apache, dest=dmitry@my-svr]logpath  = /var/log/httpd/error_logmaxretry = 2

Таким образом я:

• включил (enabled = true)…
• выбранный фильтр (filter = apache-noscript)…
• на анализ файла протокола (logpath = /var/log/httpd/error_log)…
• и при возникновении 2 ошибок (maxretry = 2)…
• доступ блокируется при помощи файервола (action = shorewall).

Вот и все…

P.S.

Не вышло «все», однако… 21 марта с одного IP такой «вал валил», что я решил предпринять что-то. И нашел еще один фильтр — apache-overflows.conf, который вроде как очень подходил моим потребностям. Судите сами, вот кусок лога apache:

[Sat Mar 21 17:19:35 2009] [error] [client 221.223.93.132] Invalid method in request \xf0\xaf\xa0_\x98\x1b\x9fi\xe2\x84\xca\xc8\xca\xfa\xabA\xb4f\xe0+\xf3\x96>S\x90\x90\xc1D\x80\xc2\x11\xe17\xcc\x91\x97[Sat Mar 21 17:20:04 2009] [error] [client 221.223.93.132] Invalid URI in request \xfb%\xd2\ba\xf5\x84\x9c'\x0c\xbc\xf4|\xffu\x10?\xf2\x96\xee\xda\x9d\xe9\x9f\xb0\x15\xc9\xe9nd[Sat Mar 21 17:20:43 2009] [error] [client 221.223.93.132] request failed: error reading the headers

А вот (но, правда, уже немножко подкорректированный мной) фильтр:

# Notes.:  Regexp to catch Apache overflow attempts.# Values:  TEXT#failregex = [[]client []] (Invalid method in request|Invalid URI in request|request failed: URI too long|request failed: error reading the headers|erroneous characters after protocol string).*# Option:  ignoreregex# Notes.:  regex to ignore. If this regex matches, the line is ignored.# Values:  TEXT#ignoreregex =

Пришлось и его включать. С поправкой на тот факт, что мне показалось, что это была именно атака, рубить доступ я решил с первой же попытки. Для этого в файл /etc/fail2ban/jail.conf я добавил следующие строки:

[apache-overflow]enabled	= truefilter	= apache-overflowsaction	= shorewalllogpath	= /var/log/httpd/error_logmaxretry = 1

После этого перезапустил fail2ban командой:

fail2ban-client reload

И вот теперь сижу и жду новых поводов для добавления новых фильтров…

я описал пару фильтров, используемых мной для предотвращения «вражеских» происков, направленных против моего apache. Работало все это отлично, и вопросов не возникало. И дальше бы работало, если бы меня не потянуло на разборки с Chillispot. Дело в том, что в описанных мной конфигурациях fail2ban блокирование нежелательного доступа осуществляется при помощи shorewall. А его-то я как раз и поломал, ковыряясь с Chillispot. Точнее, не поломал, а отключил, так как для работы Chillispot требуется загрузка своего собственого скрипта с правилами дляiptables, который «множит на ноль» всю работу shorewall…

Чтож, iptables, так iptables. Нам-то какая разница!? Нужно всего-лишь заставить fail2ban тоже использовать iptables при блокировании доступа. Для этого залез я в файл /etc/fail2ban/jail.conf и настройки «тюрем» своих поисправлял следующим образом:

[apache-shorewall]enabled  = truefilter   = apache-noscriptaction = iptables[name=httpd, port=http, protocol=tcp]logpath  = /var/log/httpd/error_logmaxretry = 2

И второй «тюрьме» тоже:

[apache-overflow]enabled	= truefilter	= apache-overflowsaction = iptables[name=httpd, port=http, protocol=tcp]logpath	= /var/log/httpd/error_logmaxretry = 1

Изменения по сравнению с предыдущим вариантом, описанным мной ранее, для наглядности я выделил красным цветом. Также, если сравнить с предыдущими вариантами, я не стал писать строку со вторым «действием» (action) — отправку письма администратору (mail-whois или sendmail). Ему (мне) и так писем достаточно… Названия самих «тюрем» (те, что в указанных примерах написаны в квадратных скобках) я менять не стал. Они все равно ни на что не влияют, только лишь в лог пишутся.

После внесения указанных изменений перезапустил fail2ban командой:

fail2ban-client reload

И все! Кстати, есть еще одно отличие у данного варианта блокирования по сравнению с shorewall, описанным ранее: iptables блокирует только портapache…

Настройка Fail2ban на Debian

Fail2ban - отслеживает IP адреса с которых производились неудачные повторяющиеся попытки получить доступ по какому-либо из сервисов (SSH, FTP, SMTP, Apache) сервера в файлах журналов.

Установка

из под root`а выполним:

После установки Вы можете настроить fail2ban с помощью этих двух файлов, расположенных в /etc/fail2ban/

Откроем jail.conf, что бы включить отслеживание сервисов.

Теперь можем включить или выключить нужные сервисы.

По умолчанию отслеживание SSH включено.

Если Вы хотите добавить отслеживание Apache измените:

на:

Для FTP (proftpd)

изменим на

Другие настройки

• ignoreip - это разделенный пробелами список ip-адресов, которые не могут быть блокированы fail2ban. Сюда можно занести свою локальную машину или комьютер, с которого будут проводится эксперименты над системой
• bantime - время в секунда, на которое блокируется хост.
• maxretry - максимальное число ошибочных попыток доступа к сервису, прежде чем хост будет заблокирован fail2ban.
• filter - имя соответствующего файла-фильтра в /etc/fail2ban/filter.d, без конечного .conf
• action - имя соответствующего файла-реакции на срабатывание фильтра в /etc/fail2ban/action.d
• logpath - файл логов, мониторинг которого осуществляет fail2ban, для проверки попыток атак.
• enabled - может принимать значение true или false. Включено,выключено правило.

Поставив, достаточно простое средство, fail2ban вы увидите значительное сокращение log-файлов.