HOW DOS ATTACKS WORK

---

The main thing that makes DoS attacks so hard to fend off is that, at least on the surface, they look like valid traffic. The basic difference between legitimate visits and attacks is the intent—along with the volume, frequency, and source of the traffic. Normal traffic to a mail server might come in spurts and waves, but an attack against sendmail entails a barrage of messages in close proximity—so close that the service cannot keep up with the volume and crashes or hangs. In fact, a DoS attack will likely bring the system itself to a halt. If the server doesn’t run out of swap space, it will probably run out of process space or network connections. It’s also likely to suffer from network congestion problems. In addition to the difficulty of differentiating attacks from normal traffic, it is hard to effectively slow down or control the traffic comprising the attack.

DoS attacks are cheaper to launch than to deal with. The effort involved in launching attack is almost always minimal compared to the effort involved in fending off or recovering from the attack.

DoS attacks are hard to characterize because what they have in common is their overall effect, not the technique by which they’re carried out. DoS attacks can seek to flood a network with traffic or to modify a router’s configuration. The goal of both methods is to deny legitimate users access. The various means of achieving that goal have little in common. Typical DoS attacks involve:

• Jamming networks

• Flooding service ports

• Misconfiguring routers or other critical devices

Efforts to flood a network, for example, can block or slow all communication between servers and clients, making it difficult or impossible for any work to be done. Excessive traffic to a specific service port on a server, on the other hand, might make that service or server unusable.

In a DoS attack against sendmail, hundreds of thousands of messages can be sent in a short period of time; a normal load might only be 100 or 1,000 messages an hour. If a DoS attack is noticed in time, a service can be shut down while the organization rides out the attack. That cannot always be done without repercussions, though. Attacks against sendmail might not make the front page, but downtime on major Web sites will. For companies whose reputation depends on the reliability and accuracy of their Web-based transactions, a DoS attack can be a major embarrassment and a serious threat to business.

SYN Floods

DoS attacks do not always involve a deluge of service requests. Some involve the disabling of a critical component. If an attacker crashed or changed the configuration of a company’s firewall, for example, the company would likely be isolated until someone brought the system back on-line or routed traffic through another system. In fact, the recent DoS attack on Microsoft involved interference with the routers that provide access to the company’s Web sites.

Even more insidious than overwhelming a system with legitimate requests is flooding a system with requests falsified in such a way that the server expends more resources trying to validate or complete connections than it would setting up legitimate connections.

One well-known attack of this type is the SYN flood. A SYN (SYN stands for synchronize or start) is a request that’s sent to a server when establishing a network connection (when someone issues a telnet request). In a normal sequence, the server replies with a SYN ACK (an acknowledgment) and the client then sends an ACK in response to the SYN ACK. This orderly handshaking establishes a connection and is called the TCP three-way handshake.

The server keeps track of incomplete connections by maintaining a queue: a kernel data structure of limited size that’s dedicated to keeping track of connections. When the ACK from the client isn’t returned, the incomplete connection sits in the queue until it times out. Because ACKs are normally returned in a matter of milliseconds, a connection that takes minutes to expire occupies space in the queue for a relatively long time. Given enough malformed SYNs, the kernel data structures are used up faster than they can be released, and no additional connections can be made. The pending connections, referred to as being half-open, block proper connections from being initiated.

Why are the ACKs not returned? Generally, connection requests sent in SYN floods contain bogus source addresses. TCP SYN floods are sent with random source addresses. Therefore, when the server replies to a SYN with its SYN ACK, it sends it to a nonexistent system, or one that didn’t make the initial request and isn’t waiting for it.

Though most DoS attacks are deliberate, some are merely a side effect of some other form of abuse or carelessness. A small minority may actually be the result of honest mistakes. When an undergraduate at a major university took it upon himself to mirror a newsgroup on a departmental server, he probably had no idea that the number of visitors would cripple the system so it could no longer be used by the researchers for scientific computation. Similarly, the individual who used an e-mail address associated with one of his employers as a reply address in his spam probably only meant to hide his real address. The fact that the hundred thousand or so bounced messages that a server processed nearly brought the flow of legitimate e-mail to a standstill may or may not have crossed his mind.

DoS Versus DDoS

A variation on the basic DoS attack is the distributed denial of service (DDoS) attack. A DDoS attack is launched from a variety of sites, making it more difficult to detect and block. DDoS attacks are considerably harder to combat because blocking a single IP address or network will not stop them. The traffic can derive from hundreds or even thousands of individual systems; sometimes the users are not even aware that their computers are part of the attack.

Note 

A program may have been planted on their systems as part of a virus.

The potentially unintentional attacks described in the preceding are more like DDoS attacks than normal DoS attacks, simply because the bounces could derive from as many different sources as the original e-mail was sent to. Some DoS attacks can be squelched while in progress by blocking the particular site from which the attack is launched (at your company’s firewall). By blocking a particular IP address, network address, or service port combination, you can keep the offensive traffic from reaching your server—but only if you recognize the attack in time to prevent it from fully compromising your server(s). Unfortunately, most attackers are cleverer than that, and use falsified addresses or launch their attacks from so many locations that it’s impossible to discern the source.

Detection of DoS attacks depends on the requests being sent at regular intervals. If the messages are all from the same site, are the same size, or have some other characteristic in common, you may be able to build a filter that blocks messages that match the pattern. The problem with this approach is that it’s not possible to determine what the pattern will be, and, during an attack, it may be difficult to respond coolly and decisively. Increasingly, products are incorporating detection of attacks, such as filters that look for patterns of activity that correspond to various attack methodologies. Eventually, packet headers may be encrypted so source addresses cannot be falsified.

Some preventative measures might involve pacing a service so it never processes enough requests in a short period of time to overwhelm a service. These choke points are often established on routers and might, for example, limit ICMP requests (as would be used in a Ping of Death attack).

Preventative measures have been slow to evolve because DoS attacks are so diverse and hard to predict. Nevertheless, some effective measures, such as smart filtering on Cisco routers,^[vii] are being developed.

One of the most effective safeguards against DoS attacks is simple redundancy. If your primary router or firewall can be brought down, have a back-up on hand. Also, be ready to rebuild from back-up or hot spares as needed. There’s no substitute for being prepared for an attack—even if the playing field is wide open. A staff that runs through fire drills to prepare itself has a chance of surviving an attack without a major outage.

Many organizations have grown their Internet set of features across multiple devices or possibly multiple network connections—a firewall for Web and mail traffic, a VPN appliance for remote connections, a different firewall for a business-to-business relationship that may exist, or other possible combinations of lines and devices that can push Internet vulnerabilities beyond control. These services can even be distributed across multiple Internet connections or across multiple Internet service providers. Regardless of the number of devices that are on the Internet, each has different services that can be potentially exploited. You can see how an enterprise environment such as this could quickly become difficult to manage from a security standpoint.

What You Can Do

There are a number of things you can do to keep your network connections secure and to keep business running as usual. One of the easiest measures you can take is to clean things up:

• Verify that there are no accounts for terminated employees.

• Check for any manufacturer or service provider default passwords that may be easily known or guessed.

• Verify that any “temporary” services or open ports are disabled.

• Beware of potential internal threats.

• Have the mindset of “deny all except that which is explicitly stated in the rule set.”

After this basic housekeeping is completed, it’s important to perform a “Vulnerability Chain Assessment” with your computer forensics tools on your own. This will allow you to gauge the entire scope of an Internet and network security policy. A Vulnerability Chain Assessment tells administrators what is affected by what and who potential perpetrators could be.

All the items listed below have vulnerabilities—some of which are beyond your control. For each item, consider the potential vulnerabilities that could cause an interruption of service:

• Internet (outside of your router): Internet being unavailable from your carrier or region, phone line cut, denial of service, and so on.

• Internet line: physical disconnection—via a perpetrator or the carrier.

• Internet router: ISP configuration may have well-known default passwords; this could reroute all incoming mail, shut down an interface, or adversely affect performance by some other means.

• Internet/external network: If this segment is a managed device (hub, switch, or other), it could be falsely managed to disable ports or could be affected by the failure of device.

• VPN appliance and firewall: security compromise, stale VPN accounts or vendor default account, unwanted services, failure of device, and so on.

• Internal network: failure of any internal device, internal security threats on interior devices to the Internet, and the like.

Obtain Peace of Mind

One thing you can do to bring some validity to your efforts is to get an external opinion of your Internet and network security. You can obtain this opinion via:

• A formal Internet and network security audit from a person or organization with CISA and computer forensics certification.

• A third-party piece of computer forensic auditing software or OEM-provided tool to examine security issues.

• A professional hacker trying to compromise an Internet presence.

The professional hacker approach is recommended, but you have to be careful. These types of companies need to be true DEF CON followers and really know their stuff. You want a professional hacker to do more than call vendors asking for passwords and back-door methods.

Many general IT vendors offer intrusion detection or an Internet exposure analysis. These third-party computer forensic examinations can yield beneficial information to solidify a security strategy. One of the benefits provided is when they attempt to exploit vulnerabilities (although they will not actually destroy data or compromise systems) and demonstrate how much damage they could do by how far they’re able to get in. It’s a wonderful feeling to present management with a report saying that this external group is impressed with the security of your Internet presence.

Continued Monitoring and Risk Distribution

You can solidify your security strategy by constantly monitoring it and by keeping up with the latest computer-forensic and hacking tools and methodologies. You can also find Web sites that host information on how to exploit specific products. These are usually based on out-of-the-box configurations, so keep current with vendors on new features, versions, or newly exposed risks.

There are countless free or time-trial pieces of computer forensics auditing software you can use to peek at your connection. But be careful. These tools may be dangerous to your operating environment, so a test computer is ideal for such computer-forensic investigations.

One of the things that is also very important is the ability for you to distribute risk. That’s rather easy, actually. However, the better you distribute risk, the more expensive things become. Here are some recommended risk distribution tips:

• If you need firewall and VPN services, consider having those on two different devices—from different vendors.

• Have an alternate Internet connection. If another ISDN or T1 line is not possible, consider testing the alternate serial out interface of a router that may be configurable to dial a modem.

• Put up a honeypot to attract or distract would-be hackers. Give it a registered DNS name such as lotusnotes.company.com but don’t host anything on it.

• Proactively renew or cancel your Internet service provider agreement before it expires or before the carrier contacts you. Do not assume that they will continue to bill you at the current rate or that someone will call you to discuss options.

With a bit of diligence, you can keep your Internet and network security at peak, which will protect the business goals of the organization. Hopefully, this final chapter has provided some fresh ideas on keeping security first.

^[vii]John R. Vacca, High-Speed Cisco Networks: Planning, Design, and Implementation, CRC Press, 2002.

---