Log Injection and Fail2ban
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.
5 Replies
Then again YOU yourself could lock yourself out rather easily if you're not careful and have very strict banning rules.
@Azathoth:
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?
@Tayne:
It seems like the attacker could alter whatever is being used to produce a log entry as follows:
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.
> Which would effectively block SSH access from everywhere, correct?
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.
@Tayne:
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 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.