Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Banning IPs from Apache?



Chris Devers <cdevers at pobox.com> wrote:
> [...]
> 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?

I've been playing a lot with spamassassin lately, and have found the bayesian
filtering very effective. I'm wondering if a similar "smells like spam/worm"
technique might be useful here as well. While determining every worm's specific
signature in advance is impossible, it SHOULD be possible to build up
signatures of "normal" activity for a site pretty quickly, and then train it
against known worm hits. Plug this into a proxy in front of a web server, and
have it selectively reject "funny looking" requests and perhaps this would work
proactively?

> 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.

Application level to detect (the proxy) and network (iptables) to block? Add
snort to the mix per Nathan's suggestion for an extra level and it might be
"more proactive" than just monitoring for known signatures.

> 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/>

Certainly a good alternative if you have control of ONLY the web server! Or
redirect worm hits to a tarpit.

Just thinking out loud here!

- Bob

>
> 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 :)





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org