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 |
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 | |
We also thank MIT for the use of their facilities. |