Комментарии 40
Всегда удивлялся умению написать целую статью из ничего.
TL;DR: $ sudo apt install fail2ban
Автору стоило бы хотя-бы написать, как fail2ban на nftables переключить, т.к. iptables - deprecated давно:
[DEFAULT]
banaction = nftables-multiport
banaction_allports = nftables-allports
chain = input
Однако это не считается хорошей практикой
Кем не считается? Наоборот, это довольно частая рекомендация и криминала никакого в этом нет.
Да и трудностей не возникнет с запоминанием портов, если добавить в .ssh/config
Файл конфигурации по умолчанию можно найти в /etc/fail2ban/jail.conf. Файл хорошо документирован и в основном не требует пояснений. Имейте в виду, что вам не следует вносить какие-либо изменения в этот файл, так как он может быть перезаписан во время обновления fail2ban.
Угу, а то что есть файл jail.local и то что надо бы включить mode = aggressive и bantime.increment = true не стоило разве написать ?
Поддерживаю.
Плюс от авторизации по ключам ещё в том, что не нужно пользователям особо монструозные пароли создавать.
Особенно когда внутри системы ограниченный круг пользователей работает.
ipset и banaction = iptables-ipset-proto6-allports, дабы не учить начинающих как быстро загадить правила iptables…
мои провайдеры к сожалению не осилили раздавать ipv6, поэтому я принял себе 6in4 от Hurricane Electric. И всё бы ничего но через раз scp одного и того же файла может как занять 5 минут так и пол часа если система решит что в ipv6 меньше хопов и поедет через него несмотря на то что скорость сильно ниже. пока не придумал как с этим бороться но как пойду в отпуск сяду над этим думать точно
Дальше в конфиге SSH сервера:
PasswordAuthentication no
PermitRootLogin no
Воображаемый пират потратит тысячелетия (посчитайте сами) пытаясь подобрать ваш нормальный 8-символьный пароль пусть даже со скоростью 1000 попыток в секунду (со стандартным SSH вы такой скорости не получите). А вот огрести блок от своего-же fail2ban'а не так уж сложно.
iptables -A INPUT! -i lo -m recent --name BLOCK-BOTNET --update --seconds $TIME2BAN --reap -j REJECT
iptables -A INPUT -p tcp -m multiport --dports 110,143,25,465,587,993,995,585,80,443,$SSH_PORT -j ACCEPT
iptables -A INPUT! -i lo -p tcp --syn -m recent --name BLOCK-BOTNET --set -j REJECT
главное повесить SSH на какой-то совсем рандомный TCP-порт типа 41936
а дальше явно разрешаем открытые публично порты, а любого кто стукнется на любой другой порт (в том числе и на 22) — в бан минимум на недельку.
Таким образом любой, кто попытается посканировать ваши открытые TCP-порты отправится в глухой бан на недельку после первой же попытки.
Только надо обязательно добавить в /etc/modprobe.d/xt_recent.conf строчку наподобие этой:
options xt_recent ip_list_tot=102400 ip_pkt_list_tot=4 ip_list_hash_size=0и либо перезагрузить модуль xt_recent, либо целиком перезагрузить систему.
они все равно будут использовать вашу пропускную способность и генерировать огромное количество журналов.
Вот от этого никакие баны не помогают — один IP редко ломится чаще чем два-три раза подряд (ровно столько сколько нужно для бана), а за сутки там сотни (временами и тысячи) разных IP накапливаются — ботнеты нынче умные пошли, распределяют нагрузку во избежание банов.
Так что либо белый список, либо port knocking, либо что-то подобное — единственный способ избавиться от мусора в журнале.
Лучше посмотреть в сторону sshguard. Быстрее и легче, чем fail2ban.
К fail2ban дополнительно использую denyhosts.net (с небольшим патчем). Но denyhosts больше не для защиты, а для распространения IP, которые пытаются подобрать пароль на других пользователей этого сервиса.
Ограничение попыток входа в ssh с помощью fail2ban (средство от ботов подбирающих пароли через ssh)