Came across the following in my iptables Fail2ban SSH chain:

 
pkts bytes target     prot opt in     out     source               destination
   18  1180 DROP       all  --  any    any     .                    anywhere

And the log that triggered it:

Nov 27 12:07:54 ex sshd[29759]: reverse mapping checking getaddrinfo for . [31.210.109.31] failed - POSSIBLE BREAK-IN ATTEMPT!
Nov 27 12:07:54 ex sshd[29759]: User root from 31.210.109.31 not allowed because not listed in AllowUsers
Nov 27 12:07:54 ex sshd[29760]: input_userauth_request: invalid user root
Nov 27 12:07:54 ex sshd[29760]: Received disconnect from 31.210.109.31: 11: Bye Bye

I'm curious as to whether Fail2ban could lock me out of SSH completely if someone were to put "ANY" instead of "." in the above entry, or are there safeguards against this in Fail2ban to handle particular types of injection. I'm running on the default installation of Fail2ban outside of changes in detection time and number of attempts.

No, the IP must be resolved as valid before sshd or any higher level protocol (higher than TCP three-way connection handshake) would log invalid attempts and thus reach fail2ban.

Then again YOU yourself could lock yourself out rather easily if you're not careful and have very strict banning rules.

Thanks for the quick reply and info! Maybe I'm not understanding it correctly, but the entries above are from my Linode in iptables and the log file, so wouldn't that mean the request is successfully getting through?

It seems like the attacker could alter whatever is being used to produce a log entry as follows:

Nov 27 12:07:54 ex sshd[29759]: reverse mapping checking getaddrinfo for anywhere [31.210.109.31] failed - POSSIBLE BREAK-IN ATTEMPT!
Nov 27 12:07:54 ex sshd[29759]: User root from 31.210.109.31 not allowed because not listed in AllowUsers
Nov 27 12:07:54 ex sshd[29760]: input_userauth_request: invalid user root
Nov 27 12:07:54 ex sshd[29760]: Received disconnect from 31.210.109.31: 11: Bye Bye 

Assuming Fail2ban behaves as expected, it would produce an iptables entry as follows:

pkts bytes target     prot opt in     out     source               destination
   18  1180 DROP       all  --  any    any     anywhere               anywhere 

Which would effectively block SSH access from everywhere, correct?

Where did you get that idea? The remote IP address comes from your network stack, it is part of teh TCP packet, and at this point (after three-way handshake of the TCP, after established connection to ssh and username sent to it) it cannot be spoofed.

So no, the "attacker" cannot alter whatever is being used to produce the logs.




Incorrect. The "any" is just what you see with iptables -L. The actual chain rule, the one given by fail2ban, includes the IP address fail2ban reads from teh logs, using a regex meaning it has to be a valid IP address.

Makes sense now! I was under the impression that the iptables rule was dropping traffic from what's listed under the 'source' column when using iptables -L, but that command doesn't reveal all the information available. Thanks for the help!

But it is, and shows "any" if no specific host is set.

Except you can't tell iptables to drop from "anywhere" (or "any") by that word in place of -s flag for remote IP. I mean, you can but iptables would think that's a host name, not "anywhere" as in "any source".

#> iptables -A INPUT -s anywhere -j DROP
iptables v1.4.10: host/network `anywhere' not found
Try `iptables -h' or 'iptables --help' for more information.

#> iptables -A INPUT -s any -j DROP
iptables v1.4.10: host/network `any' not found
Try `iptables -h' or 'iptables --help' for more information.