Banning IPs from Apache?

[cdevers at pobox.com (Chris Devers)]

On Wed, 11 Feb 2004, Keller, Tim wrote:

> > From: Bob George [mailto:mailings02 at ttlexceeded.com]
> > 
> > Duane Morin <dmorin at lear.morinfamily.com> wrote:
> > > Recently I'm experiencing nasty load problems on my home web
> > > server for reasons I have yet to determine.  But I do see that
> > > my access logs are full of the usual worm traffic.  Can
> > > somebody point me in the right direction (or just give me the
> > > quick tutorial) on whether I can tell Linux or Apache ASAP
> > > "here's a bunch of IPs that I dont want you to respond to at
> > > all?"  What's the optimal way of making sure that these hits
> > > don't kill your server (or even interfere with its usual
> > > operation)?
> > 
> > Stupid question, but how do you know in advance where hits from
> > worms will come from? Or are you getting massive hits from the
> > same addresses repeatedly? 
> 
> Bob,
> 
> What you could do is write a perl script that would just watch your
> error logs and then add a rule to iptables to just block that IP... 


But that doesn't quite answer the original question, does it? 

Yes, you can adaptively respond to where this traffic starts coming in
from, and the suggestion you make ought to work very well for that kind of
thing.

But has anyone done much profiling of typical worm traffic? How bad is the
"repeat offender" situation? Is it possible to know in advance what IPs or
netblocks ought to be filtered? 



When this message first popped up, my instinct was that Apache was the
wrong level to fix this -- the iptables line of thought should do better. 

But now that I think about it, what about Apache's mod_throttle? Could it
do this kind of adaptive filtering for you at the web server level? It
might not be as efficient as a firewall that just blocks the traffic
before it gets that far, but it might be easier to maintain, too.

    <http://www.snert.com/Software/mod_throttle/>

It looks like the ThrottleRuntimeFile directive could be used to save
state data to a file, and that file could in turn be parsed by the
above-suggested Perl script to update your iptables config. This might
actually be a pretty robust approach to try...

Not that it's at all predictive though. I'm not answering the earlier
question either, but I'm also interested in responses to that :)



-- 
Chris Devers