Re: [Fail2ban-users] security question

[Yaroslav H. <li...@on...>]

>    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.*"(?:%(badbots)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 totally
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 failure

I guess we just need to append '$' at the end, since otherwise user name could
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 have
ending '$'. 

Actually Cyril -- I think we need to finalize all failregexes with $ providing
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 substitute
search with match for failregex... or append '$' explicitely to every provided
failregex

To summarize: there might be no security hole at the moment since my thoughts
are simply 'thoughts out loud' and I can be wrong, but they might be correct
points thus need to be verified.

-- 
                                  .-.
=------------------------------   /v\  ----------------------------=
Keep in touch                    // \\     (yoh@|www.)onerussian.com
Yaroslav Halchenko              /(   )\               ICQ#: 60653192
                   Linux User    ^^-^^    [175555]