Question

Consider the following situations:

1. You are the system administrator for an ISP that provides a large network (e.g., over 64,000 IP addresses). Show how you can use SYN cookies to perform a DOS attack on a web server.
2. If you are the system administrator of the web server, how do you defend against such DOS attack?

Answer 1

a. A SYN cookies are a way to mitigate SYN flood attacks.

The gist of SYN floods is that keeping state for an opening connection is expensive (because it uses RAM somewhere). In a SYN flood, the attacker "cheats" by not keeping state: he sends a SYN but forgets it; on the other hand, the server remembers the SYN.

SYN cookies are the server's cheat: it just forgets them too. Instead, it encodes whatever it should remember in the TCP sequence number that it sends in the response to the SYN (an ACK+SYN packet); when a normal client responds to that, it sends its own ACK with the same sequence number (actually incremented by exactly 1), which allows the server to recover the data it did not bother to remember. A TCP sequence number is 32 bits, so the server must fit the "state" within 32 bits. SYN cookies are defined to use 5 bits for a timestamp, 3 bits for the MSS, and 24 bits of "output of a cryptographic function". These 24 bits are really a MAC computed over the server IP address, client IP address, both port numbers (server side and client side), and the timestamp.

A consequence is that when the server receives an ACK which looks like a response to an ACK+SYN (one with a cookie) then the server must consider it as the third element of a TCP handshake, and thus allocate the resources for a now fully open connection. This happens if and only if the cookie value is correct (when the server recomputes it, it matches the value sent in the ACK). The attacker knows the current time and can guess/observe the three-bit encoding for the MSS value, so there are 24 unknown bits. If the cookie value is computed properly (with a cryptographic hash or something equivalent in this situation), then an attacker has only probability one in 16 millions (16777216, precisely) to hit a correct cookie value. This severely limits the possibilities of the attacker.

There has been some discussion on the CPU cost involved in SYN cookie processing. Consider that a basic Core2 x86 CPU will happily compute 8 millions of MD5 hashes per second, using a single core. It will be hard for the attacker to DoS that way (it would require sending more than 8 millions packets per second to that server...).

What can be done is the following:

• Attacker sends a normal SYN, then receives the ACK+SYN from the server. The ACK+SYN contains a valid cookie for the source address and port that the attacker used; the cookie is valid for a minute or so (since the timestamp changes typically once every 64 seconds).
• Attacker repeatedly sends, using the same source address and port, two packets:
  • a packet containing a ACK and the cookie obtained above, and also some applicative data (a 'push') which encodes a valid HTTP request;
  • a second packet which does a RST.

Upon receiving the first packet, the server must assume that it is a valid third packet of a TCP handshake; it then reads the data and processes the HTTP request. While the HTTP server software considers the request (and this can involve considerable resources, especially if the request is a POST and/or requests HTTP-level compression with gzip), the target kernel reads the RST and considers the socket as closing -- the HTTP server will get a write error when it will try to send the HTTP response (but only then, not before).

Since the connection is closing, the source address+port is considered "free" again, so the next ACK+push from the client will be honoured similarly.

The 64000 IP addresses come here as a way for the attacker to "fly under the radar". Repeated connections from a single IP address are likely to be noticed by any half-decent firewall, and blocked early on (before reaching the target Web server). Since the evil admin "owns" 64000 addresses, he can simulate connections from any of the 64000 addresses. The attacker would use a first SYN to get a cookie, then send a hundred or so ACK+push,RST pairs from that address. For increased effect, he would do that with a hundred addresses at a time, regularly getting new ones. He has 64000 addresses to play with, so it will take some time before he has to reuse an address.

In that scenario, the SYN cookies have the following aggravating effect, when compared to the same setup without SYN cookies: they allow the attacker not to wait for an ACK+SYN most of the time. This disables one of the classic countermeasures against DoS, i.e. adding a bit of latency when responding to a SYN.

This is still unconvincing. The SYN cookies, here, do not multiply the attacker's power by a large factor. With 64000 addresses, the attacker could maintain a million open connections (or at least seemingly open, from the server's point of view), with or without SYN cookies, and no Web server will resist that.

b.The best way to detect and identify a DoS attack would be via network traffic monitoring and analysis. Network traffic can be monitored via a firewall or intrusion detection system. An administrator may even set up rules that create an alert upon the detection of an anomalous traffic load and identify the source of the traffic or drops network packets that meet certain criteria. most effective solution for preventing DDoS is through a global cooperative effort to secure the internet. The first step in the process, therefore, is concerned with scanning your internet computers to make sure they are not being used as unwitting DDoS attack platforms. This is not just good internet citizenry, however, because this also serves to document and verify that your internet computers are not suspect when DDoS attacks occur.

• Recognize and understand the vulnerabilities of internet servers:
  • Unless special measures have been taken, internet servers have host names and IP addresses that can be easily looked up by anyone on the internet.
  • Many organizations do not put firewalls in front of their internet servers, leaving them largely unprotected from many of the probes and attacks that firewalls can easily stop.
  • By default, servers listen for service requests on standard, well known ports, and they naturally attempt to process all requests.
  • Servers are designed to run unattended, so there is rarely a "user" present who could look for unusual activity.
  • Servers often need to be administered remotely, from off-site, so they are designed to accept remote connections from users with very powerful permissions.
  • Many servers will reboot automatically after a shutdown, which is exactly what certain types of exploits are looking for.
• If your system has already been compromised, then backup the filesystem, re-install the operating system and restore the filesystem.
• Install operating system updates provided by OS vendor.
  • If the update is security-related, then it is especially crucial to install it.
  • Be sure to read the vendor's documentation carefully. Some updates are less well-tested than others, and an update can actually harm your system if it contains defects.
• Secure the servers.
  • Turn off all unnecessary server services. Many of the services offered by your operating system are not required by your web server, for example RPC-based services. Adopt the attitude of "deny first, then allow". Assume a service should be turned off, unless it is absolutely required.
    • First determine which of the program-based services can be turned off, such as FTP, telnet, etc. These services are easily found as executable programs in the file system.
    • Many systems have been compromised by exploitation of buffer overrun bugs in the RPC services "statd", "cmsd" and "ttdbserverd". These attacks are described in CERT Incident Note 99-04 available on http://www.cert.org/incident_notes/IN-99-04.html.
    • Next check your operating system's documentation to see if it is providing services at the kernel level which are not visible as separate programs. For example, the netmask service may be provided at the kernel level. In this case, determine what parameters can be set, if any, to turn off kernel level services that are not required.
    • Contact your operating system vendor to find out if there are additional kernel level services that are not in the system documentation, and, if so, how to disable them.
    • Once all unnecessary services have been disabled, make cryptographic checksums of the entire system, which can be used later if there has been a suspected breach.
      • For UNIX-based systems, Tripwire will handle this, available from TSS.
      • More information on cryptographic checksums is available on http://www.cert.org/security-improvement/practices/p043.html
  • Configure the web server software.
    • Verify that you have the latest version of the web server software installed. If your version is old, get the new one and install it before continuing.
    • Turn off all unnecessary services offered by your web server software. For example, Java support, CGI support, and Server-side Script support should be turned off if they are not required.
  • Limit physical access to the server.
    • Take appropriate action to ensure that the server is only accessible to the designated system administrator(s). All the security in the world can be defeated by a simple floppy disk if the perpetrator has physical access to the server.
• A comprehensive treatment on server-side security is currently available

For the most part, companies don't know in advance that a DDoS attack is coming. The nature of an attack will often change midstream, requiring the company to react quickly and continuously over several hours or days. Since the primary effect of most attacks is to consume your Internet bandwidth, a well-equipped managed hosting provider has both the bandwidth and appliances to mitigate the effects of an attack.