Counter-attacking DDoS: something that works

Yesterday I told you that we were under a mail-bomb DDoS. Message rates of about 147 per minute. As our normal rate is 1-2 messages per minute, this was a 100x or more increase. Not against our normal domain name, but against one that we host. One that doesn’t have a web site. And has one email user. Obviously the people who did this are really, terribly smart. Oh yes. (keyboard dripping with sarcasm). Going after low profile targets of marginal value is not the hallmark of a deep thinker. But lets not dwell on that, lets focus on how to defeat this. Have a look at this:

[

](http://scalability.org/images/counter.jpg)

Notice that sudden drop off right before midnight. Thats when I began our counterattack. The counterattack makes use of a very simple reality. Every one of these attacking servers needs to know how to map the domain name they are trying to send mail to, to an IP address. If they were attacking IP addresses, then we could change that with little loss of functionality. If they are attacking domain names, we can counterattack by providing a purposefully incorrect mapping. Which is what we did. Starting at, about 23:10 or so. We left that mapping in place for about 1 hour. And then restored it. Mailbombs must be based upon scale-free networks, as our counter attack was devastating. After restoring the correct mapping at 0:30, the attack network did not recover. No adaptation is built into it for continual attacking. And this is interesting. If the attacking system cached the IP address to name mapping, we could simply change the IP address to name mapping, and the attack would fail. If they relied upon DNS (which they do), then altering the name to IP mapping should put individual bots out of commission. If they cached and did a bit-torrent like exchange of mapping, then they could be traced based upon their communication pattern , and this wouldn’t be a set of independent bots, but a coordinated attack. With some effort, we might be able to determine the bot master, and therefore prime the law-enforcement folks to start their work. But our counterattack does more than that. It must put the central bot-master out of commission. Which means we now know how to disable this class of attack. It also suggests an interesting defense against such bot attacks. Continuously variable server names, shifting every few minutes. Real mail systems, that is ones that work correctly, will understand links being down, and will be able to deal with 450 messages, or set up retries moments later, or requery DNS. Bots generally are not so smart, don’t implement a mailer. Just injection code. Alter the mail system slightly, so that you assume a rapidly changing IP to name mapping. During a bot attack, turn up the frequency of that change. Bot messages will fall flat, real messages will get through. Make the medium too dynamic for the static bots to deal with. Oh, of course, due to design considerations, this likely will not work with Microsoft exchange or Microsoft tools in general. No problem. The front end of many such systems should be a postfix system anyway (its rather hard to crack a postfix system with exchange hacks), so implement it at that level, and leave the Microsoft tools blissfully in their own assumed universe. Just some thoughts. Note: Our DNS provider used to make this much simpler. It is now harder to purposefully change the mail address to deflect mail bombs. I will bug them about restoring the functionality they removed.