Действительно ли это стоит усилия заблокировать отказавшие попытки входа в систему
Да, можно использовать LDAP. Если Вы рады позволить пользователям использовать пароли, можно сохранить пароли в LDAP и использовать nss ldap и pam ldap, чтобы идентифицировать и аутентифицировать пользователей из каталога соответственно.
Необходимо будет поставить некоторые пользовательские атрибуты пользователям в LDAP, чтобы дать им идентификаторы пользователя UNIX и пароли.
Если Вы захотите ssh ключи, то необходимо будет установить патч к sshd, который берет его ключи от LDAP, это обычно не опция. Это - то, что мы используем, это работает действительно хорошо (несколько дюжин уполномоченных инженеров, 650 + серверы).
Уровень, ограничивающий попытки входа в систему, является простым способом предотвратить некоторые высокоскоростные нападения подбора пароля. Однако трудно ограничить распределенные нападения, и многие работают в низком темпе за недели или месяцы. Я лично предпочитаю избегать использования инструментов автоматического ответа как fail2ban. И это по двум причинам:
- Законные пользователи иногда забывают свои пароли. Я не хочу запрещать законным пользователям свой сервер, вынуждая меня вручную включить их учетные записи снова (или хуже, попытайтесь выяснить, какой из запрещенных IP-адресов 100/1000 их).
- 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 помогают уменьшить ненужный сетевой трафик и сохранить файлы журнала немного меньшими и более чистыми. Это не большая панацея безопасности, но делает жизнь системного администратора немного легче; вот почему я reccomend, использующий fail2ban в системах, где можно предоставить его.
Не примерно сокращающий шум - большинство нападений ssh пробует к предположениям "в лоб" в паролях. Таким образом, в то время как Вы будете видеть много неудавшихся попыток ssh, возможно к тому времени, когда это получает 2034-ю попытку, они могли бы получить допустимое имя пользователя/пароль.
хорошая вещь о fail2ban по сравнению с другими подходами состоит в том, что он имеет минимальный эффект на попытки подходящих соединений.