On Sun, Aug 21, 2011 at 05:46:18AM -0700, Craig White wrote:
What you seem to want to do is to block host access (TCP possibly UDP) based upon certain GET/POST activities on your web server. Thus you are attempting to create a curtain based upon things that have already failed and eventually you will get a huge IPTABLES filter that will slow up all traffic while parsing the rules. I would suspect that this would
fail2ban handles rule expiration; firewall rules can be configured as the admin sees fit for the offending action. In fact each trigger can have a configurable lifetime. fail2ban also ships with working apache triggers, for example there is one that triggers off of failed auth attempts; these can be modified to fit the OP's needs with minimal work.
You should spend the time protecting the server with good system administration... SELinux, which you state 'you are not using at the moment' is a prime example.
There is little excuse in not having selinux enabled. Every hacked box we've seen in #centos for the past few years has had selinux disabled; not one that I've seen reported had it enabled.
The security issues you should be worrying about are not the things that are getting logged - that's just a record of things that already didn't work.
True, but blocking automated 5cr1p7-k1dd135 probes will reduce log volume and potentially protect you from probes further down the scan chain that haven't hit yet that you may be vulnerable to.
John -- We cannot do everything at once, but we can do something at once.
-- Calvin Coolidge (1872-1933), 30th president of the United States