Tony Finch - Flood protection

I'd suggest a few simple things, such as

1. 30 second delays before the smtp banner on your outbound mail relays

2. Look for signs of http headers or other proxy type headers being passed to your mail relays before the email is injected. That kills http proxies dead

3. Rate limits arent going to work against the sort of horizontal scaling viruses are becoming good at (infect more machines and send less spam per machine, as far as possible mimicking regular user mail traffic volumes)

4. There's a symantec "antispam router" which was originally called turntide aka spamsquelcher, before symantec bought it. I know the developers, and it is pretty decent for outbound filtering (note: it was originally intended to filter out incoming mail from trojans etc but most trojans route out through smarthosts these days). It is basically like an IDS for spam, and claims to sniff traffic at wire speed, and when it finds a flow of spam incoming through it [in this case outgoing spam across your network] it QoS's that spam flow down to something ridiculous like a few bits per minute, so it times out. You could hack a variant of this together if you hacked around with openbsd's pf I expect, but well, the product is ready and its reasonably good.

-suresh

(Reply) (Thread)

Thanks for the feedback!

delays

We can't do this because the relays are used directly by MUAs.

http

Exim does this by default. We should probably be doing more thorough checks of the logs.

slow senders

Yes, I mentioned in the doc that this is a weakness. Our AV scanner seems to be seeing only a few messages from infected machines in the last few months (rather than the hundreds that was common last year) so perhaps rate limiting will not be as effective as I hope. However in the one instance of outgoing spam via our MXs the offending machine would spew copiously for an hour or two a few times a week. This is what I'm aiming to detect and prevent.

antispam router

How does it define spam?

(Reply) (Parent) (Thread)

the muas are going to feel like its slightly slower to send email - though the delay you set can be dynamic, and based on other factors too (wire the delay interval to your rate limiter, for example)

slow rates - you need something like Vern Schryver's DCC to aggregate bulkiness of outbound email from across your network

Implement smtp auth and force use of smtp auth. That way you dont need to dig through several logs to find who owns an IP, and you dont need to track his infected laptop across several dhcp sessions on your campus wireless. Even if viruses hijack the guy's smtp auth creds from his outlook settings - which they will - you can identify the guy and cut off his auth privileges pronto when you detect spam. Oh, and note that you'd better have some way to get the guy VLAN'd into a walled garden that only has access to windows update / other security patch sites, till such time as he cleans his virus up and contacts campus IS staff.

how turntide defines spam - last I saw of it (BEFORE symantec bought it, and when it was in very early beta .. say mid 2003) it was pretty flexible. Existing signatures provided by turntide's developers [at least one of who is a respected antispammer, and a friend over the last six or seven years], plus stuff you can plug in yourself. Now? I guess it'll operate the same way norton antivirus works, distributing signatures .. though if the norton people know what they're doing they'll give you a lot more flexiblity than the average norton antivirus server edition user gets :)

(Reply) (Parent) (Thread)

Turntide uses bayes to determine what is/isn't spam. Well, they use a weighted decision, of which 80% of the weighting is towards bayes.

(Reply) (Parent) (Thread)

delays

Yes, I was thinking of introducing delays for fast senders before starting to reject email from them. However I hadn't really thought about connection rate limiting and delaying, which is what we want for pump-and-dump abuse. I shall have to make sure that it is possible.

auth

Yes, we're on that road. I rolled out SMTP AUTH last year and it'll be (mostly) enforced by this time next year. We're going relatively slowly so as not to overload our support staff.

Hijacking of authentication credentials is the main reason I want to implement rate limiting.

outbound dcc

Nice idea!

(Reply) (Parent) (Thread)

oh another thing (ot to this discussion, sort of)

MAAWG (http://www.maawg.org) in Düsseldorf June 21-24, at the Hilton on Georg Glock Strasse. Lots of people will be around, including some large broadband providers who have done just this kind of thing across large networks.

Then, ITU thematic meet on cybersecurity and spam at geneva (just like the thematic meeting on spam last year - I spoke in that meeting and found a lot of it well worth my time to attend). Spamhaus will be there, I'll be there, a few other people we both know as well .. [Wietse Venema was there last year, as was John Levine]

I'd strongly recommend your making a quick trip across the channel (maybe bring Philip Hazel over too) for one or the other meeting. Both if you can swing it ..

(Reply) (Parent) (Thread)

I'm planning to go to the IETF in August, though I still have yet to get my boss to clear it. Philip and I are quite busy before then, preparing for things like the Exim course and my wedding (respectively).

(Reply) (Parent) (Thread)

> my wedding

well, congratulations!

(Reply) (Parent) (Thread)

Thanks :-)

(Reply) (Parent) (Thread)