[Fail2ban-users] security question
From: Quartex Quartex <quartex73@gm...> - 2007-05-06 19:59
Attachments: Message as HTML
Hi all.
I'm always be tempted about 'active response' tools like this one. Still
there are a lot of warnings from people about spoofing and DoS dangers. My
question is short and fast:
what are the considerations to do about this tool and DoS and spoofing
dangers? Is possible that someone is able to spoof so in depth to commit
wrong credentials?
Thanks for your thoughts
Re: [Fail2ban-users] security question
From: Yaroslav Halchenko <lists@on...> - 2007-05-07 14:15
> I'm always be tempted about 'active response' tools like this one.
> Still there are a lot of warnings from people about spoofing and DoS
> dangers. My question is short and fast:
> what are the considerations to do about this tool and DoS and spoofing
> dangers? Is possible that someone is able to spoof so in depth to
> commit wrong credentials?
Well, I really like someone correct me if I am wrong but here are my
thoughts. Spoofing can occur in 2 places
1. at the level of spoofed IP in the packets, so that the service
records that IP as the one to fail authentication. But since most of the
services (if there is any actually please let me know) do not use single
packet authentication, but rather require first to establish some kind
of encrypted (TLS/SSL) connection, proper IP is required to get to the
phase of authentication.
That gives fail2ban (and other tools monitoring log files) advantage
over pure iptables solution using marking packets to ban host on the
exhaust of the rate limit or matching the content of the packets
To assure that fail2ban is not prone to such kinds of attacks: I
guess careful look over all shipped in fail2ban filters is necessary to
verify that all failregexes for services operate whenever preliminary
TCP/IP packet exchange has happened... I am afraid that some filters for
apache might fail since iirc http request is served with a single
packet, so such rules as
apache-badbots.conf:failregex = ^<HOST> -.*"(GET|POST).*HTTP.*"(?:%(badbott
s)s|%(badbotscustom)s)"$
apache-noscript.conf:failregex = [[]client <HOST>[]] File does not exist:
.*(\.php|\.asp)
someone needs to try IP spoofing though to check for sure... I can be totaa
lly
wrong.
and I am not sure on some smtp requests if mail server doesn't require
encrypted channel
2. embedding victim IP inside of the login (or other part of the query)
which gets recorded in the log file. This is a known and fixed issue:
http://lwn.net/Articles/222529/ (fail2ban) and
http://lwn.net/Articles/216217/ (denyhosts). Since the time when this
bug was reported first in Debian a year or so ago, it has been fixed by
hardcoding possible position of an IP within ssh failregex and some time
rely on the greediness of '*' operator which matches as much as
possible. Most of the fail2ban failregexes followed this rule, but
having a look now I see some rules which might impose the hazard:
apache-auth.conf:failregex = [[]client <HOST>[]] user .* authentication faa
ilure
I guess we just need to append '$' at the end, since otherwise user name cc
ould
be used to incorporate some other fail2ban regex for apache log file which
might trigger another failregex for the same log file which also doesn't hh
ave
ending '$'.
Actually Cyril -- I think we need to finalize all failregexes with $ provii
ding
a regexp for the complete line since otherwise smth like what I described
might occur in some filters I guess.... or may be within filter.py substitt
ute
search with match for failregex... or append '$' explicitely to every provv
ided
failregex
To summarize: there might be no security hole at the moment since my thougg
hts
are simply 'thoughts out loud' and I can be wrong, but they might be corree
ct
points thus need to be verified.