Hell Kerin,

Thanks for the pointer, I will take my time in searching for that
"attacking-loganalysis".
Actually we are talking about proftp deamon analysed using
/var/log/auth.log.

Here is the /var/log/auth.log that is suppose to trigger BAN on fail2ban:

Jul 31 23:43:41 fileserver proftpd[28423]: fileserver.mzalendo.net
(124.205.130.15[124.205.130.15]) - USER mysql (Login failed): Incorrect
password.
Jul 31 23:43:41 fileserver proftpd[28423]: fileserver.mzalendo.net
(124.205.130.15[124.205.130.15]) - USER mysql (Login failed): Incorrect
password.
Jul 31 23:43:42 fileserver proftpd[28423]: fileserver.mzalendo.net
(124.205.130.15[124.205.130.15]) - USER mysql (Login failed): Incorrect
password.
Jul 31 23:43:42 fileserver proftpd[28423]: fileserver.mzalendo.net
(124.205.130.15[124.205.130.15]) - Maximum login attempts (3) exceeded,
connection refused
Jul 31 23:43:42 fileserver proftpd[28423]: fileserver.mzalendo.net
(124.205.130.15[124.205.130.15]) - FTP session closed.

And here is the filter using regular expression  that actually confirms
how it has been missed:

fail2ban-regex /var/log/auth.log
/etc/fail2ban/filter.d/proftpd.conf|grep 124.205.130.15

Is it a normal routine that users have tweak those filters?

GR
mrfroasty



Kerin Millar wrote:
> 2009/8/2 mrfroasty <mrfroasty@gmail.com>:
>   
>> Hello,
>>
>> I have setup iptables and fail2ban, but I am curios that this line of
>> defense seem not to work and ban me if i do this:
>> #wget ftp://mysql:xxxx@fileserver
>>
>> I have seen a script kido, doing that and firewall just didnt respond to
>> him or atleast not on the logs that he had been banned when he tried that.
>> The firewall does ban or respond if I do this:
>> #wget ftp://foo:pass@fileserver
>>
>> Probably he could have been banned if used a different user, but not
>> mysql...I am confused...any clue? :-D
>>     
>
> You haven't provide any pertinent background information (ftp daemon
> in use, log message which is expected to trigger action, details of
> the fail2ban filter and so forth), which makes it rather difficult to
> take a view. My guess is that the particular filter you are using
> contains a regex which matches log messages from the daemon which
> convey only an invalid user, rather than an authentication failure in
> general. If so, you would need to adjust the filter - or add an
> additional one - so as to cover both cases.
>
> As a side note, do be careful when crafting the regular expressions
> that form the basis of the filter. The slightest mistake can
> potentially result in the tool being open to attack itself via log
> injection. For more information on this topic, search for
> "attacking-loganalysis.html" via Google and view the cached copy; the
> original article seems to have disappeared from the ossec.net site.
>
> Cheers,
>
> --Kerin
>
>
>   


-- 
Extra details:
OSS:Gentoo Linux
profile:x86
Hardware:msi geforce 8600GT asus p5k-se
location:/home/muhsin
language(s):C/C++,VB,VHDL,bash,PHP,SQL,HTML,CSS
Typo:40WPM
url:http://www.mzalendo.net