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

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

Я видел, как утверждается, что это театр безопасности на «должным образом защищенном» сервере. Тем не менее, я чувствую, что это, вероятно, заставляет детей сценариев переходить на следующий сервер в их списке.

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

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

Попытки входа в систему с ограничением скорости - это простой способ предотвратить некоторые атаки по подбору пароля. Тем не менее, сложно ограничить количество распределенных атак, и многие из них работают медленными темпами в течение недель или месяцев. Я лично предпочитаю избегать использования инструментов автоматического ответа, таких как 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-секундный период. Остальные могут быть обработаны, если пароли достаточно надежны. На серверах с высоким уровнем безопасности принуждение пользователей к использованию аутентификации с открытым ключом является еще одним способом прекратить догадки.

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

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

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

Что ж, это несколько спасает вашу сеть от атак типа «отказ», а также снижает накладные расходы на обработку сбоев.

Не быть самым слабым сервером в списке детишек скриптов - это всегда хорошо.

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

PasswordAuthentication no