☰

Стоит ли блокировать неудачные попытки входа в систему?

tag-icon • tag-icon security ssh fail2ban
Стоит ли блокировать неудачные попытки входа в систему?

Стоит ли бежать?fail2ban,sshdfilter или аналогичные инструменты, которые заносят в черный список IP-адреса, которые пытаются войти в систему, но не могут ее выполнить?

Я видел, как это обсуждалосьчто это театр безопасности на "надлежащим образом защищенном" сервере. Однако я чувствую, что это, вероятно, заставит скрипт-кидди перейти к следующему серверу в их списке.

Допустим, мой сервер «надёжно защищён», и я не беспокоюсь, что атака методом перебора действительно увенчается успехом. Эти инструменты просто поддерживают чистоту моих лог-файлов или я получаю какую-то значимую выгоду от блокирования попыток атак методом перебора?

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

решение1

Ограничение количества попыток входа в систему — простой способ предотвратить некоторые атаки с высокой скоростью подбора пароля. Однако трудно ограничить распределенные атаки, и многие из них работают в медленном темпе в течение недель или месяцев. Лично я предпочитаю избегать использования автоматизированных инструментов реагирования, таких как fail2ban. И на это есть две причины:

  1. Законные пользователи иногда забывают свои пароли. Я не хочу банить законных пользователей на моем сервере, заставляя меня вручную снова включать их учетные записи (или, что еще хуже, пытаться выяснить, какой из 100/1000 запрещенных IP-адресов принадлежит им).
  2. IP-адрес не является хорошим идентификатором пользователя. Если у вас есть несколько пользователей за одним IP (например, школа, которая использует NAT на 500 компьютерах учеников), один пользователь, сделавший несколько неудачных попыток, может доставить вам массу неприятностей. В то же время большинство попыток подбора пароля, которые я вижу, распределены.

Поэтому я не считаю fail2ban (и подобные автоматизированные инструменты реагирования) очень хорошим подходом к защите сервера от атак методом подбора. Простой набор правил IPTables для сокращения спама в журналах (который у меня есть на большинстве моих серверов Linux) выглядит примерно так:

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP

Он предотвращает более 4 попыток подключения с одного IP к ssh в течение любого 60-секундного периода. Остальное можно сделать, обеспечив достаточно высокую надежность паролей. На серверах с высоким уровнем безопасности заставить пользователей использовать аутентификацию с открытым ключом — еще один способ прекратить угадывание.

решение2

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

решение3

Речь идет не только о сокращении шума - большинство атак ssh пытаются перебрать пароли. Так что, хотя вы увидите много неудачных попыток ssh, возможно, к тому времени, как будет сделана 2034-я ​​попытка, они получат действительное имя пользователя/пароль.

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

решение4

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

PasswordAuthentication no

Связанный контент