Я настраиваю сервер LAMP и должен предотвратить SSH / FTP / и т. Д. попытки входа в систему методом грубой силы не удаются. Я видел много рекомендаций как для denyhosts, так и для fail2ban, но сравнений мало. Я также читал, что правило IPTables может выполнять ту же функцию.
Почему я выбрал бы один из этих методов по сравнению с другим? Как люди на сервере справляются с этой проблемой?
Ответы:
IIRC, DenyHosts будет только наблюдать за вашей службой SSH. Если вам это нужно и для защиты других сервисов, Fail2ban определенно станет лучшим выбором. Можно настраивать просмотр практически любого сервиса, если вы хотите настроить его конфигурацию, но в этом нет необходимости, поскольку более новые версии Fail2ban включают наборы правил, которые подходят для многих популярных серверных демонов. Преимущество использования fail2ban сверх простого ограничения скорости iptables заключается в том, что он полностью блокирует злоумышленника на определенный период времени, а не просто снижает скорость, с которой он может взломать ваш сервер. Я использовал fail2ban с отличными результатами на ряде производственных серверов и никогда не видел, чтобы один из этих серверов был взломан перебором с тех пор, как я начал его использовать.
Не позволяйте им добраться до вашей машины в первую очередь! Есть много способов остановить попытки перебора до того, как они попадут на ваш хост или даже на уровне SSH.
Сказав это, защита вашей операционной системы с помощью что-то вроде fail2ban - отличная идея. Fail2ban немного отличается от DenyHosts, хотя они играют в одном пространстве. Fail2ban использует iptables.
http://en.wikipedia.org/wiki/Fail2ban
Fail2ban похож на DenyHosts ... но в отличие от DenyHosts, который ориентирован на SSH, fail2ban может быть настроен для мониторинга любой службы, которая записывает попытки входа в файл журнала, и вместо использования /etc/hosts.deny только для блокировки IP-адресов / хостов , fail2ban может использовать Netfilter / iptables и TCP Wrappers /etc/hosts.deny.
Существует ряд важных методов обеспечения безопасности, которые следует учитывать для предотвращения грубых входов в систему:
SSH:
Заявка:
Я использую правила iptables для ограничения скорости новых подключений с одного и того же IP-адреса (главным образом, по SSH, но и для FTP это тоже подойдет). На мой взгляд, преимущество по сравнению с «fail2ban» и другими подобными инструментами состоит в том, что маршрут iptables происходит полностью в режиме ядра и не зависит от каких-либо инструментов пользовательского режима для привязки / анализа файлов журнала.
Если вы можете это сделать, ограничение адресов источника, которые могут обращаться к рассматриваемым протоколам, очевидно, также поможет.
С SSH вы действительно должны использовать проверку подлинности сертификата и не принимать пароли в любом случае.
ДРУГОЙ БОЛЬШОЙ СПОСОБ ЗАЩИТИТЬ SSH (я использовал это в течение десятилетия или лучше) - использовать последние библиотеки в iptables изначально (в зависимости от вашего дистрибутива).
По сути, это может быть использовано как стук порта, встроенный в iptables. Это избавит вас от головной боли. До тех пор, пока вы можете tcp connect (telnet - это один из способов. Я также использовал ssh-клиенты и указывал их на порт. Все, что будет делать tcp-соединение с указанным номером порта. Я смотрю на вас, Putty!) Из клиент, инициирующий соединение ssh, вы можете использовать это.
Ниже приведен пример, в котором iptables будет иметь открытый порт 22 для вашего хоста, когда вы будете использовать telnet с вашего хоста на сервер через порт 4103. Затем вы можете использовать telnet для порта 4102 или 4104, чтобы закрыть открытие sed. Причина как для 4102, так и для 4104 состоит в том, чтобы не открывать простое сканирование tcp 22. Только tcp-соединение (telnet) с портом 4103 позволит вам войти.
Наслаждайтесь!
Ох, и я предпочитаю Fail2Ban. Больше гибкости, и мне нравится, что бан происходит в iptables, а не в tcpwrappers.
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -m recent --rcheck --name SSH -j ACCEPT
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 4102 -m recent --name SSH --remove -j DROP
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 4103 -m recent --name SSH --set -j DROP
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 4104 -m recent --name SSH --remove -j DROP
Еще одно различие между Fail2ban и Denyhosts заключается в том, что Denyhosts может делиться списком блокировки с другими пользователями Denyhosts. С Fail2ban вы можете заблокировать только те IP-адреса, которые ваш сервер видел раньше - с помощью Denyhosts, попытка грубой силы может даже не попасть на ваш сервер, если кто-то еще видел это, и список блокировки загружается на ваш сервер перед атакующим добирается до вашего компьютера.
Еще одно отличие состоит в том, что Fail2ban использует iptables, а Denyhosts использует tcpwrappers. Другие уже упоминали об этой разнице, но есть пара замечаний, которые стоит упомянуть.
В iptables ограничено количество IP-адресов, которые вы можете эффективно заблокировать. Вероятно, это одна из причин, по которой Fail2ban не имеет механизма для совместного использования списков блокировки.
Другой эффект заключается в том, что когда iptables заменяется на nftables, Fail2ban, вероятно, перестанет работать или его необходимо переписать. Denyhosts, вероятно, продолжит работать.
Таким образом, оба имеют свои преимущества и недостатки. Мне нравятся оба; для себя я использую Denyhosts, потому что обычно я хочу защитить только SSH, и мне нравится делиться списком блокировки.
Что касается Fail2Ban, то следует отметить, что он использует на 10 МБ больше памяти, чем DenyHosts. Так что, если вы используете 128 МБ VPS, вы можете посмотреть на это. Кроме того, out-of-the-box fail2ban настроен только на SSH, что означает, что без изменений в конфигурации - DenyHosts делает то же самое с меньшим объемом памяти.
denyhosts для ssh. fail2ban является более полным (HTTP, FTP и т. д.). Оба используют iptables за кулисами.
Вместо того, чтобы возиться с утомительными настройками iptables или fail2ban, почему бы не сделать так, чтобы открытое сообщество сделало всю работу за вас, а вместо этого использовало CSF / LFD? Я настоятельно рекомендую это выше всех других упомянутых вариантов. Посмотрите http://configserver.com/cp/csf.html, что он может сделать для ваших серверов. CSF не требует панели управления, он предлагает простой пользовательский интерфейс для тех, кто не хочет делать это с помощью оболочки. И это много стабильных надежных нерезидентных perl-скриптов.
Похоже, что fail2ban не имеет механизма для распознавания успешного входа в ssh и сброса количества ошибок.
Стандартный фильтр для sshd (по крайней мере, при моей установке Debian) фиксирует счетчик ошибок для каждого ключа ssh, который клиент представляет, который сервер отклоняет. Некоторые пользователи предоставляют много ключей при каждом входе в систему и регулярно блокируются, несмотря на то, что их вход был успешным после прохождения нескольких ключей.
В результате вышесказанного я сейчас думаю о том, чтобы отойти от fail2ban. В этом отношении, по крайней мере, лучше денегостов. Однако, по-видимому, он больше не является хорошим вариантом и больше не поддерживается в более поздних версиях Debian (некоторые обсуждения на https://www.chrissearle.org/2015/06/16/replacing-denyhosts-with-fail2ban-for- Debian / )
У меня нет хорошего решения здесь.
На самом деле, я думаю, что denyHost способен предотвратить множество других сервисов, кроме сервиса sshd. В его конфигурационном файле /etc/denyhosts.confесть несколько строк кода:
# BLOCK_SERVICE: the service name that should be blocked in HOSTS_DENY
#
# man 5 hosts_access for details
#
# eg. sshd: 127.0.0.1 # will block sshd logins from 127.0.0.1
#
# To block all services for the offending host:
BLOCK_SERVICE = ALL
# To block only sshd:
# BLOCK_SERVICE = sshd
поэтому, если мы установим BLOCK_SERVICEпеременную, ALLкак указано выше, мы сможем посмотреть наш сервис ssh.
Denyhosts версия 3.0: Каждый раз, когда IP-адрес появляется в файле журнала, Denyhosts открывает файл hosts.deny и считывает все, что соответствует адресу. Каждый раз. Ничто не кешируется в памяти. Если у вас огромный файл hosts.deny и вы подвергаетесь множеству проверок (много записей в файле журнала), Denyhosts становится процессором, считывающим данные и перечитывающим файл hosts.deny для каждого отображаемого IP-адреса. Фигово.
Если вы включите поддержку iptables, Denyhosts будет создавать огромные, медленные списки заблокированных IP-адресов. Denyhosts не использует ipset или nftables для создания эффективных карт IP.