Practical Rate Limiting numbers?

[mgraci_ironport]

We got swamped by a german spammer sending over 160,000 messages in 4 hours.

Does anyone have any practical suggestions for using rate limiting beyond the defaults?

-Matt

[MikeK_ironport]

We throttle between 0 - (-2) and block all below -2

[Corey_ironport]

We throttle between 0 and -4.9 and block -5 to -10.

[shannon.hagan]

Bet you wouldn't be doing that if you had to put up a phone number do they could call you to find out why they are blocked.

The company I work for :
TCP Refuses for -7 to -10
Puts in the banner to send a message to postmaster for -2 to -7 (used to have a phone number but it recently got removed due to the abuse)
Really throttles 0 to -2
And throttles all other traffic to a reasonable number

[mgraci_ironport]

Whats the different between Reject and TCPREFRUSE?

Why would I choose one over the other?

-Matt

[jsikorski_ironport]

A TCPREFUSE simply rejects the connection- no SMTP banner, no error message, etc. To the naked eye, it will appear as if the remote mail server is completely down.

The "Reject" behavior actually allows a connection to be established before sending an error message via SMTP (4xx, 5xx) and disconnecting. Since a rejected sender can use the error message to gain some insight into why they've been blocked, this method is usually preferred.

-Jason

[MikeK_ironport]

We block everything below -2 and throttle between 0 and -2.

Mike

[Donald Nash]

Speaking of TCPREFUSE vs REJECT, I'd like to see a third option: BLACKHOLE. This one would throw the incoming SYN on the floor, making it look to the attempted sender like the entire server is dead. If the idea is to provide the least amount of information possible to a would-be attacker, not even letting him know that you're alive would be best. It also means he has to wait for the connection attempt to time out, which costs him time. I'm sure that spammers use short timeouts to foil this sort of passive attack, but every little hindrance helps.

[kisanak_ironport]

Speaking of TCPREFUSE vs REJECT, I'd like to see a third option: BLACKHOLE. .

How do you implement this? there's no blackhole option on the mail flow policy.

Instead of giving them phone number, I'd like to put a url-form, so the legitimate senders can use this form to unblock their IPs.

[Donald Nash]

How do you implement this? there's no blackhole option on the mail flow policy.

Yes, that's my point. There is no such option, so I'd like to see IronPort implement it.

[jsikorski_ironport]

I'll play devil's advocate.. are there any other ways that a BLACKHOLE would be better/different from a TCPREFUSE? I understand the part about the SYN being dropped on the floor - but the end result is still the same (no TCP connection; do not pass go, do not collect $200).

Since spammers generally obtain IPs from a domain's MX record at least once (in other words, you're advertising the fact that you run a mail server on $x IP address), what's the advantage of "playing dead" when you can make it known (at layer 4) that you don't want their traffic? Seems like playing dead would cause them to retry, where an outright TCP refusal might not.

I do like the added advantage of forcing them to wait for a timeout - depending on the number of domains a spammer is sending to, those could add up.

[Erich_ironport]

You have to be careful, if your doing network load-balancing to multiple IronPorts the "BlackHole" effect can really mess with some load-balancers. And he has a point, your MX record is out there, you can only hide so much. :?

Don you got my vote for best MX record names!!! You got love those names :lol:

its.utexas.edu. MX ironfist.mail.utexas.edu. [Preference = 10] its.utexas.edu. MX ironmaiden.mail.utexas.edu. [Preference = 10] its.utexas.edu. MX ironman.mail.utexas.edu. [Preference = 10]

[Donald Nash]

Since spammers generally obtain IPs from a domain's MX record at least once (in other words, you're advertising the fact that you run a mail server on $x IP address), what's the advantage of "playing dead" when you can make it known (at layer 4) that you don't want their traffic?

Spammers don't care that you don't want their traffic, so they have no incentive to learn that "TCPREFUSE" means "go away and don't come back." How many of us have seen spammers repeatedly banging their heads against the wall of TCPREFUSE or SBRS rate limiting? Blackholing their connection requests has an effect similar to tarpitting: it slows them down so they can't beat on you as hard. TCP SYNs and RSTs might not cost much, but they're not totally free either.

You have to be careful, if your doing network load-balancing to multiple IronPorts the "BlackHole" effect can really mess with some load-balancers.

Good point. I had allowed myself to forget about that.

 Don you got my vote for best MX record names!!!

Thanks! We also have ironlung and ironhorse waiting in the wings. I've got a whole list of "iron" words that I put together just for this purpose.

[jsikorski_ironport]

How many of us have seen spammers repeatedly banging their heads against the wall of TCPREFUSE or SBRS rate limiting?

Interesting - so you're getting hit by spammers who keep retrying after being TCPREFUSE'd? Could the connections be coming from a poorly configured (legitimate) MTA, or are you sure they're from spammers?

In the past, I haven't noticed behavior like that coming from actual spammers.. I figured they wouldn't want to take a chance on drawing attention to themselves. Guess I've been giving them too much credit. :-)

[Donald Nash]

Interesting - so you're getting hit by spammers who keep retrying after being TCPREFUSE'd?  Could the connections be coming from a poorly configured (legitimate) MTA, or are you sure they're from spammers?

It's spammers. Here are my top 10 for the past 36 hours or so (that's how many logs I currently have uncompressed):

Count   IP Address       Host
------  --------------   -------------------------------------------------
122517  221.189.115.48   p16048-ipbffx02marunouchi.tokyo.ocn.ne.jp
122287  65.222.147.130   system130.VOBAutoSalesBMW.com
 96216  201.152.87.217   dsl-201-152-87-217.prod-infinitum.com.mx
 94282  68.163.223.223   pool-68-163-223-223.bos.east.verizon.net
 76931  66.74.166.80     cpe-66-74-166-80.socal.res.rr.com
 57106  220.119.138.107  No PTR record; address belongs to Korea Telecom
 56831  69.155.94.109    adsl-69-155-94-109.dsl.rcsntx.swbell.net
 56383  201.24.228.73    201-24-228-73.ctame704.dsl.brasiltelecom.net.br
 55590  68.234.70.9      londonderry-cuda1-68-234-70-9.lndnnh.adelphia.net
 54846  141.154.209.79   pool-141-154-209-79.bos.east.verizon.net

Eight of the top 10 are DSL or cable modem connections, i.e. spam zombies. The top two are hitting me at 1 connection attempt per second each. And remember, this is just the top 10. In the same appx. 36 hours, my appliances refused 4.8 million connection attempts. That's almost 40 per second.

I've seem similar behavior from spammers that run afoul of our SBRS-based rate limiting. They send RCPT TO commands as fast as they can in spite of the fact that they keep getting rejected by receving control. They just don't care because experience has shown that they don't need to.

In the past, I haven't noticed behavior like that coming from actual spammers.. I figured they wouldn't want to take a chance on drawing attention to themselves.

This doesn't jive with my observations. They have no reason to be subtle because they're mostly using throw-away zombie systems.