The problem with that would be dynamically assigned addresses, unless you included a lookup being done against your radius databases by the SMTP proxy, so that the user can be identified. Possibly, a better solution would be to analyse netflow data as it hits the collectors, and identify offending machines that way. By using netflow, you can extend detection of worms, etc to include all ports, rather than just port 25 Doing dynamic throttling of infected connections is much more difficult - there's not a large range of equipment out there that can do that reliably, although the Juniper ERX does spring to mind :-) But that's not a box you'd find in most ISPs Cheers, Gordon
-----Original Message----- From: neil gardner [mailto:neil.gardner(a)alliedtelesyn.co.nz] Sent: Thursday, 10 June 2004 3:20 p.m. To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Zombies
OK, serious thought here... Bear with me... I may be a) Describing an existing system or b) way off base.
Transparent SMTP proxy intercepts all messages and maintains a running total of emails sent per source IP. This running total is actually stored as a time distribution (ie. 10 emails in 10 minutes, then none in 10, then 100 in ten etc)
Rulebase periodically examines this time distribution for each source IP. Something like
If last 3 matches are >10, >10, >10 then block for 30 minutes per strikeout(sourceIP) and increment strikeout(sourceIP) by one.
After expiry of downtime, open them up again. After (say) 90 minutes of non-abhorrent behaviour, decrement strikeout(sourceip) by one.
If strikeout(sourceIP) gets to threshold (Say 10) then email user and 48 hours later disable account unless they contact helpdesk and claim to have addressed the situation.
You probably want cleverer rules to identify bursts of email, and possibly a training period with rules referrent to earlier data from the same source - this should be able to reliably identify legitimate high volume users - especially if you build in a time of day factor.
This should quickly throttle zombies and disable the account if not fixed, but allow for brief infections to be throttled, and if fixed, NOT need manual intervention to unblock. It may impact some legit heavy email users, but mail will bounce, and it should fix itself.
Just a thought.
Cheers - N.
Another suggestion: Why not set up a spamtrap system. With an /etc/alias pipe to some perl with a regex to catch your domain and a lookup to (this is the critical bit) your billing db/radius/whatever to see who is assigned the address at the time, you could block that user in realtime (or next re authentication time). I would also keep the email content in a db for evidence purposes, ie so you can present the customer with the spam that was relayed through their zombie. If having this entirely automated is too scary then put it into a db and have a human look at it. When presented with the facts that customerA, who was using this ip at the time, sent this spam to our spamtrap address and has done so 15 times this week it should be a clear cut decision. Well over 50% of spam these days is going through zombies produced by viruses like mimail rather than open relays or proxys. The majority of affected machines reside in large foreign ISP's dsl/cable/dynamic/pool address blocks. If the ISP's in charge of ranges like: dsl.chcgil.ameritech.net dynamic.hinet.net dsl.lsan03.pacbell.net dip.t-dialin.net dsl.emhril.ameritech.net dsl.telesp.net.br phil.east.verizon.net user.veloxzone.com.br client.comcast.net ap.plala.or.jp would do this it would cut our incoming spam by > 50% of course you can do the same with access.db/host_reject_recipients et al. on your side. Regards -- Donovan Jones Network Engineer Comnet Networks +64-4-569 0060 http://www.comnet.co.nz
Gordon Smith wrote:
The problem with that would be dynamically assigned addresses, unless you included a lookup being done against your radius databases by the SMTP proxy, so that the user can be identified.
Possibly, a better solution would be to analyse netflow data as it hits the collectors, and identify offending machines that way. By using netflow, you can extend detection of worms, etc to include all ports, rather than just port 25
Doing dynamic throttling of infected connections is much more difficult - there's not a large range of equipment out there that can do that reliably, although the Juniper ERX does spring to mind :-) But that's not a box you'd find in most ISPs
Done -- I wrote a simple detection script that parses netflow data and warns about users that are doing sustained amounts of high volume to various ports. :)
participants (3)
-
Donovan Jones -
Gordon Smith -
Perry Lorier