Установка и настройка Fail2ban

Уже через несколько дней после установки сервера с смотрящим наружу ssh обычно начинаются попытки взлома. Самый распространенный способ борьбы с подбором паролей – установка на сервер fail2ban.

1. Установка Fail2ban

Fail2ban базируется на простой и понятной концепции. Она включает в себя три стадии:
1. Просмотр логов по определенным в шаблоне параметрам;
2. Проверка на основе таких критериев, как ограничение числа попыток ввода пароля;
3. Создание правила в iptables для блокировки соответствующего ip в течении периода времени

Fail2ban начинает работать сразу после установки, но необходимо произвести минимальную настройку.

2. Создание файла конфигурации

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

Все правки конфигурации мы будем производить в файле /etc/fail2ban/jail.local, этот файл будет подключен автоматически и его настройки имеют наивысший приоритет.

3. Глобальные настройки

Правила блокировки хранятся в одном файле под названием jail.conf в каталоге /etc/fail2ban

Рассмотрим, что в этом файле

Ignoreip указывает на IP – адрес , которые Fail2ban следует игнорировать. Например, Вам необходимо заходить на сервер из дома. Вы можете просто добавить свой IP или диапазон адресов, разделенные пробелом:

Bantime определяет а какой срок вы хотите блокировать атакующего. По умолчанию это 10 минут.

findtime – интервал времени в секундах, в течение которого программой будет определяться подозрительная активность.

maxretry – число попыток ввода пароля в течение findtime секунд до попадания IP-адреса в черный список.

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

Защита SSH

Файл конфигурации fail2ban имеет по умолчанию подготовленные секции для различных сервисов, поэтому защита какого-либо из них требует минимальных усилий и знаний. Итак, откроем снова файл конфигурации /etc/fail2ban/jail.local и найдём в нём секцию [sshd] (в вашей системе это может быть [ssh] или [ssh-iptables], если это так, то используйте ту секцию, которая у вас есть). Пробежимся по параметрам (в большинстве своём они не являются обязательными, и если не будут указаны, то применяются настройки по умолчанию):

• enabled – состояние (true/false) фильтра, показывающее, включен он или выключен.
• filter – какой фильтр применяется (со списком фильтров можно ознакомиться в /etc/fail2ban/filter.d/).
• action – действия, выполняемые при бане IP-адреса.
• logfile – файл с логами, которые будет отслеживать fail2ban.

Исходя из этого, конфиг, банящий IP на 12 часов, если с него в течение 10 минут было произведено 3 неудачных попытки авторизоваться, выглядит так:

Сохраните изменения (в nano это Ctrl+O) и перезапустите fail2ban для применения настроек:

5. Проверка настроек

Этот шаг не является обязательным, но всё же имеет смысл проверить, что всё работает как было задумано. Посмотреть полный список правил, которыми руководствуется программа при мониторинге активности можно с помощью команды

Также для выполнения проверки достаточно несколько раз ввести неправильный пароль при авторизации и убедиться, что дальнейшие запросы от вас не обрабатываются. Следует обратить внимание на следующее:

• желательно проверку производить не с того же IP, с которого осуществляете настройку (чтобы иметь возможность разбанить себя и отредактировать конфиг).
• для проверки время бана лучше выставить поменьше.
• необходимо убедиться, что IP, с которого производится проверка, не был указан в ignoreip.

Заключение

Мы рассмотрели использование fail2ban для защиты от перебора паролей по ssh. Точно также можно защитить FTP, web-сервер, почтовый сервер и т.п. Это спасет от многих проблем.

Защита терминального сервера от подбора пароля

• 
• 
• 
• 
• 
• 

Итак, что мы имеем:

• терминальный сервер на Windows 2008R2
• реальный IP адрес сервера
• нет возможность всех клиентов заставить работать по VPN
• события о подборе пароля в журнале безопасности.

Трудности в том, что:

• при включенной NLA (Network Level Authentication) в логах отсутствует IP адрес источника;
• в отличии от Windows Server 2012 r2 в журнале Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational есть только запись «Прослушиватель RDP-Tcp получил соединение» но нет IP адреса источника.

Вариант 1: отключить NLA (в конфигурации сервера узла удалённых рабочих столов, с свойствах подключения убрать галоску «Разрешить подключаться только с компьютеров, на которых работает удалённый рабочий стол с проверкой подлинности на уровне сети»), после чего можно будет использовать DRPDefender — но это не наш метод.

Вариант 2: При успешном подключении (код события 4624 в журнале безопасности) выполняется запись айпишника в «белый лист». На всякий случай, чтоб его случайно не заблокировать. Так как некоторые терминальные клиенты (с MacOS и Linux) при подключенном состоянии к серверу но не работы на самом терминальном сервере (т.е. работе на локальном компьютере) пытаются переподключиться к серверу, создавая события 261 из Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational , и рискуют попасть в бан.

При создании нового события с кодом 261 из Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational выполняем скрипт. Который берёт айпиадреса которые сейчас активны на порту нашего терминального сервера (net stat с фильтрами), сравнивает их с IP адресами с которых за последние 7дней были успешные подключения по RDP, если с адреса были успешные подключения — тогда не трогаем его (скрипт закрывается). Если за 7 дней с этого IP адреса небыло успешных подключений — тогда «берём его на карандаш» а точнее записываем его в отдельный файлик (отдельный файлик для каждого адреса). Если в файлике более 20 строк (было 20 попыток подключиться) тогда добавляем этот адрес в правило фаервола (виндового) и создаётся отдельное задание (само, автоматически) на разблокировку через 15 минут.

P.S. 1: Для блокировки нужно в виндовом фаерволе создать запрещающее правило с названием BlockAttackers

P.S. 2: Задание в шедуллере должно иметь право на чтение виндовых журналов. По идеи должно хватать роли «Читатели журнала событий».

P.S. 3: Задание в шедуллере должно иметь право на изменение правил фаервола. Запускаю от имени системы.

Собрал оба скрипта в один файл. вынес ключевые параметры в переменные в начале файла

Инструкция по установке:

1. создаём правило в Брандмауере с названием «BlockAttackers»:

• действие «блокировать»;
• тип протокола — любой (ну или можно указать только порт RDP подключения, настроенный в виндовой службе);
• область — Удалённый IP адрес — указанные IP-адреса — добавьте адрес к примеру 1.1.1.1 (вероятность подключения вашего сотрудника с такого IP близится к нулю);
• профиль безопасности — все.

2. создаём задание в виндовом шедуллере, выполнять от имени «система» к примеру, при возникновении события с кодом 261 в журнале Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational выполняем действие «запуск программы» powershell.exe с аргументом

3. создаём задание в виндовом шедуллере, выполнять от имени «система» к примеру, при возникновении события с кодом 4624 в журнале «безопасность» источник «Microsoft Windows security auditing.» выполняем действие «запуск программы» powershell.exe с аргументом

4. создаём задание в виндовом шедуллере, выполнять от имени «система» к примеру, по расписанию в полночь (или около того) выполняем действие «запуск программы» powershell.exe с аргументом

По итогу в папке Temp создаются файлики с айпишниками успешных и неуспешных подключений.

— Добавил ключ устаонвки

— Подправил некоторые моменты относящиеся к описанию внутри кода.

— опитимизирован процесс установки в зависимости от версии ОС.

Защита web-сервера от DDOS-атак с использованием fail2ban

Доброго времени суток!

Сегодня мы расскажем вам о том, как защитить web-сервер от DDOS-атак с использованием пакета fail2ban.

Предыстория: недавно, на веб-сервере клиента, был замечен подозрительно высокий трафик запросов. В лог-файле access.log наблюдалось следующее: (tail -f /var/log/nginx/access.log)

В логе было отчетливо видно, что производиться ddos-атака. (причины атаки неизвестны до сих пор). На web-сервере не размещены коммерческие ресурсы. Есть CRM исключительно для внутреннего использования. Открыты для доступа удаленных подразделений организации. За сутки, на данном linux сервере, почти закончилась оперативная память: из 4Gb оставалось

450Мб. Было решено временно остановить демон web-сервера Nginx. После проведенного анализа рынка существующего ПО, по защите от DDoS-атак выбор пал на софт fail2ban (спасибо за подсказку, моему другу и отличному linux-администратору — Диме Водолазову). Данный софт анализирует любой из предоставленных ему log-файлов и по определенным правилам может блокировать «подозрительные» соединения.

В Интернете есть много статей по настройке данного ПО, но мы решили написать свою, так как многие статьи, на наш взгляд, имеют не правильное описание настройки fail2ban. (p.s. софт может защищать не только web-сервер но и другие сетевые службы и сервисы).

Первым делом, мы установили официальный пакет с репозитория Ubuntu, но в процессе эксплуатации софта выяснилось, что он «из коробки» не включает в себя модуль БД sqlite3 для хранения заблокированных ip-адресов и увы, после перезапуска демона fail2ban, все заблокированные адреса благополучно очищались, а при повторном запуске софт начинал их заново блокировать и так, до следующей перезагрузки. Разумеется, такой вариант нас не устраивал. Было решено установить ПО из исходников, таким образом, убить двух зайцев:

1. установить последнюю (самую новую) версию (в репозитории была довольно-таки старая);
2. включить использование модуля БД sqlite3 для хранения уже заблокированных адресов.

Теперь перейдем к установке и настройке fail2ban:

ОС: Ubuntu server 14.04

Переходим по ссылке http://www.fail2ban.org/wiki/index.php/Downloads, копируем ссылку на файл stable (на момент написания статьи актуальная версия 0.9.4) и скачиваем ее на сервер через wget:

Далее распаковываем скачанный архив:

И переходим в директорию с ПО:

после установки переходим в каталог files

и копируем init-файл для управления демоном fail2ban. В нашем случае, пойдет файл debain-initd, его нужно скопировать в директорию /etc/init.d/ под другим, более понятным названием, скажем: fail2ban:

Затем прописываем исполняемому файлу необходимые права и добавляем в автозагрузку:

На данном этапе установка закончена. Далее будем конфигурировать установленный софт:

Для начала, необходимо настроить хранение заблокированных ip-адресов в файле БД: сначала проверяем, подключен ли модуль БД, для этого, достаточно удостовериться в наличии строки dbfile = /var/lib/fail2ban/fail2ban.sqlite3 в файле /etc/fail2ban/fail2ban.conf

sudo nano /etc/fail2ban/fail2ban.conf

Затем,в самом низу находим параметр dbpurgeage = он отвечает за срок хранения записи в БД (в секундах), устанавливаем свое (на свое усмотрение) мы указали 1 год:

За основную настройку отвечает файл jail.conf он хранит в себе информацию, о так называемых фильтрах, которые мы будем применять для защиты сервера. Открываем файл /etc/fail2ban/jail.conf для редактирования и добавляем в самом конце следующие строки:

Далее находим параметр ignoreip по умолчанию, его значение 127.0.0.1/8. Он отвечает за список тех ip-адресов, которые будут пропускаться и не проверяться софтом. Так называемые «свои» ip, туда можно например включить ip из локальной сети 192.168.0.0/24 или какой-нибудь белый ip: 8.8.8.8, значения записываются через пробел, также можно использовать общепринятое указание маски, Например:

Далее создадим сам фильтр для распознавания нетипичных запросов в логах web-сервера, как ранее упоминалось, все фильтры расположены в директории filter.d, переходим туда и создаем

Далее открываем созданный файл и вносим туда следующий код:

Самой главной строкой в этом файле является переменная с регулярным выражение failregex = ^ -.*»(GET|POST|CONNECT), где сказано, что нужно из лог файла следить за всеми HOST (ip-адреса) с запросами GET|POST|CONNECT, то есть, соединив правило из файла jail.conf и данный файл, программа будет искать следующую логику:

Если в файле access.log появился запрос GET|POST|CONNECT и HOST инициировавший данный запрос, сделал это более чем 10 раз в 60 секунд — то заблокировать его. Вот такая вот логика, значения которой Вы можете менять самостоятельно, можете указать, хоть 1 попытку запроса с любого ip и разрешить полный доступ только на «белые», которые указаны в параметре ignoreip. Остальное всё будет заблокировано.

После успешного сохранения настроек, необходимо перезапустить демон fail2ban:

После перезапуска можем посмотреть работу программы в лог-файле:

в лог-файле видно, что сработал фильтр [http-query-ddos] нашел ip 41.210.125.169 — 9 раз и на 10 заблокировал его. Также в логе можно видеть текст Ignore 192.168.0.32 by ip где также понятно, что данный ip (из локальной сети) был пропущен из проверки, так как он у нас использован в параметре ignoreip.

Так как, при многочисленных запросах, сильно увеличивается размер log-файлов и они могут «вздуться» до неимоверных размеров, необходимо производить их ротацию, то есть при достижении логом определенного (максимального) размера, архивируем его и создаем новый. Для этого, мы будем использовать пакет logrotate. Устанавливаем:

Далее открываем (создаем) конфигурационный файл для ротации файла fail2ban.log

и добавляем туда следующее содержимое:

Сохраняем и закрываем.

Далее проверяем правильность настройки следующей командой:

Если всё нормально, то видим следующее (среди большого количества текста, возможно нужно будет покрутить скролл):

После установки пакета logrotate он автоматически прописывает задание в /etc/cron.daily, там должен лежать файл logrotate, который будет ежедневно запускаться и выполнять ротацию для файлов, расположенных в директории /etc/logrotate.d/

На этом, установка fail2ban для защиты web-сервера завершена, спасибо за внимание!