Brute force prevention by IP address

[Heath Raftery]

The built-in Brute Force Prevention feature seems effective when clients try brute forcing the password for a particular username. But I have a client (219.246.178.229) whose been trying to brute force using a different username each time. It looks like the Brute Force Prevention is not kicking in because my log is full of the attempts every three seconds for many hours. It looks like this:

Mar 13 11:28:51 mtcdt auth.info sshd[30616]: Invalid user oracle from 219.246.178.229
Mar 13 11:28:51 mtcdt auth.info sshd[30616]: input_userauth_request: invalid user oracle [preauth]
Mar 13 11:28:51 mtcdt authpriv.warn sshd[30616]: pam_unix(sshd:auth): check pass; user unknown
Mar 13 11:28:51 mtcdt authpriv.notice sshd[30616]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=219.246.178.229
Mar 13 11:28:53 mtcdt auth.info sshd[30616]: Failed password for invalid user oracle from 219.246.178.229 port 51162 ssh2
Mar 13 11:28:53 mtcdt auth.info sshd[30616]: Received disconnect from 219.246.178.229: 11: Bye Bye [preauth]
Mar 13 11:28:56 mtcdt auth.info sshd[30644]: Invalid user oracle from 219.246.178.229
Mar 13 11:28:56 mtcdt auth.info sshd[30644]: input_userauth_request: invalid user oracle [preauth]
Mar 13 11:28:56 mtcdt authpriv.warn sshd[30644]: pam_unix(sshd:auth): check pass; user unknown
Mar 13 11:28:56 mtcdt authpriv.notice sshd[30644]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=219.246.178.229
Mar 13 11:28:58 mtcdt auth.info sshd[30644]: Failed password for invalid user oracle from 219.246.178.229 port 58802 ssh2
Mar 13 11:28:58 mtcdt auth.info sshd[30644]: Received disconnect from 219.246.178.229: 11: Bye Bye [preauth]
Mar 13 11:29:01 mtcdt auth.info sshd[30676]: Invalid user oracle from 219.246.178.229
Mar 13 11:29:01 mtcdt auth.info sshd[30676]: input_userauth_request: invalid user oracle [preauth]
Mar 13 11:29:01 mtcdt authpriv.warn sshd[30676]: pam_unix(sshd:auth): check pass; user unknown
Mar 13 11:29:01 mtcdt authpriv.notice sshd[30676]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=219.246.178.229

Over and over. Is there a way to prevent brute force by IP address instead of username?

[Heath Raftery]

Still an issue. Adds up to quite a bit of traffic.

I tried to install fail2ban to take care of it, but could not figure out a configuration to suit the mLinux distribution.

[Peter Ferland]

If its just one nuisance ip address or range you could manually use iptables to DROP all traffic from the ip/range.

Something like: iptables -I INPUT -s 219.246.178.229 -j DROP
or for the entire class C:
iptables -I INPUT -s 219.246.0.0/16 -j DROP

[Heath Raftery]

If its just one nuisance ip address or range you could manually use iptables to DROP all traffic from the ip/range.

Very handy. I tried to install ipset to streamline this but it’s not part of the opkg list.

In the end I hacked fail2ban into working. It’s not an ideal hack, but nonetheless 24 hours later it has banned 63 IP addresses!

Interestingly, very few are in the same subnet. There’s three 61.177.172.0/24, two 103.207.37.0/24, two 123.31.0.0/16 and two 193.201.224.0/24. I think the rest are unique, so there’s probably not much value in risking a false positive with entire classes. Not sure if there’s a performance hit having so many to check.

Also of interest, instead of -j DROP, fail2ban uses -j REJECT --reject-with icmp-port-unreachable by default. I guess that’s more likely to discourage future attempts?

Would love to see some improvements to or configuration of the built-in brute-force prevention, or even a supported fail2ban package. It was pretty maddening even trying to figure out which distribution mLinux was closest to to get fail2ban to play ball. Each fail2ban package relies on so many packages that turned out to be unavailable, that I ended up just disabling large sections of functionality just to get it to run.

[Author]

Posts