Kurt Seifried, [email protected]
February 2, 2000 - Denial of service attacks are a part of life on the Internet. They are generally speaking the easiest attacks to commit since they require minimal skill, only a minimum of knowledge about your intended victim's network, and can be done relatively anonymously. Businesses and their customers are beginning to rely on the availability of corporate web servers to conduct basic business tasks, such as collaborating on projects, retrieving email securely, checking the status of their pension fund, and so on. The deployment of virtual private networking technology, much of it based upon IP Security (IPSec) is also starting to accelerate, making it possible for businesses to link various sites, traveling employees, and customers together securely and cheaply. As people rely more heavily on these services, they will become an attractive target for malicious people, potentially disrupting large numbers of users and services.
SSL provides authentication mechanisms for the proving of identity as well as encryption services for data. The problem is that unlike a traditional service (say telnet or ftp) there is a relatively high overhead on the encryption and decryption required to talk to other parties. Flooding a traditional HTTP webserver with say 50 bogus requests a second won't bother most servers (for example SecurityPortal.com recently got slashdotted, site traffic suddenly jumped but the servers managed to make it through), however flooding an HTTPS (SSL enabled) webserver with 20 requests per second can quickly bring it to it's knees. Processing an HTTPS based request as opposed to an HTTP request can require up to 10 times (and sometimes more) the CPU time, due to the decryption that takes place. Even if you require secure digital identification (using a client based X.509 certificate for example) of the party requesting a document from your secure website there is still significant overhead in figuring out if the request is kosher or not. Even with hardware crypto accelerators for SSL, a determined attacker can still flood a server into the great beyond.
"QuickSpecs: Compaq AXL200 Accelerator PCI Card
The Compaq AXL200 Accelerator PCI Card is the performance solution for secure application servers. It supports more than 200 secure sockets layer (SSL) connections per second. [Adobe Acrobat]"
This is one of the latest, greatest cryptographic accelerator cards to be released, and it only supports up to (let's be charitable and say 300) 300 connections per second, even with a server farm of say 20 servers, an attacker would only have to generate 6000 requests per second to flood your e-commerce site (or whatever you are using it for) into the dirt. You might be wondering at this point "how is an attacker going to create 6000 bogus SSL connections if SSL is such a CPU hog?" the simple answer is: (s)he doesn't have to. They can simply create a few bogus SSL packets and send them repeatedly, or simply flood the server with garbage packets which it will try to decrypt (and fail at). Unfortunately you can't block these bogus requests, since the attacker will simply start spoofing their packets as from large proxy servers and customer machines that you want to talk to.
It gets worse, too.
Probably the best thing you as an administrator can do, right now, is to make sure your firewall rules prevent spoofing. If all networks had outgoing firewall rules that prevented any packets claiming to come from networks not actually at that location, the ability to trace attacks would be significantly easier. Additionally by having outbound filters you stand a much better chance of detecting malicious users and compromised hosts internally, and the odd misconfigured host. If you have a high requirement for security I would advise against using the Internet, frame relay is a lot better, and dedicated lease lines are best (but hideously expensive), and if an attacker is sufficiently motivated they will rent a backhoe and buy some blueprints. Some firewalls (like IPF) will let you block small mangled packets, which is another technique attackers can use to a) sneak the packets past many firewalls, and b) use server resources, while it tries to put the packets together (i.e. it will wait for fragments that never show up).
Last updated 9/10/2001
Copyright Kurt Seifried 2001