Защита серверов Linux: iptables против fail2ban

Я хотел бы выбрать мозг сообщества в отношении безопасности серверов Linux, особенно в отношении атак методом перебора и использования fail2ban против пользовательских iptables .

Есть несколько подобных вопросов, но ни один из них не затрагивает тему к моему удовлетворению. Короче говоря, я пытаюсь определить лучшее решение для защиты серверов Linux, подключенных к Интернету (с использованием обычных служб, ssh, web, mail), от атак методом перебора.

У меня есть приличный контроль над безопасностью сервера, то есть блокировка ssh, не позволяющая войти в систему как root или пароль, изменить порт по умолчанию, обеспечить актуальность программного обеспечения, проверить файлы журнала, разрешить доступ к серверу только определенным хостам и использовать защиту инструменты аудита, такие как Lynis ( https://cisofy.com/lynis/ ), для обеспечения общего соответствия требованиям безопасности, поэтому этот вопрос не обязательно касается этого, хотя всегда приветствуются входные данные и советы .

У меня вопрос: какое решение я должен использовать (fail2ban или iptables) и как его настроить, или я должен использовать комбинацию обоих для защиты от атак методом перебора?

Есть интересный ответ по этой теме ( Denyhosts vs fail2ban vs iptables - лучший способ предотвратить грубый вход в систему? ). Самым интересным ответом для меня лично было ( https://serverfault.com/a/128964 ), и что в ядре происходит маршрутизация iptables, а не fail2ban, который использует инструменты пользовательского режима для анализа файлов журнала. Fail2ban, конечно, использует iptables, но он все равно должен анализировать файлы журнала и сопоставлять шаблон, пока не выполнит действие.

Имеет ли смысл тогда использовать iptables и использовать ограничение скорости ( https://www.rackaid.com/blog/how-to-block-ssh-brute-force-attacks/ ) для отбрасывания запросов с IP на период времени, которое делает слишком много попыток подключения в течение определенного периода, независимо от того, к какому протоколу он пытался подключиться? Если так, то есть некоторые интересные мысли об использовании отбрасывания против отклонения для этих пакетов здесь ( http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject ), есть какие-нибудь мысли по этому поводу ?

Fail2ban допускает настраиваемую конфигурацию в форме возможности написания настраиваемых « правил » для служб, которые могут не учитываться в конфигурации по умолчанию. Он прост в установке и настройке и является мощным, но может ли это быть излишним, если все, чего я пытаюсь добиться, - это « заблокировать » IP-адрес с сервера, если они предпринимают 2 неудачные попытки доступа к любой услуге / протоколу за большее количество x времени?

Цель в том, чтобы открывать ежедневные отчеты журнала и не нужно пролистывать страницы попыток неудачных подключений к серверу.

Спасибо, что нашли время.

я должен использовать fail2ban или iptables?

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

Упрощенно: брандмауэр видит только сетевые соединения и пакеты и может иметь некоторое представление о шаблонах в нем, но у него нет понимания уровня приложения, чтобы отличить желаемые и действительные запросы от вредоносных, искаженных и нежелательных запросов. Например, ваш брандмауэр не может определить разницу между кучей HTTP-запросов API и количеством неверных попыток входа в систему, вызванных подборами паролей грубой силы на вашей странице администратора Wordpress, к брандмауэру они оба являются только TCP-соединениями с портом 80 или 443.

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

Другой способ предоставления межсетевым экранам информации об уровне приложения - это система обнаружения / предотвращения вторжений .

Например, веб-сервер является общедоступной службой, и в вашем брандмауэре TCP-порты 80 и 443 открыты для Интернета в целом.
Как правило, у вас нет каких-либо ограничений скорости на портах HTTP / HTTPS, потому что у нескольких допустимых пользователей может быть один источник, когда они находятся, например, за шлюзом NAT или веб-прокси.

Когда вы обнаруживаете нежелательные и / или злонамеренные действия в отношении вашего веб-сервера, вы используете fail2ban, чтобы автоматизировать блокировку такого нарушителя (либо полностью заблокируйте его, либо заблокировав доступ к портам 80 и 443).

С другой стороны, доступ по SSH не является общедоступной службой, но если вы не в состоянии ограничить доступ SSH в брандмауэре только диапазонами ip-адресов из белого списка, ограничение скорости входящих соединений является одним из способов замедления грубого обращения. силовые атаки. Но ваш брандмауэр по-прежнему не может отличить пользователя bob, успешно выполнившего вход в систему 5 раз, потому что он запускает ANSIBLE PlayBooks, и 5 неудачных попыток входа в систему как root с помощью бота.

я должен использовать fail2ban или iptables?

Это немного похоже на вопрос «должен ли я пользоваться ремнем безопасности или автомобилем?».

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

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

Вы можете использовать fail2ban для добавления (и удаления) правил iptables по требованию. Вы также можете добавлять и удалять правила iptables вручную или использовать fail2ban, чтобы сделать что-то совершенно другое в ответ. Это все о том, как вы это настраиваете.

Вы должны иметь общий межсетевой экран независимо от того, используете ли вы fail2ban или нет. Такой межсетевой экран мог бы, например, блокировать (входящий или исходящий) трафик, который, как вы знаете, никогда не будет легитимным. Например, это , что сервер базы данных действительно нужен иметь дело с входящими соединениями на порт 25 из всего интернета?

Кроме того, сбои fail2ban реагируют на нарушения политики, на какое-то время отключая нарушающие IP-адреса, мало что может сделать для защиты вашего сервера как такового (хороший эксплойт должен пройти через брандмауэр только один раз), но это сократить уровень шума в вашей системе, в том числе, но не ограничиваясь, в системных журналах. Простой способ сделать это - заставить fail2ban запустить iptables, чтобы настроить ядро ​​на некоторое время отбрасывать пакеты. Если вы можете перенастроить свой брандмауэр по периметру, а не только брандмауэр хоста, то тем лучше.

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

может ли это быть излишним, если все, чего я пытаюсь добиться, это «заблокировать» IP-адрес с сервера, если они предпринимают 2 неудачные попытки доступа к какой-либо услуге / протоколу в течение определенного промежутка времени?

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

Цель в том, чтобы открывать ежедневные отчеты журнала и не нужно пролистывать страницы попыток неудачных подключений к серверу.

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

Я решил тот же вопрос несколько лет назад. Я решил использовать iptables с недавним модулем из-за производительности и простоты установки. Мне пришлось защищать множество виртуальных контейнеров на хостах. Только помните, чтобы не открывать вектор DOS с вашими правилами. Также используйте ipset для сопоставления списков сети или списков ip в правилах. Я использую это для белых списков. Все сети одной страны в одном списке отлично подходят для тонкой настройки. И очень легко защитить другой сервис с тем же набором правил, только добавив еще один порт для соответствия. Поэтому я не люблю менять с fail2ban, но, возможно, кто-то с другими потребностями будет счастлив с fail2ban.

Вот пример:

  #
  # SSH tracking sample
  #
  #################################################################################
  iptables -X IN_SSH
  iptables -N IN_SSH
  iptables -A IN_SSH -m set --match-set net_blacklist src -p tcp -j REJECT
  iptables -A IN_SSH -m set --match-set net_whitelist src -p tcp --match limit --limit 5/second -j LOG --log-prefix whitelist_de_prefix
  iptables -A IN_SSH -m set --match-set net_whitelist src -p tcp -j ACCEPT
  # filter update
  iptables -A IN_SSH -m recent --name sshbf --set --rsource
  # connlimit
  iptables -A IN_SSH -m connlimit --connlimit-above 4 --match limit --limit 5/second -j LOG --log-prefix ssh_connlimit_per_ip_above_4
  iptables -A IN_SSH -m connlimit --connlimit-above 4 -j REJECT
  # filter
  iptables -A IN_SSH -m recent --name sshbf --rttl --rcheck --hitcount 13 --seconds 60 --match limit --limit 5/second -j LOG --log-prefix ssh_filtered_13in60sec
  iptables -A IN_SSH -m recent --name sshbf --rttl --rcheck --hitcount 13 --seconds 60 -j REJECT
  iptables -A IN_SSH -j ACCEPT

iptables -A FORWARD -p tcp --dport ssh --syn --jump IN_SSH
# iptables -A INPUT -p tcp --dport ssh --syn --jump IN_SSH

Вывод ваших сообщений регистрации может быть объединен с fail2ban. Вы также можете использовать его для правил INPUT.