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.
Simon Lyall
10/06/2004 1:46:38 p.m. >>> It looks like there are lot of NZ based Zombies sending very large amounts of Spam ( much of it in German) to some ISPs.
This has really been going hard over the last hour. I'm seeing adsl accounts at xtra, iprolink and ihug, xtra dialups etc etc. As a related issue, how do people feel about a whitelist RBL of NZ mail servers, It looks like it's not good to just whitelist NZ IPs -- Simon J. Lyall. | Very Busy | Mail: simon(a)darkmere.gen.nz "To stay awake all night adds a day to your life" - Stilgar | eMT. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog NOTICE: This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Allied Telesyn Research Ltd immediately. Any views expressed in this message are those of the individual sender, except where the sender has the authority to issue and specifically states them to be the views of Allied Telesyn Research.
On 9 Jun 2004, at 23:20, neil gardner wrote:
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.
How would you handle STARTTLS?
Transparent SMTP proxy intercepts all messages and maintains a running total of emails sent per source IP.
How would you handle STARTTLS?
I was thinking the same thing. Why don't we all just drop, at smtp time, any of the following: Mail that contains malware[1] Mail that fails an SPF test Mail that comes from a dynamic IP block [1] malware can be defined as executable attachments and anything matching Vipul's Razor for concealed malware (passworded zip files which contain a trojan). Legitimate users who get caught by this will be: People who run their own MTAs on a dynamic IP. Bad move guys, most of the world ignores you already anyway. People who post from different ISPs to their domain. You can get around this with SMTP AUTH + STARTTLS. People who for some reason want to post executable content via email. They'll get an SMTP rejection, perhaps with a link to a url containing information about why. All of these problems are easily overcome, in particular by using your ISPs MTA as a smarthost, if you don't have your own MTA elsewhere, and by ISPs implementing SMTP AUTH + STARTLS for remote users. Illegitimate users who will get caught by this include: Virus infected machines. If they don't send via their smarthost, they don't get anywhere. If they do send via their smarthost, their smarthost drops malware anyway. The mail doesn't get anywhere. -- Daniel Lawson WAND Group, Computer Science Department University of Waikato email: daniel(a)wand.net.nz phone: +64 7 838 4466 ext 6254
On Thu, Jun 10, 2004 at 03:20:24PM +1200, neil gardner wrote:
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)
Sounds pretty complicated to me. Why not just tell all your customers you're going to block port 25 except to your mail server, and that it won't affect them unless they're doing something unusual. Those that will be affected will probably know, and they can contact you and ask for an exception. You ask a few basic questions to make sure they have some degree of clue, and open it for them. Those who are doing it and didn't know will hopefully remember that email they got, and contact you afterwards. You'd probably need to send a few emails over the month before you actually cut them off. You could also monitor who's making direct connections before all this and contact them directly, of course. Most importantly, advertise what a good ISP you're being, helping save the world from spam. Just my thoughts. Richard
On 10 Jun 2004, at 05:16, Richard Hector wrote:
Why not just tell all your customers you're going to block port 25 except to your mail server, and that it won't affect them unless they're doing something unusual. Those that will be affected will probably know, and they can contact you and ask for an exception.
There are enough places in the world (WiFi hotspots, hotels, etc) that already mangle port 25 out from the client that I don't bother trying any more. I direct all my mail at 465/tcp, session pre-wrapped with SSL (i.e. no STARTTLS). Joe
This would work perfectly in a world of static IPv6 networks. Unfortunately, while we are all stuck using Dynamic IP pools, especially on dialup, when customers disconnect every 3 or 4 minutes, and IP addresses are re-assigned constantly, this (like almost all the previous suggestions) just isn't really feasible - especially from a helpdesk point of view. Sure, there are ways for it to be done, but with a large amount of hassle. Similar to the caching issue, the money burnt paying staff to maintain/troubleshoot these extra setups would quite possibly mean that little benefit would arise from it, apart from the CEO having to delete one less message per day. This also doesn't do anything to stop the various forms or Malware which either send email out via outlook* or digs for the info, and then relays to the SMTP server listed in the email config. The fixing really needs to be done at the user end - somehow. Maybe Microsoft will be smart enough to release something to combat this with the first release of Longhorn.. Probably not. It seems like a lot of us are trying to see a positive which doesn't exist, and probably wont for a long time. The music industry has been trying to combat piracy for years with all sorts of extravagant little schemes. "Lets make a CD which only plays in 'dumb' hardware, or hardware which supports proprietary Microsoft codec's! The end user wont mind the inconvenience, surely..) Still, pipe dreams are nice, and we all spend endless hours dreaming and scheming of ways to crush those ignorant little end users with our thumbs - while exploding in fits of evil laughter.. Jeremy. -----Original Message----- From: Richard Hector [mailto:rhector(a)paradise.net.nz] Sent: Thursday, June 10, 2004 9:17 PM To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Zombies On Thu, Jun 10, 2004 at 03:20:24PM +1200, neil gardner wrote:
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)
Sounds pretty complicated to me. Why not just tell all your customers you're going to block port 25 except to your mail server, and that it won't affect them unless they're doing something unusual. Those that will be affected will probably know, and they can contact you and ask for an exception. You ask a few basic questions to make sure they have some degree of clue, and open it for them. Those who are doing it and didn't know will hopefully remember that email they got, and contact you afterwards. You'd probably need to send a few emails over the month before you actually cut them off. You could also monitor who's making direct connections before all this and contact them directly, of course. Most importantly, advertise what a good ISP you're being, helping save the world from spam. Just my thoughts. Richard _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
On 10 Jun 2004, at 07:52, Jeremy Brake wrote:
This would work perfectly in a world of static IPv6 networks. Unfortunately, while we are all stuck using Dynamic IP pools, especially on dialup, when customers disconnect every 3 or 4 minutes, and IP addresses are re-assigned constantly, this (like almost all the previous suggestions) just isn't really feasible - especially from a helpdesk point of view.
The suggestion of blocking 25/tcp connections outbound from customers by default (or restricting them to set of ISP mail servers), and disabling that behaviour on request for specific users, is not hard. You can hand out appropriate per-user filter specifications in a RADIUS profile. As to the uselessness of this in the face of worms which send spam using the configured smarthost -- if the only smarthost the worms can reach is the ISP's mail server, you have an opportunity to spam-filter outbound mail from customers and to take appropriate action if the filters are getting exercised too much. The real trouble with these approaches is that they cost the ISP money without providing much of a return -- the benefit to blocking outbound spam from your own customers is felt by the rest of the world, who probably aren't going to pay you for it. The only remaining benefit to the ISP is that they can save money on their abuse desk because the number of complaints received about customers ought to go down (but then, an ISP that concerned with revenue probably doesn't have a functional abuse desk anyway). Joe
An abrupt flaw with all of these ideas, is the fact that his has to be implimented EVERYWHERE (as I am sure most of you know). In theory, lets say America on a much more vast user base. None of the ISPs will adopt this technique, so now we have thousands of ISPs allowing all this malware smtp traffic. We have all of our users secured so malware has 1% chance of getting through. The flaw is, this lack of co-operation from the Americans result in pretty much only protecting ourselves, from ourselves .: we would still receive pretty much the exact amount of spam/virus traffic as before (minus the occasional hit locally) I would suggest, IMHO, that Microsoft (the source of a majority of the email+virus activity) do some sort of rate limiting on outgoing SMTP traffic on their OS. The thing is, sure spammers will "patch" and "hack" this and get around it, okay spam isn't THAT bad when comparing it against viruses and other malicious content being forwarded to mailboxes. But it would indeed make it harder for a less logical/intelligent virus to come along and spread like it usually does. This is only a thought, I haven't thought into it further then the bottom of the cup of the hot chocolate I had this morning. Here's hoping Microsoft have a noodle soup of code for networking that cannot be patched simply. My 2 cents. - Drew
participants (6)
-
Daniel Lawson
-
Drew Broadley
-
Jeremy Brake
-
Joe Abley
-
neil gardner
-
Richard Hector