Coping with a DoS attack

We keep hearing about Denial of Service attacks, and how they can bring large organisations to a standstill, yet do we really understand the full range of events that the term encompasses? What does make up a DoS (or distributed DoS) attack, how it is done, and what can you do to prevent it happening to you?

There are probably four main categories of DoS attacks.

Resource starvation is when an end system (usually a server or possibly a router) is targeted, and all of its resources used up so that it can’t process any new, legitimate sessions, thereby denying access, for example an ecommerce server that can’t be used by potential customers.

Bandwidth consumption attacks the network rather than end system, the idea being to prevent anyone else being able to access that site. This is normally targeted at WAN links, and is where we tend to see Distributed DoS attacks focused (see below), since often otherwise it wouldn’t be feasible for an attacker to be able to generate enough traffic to flood a high speed link into an enterprise.

Routing and DNS corruption occurs when attackers manage to persuade network users that the best route to a particular address is via themselves rather than the correct path and effectively hi-jack and blackhole all traffic intended for that site. This is the sort of thing that can happen accidentally even on a campus LAN, if someone installs a Unix server, for example, running routed, and advertising a default route to itself which takes precedence over a real default route to the Internet, say. Similarly pretending to be a DNS server and sending erroneous addressing information can also effectively take the intended recipient out of the picture altogether.

And then there are the bugs, misconfigurations and errors in programming that allow malformed or specially crafted packets to crash a system. Often these will be advertised by the manufacturer and a patch produced when a vulnerability is discovered, but the time between this notification and companies managing to test out and deploy such fixes is often open season as the attackers seek to make the most of new loopholes.

Mitigating against DoS attacks

DoS and DDoS attacks aren’t particularly elegant. They can certainly be effective, but they don’t require as much skill as some of the less obvious attacks and intrusions. Someone who’s determined to gain access to your network to acquire confidential information, for instance, may spend a lot of time navigating your environment, studying its topology and configuration, and sneaking in and out with the information without you knowing. Someone who just wants to create havoc will launch a DoS attack with the aid of one of the many tools around and sit back, thinking they’ve done something clever.

The fact that it isn’t all that clever means you have a chance of deflecting them.

One of the most common resource starvation attacks is using SYN floods, whereby an attacker launches multiple TCP SYN connection requests at a server. This can quickly use up all connection resources (the amount of in-progress connections supported usually being very much lower than the number of actual sessions a server can handle). Some operating systems have SYN flood detection inbuilt now; however it can also be stopped from ever reaching the server by using network or host based intrusion detection systems — content switches, which employ delayed binding in their load balancing mechanisms, will also prevent these SYNs getting to the target.

When it comes to preventing bandwidth hogging, here you need to protect yourself against not just the potential attack itself, but also to stop yourself being used as an amplifying network in a Distributed DoS attack. Because it can be quite tricky for one attacker to over-utilise a corporation’s bandwidth (or use up all processing resources on a large server), with a DDoS attack, an attacker sends information to a group of vulnerable systems, not to attack them, but to make them attack a third, different target.

Typically this is done by sending ICMP requests or UDP echoes, supposedly from the target, using a spoofed address, to a group of devices on the intermediate network. They will then all reply to that address and flood the intended victim.

Usually this is done using a directed broadcast address from attacker to intermediate network, and it’s not difficult to prevent this by turning off the ability to pass directed broadcasts through your routers and systems. In terms of protecting yourself against the end attack, as a minimum, limit ICMP traffic from entering your network to protect your devices. In order to stop them flooding your WAN bandwidth, you can ask your provider about rate limiting this type of traffic before it ever gets to your ISP router.

The only way really to prevent erroneous routing updates from poisoning your environment is to use authentication on your routers (and hope that your service provider does too). Unfortunately, the levels of authentication available for the different routing protocols aren’t always all that great, but it’s definitely better than nothing and ensures that the only devices routing on your network are the ones you want to be.

For specific platform or code vulnerabilities, it’s essential that you keep code up to date with all the latest security patches and manufacturer-recommended workarounds. It may be a never-ending battle, but it is possible to deter at least the more casual troublemaker.

Join the newsletter!

Error: Please check your email address.
Show Comments

Featured Whitepapers

Editor's Recommendations

Solution Centres

Stories by Louise McKeag

Latest Videos

More videos

Blog Posts

Market Place