Denyhosts vs fail2ban vs iptables- лучший способ предотвратить грубые входы в систему?

лучший способ предотвратить грубые входы в систему?

Не позволяйте им добраться до вашей машины в первую очередь! Есть много способов остановить попытки перебора до того, как они попадут на ваш хост или даже на уровне 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:

• Не разрешать пользователю root вход в систему
• Не разрешать пароли ssh (используйте аутентификацию с закрытым ключом)
• Не слушайте на каждом интерфейсе
• Создайте сетевой интерфейс для SSH (например, eth1), который отличается от интерфейса, с которого вы обслуживаете запросы (например, eth0)
• Не используйте общие имена пользователей
• Используйте список разрешений и разрешайте только пользователям, которым требуется доступ по SSH
• Если вам требуется доступ в Интернет... Ограничьте доступ к конечному набору IP-адресов. Один статический IP-адрес идеален, однако его блокировка до xx0.0/16 лучше, чем 0.0.0.0/0.
• Если возможно, найдите способ подключения без доступа к Интернету, таким образом вы можете запретить весь интернет-трафик для SSH (например, с помощью AWS вы можете получить прямое соединение в обход Интернета, оно называется Direct Connect)
• Используйте программное обеспечение, как fail2ban, чтобы поймать любые атаки грубой силы
• Убедитесь, что ОС всегда обновлена, в частности, пакеты безопасности и ssh

Заявка:

• Убедитесь, что ваше приложение всегда обновлено, в частности пакеты безопасности
• Заблокируйте страницы приложения "admin". Многие из приведенных выше советов относятся и к административной области вашего приложения.
• Пароль Защитите вашу область администратора, что-то вроде htpasswd для веб-консоли спроецирует любые основные уязвимости приложений и создаст дополнительный барьер для входа
• Заблокируйте права доступа к файлам. "Загрузите папки" известны тем, что они являются точками входа для всякого рода неприятных вещей.
• Рассмотрите возможность размещения вашего приложения за пределами частной сети и предоставьте только ваш балансировщик внешней нагрузки и панель переключения (это типичная установка в AWS с использованием VPC)

ДРУГОЙ БОЛЬШОЙ СПОСОБ ЗАЩИТИТЬ 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.

SSH ПОРТНОКИНГ

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, и мне нравится делиться списком блокировки.

Я использую правила iptables для ограничения скорости новых подключений с одного и того же IP-адреса (в основном SSH, но для FTP это тоже хорошо бы работало). На мой взгляд, преимущество по сравнению с "fail2ban" и другими подобными инструментами состоит в том, что маршрут iptables происходит полностью в режиме ядра и не зависит от каких-либо инструментов пользовательского режима для привязки / анализа файлов журнала.

Сотни неудачных логинов SSH

Если вы можете это сделать, ограничение адресов источника, которые могут обращаться к рассматриваемым протоколам, очевидно, также поможет.

С SSH вы действительно должны использовать проверку подлинности сертификата и не принимать пароли в любом случае.

Что касается Fail2Ban, то следует отметить, что он использует на 10 МБ больше памяти, чем DenyHosts. Так что, если вы используете 128 МБ VPS, вы можете посмотреть на это. Кроме того, out-of-the-box fail2ban настроен только на SSH, что означает, что без изменений в конфигурации - DenyHosts делает то же самое с меньшим объемом памяти.

Denyhosts для ssh. fail2ban является более полным (HTTP, FTP и т. д.). Оба используют iptables за кулисами.

Denyhosts версия 3.0: Каждый раз, когда IP-адрес появляется в файле журнала, Denyhosts открывает файл hosts.deny и считывает все, что соответствует адресу. Каждый раз. Ничто не кешируется в памяти. Если у вас огромный файл hosts.deny и вы подвергаетесь множеству проверок (много записей в файле журнала), Denyhosts становится процессором, считывающим данные и перечитывающим файл hosts.deny для каждого отображаемого IP-адреса. Нехорошо.

Если вы включите поддержку iptables, Denyhosts будет создавать огромные, медленные списки заблокированных IP-адресов. Denyhosts не использует ipset или nftables для создания эффективных карт IP.

Похоже, что fail2ban не имеет механизма для распознавания успешного входа в ssh и сброса количества ошибок.

Стандартный фильтр для sshd (по крайней мере, при моей установке Debian) фиксирует счетчик ошибок для каждого ключа ssh, который клиент представляет, который сервер отклоняет. Некоторые пользователи предоставляют много ключей при каждом входе в систему и регулярно блокируются, несмотря на то, что их вход был успешным после прохождения нескольких ключей.

В результате вышесказанного я сейчас думаю о том, чтобы отойти от fail2ban. В этом отношении, по крайней мере, лучше денегостов. Однако, по-видимому, он больше не является хорошим вариантом и больше не поддерживается в более поздних версиях Debian (некоторые обсуждения на https://www.chrissearle.org/2015/06/16/replacing-denyhosts-with-fail2ban-for-debian/)

У меня нет хорошего решения здесь.

Вместо того, чтобы возиться с утомительными настройками iptables или fail2ban, почему бы не сделать так, чтобы открытое сообщество сделало всю работу за вас, а вместо этого использовало CSF/LFD? Я настоятельно рекомендую это выше всех других упомянутых вариантов. Посмотрите http://configserver.com/cp/csf.html что он может сделать для ваших серверов. CSF не требует панели управления, он предлагает простой пользовательский интерфейс для тех, кто не хочет делать это с помощью оболочки. И это много стабильных надежных нерезидентных perl-скриптов.

На самом деле, я думаю, что 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.