1

I'm seeing a lot of logs like these in /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]

I know these are attempts to break in, because no one should be attempting to log in that machine (other than me).

There is no corresponding rule in /etc/fail2ban/filter.d/sshd.conf, so these attempts don't cause fail2ban to ban the offending IP address.

I have disabled password login, so I guess that what happens here is these attempts are dropped before they even attempt to authenticate, and for that reason fail2ban is not picking them up.

However, since I know these are break in attempts, I would still like to ban the IP, to stop them trying other things and filling up my logs.

Is it safe for me to add a Regexp matching some of those lines, or would I risk matching legitimate (key based) login attempts ? Which parts would make a safe combination ? Would matching the words "Disconnected" and the tag "[preauth]" necessarily indicate a failed password-based brute force ?

Alice Heaton
  • 113
  • 1
  • 4

3 Answers3

2

There is no corresponding rule in /etc/fail2ban/filter.d/sshd.conf, so these attempts don't cause fail2ban to ban the offending IP address.

What version are you using? Fail2Ban comes with a predefined rule about this, included in the common failregex used by all modes.

Fail2Ban v0.10.2 in one of my systems includes this rule:

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

And Fail2Ban v0.11.2 includes this one (which is better):

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

Apparently the developers thought that any of the following lines

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

will suffice. The relevant keywords being Received disconnect from and the : 11: part (instead of the [preauth] suffix).

The <F-NOFAIL> means that this line isn't a failure and will expect another match without <F-NOFAIL> to ban the IP, so you will have to remove the surrounding tags.

AndroidX
  • 238
  • 1
  • 6
  • 1
    Thanks that was useful :) I'm running v0.10.2, which includes the first variant. This variant doesn't actually match my logs, which includes the port number. The v0.11.2 would match,though I think I'll add custom rules manually rather than use a version which is not the packaged one. Also, as you point out, the tag means these won't trigger as I don't have other matching rules. – Alice Heaton Jan 09 '21 at 09:37
0

Is it safe for me to add a Regexp matching some of those lines, or would I risk matching legitimate (key based) login attempts ? Which parts would make a safe combination ? Would matching the words "Disconnected" and the tag "[preauth]" necessarily indicate a failed password-based brute force ?

A legitimate successful connection and authentication does not trigger such log lines. These entries can come from scanners, which do not cause harm, but can be be blocked as well. preauth means, those clients did not start authentication yet.

Even if you yourself cause a failed login, either by using wrong keys or mistyping the password, using fail2ban is still okay. fail2ban only blocks after a configurable number of matching log lines and only for a certain time frame.

You can use this snippet (e.g. as cmdfailre) in 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$
sebix
  • 4,313
  • 2
  • 29
  • 47
  • Thanks that's useful to know. I've marked the other answer as accepted, but this answer is equally useful, unfortunately I can't mark both :( – Alice Heaton Jan 09 '21 at 09:44
0

I enabled this functionality by setting mode = aggressive under [sshd] in my jail.local file

JayTee
  • 1
  • 2