Безопасно ли применять fail2ban к журналам sshd «Получено отключение/Отключено ... [preauth]»?

Question

Я вижу много подобных журналов в /var/log/auth.log(Debian Buster):

Jan  2 17:10:17 mybox sshd[16304]: Received disconnect from 1.2.3.4 port 37792:11: Bye Bye [preauth]
Jan  2 17:10:17 mybox sshd[16304]: Disconnected from authenticating user root 1.2.3.4 port 37792 [preauth]
Jan  2 17:10:20 mybox sshd[16306]: Received disconnect from 5.6.7.8 port 63061:11: Bye Bye [preauth]
Jan  2 17:10:20 mybox sshd[16306]: Disconnected from authenticating user root 5.6.7.8 port 63061 [preauth]
Jan  2 17:12:38 mybox sshd[16380]: Received disconnect from 9.10.11.12 port 55224:11: Normal Shutdown, Thank you for playing [preauth]
Jan  2 17:12:38 mybox sshd[16380]: Disconnected from authenticating user root 9.10.11.12 port 55224 [preauth]

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

Соответствующего правила в /etc/fail2ban/filter.d/sshd.conf, поэтому эти попытки не заставят fail2ban забанить нарушающий IP-адрес.

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

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

Безопасно ли мне добавлять Regexp, соответствующий некоторым из этих строк, или я рискую, сопоставляя легитимные (на основе ключей) попытки входа в систему? Какие части составят безопасную комбинацию? Будет ли соответствие словам "Disconnected" и тегу "[preauth]" обязательно указывать на неудачный подбор пароля?

Answer 1

Соответствующего правила в /etc/fail2ban/filter.d/sshd.conf нет, поэтому эти попытки не заставят fail2ban заблокировать подозрительный IP-адрес.

Какую версию вы используете? Fail2Ban поставляется с предопределенным правилом по этому поводу, включенным в общее failregex, используемое всеми режимами.

Fail2Ban v0.10.2 в одной из моих систем включает следующее правило:

^<F-NOFAIL>Received <F-MLFFORGET>disconnect</F-MLFFORGET></F-NOFAIL> from <HOST>: 11:

А Fail2Ban v0.11.2 включает в себя вот это (что лучше):

^<F-NOFAIL>Received <F-MLFFORGET>disconnect</F-MLFFORGET></F-NOFAIL> from <HOST>%(__on_port_opt)s:\s*11:

Видимо, разработчики посчитали, что любая из следующих строк

Received disconnect from <HOST>: 11:
Received disconnect from <HOST> port XXXXX:11:

будет достаточно. Соответствующие ключевые слова Received disconnect fromи : 11:часть (вместо [preauth]суффикса).

Это <F-NOFAIL>означает, что эта строка не является ошибкой и будет ожидать другого совпадения без <F-NOFAIL>блокировки IP, поэтому вам придется удалить окружающие теги.

Answer 2

Безопасно ли мне добавлять Regexp, соответствующий некоторым из этих строк, или я рискую, сопоставляя легитимные (на основе ключей) попытки входа в систему? Какие части составят безопасную комбинацию? Будет ли соответствие словам "Disconnected" и тегу "[preauth]" обязательно указывать на неудачный подбор пароля?

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

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

Вы можете использовать этот фрагмент (например, как cmdfailre) в Debian buster:

^Received disconnect from <HOST>%(__on_port_opt)s:11: \s* %(__suff)s$
^Disconnected from authenticating user <F-USER>.*?</F-USER> <HOST>%(__on_port_opt)s %(__suff)s$

Answer 3

Я включил эту функцию, установив mode = massive в [sshd] в моем файле jail.local