В прошлых моих записях с заголовком «Ну «Secure», так «secure» я защищался от попыток постороннего входа в мой «сервер» по ssh. Но, это ведь не единственный порт моего «сервера», который открыт наружу. Раз уж у меня установлен веб-сайт, то доступ к нему извне, естественно, тоже есть. И вот теперь заглянем-ка в файл протокола ошибок 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 <HOST>[]] (File does not exist|script not found or unable to stat): .*(\.php|\.asp|\.exe|\.pl)
Результат, который в конце концов устроил лично меня, выглядит так:
failregex = [[]client <HOST>[]] (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«. В данном случае «.*» обозначает «любой текст». После этого фильтр начал срабатывать на сообщения об ошибках о запуске несуществующих скриптов.
Ну и вкратце о том, как я подключал фильтр. В файле настроек /etc/fail2ban/jail.conf я нашел раздел:
[apache-shorewall]
enabled = false
filter = apache-noscript
action = shorewall
sendmail[name=Postfix, dest=you@mail.com]
logpath = /var/log/apache2/error_log
И изменил его следующим образом:
[apache-shorewall]
enabled = true
filter = apache-noscript
action = shorewall
mail-whois[name=Apache, dest=dmitry@my-svr]
logpath = /var/log/httpd/error_log
maxretry = 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 = true filter = apache-overflows action = shorewall logpath = /var/log/httpd/error_log maxretry = 1
После этого перезапустил fail2ban командой:
fail2ban-client reload
И вот теперь сижу и жду новых поводов для добавления новых фильтров…