Re: [exim] Any Joe Job advice?

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Marilyn Davis
Dátum:  
Címzett: Mark Moseley
CC: exim-users
Tárgy: Re: [exim] Any Joe Job advice?
On Mon, 11 Apr 2005, Mark Moseley wrote:

> No, not how to *send* them ;)
>
> I'm curious if anybody on the list has any experience with fending off
> very large scale Joe Job attacks? We're getting hit with about 75
> million a day (yes, 75 million) since Saturday. I'm doubtful that
> there's much I can do externally to mitigate this, but I figured it
> couldn't hurt to ask the list.


Wow. My sympathies.

I don't have anything external to suggest to help you, but hopefully,
someone else might.

I have a question/idea because I'm trying to get a good theoretical
grip on a Joe Job myself.

>
> Points:
> * The bounces of course have a null sender.
> * Our legit bounces should be coming back to SRS-encoded addresses, due to SPF.
> * We're a web hosting company and the bounces are coming to thousands
> of different domains we host.
> * Due to being a web hosting company, though we have SPF records,
> management is loathe to set them to 'strict' (aka -all; set to ?all
> now to make AOL happy), since many people send mail via their ISP's
> mail servers but using a From: address with the domain they host with
> us. This experience however might convince them to accept the pain of
> turning on SPF strictness.
> * I've had to block (via 'deny' ACL) all null senders sending to
> non-SRS-encoded addresses. No, this is not exactly something I like
> doing, but it's better than our mail system going down in flames
> (which it had been till I put in the ACL to discard these).
> * The hosts bouncing to us are all over the board and appear totally legit.
> * The IPs in the Received: headers in the body of bounce messages
> they're sending us are also completely all over the board (I'm making
> the assumption that since the bouncers appear legit, then at least the
> last Received header they added is not faked).


I'm thinking that the last Received header, in the body, is not fake
and was not put there by the spammers. In fact, I don't see a way to
forge it. It has the IP of the client who sent the spam and never one
of yours.

> * I'd previously done something much less draconian (back in the good
> ol' days when we were getting only 5 million joe jobs a day) but
> similar by looking at headers. I'd need another rack of machines to do
> the recipient verification, so being able to look at headers in the
> DATA ACL is out of the question. We've got about 10 machines handling
> incoming mail now.


Too bad you can't process the message body in the DATA ACL. I think
you'd be safe then.

Or, mail experts, am I wrong?

Marilyn Davis

>
> Anybody have any tips on how to mitigate this, externally? I'm
> completely at a loss. I can't possibly contact all of the thousands of
> companies bouncing mail to us. Is turning on SPF our only hope (and
> even then, does anyone expect that it'd help more than maybe 10-20%?)?
>
> Our totals today are about 90 million connections over 10 machines
> behind a load balancer. Granted 75 million are being rejected in the
> RCPT ACL. The boxes are running at a load of 15 or so pretty much
> continuously (which is where I have smtp_load_reserve set).
>
> Thanks!
>
>


--