Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Community Member

Practical Rate Limiting numbers?

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

24 REPLIES
Community Member

Re: Practical Rate Limiting numbers?

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

Community Member

Re: Practical Rate Limiting numbers?

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

Community Member

Must be nice

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

Community Member

Re: Practical Rate Limiting numbers?

Whats the different between Reject and TCPREFRUSE?

Why would I choose one over the other?

-Matt

Community Member

Transport vs Application Layer

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

Community Member

Re: Practical Rate Limiting numbers?

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

Mike

Community Member

Re: Practical Rate Limiting numbers?

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.

Community Member

Re: Practical Rate Limiting numbers?

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.

Community Member

Re: Practical Rate Limiting numbers?

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.

Community Member

DA

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.

Community Member

Re: Practical Rate Limiting numbers?

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]

Community Member

Re: DA

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.

Community Member

Re: Practical Rate Limiting numbers?

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. :-)

Community Member

Re: Practical Rate Limiting numbers?

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.

328
Views
0
Helpful
24
Replies
CreatePlease to create content