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

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

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

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

http://denyhosts.sourceforge.net/

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

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

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

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

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

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

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

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

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

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

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

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

например,

AllowUsers user1 user2@host.example.com

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

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

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

таблица сохраняться
блок в быстром логе от ярлыка ssh_brute
передать протокольный протокол $ext_if в ($ext_if) состояние модуляции ssh порта \
(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. И в конце он отправит вам отчет с указанием деталей. это регистрирует все, что приятно. Сомоне однажды попробовал более 8000 имен для входа в систему. я проанализировал логи и получил хороший список пользователей из сделки;)