Wednesday, February 27, 2008

Very Common Uncommon DoS attack vectors

Who needs bot armies when you have end-users, uncooperative software, and overwhelmed systems and network administrators?

I have found a few recurring themes lately which fall loosely under the heading of Denial of Service attacks, but turn out to be something else. These are things I've seen seen in my clients' environments and heard echoed from other consultants and IT pros, especially in small businesses.

The first two "Denial of Service" attacks are often reported as a DoS eating up all available bandwidth. Those who guessed a combination of end-users with streaming media and/or peer-to-peer traffic got the first one and get a gold star. It doesn't take too many users streaming media to cripple your network. I have been a big proponent of Internet filtering for a long time, this is one reason why. The second one is a bit trickier and has to do with the evolving nature of devices at the network perimeter. More and more small businesses have proxies in their networks, usually in their firewalls, UTMs, or content filters- and they don't usually have fully locked down desktops or patch management systems. The problem is that all of those automatic update applications bundled with everything from your OS to your PDF reader don't always understand proxies, and visa-versa. This scenario play out something like this:

  1. The update application "phones home" (there's another issue, but we won't go there now)
  2. It finds that there is an update available
  3. Launches the downloader
  4. The proxy intercepts the request and starts a download
  5. The application downloader gets impatient and requests a new download
  6. The proxy intercepts the request and starts a download
  7. And so on until a handful of client machines crash your entire network.

You could blame the proxies, but they are just doing what they are supposed to. The downloader apps could be more patient, but the only real workaround I have seen is to whitelist the download sites. I say workaround rather than fix because the proxy generally has to pass the file without scanning it. You should be able to trust the update servers, but I would rather be able to "Trust, but Verify" instead of "Blindly Trust".

The third category of misdiagnosed DoS attack has been with us for a long time and is not going away any time soon. Some people like to ridicule the "incompetent" system and network admins throughout the industry, and there are certainly a few who might be better suited to another line of work (maybe involving the phrase "would you like fries and a soft drink with that?") but very few admins have the training and resources they need- and they make mistakes. Big mistakes, little mistakes, and mistakes that are just right. I won't go into too much detail, we've all made mistakes and cut corners. I have recently seen a few cases of harried admins leaving gaping holes in their infrastructure which resulted in serious problems for the network. A couple of hints:

  • Don't leave vulnerable services open to the Internet.
  • Move services off of their standard ports if you have to leave them open (port 22, SSH is getting heavily scanned and attacked lately).
  • Watch out for service port conflicts when you are port-forwarding to/from non-standard ports, your traffic may end up somewhere unexpected and unwanted.

When something goes wrong that we do not understand, we often think we are being attacked. It is primal, and it works well if you are trying to feed yourself while not being eaten by lions- but it isn't always helpful when trying to diagnose network problems. Step back, look at the clues, isolate the problem, and then identify it- it isn't always the lions.