Вопрос: Предотвращение нападений грубой силы против ssh?


Какой инструмент или метод вы используете, чтобы предотвратить атаки грубой силы против вашего порта ssh. Я заметил в своих журналах безопасности, что у меня есть миллионы попыток входа в систему как различные пользователи через ssh.

Это находится в окне FreeBSD, но я полагаю, что это применимо в любом месте.


49
2018-05-04 17:46


Источник




Ответы:


Вот хороший пост по этому вопросу Райнер Вихманн.

В нем объясняются плюсы и минусы методов диссертаций:

  • Сильные пароли
  • Аутентификация RSA
  • Использование «iptables» для блокировки атаки
  • Использование журнала sshd для блокировки атак
  • Использование tcp_wrappers для блокировки атак
  • Стыковка портов

25
2018-05-05 16:53





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

Объедините это с проверкой силы пароля (используя Джон (John the Ripper)), чтобы атаки с грубой силой не удались.


39
2018-05-04 17:53



Fail2ban отлично. Было просто расширить его для мониторинга / var / log / maillog и заставить его запретить постоянным спамерам ударять мой почтовый сервер - Dave Cheney
Fail2ban можно комбинировать с цепочкой iptables, которая отправляет трафик tcp на TARPIT цель, если вы чувствуете себя отвратительно (от xtables-addons). - Tobu


Небольшая вещь, которую вы можете сделать, это использовать что-то вроде DenyHosts:

http://denyhosts.sourceforge.net/

Он использует встроенный hosts.allow / hosts.deny, чтобы блокировать злоумышленников SSH.


24
2018-05-04 18:06





  • Изменить порт используется в качестве Трент упоминается)
  • Требовать ключи шифрования вместо паролей. http://novosial.org/openssh/publickey-auth/
  • Черный список атакующий ips
  • Whitelist чтобы предотвратить случайный черный список. (как упоминал Самиуэла)

16
2018-05-04 17:53





Одним из самых простых способов избежать этих атак является изменение порта, который sshd прослушивает


15
2018-05-04 17:48



Если, конечно, система может выдержать это. - C. Ross
Безопасность через безвестность, эффективная каждый раз. - Chris Ballance
Я бы не стал сильно менять порт, но я узнал, что большинство брандмауэров (кроме моих собственных) имеют тенденцию блокировать все порты, кроме обычных (80,22, 443 и т. Д.). Если я за этими брандмауэрами, я не могу добраться до своего домашнего сервера на этом нестандартном порту. Для меня это не выход. - grieve
@grieve, затем измените наш брандмауэр, чтобы вывести этот порт? - Rory
@Roy Я говорю о брандмауэрах, кроме тех, которые у меня есть. Например, если я хочу ssh в мою домашнюю машину из Starbucks, их брандмауэр блокирует исходящий порт. Я не могу это изменить. (Я просто использовал Starbucks в качестве примера. Я понятия не имею, какие порты они фактически блокируют или нет). - grieve


Как указывает Крис, используйте ключи шифрования вместо паролей.

Добавьте к этому:

  • используйте белый список, где это возможно.

Сколько людей или мест (с плавающими публичными IP-адресами) вам действительно нужно получить доступ к вашим общедоступным подключениям ssh?

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

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


12
2018-05-23 17:36



Белый список очень важен, если вы делаете какие-либо черные списки, если не хотите, чтобы их заблокировали. - Ryaner
+1 для проактивного белого списка. - Chris Ballance
+1 за абсолютный лучший ответ. Эти две вещи являются единственными разумными шагами, и они действительно эффективны. Один из них стоит того, и оба вместе. Бу на других ответах, защищающих безопасность через неясность! - dwc


В дополнение к другим хорошим предложениям, одна очень легкая вещь - это входящие соединения с ограничением скорости. Ограничение до 3 подключений в минуту на IP:

iptables -A INPUT -p tcp --dport 22 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m limit --limit 3/min --limit-burst 3 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP

11
2018-05-21 09:04



Возможно, я что-то недопонимаю, но многие основные браузеры соединяются между 4-6 соединениями одновременно - хотя стандарт HTTP устанавливает его на 2. - Joshua Enfield
Да, это было бы проблемой, если бы вы пытались ограничить размер порта 80. Вы не подключаетесь к ssh с вашим веб-браузером, а сеансы ssh - это долгоживущие сеансы, которые поддерживают состояние, а не краткосрочные сессии без гражданства, такие как HTTP. Параллельные сеансы ssh, подобные этому, не имеют смысла. Это не означает, что нет никакой пользы ssh в том, что это сломается, но это редко. - sherbang
Это решение не так хорошо, если, как и я, вы обслуживаете Subversion через ssh. Один запрос SVN может быстро создавать множество соединений. Если вы предоставляете эту услугу, вы можете либо использовать вторую службу sshd на другом порту, либо использовать белые списки известных IP-адресов. Я думаю об использовании fail2ban или sshdfilter, чтобы в первый раз обнаруживать очевидные атаки, не наказывая моих законных пользователей. - paddy
хорошо знать этот вариант тоже ... - ZEE


Используйте параметр «AllowUsers» в sshd_config, чтобы обеспечить доступ только к небольшому набору пользователей. Все остальные будут отвергнуты, даже если их имя пользователя и пароль верны.

Вы даже можете ограничить пользователей входами из конкретный хост.

например.,

AllowUsers user1 user2@host.example.com

Это уменьшит пространство поиска и избежит тех старых пользователей, которые случайно оставлены на месте или включены (хотя они, конечно же, должны быть отключены в любом случае, это простой способ остановить их использование для входа на основе SSH).

Это не полностью останавливает атаки грубой силы, но помогает снизить риск.


6
2018-05-27 19:20