Managing Network Security

Countering DCAs

by Fred Cohen

Series Introduction

Computing operates in an almost universally networked environment, but the technical aspects of information protection have not kept up. As a result, the success of information security programs has increasingly become a function of our ability to make prudent management decisions about organizational activities. Managing Network Security takes a management view of protection and seeks to reconcile the need for security with the limitations of technology.

DCAs are here to stay.

I got a call earlier this evening from a cybercop on the East coast. He was asking on behalf of lots of folks who were recently attacked by Distributed Coordinated Attacks (DCAs) if there was anything they could do right now to defend themselves. My answer was not as hopeful as it might have been, but after I hung up, I thought about it, and I think there are some things we can do here and there to fare better than many folks have been doing to date.

With that in mind, and realizing that it's getting late on a Friday night, I figured that the only way to get the word out would be to write this article and tell a lot of folks about it. Now I realize that this is supposed to be a management article and all, and I also understand that having written all of these management articles over the last few years, I may no longer be able to do technospeak. In fact, I was appalled recently at two events - one in which a woman of about my age told me that I represented one of those outdated old white males - and another in which a youth in his early twenties accused me of being a know-nothing old guy who couldn't possibly understand what he was telling me since he had spoken to nearly 20 real hackers in his career. However, I am a brave sole by nature, and I figure I have a few bytes left in these weary brain cells of mine, so here we go.

This article is about defending against DCAs here and now. It's not about perfect defenses and it's not about what we might be able to do some day or in an ideal world. It's about the options you have here and now, while we're under attack, in the trenches.

How would I know anyway?

Now I don't want you to get the wrong impression about me. I didn't think up these things I am about to tell you with the luxury of hindsight or in my pensive moments. Every one of the techniques I will discuss was developed in haste while under or about to be under attack. Yes - I generally know ahead of time that I will be attacked in a particular way.

For example, I knew that I was likely to be attacked in a big way earlier in 1999 when I 'offended' some of the malicious virus-writing community by telling everybody I could about their virus and FTP site for stealing RSA keys. It was a few months before they launched the papa virus aimed at denying service to my site by packet flooding. It failed because I knew something like that was coming and prepared for it ahead of time. It did bring down the @home network for a while, but my important sites were both reachable and reaching out to the rest of the world the whole time.

In the same way as I knew that then, I know now that within the next few days or weeks or months, somebody will be hitting my site with yet another DCA - perhaps one of the newer high-tech ones. I know that despite their best efforts, law enforcement will be unable to do much about it, and I know that bothering to trace down the source will be fruitless because the level of damage will not exceed the current threshold for law enforcement caring about it. But I am not worried, and frankly, neither should you be. As the song once went... "What's the use of worrying, it never was worthwhile, so... pack up your troubles in your old kit bag and smile, smile, smile. (I'm not really that old you know...)

Defense Strategies Against DCAs

These strategies are long-term things that you can do to mitigate the risks from large-scale DCAs. They are directed primarily at preventing attacks from being launched and being prepared for attacks if they come.

Well, with this much strategic preparation, you can likely weather any storm out there today unless it is very well resourced. That is - if you know how to use these resources.

Defense Tactics Against DCAs

The basic tactical plan for the defender is to fend off the attack rapidly by moving to redundant infrastructure and leaving the attack on the infrastructure it started with. If the attack follows you through the infrastructure changes, and assuming the details of the redundancy have been kept properly confidential, this requires active control on the part of the attacker. In order to exert that control, (1) the attacker has to have a lot of resources - which each in turn get destroyed as they are used because the defender is able to filter them out - and (2) the attacker has to issue commands to redirect the attack over time. These commands are traceable to their source - if law enforcement is involved. The goal is to be able to move at a faster pace than the attacker, exhausting their resources, and tracing them further and further toward their source. You stay operating, they chase you with little effect, and they get tracked down and arrested. In the military parlance, this is called maintaining a faster operational tempo than the enemy.

Now that I have given up the plan, all you have to do is execute it. With proper planning, technical skills, and training, any reasonably good network security and IT department should be able to carry this off in real time and to great effect.

What was that?

I'm sorry. I thought my work was done. So you don't have all of this set up and worked out yet, and you are under attack right now! OK. Here are some cheap tricks that might get you out of it this time, but you can only use these if you promise to do the right thing for the future.

Some Other Details

Since I first wrote this article, several fine discussions of the topics related to IP address forgery have taken place, and I thought it might be worthwhile to include the details here. Please feel free to skip over the rest of this section if you don't want to hear the technical stuff.

Since the SYN floods of a few years ago, the mechanisms in OSs have changed to mitigate the effects of SYN flood attacks. There are several versions of the change, however, the basic limitation is the size of a table in the kernel that keeps track of pending TCP connections. While increasing the table size is helpful (typical size was 128 for Unix boxes, so some have gone to 2048 or so) it also takes up more and more kernel space - which is not swappable and thus reduces available memory. The other simplistic move is to reduce the time associated with waiting for a connection to complete from 120 seconds (which it used to be) to - say - 15 seconds. This has a fairly small effect on reliability but, if used with 2048 table size, it means that you can handle up to about 150 SYNs per second. You can adjust these a bit more, but then you are done. That is why three different strategies were adopted:

So as we see, with the available technology, we can always defeat SYN floods, but it does require that we properly configure our systems and do the calculations necessary to assure that we can meet the peak demand. We'll do the calculation for the random drop method as an example. The trick is to know the incoming bandwidth and calculate the number of SYNs per second

Then take the average number of seconds delay under high load (say 5) and provide a queue that is large enough. For a 50% chance of not getting a legitimate SYN hit by a flooded SYN:

For a 10Mbit/second wire, you need a table with 250,000 SYN entries for a 50% chance of a legitimate connection being hit at super high loads. At 10 bytes per table entry, this comes to 2.5Mbytes of kernel memory for the SYN table.

As an aside, there is another defense method that was discussed but never widely implemented in the attacks in the 1996 time frame. The idea is to use the properties of the pseudo random number generator (PRNG) used by the attacker to defeat the attack. In this technique, you predict future source addresses from past source addresses and rapidly reconfigure your defense to reject the coming datagrams before they show up. As they show up, you update the datagrams you reject so that a normal user coming in on that IP address is not hindered. If you do this well, you can stay within a very tight window and only block a few IP addresses from each remote attacker for a period of a few second. This works very well for published off-the-shelf attacks as well as attacks written by people using easily predicted PRNGs.


OK. I've given away most of my best secrets for defeating DCAs, and wasted another perfectly good Friday night working instead of relaxing like I am supposed to do on Friday nights. At the same time, I have invited attack by every DCA writer who will be upset at my providing an out against their latest scripted attack and because they can't rip off a big company for $100K. Too bad those big companies aren't paying me for the service.

Above all, I am a realist. You can count on this or similar advice soon being posted on the CERT or some such place - likely without giving this article credit for the idea and without citation. Then the big CPA firms and major manufacturers will start to sell it, first in a consulting role, then as products and related services. They will all forget me just like they did a few years back when I wrote an article on how to counter IP address forgery. As an aside, if all the ISPs would follow the advice in that article, the current spate of attacks would be easily tracked and countered. Next year, the US will give out several multi-million dollar government grants in this area, and none of them will even mention me, much less seek my advice or council on the matter.

Thank goodness for Network Security Management Magazine. At least they will pay me a few hundred dollars for this article. And you never know, next year I may even make the SANS security roadmap. Large corporate donations of gratitude (we take visa/MC) are accepted...

About The Author:

Fred Cohen is exploring the minimum raise as a Principal Member of Technical Staff at Sandia National Laboratories, Managing Director of Fred Cohen and Associates in Livermore California, an executive consulting and education group specializing information protection, and a practitioner in residence in the University of New Haven's Forensic Sciences Program, where he educates cybercops on digital forensics. He can be reached by sending email to fred at or visiting /