Что такое fail2ban server
Настройка и использование Fail2ban на Linux
Описывая Fail2ban в двух словах, можно сказать, что он позволяет на основе анализа логов блокировать тех, кто злоупотребляет доступностью сервера по сети. Например, защитить почтовые ящики от взлома путем перебора паролей или многократного запроса какого-либо ресурса.
Читая некоторые статьи в интернете, может сложиться неправильное мнение, что Fail2ban нужен только для защиты от брут-форс атак (перебор паролей). На самом деле, данный программный продукт — система реагирования на подозрительные действия.
Установка и запуск
Для систем на базе пакетов Debian или Red Hat команды будут немного отличаться.
CentOS / Red Hat:
yum install fail2ban
Ubuntu / Debian:
apt-get install fail2ban
CentOS 6:
yum install fail2ban
Для запуска службы вводим следующие команды:
systemctl enable fail2ban
systemctl start fail2ban
* Для старых систем без systemd это будут команды chkconfig fail2ban on / update-rc.d fail2ban defaults и service fail2ban start.
Базовая настройка
Процесс настройки fail2ban не зависит от дистрибутива Linux. Основной конфигурационный файл находится по пути /etc/fail2ban/jail.conf. Однако, его не рекомендуется менять и для настройки используют подключаемые файлы из каталога /etc/fail2ban/jail.d.
Для начала создаем первый файл, в котором будут храниться настройки по умолчанию:
Приведем его к виду. Настройка будет немного отличаться в зависимости от операционной системы.
а) для CentOS / Red Hat:
[DEFAULT]
maxretry = 4
findtime = 480
bantime = 720
action = firewallcmd-ipset
ignoreip = 127.0.0.1/8
б) для Ubuntu / Debian:
[DEFAULT]
maxretry = 4
findtime = 480
bantime = 720
action = iptables
ignoreip = 127.0.0.1/8
* В данном примере, если в течение 8 минут (480) будет найдено 5 строк (maxretry = 4), содержащих критерий фильтра, Fail2ban заблокирует IP-адрес, с которого идет подключение на 12 минут (720);
* В секции [DEFAULT] хранятся общие настройки для всех правил. Каждую из настроек можно переопределить при конфигурировании самого правила.
Настройка правил
Для нового правила необходимо создать конфигурационный файл в каталоге /etc/fail2ban/jail.d, например:
[ssh]
enabled = true
port = ssh
filter = sshd
action = iptables[name=sshd, port=ssh, protocol=tcp]
logpath = /var/log/auth.log
maxretry = 10
findtime = 600
* обратите внимание, что мы переопределили параметры по умолчанию maxretry, findtime и action.
Чтобы изменения вступили в силу, перезапускаем сервис:
systemctl restart fail2ban
* в старых версиях service fail2ban restart.
Исключения
Для гарантии, что fail2ban не заблокирут компьютер администратора или другой важный узел, предусмотрена настройка исключений с помощью опции ignoreip. Опция может быть применена как на глобальном уровне (default), так и для конкретного правила.
Для того, чтобы задать общую настроку, откроем наш файл default:
[DEFAULT]
.
ignoreip = 192.168.0.0/24 95.95.95.95
* в данном примере под фильтры не будут попадать адреса с 192.168.0.1 по 192.168.0.255 и адрес 95.95.95.95.
Для конкретного правили настройки будут, примерно, следующие:
[ssh]
.
ignoreip = 192.168.1.22
* в данном примере мы добавили в белый список один адрес 192.168.1.22, который не будет блокироваться.
Обязательно перезагружаемся, чтобы настройки применились:
systemctl restart fail2ban
* добавление адреса в белый список не удаляет его из блокировки. Поэтому, если IP попал в блок, нужно будет его удалить вручную.
Действия и фильтры
Действия
Файлы с настройкой действий находятся в каталоге /etc/fail2ban/action.d. Чтобы блокировать адрес, Fail2ban создает правило в брандмауэре netfilter. Для этого, чаще всего, используются утилиты iptables или firewall-cmd. Последняя применяется в последних версиях CentOS / Red Hat / Fedora. iptables более универсальная и может использоваться, почти, во всех системах Linux.
Остановимся на описании самых используемых действий:
Подробнее, как создаются правила в netfilter при помощи iptables и firewalld.
Фильтры
Фильтры, в основном, представляют набор регулярных выражений для поиска ключевых слов в log-файлах. Они находятся в каталоге /etc/fail2ban/filter.d.
Для создания и настройки своих фильтров, можно использовать имеющиеся файлы в качестве шпаргалки.
Примеры правил
В данных примерах блокировка IP-адреса будет происходить на 12 минут после 4-х попыток ввода пароля в течение 8 минут. Эти параметры берутся из настроек [DEFAULT]. Если их нужно переопределить, просто добавляем их при описании правила.
CentOS
[ssh]
enabled = true
port = ssh
filter = sshd
action = firewallcmd-new[name=sshd]
logpath = /var/log/secure
Ubuntu
[ssh]
enabled = true
port = ssh
filter = sshd
action = iptables[name=sshd]
logpath = /var/log/auth.log
Asterisk
[asterisk]
enabled = true
filter = asterisk
action = iptables-allports[name=asterisk, protocol=all]
logpath = /var/log/asterisk/messages
NGINX
[nginx]
enabled = true
port = http,https
filter = nginx-http-auth
action = iptables-multiport[name=nginx, port=»http,https», protocol=tcp]
logpath = /var/log/nginx/error.log
NGINX DDoS (req limit)
Данное правило поможет защитить веб-сервер nginx от DDoS-атак. В некоторых сборках, для данного правило может не оказаться готового фильтра, поэтому в данном примере, мы его создадим вручную.
Для начала, необходимо настроить NGINX:
В раздел http добавим:
* данная настройка создает зону с интенсивностью запросов в 1 запрос в секунду.
server <
.
location / <
.
limit_req zone=one burst=5 nodelay;
.
* данная настройка вместе с предыдущей зоной, созданной в секции http, позволит лимитировать запросы — 1 запрос в секунду при всплеске 5 запросов.
Проверяем конфигурационный файл nginx и перезапускаем сервис:
systemctl reload nginx
В лог-файле (по умолчанию /var/log/nginx/error.log) при превышении лимита подключения мы должны увидеть запись на подобие:
2020/11/16 19:11:08 [error] 1330844#1330844: *16640836 limiting requests, excess: 10.520 by zone «one», client: xxx.xxx.xxx.xxx, server: dmosk.ru, request: «GET / HTTP/1.1», host: «dmosk.ru», referrer: «https://dmosk.ru/page1»
* обратите внимание, что в вашем случае путь до лога может быть другой. Он определяется в конфигурационном файле NGINX.
Теперь можно приступать к настройке fail2ban. Создаем фильтр:
[Definition]
ngx_limit_req_zones = [^»]+
failregex = ^\s*\[error\] \d+#\d+: \*\d+ limiting requests, excess: [\d\.]+ by zone «(?:%(ngx_limit_req_zones)s)», client:
ignoreregex =
* данный файл может быть уже создан и настроен при установке fail2ban. Если это так, то ничего не меняем и идем дальше.
Создаем правило в fail2ban:
[nginx-ddos]
enabled = true
port = http,https
filter = nginx-limit-req
action = iptables-multiport[name=nginxddos, port=»http,https», protocol=tcp]
logpath = /var/log/nginx/error.log
* еще раз обращаю внимание на путь logpath — в вашем случае он может быть другим.
После настройки не забываем перезапустить fail2ban:
systemctl restart fail2ban
Работа со списком заблокированных адресов
Просмотр
Получить статистику заблокированных адресов можно следующей командой:
Получить список правил можно командой:
При наличие заблокированных IP-адресов мы увидим, примерно, следующее:
`- action
|- Currently banned: 2
| `- IP list: 31.207.47.55 10.212.245.29
С помощью iptables:
С помощью firewall-cmd:
Удаление
Средствами fail2ban:
Для удаление адреса из списка вводим:
fail2ban-client set unbanip
fail2ban-client set ssh unbanip 31.207.47.55
С помощью iptables:
С помощью firewall-cmd:
После необходимо перечитать правила:
Аналоги
Если быть честным, достойных аналогов нет. Вот что-то похожее:
Защита сервера средством утилиты Fail2ban. Как ее настроить?
Оглавление
Принцип работы
Fail2ban отслеживает файлы журналов (например, /var/log/auth.log, /var/log/apache/access.log), временно или постоянно запрещая подозрительную активность IP-адреса путем обновления существующих правил брандмауэра. Fail2ban позволяет автоматически выполнить различные действия, такие как заблокировать IP, используя правила iptables, или просто отправить уведомление по электронной почте администратору сервера. По умолчанию Fail2ban поставляется с правилами фильтра под различные сервисы (sshd, apache, mysql proftpd, и т. д.), но конфигурация может быть легко расширена для мониторинга любой другой службы. Все фильтры и действия настраиваются в файлах конфигурации, таким образом Fail2ban является отличным гибким инструментом для предотвращения взлома вашего сервера.
Установка Fail2ban
Для установки на Debian\Ubuntu выполните следующее:
Структура конфигурационных файлов
Файлы настроек находятся в каталоге /etc/fail2ban/. Для понимания работы утилиты, рассмотрим их более детально:
jail.conf — дефолтные настройки сервисов;
Файлы paths-arch.conf, paths-common.conf, paths-debian.conf и paths-opensuse.conf хранят в себе настройки путей для различных операционных систем семейства Linux.
Первоначальная настройка Fail2ban
Главный конфигурационный файл находится по адресу /etc/fail2ban/jail.conf, однако настоятельно не рекомендуется сразу вносить в него правки, сначала скопируем его под именем jail.local. Настройку продолжим непосредственно в этом файле, это предусмотрено разработчиками, все что вы сконфигурируете в jail.local будет автоматически перезаписывать настройки в jail.conf:
Первым делом в конфигурационный файл необходимо внести ваш IP адрес, чтобы правила Fail2ban на него не распространялись, иначе после запуска службы вы рискуете внести себя в бан и доступ к серверу будет утерян:
Необходимо найти и раскоментировать строку #ignoreip, добавив через пробел свой внешний статический IP адрес. В результате у вас должно получиться следующее:
Здесь же, в секции [DEFAULT] можно задать значения findtime и maxretry, например:
Параметры findtime и maxretry определяют условия, при которых будут блокироваться вредоносные пользователи. Maxretry определяет количество попыток входа, а findtime – интервал времени, в течение которого пользователь должен пройти аутентификацию. Если клиент превысил любой из этих показателей, он будет заблокирован. Bantime определяет длительность блокировки в секундах. Эти параметры в статье будут встречаться неоднократно. Если в настройке какого либо из сервисов вы их не зададите, они будут автоматически браться с секции [DEFAULT].
Не забывайте перезапускать Fail2ban после каждого редактирования конфигурационного файла.
Важно! Путь к файлу хранения логов (logpath) обязан быть указан правильно, иначе перезапуск Fail2ban завершится ошибкой. В случае отсутствия лог-файла по указанному пути, его можно создать командой touch, например:
Теперь мы можем перейти к редактированию общих правил защиты сервисов.
Защита сервиса sshd с помощью Fail2ban
Первым делом очистим наш дефолный конфигурационный файл:
В каталоге jail.d/*.*, отвечающим за настройку сервисов, создадим файл sshd.conf и добавим в него следующие строки:
Чтобы применить изменения перезапустим сервис и внесем его в автозагрузку:
Рассмотрим детально наши действия. Мы их будем выполнять неоднократно для настройки других защищаемых сервисов:
[sshd] # обозначение конфигурируемого сервиса, в данном случае sshd
enabled = true # правило разрешающее мониторинг сервиса.
port: 2102 # Если вы для службы ssh используете стандартный порт 22, эту строку можно не указывать, однако, если вы используете нестандартный порт для подключения настраиваемого сервиса, в нашем примере это 2102, его обязательно необходимо указать.
bantime = 900 # время в секундах, на которое нарушитель будет заблокирован
findtime = 300 # время обнаружения
maxretry = 3 # допустимое количество ошибок аутентификации. На четвертой попытке нарушитель будет заблокирован.
Как это работает: Нарушитель с IP-адресом 123.123.12.13 пытается подобрать пароль к учетной записи на вашем сервере. Параметр findtime задает время, на которое ip адрес попадает под мониторинг от первого момента, когда он начинает фигурировать в логах /var/log/auth.log. Если в течении 300 секунд (5 минут), у нарушителя будет более чем три ошибки аутентификации, он будет заблокирован на 900 секунд (15 минут).
Проверить состояние правила можно командой:
Мы увидим следующее:
Защита NGINX
a) Фильтр аутентификации
Допустим, на ваших сайтах есть разделы требующие аутентификации. Выполнить базовую защиту этих разделов от подбора паролей так же поможет Fail2ban. По умолчанию, защита NGINX доступна из коробки, однако её необходимо активировать. Для этого, в конфигурационном файле /etc/fail2ban/jail.conf находим блок [nginx-http-auth], где изначально указан только logpath. Добавляем в него значения:
на выходе у нас должно получиться следующее:
Обратите внимание на то, как указаны пути к логам. Начиная с версии Fail2ban 0.9.х, писать полные пути не обязательно. Если расположение логов защищаемого сервиса стандартное, то пути к ним предусмотрены разработчиками. Значение %(nginx_error_log)s будет равнозначно пути /var/log/nginx/error. log. Вы можете использовать оба варианта.
Теперь создадим файл nginx-http-auth.conf
В который вносим следующие значения, которые являются фильтрами для корректной работы правила:
б) Фильтр доступа к скриптам
Fail2ban является довольно гибки и функциональным инструментом. Если необходимого инструмента в jail.conf нет, опытный администратор может его написать сам. Например, мы хотим заблокировать ip адрес, который обращается к файлам с расширениями php, asp, exe, pl, cgi, scgi. Это очень полезный фильтр для обнаружения всякого рода эксплойтов.
Внимание! Будьте внимательны при использовании этого фильтра. Оно имеет смысл если у вас статический сайт, или вы четко уверены, к выполнению каких скриптов необходимо применить фильтрацию. Если сайт разрабатывали не вы, обратитесь за консультацией к разработчику
Для начала отредактируем главный конфигурационный файл:
В него необходимо добавить секцию [nginx-noscript], которая по умолчанию не существует:
Теперь создадим файл фильтра, к которому будет отсылаться наше правило при анализе access.log web-сервера:
Вносим в него следующее:
Изменения вступят в силу после перезагрузки сервиса Fail2ban
в) Фильтр сканеров
Сами по себе сканеры не несут какой либо угрозы сайту, однако сканирование вашего сайта может быть тем самым звоночком, что злоумышленник ищет его уязвимые места. Определить сканеры легко по всплеску ошибок 403 и 404 в /var/log/nginx/access.log. Итак, приступим:
Добавляем следующие блоки:
Создаем правило фильтрации для ошибок 403:
Создаем правило фильтрации для ошибок 404:
И хакеры используют это как инструмент DDoS. Они генерируют тысячи запросов в минуту к несуществующим веб-страницам, что приводит к снижению производительности web-сервера или его полной неработоспособности.
Защита APACHE
В файле /etc/fail2ban/jail.local так же предусмотрена защита web-сервера Apache. Настройка аналогична настройке web-сервера NGINX, который мы рассмотрели в предыдущем разделе. Пройдемся кратко, по основным доступным фильтрам и за что они отвечают:
Каждое из правил активируется добавлением в блок строки enabled = true. Так же, в каждом блоке вы можете задать правила bantime, findtime и maxretry, которые рассмотрены выше.
Для примера, создадим несколько правил обнаружения:
Если вы используете Apache с PHP, вам может понадобиться раздел [php-url-fopen]
Защита Dovecot
Полезным будет поставить защиту от подбора паролей на почтовые ящики, если Вы используете этот популярный IMAP\POP3-сервер. Добавим секцию для фильтра в главный конфигурационный файл:
Защита FTP сервера
Выставить защиту вашего FTP сервера так же не трудно. Однако, перед настройкой вы должны учесть, какой из FTP вы используте (vsFTPd, proFTPd, Pure-FTPd etc), настройки могут отличаться. Например, если вы используете Pure-FTPd, добавим секцию для фильтра в главный конфигурационный файл:
Защита ISPmanager
Добавим секцию для фильтра в главный конфигурационный файл:
Защита WordPress
Рассмотрим защиту популярного движка WordPress от подбора паролей. Добавим секцию для фильтра в главный конфигурационный файл:
Управление fail2ban
Перезапуск и проверка состояния Fail2ban:
Полный список правил:
Проверка срабатывания правила:
Проверить работу служб:
Показать состояние указанного jail:
Допустим, произошла ошибка, и ip адрес 123.123.12.13 не является нарушителем и нам его необходимо разблокировать:
Если необходимо добавить разрешение для данного ip адреса выполните:
Удалить ip адрес из доверенных:
Для просмотра списка всех доверенных адресов:
В эту строку вы можете через пробел добавить как несколько IP адресов, так и целые подсети, например 172.16.1.0/24
Заключение.
В данной статье мы рассмотрели популярную утилиту Fail2ban, которая существенно может повысить безопасность вашего сервера. Утилита гибкая в настройке. Мы рассмотрели основные правила обнаружения для ssh, ftp, nginx и apache, которые будут актуальны ввиду того, что используются повсеместно. Рассмотреть же все возможности Fail2ban в рамках одной статьи крайне сложно, все зависит от поставленных перед вами задач и используемых сервисов. Однако логика создания правил прозрачно просматривается.
Если Вы планируете купить выделенный сервер или арендовать VPS в нашей компании, наша техническая поддержка поможет обеспечить бесперебойную работу сервера и проконсультирует Вас о принципах организации безопасности на Вашем сервере.
Fail2ban [incremental]: Лучше, быстрее, надежнее
Про fail2ban написано уже много, в том числе и на хабре. Эта статья немного о другом — как сделать защиту им еще надежнее и о еще пока неизвестных в широких кругах новых функциях fail2ban. Добавлю сразу — речь пойдет пока про development branch, хотя уже долго проверенный в бою.
Краткое вступление
В большинстве своем fail2ban устанавливается из дистрибутива (как правило это какая-нибудь стабильная старая версия) и настраивается по манам из интернета за несколько минут. Затем годами работает, без вмешательства админа. Нередко даже логи, за которыми вроде как следит fail2ban, не просматриваются.
Так вот, сподвигнуть на написание этого поста меня заставил случай, произошедший с одним сервером моего хорошего знакомого. Классика жанра — пришла абуза, за ней вторая и пошло поехало. Хорошо еще злоумышленник попался ленивый — логи не потер, да и повезло еще крупно, что logrotate был настроен, чтобы хранить логи месяцами.
Оказалось все довольно банально, подобрали пароль к его админской почте, который по совместительству был паролем для ssh (естественно без ключа). Не рут, но судоер, со всеми вытекающими. Первый его вопрос был: как подобрали — у меня же fail2ban там. И вот здесь как раз засада: не все представляют себе, что подбором паролей сегодня занимаются уже не отдельные компьютеры, а целые бот-сети, кстати поумневшие донельзя. Так вот по логам выяснили, что тут как раз такой случай: перебирала бот-сеть, причем на практике выяснившая его настройки в fail2ban (maxRetry=5, findTime=600 и banTime=600). Т.е. чтобы избежать бана, сеть делала 4 попытки в течении 10 минут с каждого IP. На минуточку в сети порядка 10 тысяч уникальных IP = что-то более 5 с половиной миллионов паролей в сутки.
Кроме того его почтовик делал большую глупость — а именно паузу до 10 секунд, при логине с неправильным именем. Т.е. выяснить, что некоторые имена, в том числе admin, реально имеются, этой сетке не составило труда. Далее шел целенаправленный перебор только паролей для имеющихся имен.
Подробнее на «ремонте» останавливаться не буду — это история долгая, и вообще тема для отдельной статьи. Скажу только, что все почистили и все разрешилось малой кровью, да и отделался он практически «легким» испугом.
Так вот, мысль написать статью возникла после того, как мне (частично заслужено) было высказано: «Так ты про такое знал и ничего не сказал, не предупредил. Да еще и решение есть и не поделился. Ну и сволочь ты». Короче, посему посту — быть.
Мой fail2ban
К безопасности «своих» серверов я отношусь чрезвычайно серьезно. Кроме того же fail2ban, всегда кастомного донельзя, у меня там и мониторинг и еще куча всего. Меня просто реально бесит, что из-за бестолковой серой массы, позволяющей брать под контроль бот-сетей свое железо, приходится убивать уйму времени на защиту (и постоянное сопровождение и контроль ее в дальнейшем). Кстати, чтобы минимизировать этот контроль, я и участвую активно в разработке и fail2ban, да и других проектов от безопасности.
Так вот, моя последняя расширенная версия [sebres:ban-time-incr], позволяет вывести этот назойливый зоопарк раз и навсегда (ну или пока они снова не приспособятся). Это фишка довольно часто обсуждалась всем коммюнити, но как-то руки не доходили. У меня оно жило в виде отдельных скриптов и каких-то кастомных изменений, пока не оформилось в готовый функционал.
Если коротко, то система, запоминая плохие IP адреса, позволяет каждый раз динамически (экспоненциально) увеличивать время блокировки (banTime) в зависимости от количества предыдущих запретов (banCount). При этом также каждый раз уменьшая количество (maxRetry) возможных провальных попыток (failure) до следующего бана. Наглядно это можно увидеть на следующем примере:
Здесь хорошо заметно, как каждый следующий бан продлевает время блокировки от 15 минут (0:15:00) первый раз, до 5 с лишним дней (5 days, 8:04:55) после десятой блокировки. У меня в базе есть IP у которых «срок» уже — от нескольких месяцев до перманентного бана.
Ниже можно увидеть, как новый функционал отразился на решении собственно банить IP XXX.XXX.XX.XXX. В примере параметр maxRetry установлен равным 5. Так мы видим, что пока IP не признан плохим он был первый раз забанен после 5-ти попыток, второй раз, уже как плохой — после 3-х (каждая попытка была засчитана за 2), третий и т.д. — после 2-х (попытка идет за 3) и четвертый раз забанен сразу после первой попытки (считается сразу за 5-ть):
Без этой логики подсчета failure, умные бот-сети научились подстраивать свою работу так, чтобы просто не попадать в бан. Когда я допилил таки и эту логику и выкатил в продакшн, за считанные дни я избавился практически от всей той нечисти, которую привык видеть годами в своих логах. Например, сейчас средний нормальный ежедневный прирост моих auth.log где то в районе 20-50 строк, раньше на некоторых серверах он был в сотни и тысячи раз больше.
Пока что это development branch, лежит pull request-ом, релиз запланирован пока в версии 0.9.2.
Кому интересно, почитать подробнее про реализацию и историю решения можно здесь — Ban time incr by sebres · Pull Request #716 · fail2ban/fail2ban.
Однако пока эта версия ляжет апдейтом на ваш сервер, пройдет еще немало времени — пока релиз выйдет в mainline, пока его в дистрибутивы возьмут… История длинная, например тот же debian все еще использует 0.8.x — собственно поэтому и статья. Так что качаем руками, устанавливаем… профит.
Взять эту версию можно здесь fail2ban-ban-time-incr.zip (sebres master branch).
Порт для debian-ов: ban-time-incr-debian.zip (merged master debian branch, и хоть и не main line — буду стараться по возможности поддерживать ветку актуальной).
Установить его довольно просто. Если у вас уже до того был fail2ban, установленный из дистрибутива, сохраняем из «/etc/fail2ban/» старые «fail2ban.local» и «jail.local» (Ну и лучше старые «fail2ban.conf» и «jail.conf»). Я бы на всякий случай (из-за возможных личных изменениях в filter и action) сохранил бы куда-нибудь весь каталог «/etc/fail2ban/».
Вот собственно и все, теперь надеюсь ваш сервер стал еще чуточку защищенней. Ну а вы не ленитесь и поглядывайте все-таки в логи (доверяй, но проверяй).