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 <mrfroa...@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:x...@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:p...@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
