Альтернативы Fail2Ban для современных серверов Linux

Перед выбором инструмента необходимо проверить зону воздействия

A Альтернатива Fail2Ban его можно выбрать обоснованно только после того, как будут определены фактически доступные службы. SSH, SMTP, IMAP и HTTP-приложение имеют разные процедуры входа, источники журналов и характерные признаки ущерба. В то же время общедоступный сервис базы данных, как правило, не должен защищаться с помощью списка заблокированных сайтов: его сетевой доступ должен быть ограничен необходимыми приложениями и доверенными сетями.

В случае административных поступлений Ограничение доступа а надежная аутентификация имеет приоритет перед автоматической блокировкой IP-адресов. SSH-сервис, расположенный за VPN, бастионным хостом или фиксированными сетями администрирования, предоставляет злоумышленникам гораздо меньшую площадь атаки, чем порт, открытый для доступа со всего мира. Актуальные обновления безопасности, отдельные учетные записи с привилегиями и тщательно продуманные пароли снижают риски, которые не могут быть устранены одним лишь списком заблокированных адресов.

Если SSH намеренно открыт для общего доступа, ограничения и блокировки на основе журналов могут снизить количество повторных попыток ввода пароля. Однако они остаются лишь дополнением: пользователи, находящиеся за общим NAT-шлюзом, могут использовать один и тот же исходный адрес, в то время как при распределенных атаках задействуется множество адресов. Для почтовых сервисов дополнительно важно, какие протоколы фактически открыты для внешних пользователей и какие неудачные попытки входа регистрируются в журналах.

В случае веб-приложений следует проводить различие между доступностью обратного прокси-сервера и внутренними бэкэнд-сервисами. Публичный сервер Nginx может принимать HTTP-запросы, при этом база данных, кэш или интерфейс администрирования не обязательно должны быть доступны из Интернета. Это Цель охраны Поэтому речь не идет о том, чтобы просто „блокировать IP-адреса“, а о том, чтобы для каждого сервиса ограничивать несанкционированный доступ, обеспечивать законное использование и избегать ненужных разрешений.

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

Кроме того, блокировка не решает вопрос о том, должна ли служба вообще быть общедоступной. Если поменять эту последовательность местами, то будут обрабатываться подозрительные соединения, хотя основная уязвимость останется неизменной. Особенно в случае редко используемых административных интерфейсов частный канал доступа зачастую оказывается более эффективным и простым в эксплуатации, чем всё более сложные правила распознавания.

Четыре подхода вместо одной альтернативы Fail2Ban

Вместо того чтобы искать единственное решение, стоит разделить процессы обнаружения и реагирования. CrowdSec обрабатывает настраиваемые источники журналов с помощью парсеров и сценариев для анализа последовательностей событий и принятия решений. Security Engine сам не осуществляет эти решения; для этого необходимо подключить и настроить отдельный компонент исправления (Remediation Component).

Такое разделение подходит в тех случаях, когда одно и то же средство обнаружения должно работать в разных местах. Один из компонентов брандмауэра может принимать решения по сетевым соединениям, в то время как компоненты для веб-серверов или обратных прокси обрабатывают HTTP-трафик. Однако это также повышает требования: сбор логов, парсеры, локальные API, права доступа и фактическое обеспечение соблюдения правил должны планироваться как единая цепочка.

SSHGuard предназначен для более узких случаев. Этот инструмент агрегирует системные журналы и может блокировать источники, неоднократно привлекавшие к себе внимание, с помощью брандмауэров; его назначение включает в себя защиту от атак методом перебора на SSH и другие службы. Поэтому он больше подходит для выявления очевидных ошибок аутентификации, чем для всестороннего анализа веб-запросов.

Нативные Ограничение скорости в nftables использует другой подход. Динамические наборы и счетчики могут ограничивать количество новых TCP-соединений для каждого адреса источника и управлять записями с истекшим временем ожидания. Это сдерживает быструю последовательность подключений до аутентификации, не требует использования анализатора журналов и при этом не оценивает, был ли сбой в авторизации или HTTP-запрос был вредоносным.

При этом важно направление правила: nftables различает правила, допускающие трафик до определенной интенсивности, и выражения с over, которые отбрасывают трафик, превышающий установленный порог. Поэтому лимит должен соответствовать характеру услуги, ожидаемому поведению пользователей и общим исходным адресам. Это не является надежной классификацией каждой подозрительной идентичности.

Для отдельного сервера с небольшим количеством четко определенных служб может быть достаточно упрощенной защиты журналов или умеренного ограничения количества подключений. Наличие нескольких хостов, централизованных источников журналов или необходимость использования различных точек применения мер безопасности скорее свидетельствует в пользу модульной архитектуры. Ни один из этих вариантов не заменяет установку исправлений, использование надежной системы аутентификации или ограничительные настройки сетевого доступа.

Таким образом, выбор подходящей альтернативы Fail2Ban зависит от того, какие сигналы доступны и где должна происходить реакция. Шаблоны журналов полезны при повторяющихся ошибках входа в систему; правила обработки пакетов ограничивают частоту подключений. Оба метода распознают только то, на что рассчитаны их источники данных и правила.

Четко разделить брандмауэр и защиту HTTP

Сервер Nginx или обратный прокси объединяет два уровня защиты, которые не следует путать. Брандмауэр отклоняет или разрешает соединения с определённого исходного адреса и, таким образом, может одновременно влиять на SSH, SMTP или веб-доступ. Однако он не анализирует отдельные HTTP-пути, заголовки или содержимое запросов; эта информация относится к прикладному уровню.

В CrowdSec Выявление и обеспечение соблюдения раздельные задачи. Процессор журналов анализирует данные журналов и HTTP-запросы совместимых веб-серверов. AppSec является частью этого процессора журналов и фильтрует такие HTTP-запросы. Компоненты исправления, в свою очередь, отвечают за реализацию решений на выбранном уровне, например, на брандмауэре, веб-сервере или обратном прокси-сервере.

Поэтому для защиты от SQL-инъекций, межсайтового скриптинга или другого вредоносного содержимого запросов одного только компонента брандмауэра недостаточно. Необходимы совместимое подключение к веб-серверу, а также соответствующая конфигурация AppSec с подходящими правилами. Устранение уязвимостей следует технически отделять от этого процесса: оно реализует решения в выбранной точке применения.

Оба уровня могут быть целесообразны одновременно. Блокировка на уровне всей сети ограничивает дальнейший трафик, исходящий от источника, в то время как Проверка HTTP оценивает и фильтрует запросы веб-серверов, совместимых с AppSec. Это не означает, что блокировка IP-адреса автоматически защищает от SQL-инъекций или межсайтового скриптинга: без проверки запросов брандмауэр не распознает ни параметры, ни полезные данные.

С другой стороны, меры, основанные на AppSec и IP-адресах, также имеют свои ограничения. Медленные попытки, не превышающие пороговые значения, большое количество меняющихся адресов источника или легитимные пользователи, находящиеся за одним и тем же адресом NAT, затрудняют принятие решений на основе IP-адреса источника. Поэтому правила должны учитывать ложные срабатывания и не рассматривать доступ к обычным формам, API и автоматизированным интеграциям как атаку в целом.

Для планирования полезно кратко обозначить контекст: Уровень брандмауэра управляет сетевым трафиком по адресам, портам и характеристикам соединений. AppSec обрабатывает и фильтрует HTTP-запросы совместимых веб-серверов в рамках модуля обработки журналов. Компоненты исправления ошибок целенаправленно реализуют принятые решения на выбранном уровне.

Кроме того, для публичной веб-системы необходимо четкое разделение полномочий. Обратный прокси-сервер должен иметь доступ только к необходимым бэкэндам, а административные конечные точки не должны оставаться общедоступными только из-за наличия фильтра, расположенного выше по цепочке. Таким образом, сегментация сети, безопасный вход в систему и целевые правила дополняют друг друга, не придавая отдельной технологии блокировки большего защитного эффекта, чем она может обеспечить.

Сравнение типичных серверов Linux

Альтернативу Fail2Ban нельзя выбрать, ориентируясь исключительно на количество возможных блокировок. Решающую роль играют анализируемые сигналы и место применения мер. CrowdSec отделяет свой механизм безопасности от компонента, который обеспечивает выполнение решений на брандмауэре, прокси-сервере или веб-сервере. SSHGuard, в свою очередь, анализирует системные журналы на предмет повторяющихся попыток атак; nftables может ограничивать новые соединения непосредственно в пути прохождения пакетов.

Таблица не отражает рейтинг. Для отдельного сервиса с явными неудачными попытками входа «упрощенный анализ логов» — это не то же самое, что ограничение на шквал подключений. Для обратного прокси дополнительно важно, должны ли HTTP-запросы фильтроваться AppSec на совместимом канале связи. Это точка приложения силы должно соответствовать объекту защиты: правило брандмауэра не анализирует содержимое запросов, в то время как компоненты исправления ошибок обеспечивают выполнение решений на выбранном уровне.

Централизованное управление также не является самоцелью. Оно позволяет унифицировать процесс принятия решений и анализ журналов на нескольких хостах, но требует надежной концепции доступа и обеспечения работоспособности в случае сбоев. Для небольшого изолированного сервера такая дополнительная архитектура в некоторых случаях может привести к большему объёму работ по обслуживанию, чем к повышению безопасности. С другой стороны, идентичные службы, развернутые на нескольких хостах, могут извлечь выгоду из тщательно спланированной централизованной установки CrowdSec.

Тщательно проверить и классифицировать конфигурацию

Перед активацией необходимо сначала определить, какие сообщения действительно поступают в службу. В случае решения, основанного на журналах, проверьте источник журнала, парсер и конкретный формат событий SSH, почты или прокси. В случае с CrowdSec одного лишь обнаружения активности недостаточно: зарегистрированный и доступный компонент устранения уязвимостей должен передавать решения в предусмотренное подключение к брандмауэру или прокси-серверу.

Приведенные ниже команды предназначены исключительно для проверки в режиме чтения в системе Linux, в которой соответствующие инструменты, возможно, уже установлены. Они не изменяют правила и не устанавливают пакеты. Они помогают просмотреть текущий набор правил, зарегистрированные компоненты CrowdSec и доступные для Debian или Ubuntu кандидаты в пакеты.

nft list ruleset
sudo cscli bouncers list
apt-cache policy crowdsec

Из вывода пока не следует, что защита работает. Проверьте в nftables, содержит ли соответствующая цепочка входящего трафика ожидаемый хук и подходящее стандартное правило, а также предусмотрены ли правила для существующих соединений, loopback, IPv4 и IPv6, а также для фактического порта службы. Кроме того, зарегистрированный компонент может быть настроен на неверную точку применения. Даже видимый кандидат-пакет не дает никакой информации о том, соответствуют ли его версия, конфигурация и парсер дистрибутиву и собственной службе.

Пороговые значения, периоды блокировки и исключения не следует без проверки переносить из примеров в производственную среду. В частности, общие NAT-адреса, мобильные подключения и автоматизированные задания могут в противном случае привести к ложным срабатываниям. Для анализа сетевых событий и поведения системы можно дополнительно Отслеживание eBPF для мониторинга Linux помочь; однако это не заменяет ни проверку цепочки журналов, ни профессиональное решение о блокировке.

Оптимальный выбор для четырёх сценариев эксплуатации

Один VPS с доступным по всему миру SSH имеет четко очерченные потребности в защите. SSHGuard может сообщать о повторяющихся неудачных попытках входа, которые можно обнаружить в соответствующих журналах, бэкенду брандмауэра. Умеренное ограничение nftables может дополнительно сдерживать новые соединения, но не учитывает ошибки входа в систему. Приоритет отдаётся ограниченным каналам администрирования и надежному входу в систему; блокировка IP-адресов остаётся дополнительной мерой.

На почтовом сервере протоколы SMTP, IMAP и Submission используют разные пути аутентификации и ведения журналов. Оптимизированное реагирование на основе журналов имеет смысл только в том случае, если все соответствующие сообщения регистрируются в полном объеме. CrowdSec становится целесообразным решением, когда необходимо объединить принятие решений или анализ журналов, поступающих из нескольких систем. Без такой необходимости централизованная архитектура была бы несоразмерной по сравнению с четко обозначенным локальным решением.

Для Nginx или Traefik, расположенных перед веб-приложением, инструмента, ориентированного исключительно на SSH, недостаточно. Здесь разделяет многоуровневая защита Сетевые запросы в рамках HTTP-проверки: CrowdSec AppSec является частью Log Processor и может фильтровать запросы совместимых веб-серверов. Компоненты исправления (Remediation Components), в свою очередь, реализуют принятые решения на выбранном уровне, например, на веб-сервере или обратном прокси-сервере. Обе задачи должны быть надлежащим образом интегрированы и проверяться отдельно.

Небольшой кластер с централизованным ведением журналов или Kubernetes может извлечь выгоду из использования централизованного локального API или централизованного ведения журналов. Однако это не всегда автоматически упрощает эксплуатацию: необходимо заранее продумать вопросы прав доступа, доступности интерфейсов, сегментации и возможных сбоев центрального компонента. Аспекты обработки пакетов и распределения нагрузки в крупных сетях Linux также рассматриваются в статье по теме Масштабирование на стороне приема в сетях серверов Linux. Для небольшого числа хостов, не использующих общий рабочий процесс, локальное решение зачастую остается более понятным.

Мониторинг логики блокировки во время работы

Логика блокировки становится понятной только в том случае, если вы отдельно контролируете три этапа: поступление данных журнала, принятие решения на их основе и его техническую реализацию. В CrowdSec модуль безопасности считывает настроенные источники журналов и принимает решения на основе парсеров и сценариев; однако само блокирование осуществляется отдельным компонентом устранения угроз.

Сначала проверьте, поступают ли вообще ожидаемые сообщения. Для SSH-сервиса важны сбои при входе в систему, для почтового сервера — соответствующие протоколы аутентификации, а для прокси-сервера — его журналы доступа или безопасности. Сами по себе видимые события ещё не свидетельствуют о защитном эффекте: только цепочка, состоящая из поступления записи в журнал, распознавания последовательности, принятия решения и применения эффективного правила, позволяет поставить достоверный диагноз.

После этого проверьте решения и зарегистрированный компонент по отдельности. Если CrowdSec обнаруживает подозрительные события, но компонент устранения угроз не подключен или не работает, эти решения не приведут к каким-либо последствиям. В официальной документации по ошибкам именно этот паттерн указан в качестве причины того, что модуль безопасности работает, но блокировка не происходит. Обнаружение не означает блокировку.

В случае веб-защиты добавляется ещё одна проверка. AppSec является частью Log Processor и фильтрует HTTP-запросы совместимых веб-серверов. Компоненты исправления (Remediation Components) обеспечивают выполнение решений на выбранном уровне, например, на веб-сервере или обратном прокси. Поэтому в процессе эксплуатации должно оставаться понятным, является ли отказ результатом проверки HTTP или уже выполненного решения, чтобы можно было целенаправленно анализировать ошибки и ложные срабатывания.

Ложные срабатывания особенно опасны, когда один и тот же публичный адрес используют многие авторизованные пользователи. NAT-шлюзы, сети мобильной связи и системы CI могут объединять множество легитимных попыток входа под одним IP-адресом источника. Поэтому выбирайте пороговые значения, сроки блокировки и исключения с учётом реальных путей доступа и обеспечьте прозрачность решений, включая причину и срок действия, вместо того чтобы считать длинный список заблокированных адресов показателем успеха.

Сначала протестируйте изменения на анонимизированных исторических логах или в тестовой среде. Это позволит проверить, распознают ли парсеры предусмотренные шаблоны и реагирует ли система исправления на ожидаемом уровне, не подвергая риску административные учетные записи. SSHGuard обрабатывает системные журналы и может взаимодействовать с различными бэкэндами брандмауэров; поэтому источник журналов и бэкенд необходимо рассматривать в комплексе в установленной среде.

Контролируемый процесс не заменяет тестирования на уязвимости в производственной среде. Документируйте ожидаемые события, наблюдаемые решения и результаты их применения; после этого удалите тестовые данные или дождитесь истечения срока действия временных записей. Таким образом, можно будет проверить эффективность защиты и возможные побочные эффекты, не вызывая при этом намеренно реальных блокировок для реальных пользователей.

Поиск ошибок в журналах и правилах

Всегда начинайте поиск неисправностей с источника журнала, а затем продвигайтесь в сторону применения. Если соответствующие сообщения отсутствуют, ни парсер журналов, ни сценарий, ни логика блокировки не смогут надежно отреагировать. Поэтому проверьте службу, считыватель журналов и фактический формат, прежде чем изменять пороговые значения или подозревать правила брандмауэра.

В CrowdSec ситуация с ошибкой однозначна: если события или решения отображаются, но доступ по-прежнему возможен, это означает, что решение не выполняется движком автоматически. Убедитесь, что соответствующий компонент исправления зарегистрирован, доступен и действительно подключён к брандмауэру, веб-серверу или прокси-серверу. Без этого компонента правило блокировки не будет применяться.

В случае с SSHGuard причина часто кроется в этом. Утилита агрегирует системные журналы, однако неподходящий считыватель журналов или формат службы, отличающийся от ожидаемого шаблона, не дают пригодных для использования результатов. Пример конфигурации в репозитории демонстрирует возможные вводные данные и параметры, однако он взяты из ветки разработки; сверьте его с документацией по пакету и установленной версией, а не используйте без изменений.

В nftables необходимо дополнительно проверить, находится ли правило в соответствующей цепочке на ожидаемом хуке, охватывает ли оно фактический порт службы и применимо ли оно к необходимым семействам протоколов. В приведённом примере набора правил IPv4 и IPv6 разделены с помощью отдельных цепочек; разрешаются установленные и связанные соединения, а также loopback-трафик до открытия портов. Защита, сформулированная исключительно для IPv4, не охватывает IPv6; аналогичным образом, слишком строгие ограничения по скорости могут повлиять на допустимые параллельные соединения.

Ein Meter ограничивает количество новых подключений на основе заданной нормы для каждого источника и может управлять динамическими записями набора с таймаутом. Однако это не учитывает неудачные попытки входа. Поэтому, если атака не превышает установленную скорость, отсутствие срабатывания не обязательно означает неисправность правила, а может быть ограничением выбранного подхода. Крючок, цепь и точка измерения должны соответствовать ожидаемому эффекту.

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

Решение с учетом риска и затрат

Подходящая альтернатива Fail2Ban определяется доступной площадью атаки, а не общим рейтингом. Уточните, какие службы доступны из сети, обрабатывают ли они запросы на вход, какие журналы регистрации надежно ведутся и кто постоянно отвечает за настройку. Сервис базы данных, недоступный из внешней сети, не нуждается в списке заблокированных адресов; в этом случае более важным решением с точки зрения безопасности остаётся настройка сетевого доступа.

Для небольшого отдельного сервера, на котором часто возникают ошибки входа в SSH или почтовую систему, SSHGuard может стать эффективным решением, основанным на анализе логов. Проект направлен на защиту от атак методом перебора (brute-force) на SSH и другие службы и использует для этого системные журналы, а также бэкэнды брандмауэров. Тем не менее, конкретный охват журналов и параметры блокировки должны соответствовать установленному дистрибутиву и формату службы.

Если необходимо, прежде всего, ограничить скорость новых соединений, то умеренное ограничение скорости в nftables станет прямым дополнением. Лимитаторы могут ограничивать количество соединений на один исходный адрес; правила с over отбрасывать трафик, превышающий установленный порог. Это происходит до входа в систему, но не дает никакой семантической информации о том, был ли вход в систему неудачным или HTTP-запрос являлся вредоносным.

CrowdSec подходит в тех случаях, когда необходимо координировать анализ логов и обеспечение соблюдения правил на нескольких уровнях или на нескольких хостах. Его архитектура предусматривает разделение компонентов движка и компонентов исправления; возможны распределенные варианты с централизованным локальным API или централизованными журналами. Такие преимущества влекут за собой дополнительные требования к правам доступа, доступности, сегментации и плану действий на случай сбоев. Работоспособность поэтому является одним из критериев выбора наряду с функциональными возможностями.

В случае публичных веб-приложений блокировка на уровне брандмауэра недостаточна для оценки отдельных HTTP-запросов. Для этого требуется совместимый модуль AppSec с соответствующими правилами. AppSec является частью Log Processor и фильтрует HTTP-запросы совместимых веб-серверов; компоненты Remediation Components обеспечивают выполнение решений в выбранной точке применения. Решающим фактором является то, касается ли потребность в защите соединений, событий аутентификации или HTTP-контента.

Меры, основанные на IP-адресах, остаются ограниченными: ботнеты распределяют попытки по множеству источников, медленные атаки могут не превышать установленный порог, а в случае блокировки адресов страдают посторонние пользователи. Они снижают уровень автоматизированного шума, но не заменяют своевременные исправления, ограниченный доступ администраторов и надёжную аутентификацию. В частности, при использовании SSH вход на основе ключей и ограниченная доступность имеют приоритет перед всё более агрессивными порогами блокировки.