SSHD: разница между "соединение закрыто..." и "отключено от..." в файле журнала

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

Согласно с /var/log/auth.log файл, существует три разных типа сбоев из-за неизвестного идентификатора и IP-адреса:

• Отключено от недействительного пользователя...
• Соединение закрыто недействительным пользователем...
• Соединение закрыто пользователем xxx.xxx.xxx.xxx

В чем разница между тремя? Предполагает ли что-либо из них успешный (неавторизованный) вход в систему? особенно последний...

Я предполагая все это неудачные попытки на том основании, что я настроил SSH-сервер так, чтобы он запрашивал публичный ключ с IP-адреса, отличного от локальной сети, и ограничил вход только одним идентификатором пользователя без полномочий root.

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

я пытался использовать фейл2бан чтобы заблокировать повторные атаки с определенного IP, но это было серьезной ошибкой. Во-первых, не раньше чем через 24 часа злоумышленник(и) переключился на ротацию сотен уникальных IP-адресов. Второе (и более тревожное) фейл2бан кажется, не признает повторные попытки, которые приводят к Соединение закрыто пользователем xxx.xxx.xxx.xxx.

По соглашению с @tilman-schmidt, всего несколько центов с моей стороны (относительно fail2ban и т. д.)...

Люди OpenSSH постоянно меняют поведение ведения журнала, поэтому он может не учитываться fail2ban по умолчанию (это также зависит от того, где происходит отключение, например.на этапе предварительной аутентификации или после ввода имени пользователя, а также какие методы аутентификации разрешены в вашем sshd, а также при поведении «нарушителя»).

Я бы хотя бы установил LogLevel VERBOSE в sshd_config, как описано в /etc/fail2ban/filter.d/sshd.conf

Также обратите внимание на этот ответ на аналогичный вопрос - https://unix.stackexchange.com/questions/662946/fail2ban-regex-help-for-banning-sshd-connection-attempts/663002#663002

не раньше, чем через 24 часа, злоумышленники переключились на ротацию сотен уникальных IP-адресов.

Это никак не связано с использованием fail2ban — сканеры, найдя прослушиватель sshd, «опубликовали» его в каком-то из своих списков, чтобы можно было начать более глубокое сканирование (например, с распределенными ботнетами). Это печальная участь любого сервера с открытыми портами наружу.

Вы можете попробовать изменить порт ssh на что-то другое, но это просто избежит половины скриптовых детишек (если вы запретите попытки сканирования портов) и, по сути, вообще не панацея. Но вы можете резко сократить количество злоумышленников хотя бы на короткое время, до нескольких месяцев. Что может определенно помочь, так это включить bantime.increment в fal2ban (для джейла sshd или по умолчанию).

fail2ban, похоже, не признает повторные попытки, которые приводят к закрытию соединения

Это не совсем правильно. Вы должны установить режим = агрессивный за sshd тюрьма в тюрьма.местный чтобы позволить fail2ban рассмотреть любые виды «атак» (не только проблемы аутентификации), также происходящие с помощью сканеров портов и подобных DoS-вещей.

И вы можете увидеть, что именно найдет fail2ban с вашим текущим фильтром с помощью этой команды (примечание совпало в последней строке результата):

fail2ban-regex /var/log/auth.log 'sshd [режим = агрессивный]'