Re: [Fail2ban-users] Potential DOS attack vector (WAS: fail2ban.filter : WARNING Unable to find a corresponding IP address for [hostname])

[Amir C. <ce...@3p...>]

On Tue, January 10, 2012 3:52 pm, Lee Clemens wrote:
> On 01/10/2012 07:21 AM, Tom Hendrikx wrote:
>> In the first case (standard attacks), you can end up banning no ip
>> addresses, or the wrong ones, when PTR setup for the attacker is
>> broken. I did a fast and non-representative statistic on my postfix
>> logging, and see some 3 percent of the connecting hosts having a
>> broken dns setup (no fqrdns). Thus, in about 3 percent of the attacks
>> you have the risk of f2b not catching the attack, or banning the wrong
>> ip address, both resulting in f2b not stopping the attack, while the
>> user expects it to. This is what I call "a false sense of security".
>
> I just wanted to clarify, the 3% you mention; were they addresses which
> had PTR records to someone else's IP space, such that a DOS could be
> achieved? Or were they instances with RR DNS (I banned www.google.com,
> f2b put 6 or so IPs in iptables, none of which had an A record of
> www.google.com - this was not an attack like you have been discussing,
> and IMHO it's good that all 6 IPs got banned)?

Actually, I think this requires even more clarification.  What does "the
PTR setup for the attacker is broken" actually mean?  Is it broken in the
sense that the PTR record doesn't exist (e.g. NXDOMAIN), that the rDNS
lookup times out, or (as Lee said) that the PTR actually contains a
hostname that resolves to a different IP?

Remember, f2b isn't the one doing the rDNS lookup; the service being
attacked is doing it (assuming it does it at all).  Let's say sshd is
being attacked and is set to do rDNS lookup and log hostnames, when
available.  If the PTR record is not available (whether due to timeout,
NXDOMAIN, or any other DNS failure), sshd will simply log the IP address. 
Therefore, there is no case that I can see where f2b would actually
_not_catch_ the attack, because sshd will _always_ log at least the IP
address.  (The IP address is always known, since it's in the packet
headers.)

The only time sshd would ever log a hostname is if the PTR record is
successfully retrieved, and the only time that hostname will fail to agree
with the original IP is if the record is improperly set up (whether
maliciously or incompetently).  Thus, the only way that f2b could ban the
wrong IP is if the rDNS lookup on the IP (by sshd) yields a hostname whose
DNS lookup resolves to a different IP (when f2b checks it).  So, are you
saying that 3% of recorded IPs had PTR records with hostnames that didn't
resolve to the original IP, due to (malicious or incompetent) improper
setup?

Even so, the "security hole" we're talking about isn't a hole in f2b, it's
a hole in the logging service that is doing the rDNS lookup.  This is part
of the reason why I don't think f2b should be modified to simply ignore
hostnames - that solution tries to fix the security holes of _other_
services within f2b, which I think is not the correct way to handle
things.  Invariably, f2b must trust the integrity of the error logs which
it's using, which means it must trust that the other services are logging
correct info.  It's up to the admin to ensure that this is the case.  The
correct solution would be for f2b to suggest to the admin (whether via
warnings in the log, and/or via a detailed readme) that rDNS be disabled
within logging services so that the logs can be trustworthy.

(BTW, in CentOS, many services are set to do rDNS lookup by default, so an
admin would have to go in to explicitly change that.)

Just MHO.

						--- Amir