Аналог fail2ban для windows
Обновлено: 04.07.2024
Fail2ban - это бесплатная популярная программная платформа с открытым исходным кодом, разработанная для предотвращения вторжений, которую можно использовать для защиты вашего сервера от атак методом перебора паролей. Одной из главных задач Fail2ban является блокировка IP-адреса, активность которого имеет явный вредоносный признак. Из этого руководства вы узнаете, как установить Fail2ban на ваш VPS или физический сервер, чтобы защитить сервисы от атак цель которых несанкционированный доступ в систему, при помощи подбора пароля доступа.
Принцип работы
Установка Fail2ban
Для установки на Debian\Ubuntu выполните следующее:
Структура конфигурационных файлов
Файлы настроек находятся в каталоге /etc/fail2ban/. Для понимания работы утилиты, рассмотрим их более детально:
action.d/*.* - конфигурация выполняемых действий;
fail2ban.conf - дефолтный конфигурационный файл;
fail2ban.d/*.* - пользовательские настройки администратора для Fail2ban;
filter.d/*.* - шаблоны для анализа логов и настройки шаблонов;
jail.conf — дефолтные настройки сервисов;
jail.d/*.* - пользовательские настройки администратора для сервисов.
Файлы 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 на него не распространялись, иначе после запуска службы вы рискуете внести себя в бан и доступ к серверу будет утерян:
где 178.20.***.** - Ваш IP адрес.
Здесь же, в секции [DEFAULT] можно задать значения findtime и maxretry, например:
Параметры findtime и maxretry определяют условия, при которых будут блокироваться вредоносные пользователи. Maxretry определяет количество попыток входа, а findtime – интервал времени, в течение которого пользователь должен пройти аутентификацию. Если клиент превысил любой из этих показателей, он будет заблокирован. Bantime определяет длительность блокировки в секундах. Эти параметры в статье будут встречаться неоднократно. Если в настройке какого либо из сервисов вы их не зададите, они будут автоматически браться с секции [DEFAULT].
Не забывайте перезапускать Fail2ban после каждого редактирования конфигурационного файла.
Важно! Путь к файлу хранения логов (logpath) обязан быть указан правильно, иначе перезапуск Fail2ban завершится ошибкой. В случае отсутствия лог-файла по указанному пути, его можно создать командой touch, например:
Теперь мы можем перейти к редактированию общих правил защиты сервисов.
Защита сервиса sshd с помощью Fail2ban
Первым делом очистим наш дефолный конфигурационный файл:
В каталоге jail.d/*.*, отвечающим за настройку сервисов, создадим файл sshd.conf и добавим в него следующие строки:
Чтобы применить изменения перезапустим сервис и внесем его в автозагрузку:
Рассмотрим детально наши действия. Мы их будем выполнять неоднократно для настройки других защищаемых сервисов:
Как это работает: Нарушитель с IP-адресом 123.123.12.13 пытается подобрать пароль к учетной записи на вашем сервере. Параметр findtime задает время, на которое ip адрес попадает под мониторинг от первого момента, когда он начинает фигурировать в логах /var/log/auth.log. Если в течении 300 секунд (5 минут), у нарушителя будет более чем три ошибки аутентификации, он будет заблокирован на 900 секунд (15 минут).
Проверить состояние правила можно командой:
Мы увидим следующее:
Защита NGINX
a) Фильтр аутентификации
на выходе у нас должно получиться следующее:
Обратите внимание на то, как указаны пути к логам. Начиная с версии Fail2ban 0.9.х, писать полные пути не обязательно. Если расположение логов защищаемого сервиса стандартное, то пути к ним предусмотрены разработчиками. Значение %(nginx_error_log)s будет равнозначно пути /var/log/nginx/error. log. Вы можете использовать оба варианта.
В который вносим следующие значения, которые являются фильтрами для корректной работы правила:
б) Фильтр доступа к скриптам
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, который мы рассмотрели в предыдущем разделе. Пройдемся кратко, по основным доступным фильтрам и за что они отвечают:
[apache-auth] - Определяет неудачные попытки ввода пароля.
[apache-badbots] - Определяем ботов, которые ищут email адреса
[apache-noscript] - Блокируем доступ к определенным скриптам
[apache-overflows] - Предотвращаем попытки переполнения Apache
[apache-nohome] - Блокируем неудачные попытки поиска домашней директории
[apache-botsearch] - Определяем ботов, которые перебором ищут популярные скрипты.
Каждое из правил активируется добавлением в блок строки 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 состоит из fail2ban-server и fail2ban-client. Серверная часть работает в фоновом режиме и отвечает за отработку всех активированных правил. Клиент - ваши непосредственные правила, которые взаимодействуют с сервисом.
Перезапуск и проверка состояния Fail2ban:
Полный список правил:
Проверка срабатывания правила:
Проверить работу служб:
Показать состояние указанного jail:
Допустим, произошла ошибка, и ip адрес 123.123.12.13 не является нарушителем и нам его необходимо разблокировать:
Если необходимо добавить разрешение для данного ip адреса выполните:
Удалить ip адрес из доверенных:
Для просмотра списка всех доверенных адресов:
Однако, все разрешения которые вы внесете используя команду addignoreip - временные и после перезапуска службы Fail2ban этот список будет автоматически очищен. Если вам необходимо внести ip адрес на постоянной основе и внести его в конфигурационный файл /etc/fail2ban/jail.d/<JAIL_NAME>.conf добавив с новой строки ещё один параметр:
В эту строку вы можете через пробел добавить как несколько IP адресов, так и целые подсети, например 172.16.1.0/24
Заключение.
В данной статье мы рассмотрели популярную утилиту Fail2ban, которая существенно может повысить безопасность вашего сервера. Утилита гибкая в настройке. Мы рассмотрели основные правила обнаружения для ssh, ftp, nginx и apache, которые будут актуальны ввиду того, что используются повсеместно. Рассмотреть же все возможности Fail2ban в рамках одной статьи крайне сложно, все зависит от поставленных перед вами задач и используемых сервисов. Однако логика создания правил прозрачно просматривается.
Если Вы планируете купить выделенный сервер или арендовать VPS в нашей компании, наша техническая поддержка поможет обеспечить бесперебойную работу сервера и проконсультирует Вас о принципах организации безопасности на Вашем сервере.
Хочу вас познакомить с новым современным продуктом, призванным обеспечивать защиту серверов и веб приложений. Речь пойдет об установке и настройке CrowdSec, аналоге Fail2ban, но построенном на современных принципах работы приложений. Основная особенность его в том, что он написан на Gо, и это позволяет работать гораздо быстрее упомянутого fail2ban, написанного на python.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на . Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.Введение
CrowdSec - локальная служба, способная обеспечить некоторый уровень защиты локальных же служб и приложений. Принцип ее работы полностью аналогичен старому и известному продукту - fail2ban. В ее основе лежит анализ лог файлов и выполнение определенных действий по результату анализа. Самое распространенное действие - бан ip адреса, который выполняет недопустимые действия с сервисом.
CrowdSec vs Fail2ban
Для начала рассмотрим основные отличия CrowdSec от Fail2ban:
- Crowdsec более производительный, так как написан на Go, в отличие от Fail2ban, который на Python.
- У crowdsec современный yaml формат конфигов.
- В качестве парсера лог файлов crowdsec использует фильтры grok, хорошо известные тем, кто активно использует elk stack. Мне лично этот фильтр нравится. Я научился на нем писать правила парсинга.
- У crowdsec есть готовая web панель, с помощью которой можно управлять защитой и просматривать статистику.
- Есть готовые контейнеры docker, которые призваны упростить установку и запуск. На практике особого упрощения нет, так как надо прокидывать в контейнеры все лог файлы для анализа. Тем не менее, кому актуален докер, не надо будет самому делать контейнеры.
- CrowdSec собирает глобальную статистику по заблокированным ip адресам и предоставляет возможность настроить у себя списки блокировки на основе этой статистики. Как по мне, инициатива сомнительная, так как получится то же самое, что и с подобными списками в почте. Потом употеешь себя из этих списков убирать или разбираться, почему кто-то из клиентов не может получить доступ к твоему сервису. Более того, через ботнет доверенных хостов crowdsec можно умышленно банить какие-то ip адреса.
- С локальной службой защиты можно взаимодействовать через встроенное API, что открывает безграничные возможности для интеграции.
- Из коробки работает экспорт всех основных метрик в формате Prometheus. То есть мониторинг вообще настраивать не надо, он сразу готов.
По сравнению видно, что авторы CrowdSec взяли тот же принцип анализа лог файлов, что и Fail2ban, но развили его и адаптировали под современные реалии. Я читал, что они работают над интеграцией своего продукта с Kubernetes и его Ingress Controller.
Архитектура решения
CrowdSec состоит из следующих компонентов:
- Локальная служба, которая занимается парсингом логов и имеет свой API.
- CLI интерфейс для взаимодействия со службой через консоль.
- Различные модули интеграции (Bouncers) для выполнения каких-то действий на основе парсинга. Например, блокировка ip адресов с помощью firewall.
- База данных для хранения своей информации. В самом простом случае используется sqlite, которая устанавливается автоматически и не требует отдельной настройки.
- Публичная база данных с ip адресами и репутацией. С ней можно взаимодействовать через API.
Исходя из архитектуры, у вас есть как минимум 2 разных способа использования CrowdSec у себя. Возможна полностью локальная установка, анализ локальных логов и выполнение определенных действий на основе анализа. Взаимодействия с публичной базой данных может не быть.
Второй, противоположный вариант, когда вы вообще не анализируете свои логи, а используете публичную репутационную базу данных адресов и выполняете какие-то действия с ними с помощью Bouncers. Например, всем ip адресам из базы показываете каптчу.
Возможна комбинация этих режимов. Например, анализировать и свои логи, и брать информацию об ip из репутационной базы. Как я уже сказал, мне подобная база видится сомнительной инициативой, так что я ее использовать не буду. Настрою локальную службу и анализ своих лог файлов. То есть полный аналог Fail2ban.
Установка CrowdSec
С установкой CrowdSec все просто. Есть несколько вариантов:
- Для deb дистрибутивов есть репозиторий.
- Для всех остальных бинарники с инсталлятором. Rpm пакета, к сожалению, нет.
- Сборка и установка из исходников.
- Установка в docker.
Я буду ставить на Centos 8, так что скачаю бинарники и установлю инсталлятором. Быстрее было бы запустить в докере, но мне не нравится, что туда надо мапить логи. Да и в целом не вижу смысла в установке подобного софта через докер. Это же не разработка, когда надо по 5 релизов в день с автотестами выкатывать. Один раз поставил и пользуешься, иногда обновляешь. Что бинарники, что контейнер обновить одно и то же время надо.
Для Debian / Ubuntu устанавливаем CrowdSec так:
Он сразу же определил основные сервисы, за логами которых будет следить. В моем случае это системные логи linux, лог авторизаций ssh и логи nginx. Далее он уточнит, какие именно лог файлы будет парсить. По умолчанию он проверяет дефолтные директории. Если что-то не нашел, то потом в конфигурационных файлах сможете вручную добавить нужные файлы с логами.
Далее нужно будет выбрать преднастроенные конфиги для различных служб. Они есть для наиболее популярных сервисов. Тут все по аналогии с Fail2ban сделано. В моем случае конфиги для веб сервера nginx, сайтов на wordpress, системных логов linux и sshd:
- crowdsecurity/nginx
- crowdsecurity/sshd
- crowdsecurity/wordpress
- crowdsecurity/linux
Далее установщик сообщит, что создал конфиг с белым списком адресов, включающим все серые подсети.
Я во время первого знакомства пропустил этот момент и потом долго не мог понять во время тестов в локалке, почему ничего не работает. Найти этот белых список так и не смог и забросил дело. Когда второй раз начал тесты, внимательнее все посмотрел и понял, в чем была проблема. Так что имейте ввиду этот момент.
Дальше вам будет сказано, что ни одного bouncer не установлено, так что ничего реально заблокировано не будет.
Как я уже говорил в начале, для выполнения каких-то действий, требуются отдельные компоненты системы в виде bouncers. Далее я расскажу, как их ставить и настраивать.
На этом установка CrowdSec закончена. В конце вы увидите список основных cli команд для взаимодействия с локальной службой.
Можете их позапускать и посмотреть, как все это работает. Сама установка CrowdSec выполнена. Переходим к настройке.
Настройка CrowdSec
В целом, все базовые настройки уже сделаны установщиком и CrowdSec готов к работе. Напомню для тех, кто будет тестировать работу в локалке. В файле /etc/crowdsec/parsers/s02-enrich/whitelists.yaml перечислены подсети с приватными адресами, для которых проверки и блокировки не работают. Уберите оттуда свою локальную подсеть для тестов.
Так же еще один важный момент, на котором я сильно подзалип и потратил практически несколько часов в сумме, пытаясь разобраться, как все работает. Чуть не бросил всю затею с этим софтом, так как думал, что с ним какие-то проблемы. В конфиге /etc/crowdsec/parsers/s01-parse/nginx-logs.yaml описан шаблон парсинга логов nginx. Как я уже говорил, используется парсер grok. У меня по умолчанию в nginx используется модифицированный формат логов, который упрощает мониторинг бэкенда. Я об этом рассказываю в отдельной статье - парсинг логов nginx в elk stack.
Очевидно, что CrowdSec ничего не знает про мой формат и не понимает его. Поэтому ничего не работало. А я по привычке везде накатываю свой конфиг nginx. В общем, пока не поправил фильтр, ничего не получалось. Если у вас стандартные логи, то вам ничего делать не надо. Тут, кстати, налицо очевидное преимущество CrowdSec. Его фильтры парсинга на grok и они полностью совместимы с фильтрами, использующимися в ELK Stack. Для меня это огромный плюс, так как я постоянно использую ELK и у меня есть основные фильтры под него.
Основные метрики
Давайте теперь разберемся, как CrowdSec работает. Для начала посмотрим его основные метрики. Будут показаны цифры для тех сущностей, которые были активны. Например, если у вас есть логи, но они пустые и по ним не было ничего, в метриках вы их не увидите вообще. То же самое по фильтрам и сценариям.
- BUCKET - набор активных сценариев, по которым анализировалось содержимое логов. Живут эти сценарии тут - /etc/crowdsec/scenarios.
- SOURCE - список логов. Настраивается в конфиге /etc/crowdsec/acquis.yaml.
- PARSERS - список шаблонов парсинга. Настраиваются тут - /etc/crowdsec/parsers.
- ROUTE - урлы запросов к локальному API.
- BOUNCER - не понимаю, как переводится это слово в данном контексте, но это набор инструментов для выполнения каких-то действий. Пока у нас там пусто.
Анализ логов и поиск нарушителей
Давайте теперь с какого-нибудь соседнего сервера попробуем что-то сделать с целевым, где установлен crowdsec. Для этого удобно взять утилиту мамкиных хакеров wapiti и просканить сайт. В Centos 8 ее можно поставить через pip, который по умолчанию уже есть в системе:
Я поставил на тестовый сервер phpmyadmin и тестировал с этой панелью работу. Итак, скан web сервера запустили, теперь идем смотреть, как отработает crowdsec. Смотрим сначала метрики, убеждаемся, что парсинг лог файлов веб сервера работает. Потом смотрим список принятых решений на основе парсинга логов и работы политик.
Если я правильно понял, то фильтр срабатывает для того, кто сделал 10 и более запросов и получил в ответ 4XX ошибки. Тут на 100% не уверен, так как детально еще не разбирался с тем, как работают и как писать свои фильтры. Этим только предстоит заняться. В error.log nginx при этом было следующее.
Более детальную информацию о событии можно посмотреть с помощью команды:
5 это ID события в списке decisions. После того, как сработал один из фильтров, и ip отправился в бан, было создано ровно одно действие для этого. Посмотреть, под какие еще фильтры попал этот ip можно с помощью alerts.
Обращаю внимание, что тут так же отмечено то, что из Community blocklist пришли 80 ip адресов для бана. В будущем мы отключим этот лист, чтобы полностью управлять банами самостоятельно на основе анализа только своих логов.
Установка cs-firewall-bouncer для бана ip
Он будет банить ip адреса с помощью iptables или nftables, в зависимости от того, что у вас установлено в системе. Если iptables, то будет использован ipset. Установите его предварительно на сервер, если его нет.
Теперь устанавливаем сам bouncer.
У меня дефолтный сервер Centos 8 c Firewalld на борту. Установщик почему-то решил, что у меня установлены и iptables, и nftables. Предложил выбрать из них. Буду использовать nftables. Пора привыкать к новому.
Bouncer установлен. Проверим, все ли с ним в порядке.
После установки он автоматически забанит все адреса, что были ранее помечены для этого. Проверяем:
Видим тут целую кучу ip адресов из публичного списка. Давайте сразу отключим его. Для этого открываем основной конфиг /etc/crowdsec/config.yaml и комментируем там строки:
После этого перезапускаем службу:
Проверяем список alerts:
Видим, что обмен с crowdesc API отключен. Ранее добавленные адреса останутся. Вы можете их вручную удалить, либо подождать, когда они по таймауту будут удалены сами. Как вручную управлять блокировками, я покажу ниже отдельно.
Скажу еще пару слов о том, как crowdesc работает с iptables. Как я уже сказал ранее, он использует таблицу ipset для хранения списка блокировок. Cs-firewall-bouncer автоматически создаст список crowdsec-blacklists и поместит в самый верх списка правил iptables свое:
Посмотреть этот список можно следующим образом:
Там же сразу же будет указано время жизни записи для каждого ip. В целом, все работает просто и надежно. Я проверил и с iptables, и с nftibles. С Firewalld тоже никаких проблем нет. Он не мешает.
Ручное управление блокировками
По умолчанию в качестве Decision применяется ban на 4 часа. Изменить эти параметры можно в файле /etc/crowdsec/profiles.yaml. В настоящий момент, как я понял, доступны 2 действия:
Как настроить последнюю, я не разбирался. А вообще интересная штука. Надо бы потестировать.
Разблокировать вручную конкретный ip можно следующей командой:
Так же можно разом удалить все баны:
Можно вручную кого-то забанить:
Помимо ip адресов можно банить сразу подсети. Синтаксис точно такой же, только вместо конкретного ip указывается подсеть со своей маской. В целом, тут функционал аналогичен Fail2ban.
Web панель управления CrowdSec
Для CrowdSec из коробки идет готовая панель управления через браузер. Устанавливается она только через Docker. Как ее установить вручную без докера я не нашел информации, правда не особо и искал. Ставится она как-то глючно и через раз. То скачать что-то не может, то установка зависает, то учетку для доступа не показывает.
По установке Docker у меня есть отдельная статья. Можете воспользоваться, если еще не поставили его. Сама панель ставится через cscli.
В этой web панели вы можете просматривать все то же самое, что доступно через локальное cli. В целом, удобно, но не уверен, что в этом есть большая практическая польза. Не вижу большого смысла все это просматривать вручную. Хотя с дугой стороны там можно гибко фильтры настраивать. Возможно в каких-то случаях это будет актуально.
Мониторинг CrowdSec
Я сам мониторинг пока не тестировал и не смотрел, но не думаю, что там есть какие-то сложности. Все должно завестись без проблем.
Видео
Заключение
На этом завершаю обзор CrowdSec. Получилось и так насыщенно и объемно. Я бегло посмотрел всю документацию, чтобы понять возможности программы. Мне она очень понравилась. 100% буду ее дальше изучать и использовать вместо Fail2ban. Давно уже задумывался, почему нет развития этой программы. Очевидно, что в текущем виде Fail2ban морально устарел.
Я рассмотрел только один bouncer для firewall. Но там есть еще и для nginx, и для haproxy. Например, вы можете отдавать 403 ошибки заблокированным ip адресам. Это действие по умолчанию. Свое поведение вы сможете настроить с помощью lua в соответствующих конфигах.
Так же есть bouncer для wordpress. Он взаимодействует со специальным плагином, который нужно будет установить на сайт. Он то как раз и умеет показывать каптчу, а не просто банить ip адреса.
Все это выглядит очень интересно и перспективно. Посмотрим, как проект будет дальше развиваться. Пока он совсем молодой, встречаются баги, функционал дорабатывается.
Надеюсь, у меня получилось вас познакомить с CrowdSec и дать представление о нем. Как он вам? Пробовать будете?
3. создаём задание в виндовом шедуллере, выполнять от имени "система" к примеру, при возникновении события с кодом 4624 в журнале "безопасность" источник "Microsoft Windows security auditing." выполняем действие "запуск программы" powershell.exe с аргументом
4. создаём задание в виндовом шедуллере, выполнять от имени "система" к примеру, по расписанию в полночь (или около того) выполняем действие "запуск программы" powershell.exe с аргументом
По итогу в папке Temp создаются файлики с айпишниками успешных и неуспешных подключений.
- Добавил ключ устаонвки
- Подправил некоторые моменты относящиеся к описанию внутри кода.
- опитимизирован процесс установки в зависимости от версии ОС.
Специальные предложения
Проблему с защитой особо не решит. Даже не могу представить, в каких случаях нельзя VPN поднять. На крайняк у 1Сного сервера ставится какой нибудь микротик, там создаются VPN пользователи и тоннель, а люди со стандартного. виндового VPN цепляются уже к микротику, который уже отдает трафик серверу. Либо поднимается OpenVPN за 15 минут. Т.е. проблемы как таковой-то и нет. Цена вопроса не большая, даже очень маленькая конторка может выбрать просто подешевле устройство и все. Зачем скриптом решать в этом случае? Это реальный костыль, но за старания поставил плюс. Единственное - не надо пытаться все продать. Я свои PS скрипты прикрепляю, но весь листинг кидаю под спойлер, чтобы люди могли брать, если надо. Никому не навязываю, но все же PS скрипт не бог весть что, чтобы эту мелочь продавать. Да и эти PS скрипты больше нужны сис.админам, чем 1Сникам, а сис.админы редко имеют старт.мани =)).
З.Ы. Все в коммерсов заделались =))). Идея интересная, при желании по описанию можно свой скрипт написать ))
Описывая 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
- maxretry — количество действий, которые разрешено совершить до бана.
- findtime — время в секундах, в течение которого учитывается maxretry;
- bantime — время, на которое будет блокироваться IP-адрес;
- action — действия, которое будет выполняться, если Fail2ban обнаружит активность, соответствующую критериям поиска;
- ignoreip — игнорировать защиту, если запросы приходят с перечисленных адресов.
* В данном примере, если в течение 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
- ssh — название для правила;
- enabled позволяет быстро включать (true) или отключать (false) правило;
- port — порт целевого сервиса. Принимается буквенное или цифирное обозначение;
- filter — фильтр (критерий поиска), который будет использоваться для поиска подозрительных действий. По сути, это имя файла из каталога /etc/fail2ban/filter.d без .conf на конце;
- action — действие, совершаемое в случае срабатывания правила. В квадратных скобках указаны название для правила, сетевой порт и протокол для блокирования;
- logpath — расположение лог-файла, в котором фильтр будет искать подозрительную активность на основе описанных критериев.
* обратите внимание, что мы переопределили параметры по умолчанию 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.
Остановимся на описании самых используемых действий:
- iptables — создание простого правила в netfilter с помощью одноименной утилиты;
- iptables-multiport — использование модуля multiports, позволяющий добавлять диапазоны портов для блокировки;
- iptables-ipset — использование ipset для придания более лаконичного вида правилам;
- iptables-allports — блокирует для адреса все порты;
- firewallcmd-new — создание простого правила в netfilter с помощью firewall-cmd;
- firewallcmd-ipset — добавляет правила с помощью утилиты firewall-cmd, используя ipset;
- firewallcmd-rich-rules — создает rich-rules при помощи firewall-cmd.
Подробнее, как создаются правила в 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 DDoS (req limit)
Данное правило поможет защитить веб-сервер nginx от DDoS-атак. В некоторых сборках, для данного правило может не оказаться готового фильтра, поэтому в данном примере, мы его создадим вручную.
Для начала, необходимо настроить NGINX:
* данная настройка создает зону с интенсивностью запросов в 1 запрос в секунду.
После настраиваем лимит для конкретного виртуального домена в разделе server - location:
server .
location / .
limit_req zone=one burst=5 nodelay;
.
Проверяем конфигурационный файл nginx и перезапускаем сервис:
systemctl reload nginx
В лог-файле (по умолчанию /var/log/nginx/error.log) при превышении лимита подключения мы должны увидеть запись на подобие:
* обратите внимание, что в вашем случае путь до лога может быть другой. Он определяется в конфигурационном файле NGINX.
Теперь можно приступать к настройке fail2ban. Создаем фильтр:
* данный файл может быть уже создан и настроен при установке fail2ban. Если это так, то ничего не меняем и идем дальше.
Создаем правило в fail2ban:
* еще раз обращаю внимание на путь logpath — в вашем случае он может быть другим.
После настройки не забываем перезапустить fail2ban:
systemctl restart fail2ban
Работа со списком заблокированных адресов
Просмотр
Получить статистику заблокированных адресов можно следующей командой:
fail2ban-client status <имя правила>
Получить список правил можно командой:
При наличие заблокированных IP-адресов мы увидим, примерно, следующее:
`- action
|- Currently banned: 2
| `- IP list: 31.207.47.55 10.212.245.29
С помощью iptables:
iptables -L -n --line
С помощью firewall-cmd:
firewall-cmd --direct --get-all-rules
Удаление
Средствами fail2ban:
Для удаление адреса из списка вводим:
fail2ban-client set <имя правила> unbanip <IP-адрес>
fail2ban-client set ssh unbanip 31.207.47.55
С помощью iptables:
iptables -D <цепочка правил> -s IP-адрес
iptables -D fail2ban-ssh -s 10.212.245.29
С помощью firewall-cmd:
firewall-cmd --direct --permanent --remove-rule <правило>
firewall-cmd --direct --permanent --remove-rule ipv4 filter f2b-sshd 0 -s 188.134.7.221
Читайте также: