From: Iain L. <ia...@br...> - 2005-11-29 09:56:12
|
After using fail2ban for a while on external servers I have a feature suggestion that I think would make fail2ban a killer security tool :-) One should add a new parse type to fail2ban to be able to block webattacks. I get the following attacks all the time in my webserver logs: 220.137.93.28 - - [24/Nov/2005:00:18:18 +0100] "CONNECT smtp.rol.ru:25 212.204.78.162 - - [27/Nov/2005:16:48:04 +0100] "GET /_vti_bin/owssvr.dll?UL=1&ACT=4&BUILD=6254&STRMVER=4&CAPREQ=0 HTTP/1.1" 404 212.204.78.162 - - [27/Nov/2005:16:48:04 +0100] "GET /MSOffice/cltreq.asp?UL=1&ACT=4&BUILD=6254&STRMVER=4&CAPREQ=0 HTTP/1.1" 404 218.89.167.126 - - [28/Nov/2005:11:20:12 +0100] "GET /sumthin HTTP/1.0" What I envision is a new [ATTACK] keyword/section in the config file: [ATTACK] # Option: enabled # Notes.: enable monitoring for this section. # Values: [true | false] Default: false # enabled = true # Option: logfile # Notes.: logfile to monitor. # Values: FILE Default: /var/log/httpd/access_log # logfile = /var/log/httpd/access_log # Option: attackfile # Notes.: file containing attacks to block # Values: FILE Default: /etc/fail2ban.dat # attackfile = /etc/fail2ban.dat (rest of config to enable blocking/unblocking etc.) The attack matching and blocking file would based on the above logfile entries could be: ^[0-9]*\.[0-9]*\.[0-9]*\.[0-9]* - - \[.\*] "CONNECT .* - - .* "GET /_vti_bin/ GET /MSOffice /sumthin HTTP With the external file read in and parse ability fail2ban would be a very powerful tool and could be used to block numerous types of bad activity. Regards Iain -- +49-172-8196039 Skype: iain.lea |
From: Cyril J. <cyr...@bl...> - 2005-11-29 20:34:45
|
Hi, A new development branch should appear soon. I'm quite busy these days with my diploma so please be patient ;) We will add "split configuration file" support. We want to have a better separation of fail2ban.conf which starts to become too big at my opinion. Here is an example: /etc/fail2ban/: fail2ban.conf mail.conf whitelist.conf /etc/fail2ban/scripts.d/: iptables-chains.conf iptables-without-chains.conf watchguard.conf host-deny.conf /etc/fail2ban/logreader.d/: apache.conf apache-debian.conf sshd.conf squid.conf Notice the "host-deny.conf" file which could use "/etc/host.deny" to ban IP addresses (mmhhh... I saw this somewhere...). We could add a "apache-attack.conf" in "logreader.d" with the corresponding regexp. Maybe we could add: /etc/fail2ban/regexp.d/: apache-log.conf std-log.conf apache-auth.conf sshd-log.conf apache-attack.conf These files would contain regular expression for: 1/ log time and date 2/ failure or attack pattern Here is a possible example for "/etc/fail2ban/logreader.d/apache.conf": ------ [Apache] timeregexp = apache-log failregexp = apache-auth apache-attack ban = iptables-chain host-deny ------ However, it is already possible to block these attacks against Apache. Simply set : failregex = ^[0-9]*\.[0-9]*\.[0-9]*\.[0-9]* - - \[.\*] "CONNECT|.* - - .* "GET /_vti_bin/|GET /MSOffice|/sumthin HTTP in your Apache section. Regards, Cyril Iain Lea wrote: > After using fail2ban for a while on external servers I have a > feature suggestion that I think would make fail2ban a killer > security tool :-) > > One should add a new parse type to fail2ban to be able to block webattacks. > I get the following attacks all the time in my webserver logs: > > 220.137.93.28 - - [24/Nov/2005:00:18:18 +0100] "CONNECT smtp.rol.ru:25 > 212.204.78.162 - - [27/Nov/2005:16:48:04 +0100] "GET > /_vti_bin/owssvr.dll?UL=1&ACT=4&BUILD=6254&STRMVER=4&CAPREQ=0 HTTP/1.1" 404 > 212.204.78.162 - - [27/Nov/2005:16:48:04 +0100] "GET > /MSOffice/cltreq.asp?UL=1&ACT=4&BUILD=6254&STRMVER=4&CAPREQ=0 HTTP/1.1" 404 > 218.89.167.126 - - [28/Nov/2005:11:20:12 +0100] "GET /sumthin HTTP/1.0" > > What I envision is a new [ATTACK] keyword/section in the config file: > > [ATTACK] > # Option: enabled > # Notes.: enable monitoring for this section. > # Values: [true | false] Default: false > # > enabled = true > > # Option: logfile > # Notes.: logfile to monitor. > # Values: FILE Default: /var/log/httpd/access_log > # > logfile = /var/log/httpd/access_log > > # Option: attackfile > # Notes.: file containing attacks to block > # Values: FILE Default: /etc/fail2ban.dat > # > attackfile = /etc/fail2ban.dat > > (rest of config to enable blocking/unblocking etc.) > > > The attack matching and blocking file would based on the above logfile > entries could be: > > ^[0-9]*\.[0-9]*\.[0-9]*\.[0-9]* - - \[.\*] "CONNECT > .* - - .* "GET /_vti_bin/ > GET /MSOffice > /sumthin HTTP > > > With the external file read in and parse ability fail2ban would be > a very powerful tool and could be used to block numerous types of > bad activity. > > Regards > > Iain > |
From: Peter C. N. <sp...@le...> - 2005-11-29 20:40:48
|
Cyril, I'm working with an old codebase (well, working doesn't really describe my lack of progress for the past few weeks) to add obscene amounts of logging (optionally), and to segregate logging so it can be set differently in each section of the configuration file. It sounds like you may be moving the entire codebase to a more segmented configuration in general. Is there somewhere I should look to try to make the patches I eventually plan to submit work nicely? Thanks, -Peter On Tue, Nov 29, 2005 at 09:34:19PM +0100, Cyril Jaquier wrote: > Hi, > > A new development branch should appear soon. I'm quite busy these days > with my diploma so please be patient ;) > > We will add "split configuration file" support. We want to have a better > separation of fail2ban.conf which starts to become too big at my > opinion. Here is an example: > > /etc/fail2ban/: > fail2ban.conf > mail.conf > whitelist.conf > /etc/fail2ban/scripts.d/: > iptables-chains.conf > iptables-without-chains.conf > watchguard.conf > host-deny.conf > /etc/fail2ban/logreader.d/: > apache.conf > apache-debian.conf > sshd.conf > squid.conf > > Notice the "host-deny.conf" file which could use "/etc/host.deny" to ban > IP addresses (mmhhh... I saw this somewhere...). We could add a > "apache-attack.conf" in "logreader.d" with the corresponding regexp. > > Maybe we could add: > > /etc/fail2ban/regexp.d/: > apache-log.conf > std-log.conf > apache-auth.conf > sshd-log.conf > apache-attack.conf > > These files would contain regular expression for: > > 1/ log time and date > 2/ failure or attack pattern > > Here is a possible example for "/etc/fail2ban/logreader.d/apache.conf": > > ------ > [Apache] > timeregexp = apache-log > failregexp = apache-auth apache-attack > ban = iptables-chain host-deny > ------ > > However, it is already possible to block these attacks against Apache. > Simply set : > > failregex = ^[0-9]*\.[0-9]*\.[0-9]*\.[0-9]* - - \[.\*] "CONNECT|.* - - > .* "GET /_vti_bin/|GET /MSOffice|/sumthin HTTP > > in your Apache section. > > Regards, > > Cyril > > Iain Lea wrote: > > After using fail2ban for a while on external servers I have a > > feature suggestion that I think would make fail2ban a killer > > security tool :-) > > > > One should add a new parse type to fail2ban to be able to block webattacks. > > I get the following attacks all the time in my webserver logs: > > > > 220.137.93.28 - - [24/Nov/2005:00:18:18 +0100] "CONNECT smtp.rol.ru:25 > > 212.204.78.162 - - [27/Nov/2005:16:48:04 +0100] "GET > > /_vti_bin/owssvr.dll?UL=1&ACT=4&BUILD=6254&STRMVER=4&CAPREQ=0 HTTP/1.1" 404 > > 212.204.78.162 - - [27/Nov/2005:16:48:04 +0100] "GET > > /MSOffice/cltreq.asp?UL=1&ACT=4&BUILD=6254&STRMVER=4&CAPREQ=0 HTTP/1.1" 404 > > 218.89.167.126 - - [28/Nov/2005:11:20:12 +0100] "GET /sumthin HTTP/1.0" > > > > What I envision is a new [ATTACK] keyword/section in the config file: > > > > [ATTACK] > > # Option: enabled > > # Notes.: enable monitoring for this section. > > # Values: [true | false] Default: false > > # > > enabled = true > > > > # Option: logfile > > # Notes.: logfile to monitor. > > # Values: FILE Default: /var/log/httpd/access_log > > # > > logfile = /var/log/httpd/access_log > > > > # Option: attackfile > > # Notes.: file containing attacks to block > > # Values: FILE Default: /etc/fail2ban.dat > > # > > attackfile = /etc/fail2ban.dat > > > > (rest of config to enable blocking/unblocking etc.) > > > > > > The attack matching and blocking file would based on the above logfile > > entries could be: > > > > ^[0-9]*\.[0-9]*\.[0-9]*\.[0-9]* - - \[.\*] "CONNECT > > .* - - .* "GET /_vti_bin/ > > GET /MSOffice > > /sumthin HTTP > > > > > > With the external file read in and parse ability fail2ban would be > > a very powerful tool and could be used to block numerous types of > > bad activity. > > > > Regards > > > > Iain > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Fail2ban-users mailing list > Fai...@li... > https://lists.sourceforge.net/lists/listinfo/fail2ban-users -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one. |
From: Cyril J. <cyr...@bl...> - 2005-11-29 20:56:56
|
> I'm working with an old codebase (well, working doesn't really > describe my lack of progress for the past few weeks) to add obscene > amounts of logging (optionally), and to segregate logging so it can be > set differently in each section of the configuration file. Nice :) > It sounds like you may be moving the entire codebase to a more > segmented configuration in general. Is there somewhere I should look > to try to make the patches I eventually plan to submit work nicely? I will create a CVS branch named FAIL2BAN-0_7 for development. So just checkout this branch and adapt your patches. Moreover, I will post information about big changes in the code on this mailing-list. I will send an email on fail2ban-users mailing-list when FAIL2BAN-0_7 will be created. Cyril |