Каковы плюсы / минусы различных методов блокирования SSH-атак методом перебора?

Существует ряд различных пакетов, позволяющих исключить IP-адреса, с которых в вашей системе запускаются атаки методом перебора SSH. Например:

• DenyHosts
• Sshguard
• fail2ban

Каковы плюсы / минусы этих или каких-либо других?

Мое текущее решение - взять электронную почту, которую logwatch генерирует каждый день, и записать вопиющие IP-адреса в текстовый файл, который я передаю в скрипт, который затем перестраивает iptables. Это хакерский, трудоемкий и ручной, и я бы хотел лучше.

(Обратите внимание, что я не спрашивал, что было «лучшим» способом решения проблемы, потому что не существует «лучшего» способа что-либо сделать.)

Я использую DenyHosts, поэтому я могу хотя бы ответить за это:

Pros

• Это полностью автоматический
• Это настраивается (сколько неудачных попыток перед занесением в черный список, для имен пользователей, которые не существуют, имен пользователей, которые существуют, и специальной записи для пользователя root)
• Он может периодически отправлять вам список новых хостов, занесенных в черный список, и / или запускать определенную программу каждый раз, когда новый хост заносится в черный список.
• Он поддерживает автоматическое удаление черных хостов через некоторое время

Cons

У меня нет никаких непоправимых минусов, если вы используете это правильно:

• В конфигурации по умолчанию он не будет предупреждать вас о новых хостах, занесенных в черный список, поэтому, если кто-то атакует вашу сеть с сотен разных адресов, вы можете не заметить сразу, как если бы вы отслеживали свои журналы вручную, но (как упоминалось в раздел «Плюсы») он может отправить вам электронное письмо или запустить исполняемый файл, чтобы предупредить вас о добавлении новых хостов
• По умолчанию он будет помещать ваши хосты в черный список так же, как и любые другие, так что вы, вероятно, захотите добавить их в /etc/hosts.allow. Я заблокировал себя один раз, просто не набрав свой пароль, и как только кто-то с работы попытался войти в мою корневую учетную запись в шутку и занес в черный список мой рабочий IP, мне потребовалось несколько дней, чтобы понять, почему я вдруг не смог подключиться в мою сеть с работы больше

Другой - fail2ban , который использует iptables (поэтому он работает с любым сервисом, а не только с ssh). С fail2ban вы можете:

• Укажите путь к любому файлу журнала (apache, ssh, nginx, почтовый сервер, ...).
• Укажите регулярное выражение для шаблонов атак (например, более 10 «404 ошибок» за один и тот же ip в журнале доступа nginx за 6 секунд)
• Укажите регулярное выражение, чтобы игнорировать определенные шаблоны (очень полезно!)
• Укажите время запрета
• Отправить электронное письмо (или любое другое оповещение ...)
• Полностью настраиваемый (вы можете написать свои собственные оповещения и фильтры)

Одним из «недостатков» DenyHosts является то, что ему требуются tcp-оболочки, поэтому он будет работать только с сервисами, которые смотрят на файл /etc/hosts.deny. Но если быть честным с DenyHosts, sshd скомпилирован для использования TCP Wrappers в большинстве дистрибутивов Linux. Я также считаю, что DenyHosts проще настроить из коробки, чем fail2ban (но менее мощный).

Ссылка на подобный вопрос SF

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

Большинство методов предотвращения атак ssh brute force являются отличными способами самостоятельного DoS (упс, я испортил конфигурацию! К сожалению, я сделал несколько быстрых rsync и теперь забанен на день!) Или Assisted-Self-DoS (упс злоумышленник пришел из / подорвал машину в той же подсети, что и я (динамический диапазон IP, сеть колледжа ...), и меня тоже забанят!).

Если вы входите в систему только из нескольких мест, вы можете просто внести IP-адреса источника в белый список. Это явно бесполезно, если вы хотите ssh со своего ноутбука или мобильного телефона на ходу.

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

Другой метод, который вы не упоминаете, - это стук в порт . Он не страдает от проблем с самообслуживанием (кроме неправильной конфигурации), но он плохо пересекает брандмауэры и может добавить задержку в несколько секунд для установления соединения.

Если у вас есть надежные пароли или вы можете жить без аутентификации по паролю, отключите аутентификацию по паролю. (Ключи и одноразовые пароли достаточны для большинства случаев использования: если вы недостаточно доверяете клиентскому компьютеру для хранения ключа ssh, вы также не доверяете ему не иметь кейлоггер). Тогда атаки методом грубой силы будут стоить вам немного ресурсов ЦП и пропускной способности, но не будут подвергать вас вторжению (если вы проверили, что ни один из ваших ключей не был получен из низкоэнтропийного OpenSSL Debian ).

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