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

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

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

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

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

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

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

В нем объясняются плюсы и минусы этих методов:

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

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

http://denyhosts.sourceforge.net/

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

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

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

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

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

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

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

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

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

В дополнение к другим хорошим предложениям можно очень просто ограничить скорость входящих соединений. Ограничение до 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

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

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

например.,

AllowUsers user1 user2@host.example.com

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

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

Используйте что-то подобное с PF:

таблица <ssh-brute> сохраняется
блокировать в быстром журнале с ярлыка ssh_brute
передать через $ ext_if proto tcp в ($ ext_if) порт ssh modulate state \
(max-src-conn-rate 3/10, глобальный сброс перегрузки)

Порт-стук это довольно надежный способ не допускать подобных вещей. Немного неудобно, иногда раздражает, но это определенно решает проблему.

Контекст важен, но я бы порекомендовал что-то вроде этого:

  • Поскольку вы используете FreeBSD, подумайте о том, чтобы запустить брандмауэр PF и использовать его надежные функции ограничения скорости соединения. Это позволит вам отправить брутфорсеры в черный список, если они подключаются часто.
  • Если к этому ящику необходимо получить доступ из внешнего мира, рассмотрите возможность использования правила PF rdr, чтобы не разрешать трафик на порт 22, а перенаправить на него какой-то непонятный порт. Это означает, что вам нужно подключиться к порту 9122 вместо 22. Это непонятно, но уберегает молотки.
  • рассмотреть возможность перехода на аутентификацию только на основе ключей, что сделает атаки по словарям бесполезными

Дальше к Предложение Шербанга по ограничению скорости, важна продолжительность задержки. При увеличении задержки между группами из 3 попыток входа с 2 до 20 минут количество различных IP-адресов, которые сделали более трех попыток входа в систему, уменьшилось, по сравнению с двумя недельными периодами на одной моей машине, с 44 попыток до 3 Ни один из этих трех адресов не пытался больше 11 часов.

Очень анекдотично, но auth.log стал для меня намного более читабельным ...

Меня это просто не волнует. Пусть бьют в порту, они не собираются взламывать ключ.

установить OSSEC. Он не только отслеживает повторные входы в систему, но и вводит временный блок с iptables для нарушающего IP. И в конце он отправит вам отчет с подробностями. он регистрирует все, что приятно. Somone однажды попробовал более 8000 имен для входа в систему. я проанализировал логи и получил хороший список пользователей;)