0

Case Study of DoS attack

09/09/2021

The flood of Non-delivery reports (also known as Backscatter) due to legitimate servers sending out non-Delivery Reports to other legitimate servers has been really noticeable this week. We have had many customers call to see if others were reporting the same surge. These non-delivery reports are not technically spam, as both parties are legitimate, but it is really a big nuisance. If the forged "from" is the same sender for thousands or millions of spam messages, the resultant non-delivery reports can overwhelm the spoofed, innocent sender in essentially a DoS attack.

A reseller in the Czech Republic, Eduard Svarc, wrote this case study of his direct experience with a DoS attack due to the backscatter that he got. His English is excellent, and his meaning is always clear. Thanks, Eduard, for taking the time to share your experience.

Here is my full story. Once one of our customer did say he having problems to access our B2B application because responses were really slow. My team went to investigate reason. All did seems to be OK because all system work without any flaw, except that we had high utilization on our Internet connection . When I did look at report which I got into my e-mail from SpamSentinel to my administration account I was stunned. Our normal daily e-mail utilization was around ten thousands per day. We were at three hundred thousands e-mail per day at these days!

Here is the data from the Administrator's Report:
Date
Processed
Blocked
Block Percent
2-Mar
6,563
6,559
99.9%
3-Mar
34,319
34,181
99.6%
4-Mar
89,356
89,175
99.8%
5-Mar
358,983
358,615
99.9%
6-Mar
87,158
87,104
99.9%

So we found where is problem and I did start investigate reason, why our mail server is so overloaded. I start checking how many connections mail sever have and from where these connections come. I found that is zombie pc network most IP addresses are assigned to Asia & Pacific, African and Mexico networks. Base of that attack was sending as many messages to invalid e-mail boxes on our server with original sender residing on YAHOO and GMAIL free mail hosting. Senders domains were
com.au, com.tw, gmail.com, hinet.net, net.tw, sinamail.com

I think our server was expected to be one of mail servers who will flood targeted services by not delivery reports. Each message has more than 10 RCPT TO. For each message at normal conditions would send to our server 10 non delivery records. If you look at daily statistics we had up to three millions invalid recipients at peak per day!

So why I'm telling this story? Because even though we weren't the target of that DoS attack, someone else was, it could bring our core business down, too. Fortunately we were prepared with a tool shielding our server, SpamSentinel in this case. Yes people could say we would use another tool to shield our server. We could have setup our server not to accept e-mails from suspicious addresses. SMTP servers can be shielded pretty well against unsolicited e-mails by using three basic rules:

1) accept e-mails only from machines with DNS record for IP
2) accept e-mails only from machines where IP have valid PTR record in DNS
3) accept e-mails only from machines listed as MX for designated domain

Yes this is true, but these rules are for ideal world. Many of your customers who need to communicate with us, don't comply with these three basic rules. And not only small partners don't comply to these rules, but large companies like MICROSOFT too. They do have so many SMTP servers abolishing these security rules. We need to be able communicate with these companies, so we can't use rules like I did mention.

SpamSentinel did its job pretty well by deleting and blocking 99% of e-mails on start. It stopped the wave even before we knew about that wave. Yes is not perfect there is room for improving. I would like to see to be able specify not send non delivery reports at all in this case we could have 100% success in avoiding DoS or being part of DoS on someone else. Or use small trick which I did saw on another Mail Server product. There is small trick stopping these pc zombie networks doing harms to SMTP servers. Simple trick is delaying answer to first HELO. Few seconds from 20 seconds to 30 seconds delay 100% stops these bots from doing harm. Normal SMTP server according to RFC would wait for answer. Bot has not that luxury, because bot need send as many messages as he can. If he doesn't get answer in few seconds he expecting that server to be dead, which is not true , of course.

On bigger picture. I'm glad to have our Domino Server shielded by this guard called SpamSentinel. All what I did was setting up it well and in result our server scaled for load up from ten thousands e-mails per day, could handle four hundred thousands e-mails and pretty well!

SpamSentinel throw away all harm.

Eduard Svarc
Email Eduard Svarc
DATA Intertech s.r.o.
http://www.intertech.cz/web.nsf/pages/enprofile.html
Kladenska 46
160 00 Praha 6
Czech Republic
tel. +420-235365267, fax +420-235361446


Blog Tags
DOS attack



( 118 )