Какой инструмент или технику вы используете, чтобы предотвратить атаки методом грубой силы на ваш ssh-порт. Я заметил в своих журналах безопасности, что у меня миллионы попыток войти в систему как различные пользователи через ssh.
Это на коробке FreeBSD, но я думаю, что это применимо где угодно.
Ответы:
Вот хороший пост на эту тему от Райнера Вихмана.
Здесь объясняются плюсы и минусы этих методов:
Я использую fail2ban, который блокирует IP после нескольких неудачных попыток в течение настраиваемого промежутка времени.
Объедините это с проверкой надежности пароля (используя Джона (Джона Потрошителя)), чтобы гарантировать, что атаки методом перебора не будут успешными.
TARPITцели, если вы чувствуете себя противно (из xtables-addons).
Небольшая вещь, которую вы можете сделать, это использовать что-то вроде DenyHosts:
http://denyhosts.sourceforge.net/
Он использует встроенный hosts.allow / hosts.deny, чтобы заблокировать злоумышленников SSH.
Один из самых простых способов избежать этих атак - изменить порт, который прослушивает 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 модулирует состояние \
(max-src-conn-rate 3/10, глобальная перегрузка сброса)
Стук в порт - довольно надежный способ не допустить подобных вещей. Немного беспокойно, иногда раздражает, но это определенно заставляет проблему уйти.
Контекст важен, но я бы порекомендовал что-то вроде этого:
В дополнение к предложению Шербанга об ограничении скорости важна длительность задержки. Из-за увеличения задержки между группами из 3 попыток входа в систему с 2 минут до 20 минут количество различных IP-адресов, для которых было выполнено более трех попыток входа в систему, сократилось, сравнив два недельных периода на одной моей машине, с 44 попыток до 3. Ни один из этих трех адресов не пытался работать дольше 11 часов.
Очень анекдотично, но auth.log стал намного более читабельным для меня ...
Мне просто все равно. Пусть они пристегнутся в порту, они не собираются перебивать ключ.
установить OSSEC. он не только отслеживает повторные входы в систему, но и вводит временный блок с iptables для вызывающего ip. И в конце он отправит вам отчет с указанием деталей. он регистрирует все, что приятно. Сомоне однажды попробовал более 8000 имен для входа в систему. я проанализировал логи и получил хороший список пользователей из сделки;)