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

я должен использовать 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 раз, потому что он запускает доступные playbooks, и 5 неудачных попыток входа в систему как root с помощью бота.

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

Это чем-то похоже на вопрос: «Пристегнуть ремень или машину?».

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

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

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

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

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

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

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

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

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

Замечание, не имеющее прямого отношения к вашему вопросу: всякий раз, когда вы фильтруете журналы для просмотра, подумайте, что вы будете делать с определенной записью. Если все, что вы собираетесь сделать с записью, - это сказать «Мех» и двигаться дальше, то вы, вероятно, захотите отфильтровать ее. Обязательно сохраняйте полные журналы для просмотра, если это необходимо, но вставляйте в свой обычный рабочий процесс мониторинга только то, что вы на самом деле собираетесь делать что-то с тем, когда это появляется. Если вы настроили 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.