Назад | Перейти на главную страницу

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

Я настраиваю сервер LAMP, и мне нужно запретить SSH / FTP / и т. Д. попытки входа в систему методом грубой силы не увенчались успехом. Я видел много рекомендаций как для denyhosts, так и для fail2ban, но мало их сравнивал. Я также читал, что правило IPTables может выполнять ту же функцию.

Почему я должен предпочесть один из этих методов другому? Как люди на serverfault справляются с этой проблемой?

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:

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

Заявка:

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

ЕЩЕ ОДИН ВЕЛИКИЙ СПОСОБ ЗАЩИТЫ SSH (Я использовал это десятилетие или лучше) - использовать последние библиотеки в iptables изначально (в зависимости от вашего дистрибутива).
В основном его можно использовать как встроенный в iptables. Это избавит вас от множества головных болей. Пока вы можете подключиться по tcp (telnet - это один из способов. Я также использовал клиентов ssh и указывал им на порт. Все, что будет выполнять TCP-соединение с указанным номером порта. Я смотрю на вас, Putty!) клиент, инициирующий соединение ssh, вы можете использовать это.

Ниже приведен пример, в котором iptables открывает порт 22 для вашего хоста, когда вы telnet с вашего хоста на сервер на порт 4103. Затем вы можете использовать telnet для порта 4102 или 4104, чтобы закрыть открытие sed. Причина как для 4102, так и для 4104 состоит в том, чтобы не открывать простое сканирование tcp 22. Только TCP-соединение (telnet) к порту 4103 позволит вам войти.

Наслаждайтесь!

О, и я предпочитаю Fail2Ban. Больше гибкости, и мне нравится, что запрет происходит в iptables, а не в tcpwrappers.

SSH PORTKNOCKING

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

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

Сотни неудачных попыток входа по ssh

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

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

Еще одно различие между Fail2ban и Denyhosts заключается в том, что Denyhosts может делиться списком блокировки с другими пользователями Denyhosts. С Fail2ban вы можете блокировать только IP-адреса, которые ваш сервер видел раньше - с Denyhosts попытка грубой силы может даже не добраться до вашего сервера, если кто-то другой его видел, и список блокировки загружается на ваш сервер до того, как злоумышленник попадает к вашему компьютеру.

Еще одно отличие состоит в том, что Fail2ban использует iptables, а Denyhosts - tcpwrappers. Другие уже упоминали об этой разнице раньше, но есть пара замечаний, которые стоит упомянуть.

iptables ограничен в количестве IP-адресов, которые вы можете эффективно заблокировать. Вероятно, это одна из причин, по которой Fail2ban не имеет механизма для обмена списками блокировки.

Другой эффект заключается в том, что при замене iptables на nftables Fail2ban, вероятно, перестанет работать или его нужно будет переписать. Denyhosts, скорее всего, продолжит работу.

Итак, у обоих есть достоинства и недостатки. Мне нравятся оба; для себя я использую Denyhosts, потому что обычно я хочу защитить только SSH, и мне нравится делиться списком блокировки.

Следует отметить, что Fail2Ban использует примерно на 10 МБ памяти больше, чем DenyHosts. Так что, если у вас 128MB VPS, вы можете это изучить. Кроме того, по умолчанию 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. По крайней мере, в этом отношении denyhosts лучше. Однако, очевидно, что это уже не лучший вариант, и он больше не поддерживается в более поздних версиях 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-карт.