Denial of Service (DOS) Attacks

In modern parlance, "security" in networking refers to three factors: Confidentiality, Integrity, and Availability (or C.I.A.). Thus, even though Denial of Service (DOS) attacks don't directly involve the security of a system or the integrity of its components, defending against them is still central to the subject of network security.

DOS attacks don't involve any compromise of a system's security or privacy. Rather, they are simply brute-force floods, sending so much traffic over a network that legitimate traffic is lost in the shuffle. The goal is often to crash the server through sheer overwhelming volume of data and number of requests. These kinds of attacks are much harder to defend against than directed hack attacks, which can be foiled through the use of IPFW, PortSentry, and the other tools we have already discussed. The impact of a DOS attack cannot be eliminated; it can only be mitigated because DOS attacks are made up completely of legitimate traffic, indistinguishable from your actual mission-critical data flow. The problem is just that there's too much of it.

Sometimes, a DOS attack can be identified as coming from a certain source, and you can block it by adding a firewall rule to deny traffic from or to that source. However, many recent attacks hide the actual sourceping (ICMP) broadcast attacks look as if they're coming from a certain source address, which is actually the victim address that receives the brunt of the attack. Distributed DOS, or DDOS, attacks work even more insidiously, with hundreds or even thousands of compromised desktop machines (or "zombies") unwittingly taking part in the attack, so tracking down the actual culprit is pretty much impossible.

Certain configuration options in various servers and in the kernel can help to prevent your system from completely submerging during a DOS attack. The following sections look at a few of these measures; however, bear in mind that they can only serve to increase your system's chances of surviving a DOS attackthey can't neutralize the attack itself, nor can they guarantee that the attacker won't simply try harder until your system does succumb.

Limiting Server Forks

Many DOS attacks are targeted against services such as Apache, Sendmail, or others that operate by forking a new process to handle each incoming request. If an attacker sends an overwhelming number of requests to the service, it will fork off so many processes that the CPU and memory will eventually become exhausted, possibly destabilizing your system.

You can mitigate the risk of a server fork attack by making sure that all your forking services have built-in limits to the number of simultaneous child processes they can have. These limitations can impact the services' ability to fulfill legitimate requests during normal operation, but that trade-off may be what saves you during a DOS attack.

Apache has a MaxClients directive (by default set to 150) that keeps more than that number of requests from being serviced at once. A wily attacker, however, can repeatedly request a processor-intensive CGI script until Apache is creating executable processes faster than they can complete. Requests for executable processes are much more likely to trigger a runaway server than are requests for static HTML pages. If you can get the system to accept a Telnet or SSH login, shut down Apache (apachectl stop) until the attack is over. That may be the only way to recover from such an attack.

If you're lucky, an HTTP DOS attack will be traceable to a single client IP address, which you can block with IPFW rules or with a deny from directive in Apache itself.

If this doesn't work, though, you can always decrease MaxClients to the point where even if the server is maxed out, the clients can't swamp it.

Note

Most HTTP-based DOS attacks today, unfortunately, are distributedand as such their points of origin cannot be determined. The best defense against such attacks is to locate your server behind a network device that can detect and respond heuristically to massive activity, differentiating between IP addresses that can be blocked and ones that should be left open, or creating a "tar pit" that absorbs the attacking traffic harmlessly.

There's a similar feature in Sendmail: MaxDaemonChildren, disabled by default, which you can enable by uncommenting it in /etc/mail/sendmail.cf directly and restarting the server (make restart). Apart from this, Sendmail has a built-in brake that prevents it from starting new processes if the system load is over 12; however, this mechanism has too much lag during a fast-moving attack for the server to respond well, so it might be necessary to explicitly limit the number of children Sendmail can have at a time.

Tip

Other directives in Sendmail that you can use to help foil attackers (or anybody using your server too aggressively) are QueueLA, RefuseLA, DelayLA, and ConnectionRateThrottle. These directives are documented with comment lines in sendmail.cf itself and should be fairly self-explanatory. For instance, QueueLA (which in its default state is set to 8, but disabled) can be uncommented to make Sendmail queue messages automatically rather than attempting to deliver them, if the load average is higher than 8.

A potential general solution to fork attacks, even defending against those that might originate from your own system (a renegade or clumsy user, for example), is to modify /etc/login.conf to put limits on the CPU, RAM, and open file usage that a user can have. Create a class for the user that runs the service in questionnobody in the case of Apache, or an individual local user whose resources you want to limitand use chfn to put the user into the class. An example login.conf class might look like this:

baduser:\         :cputime=30m:\         :openfiles=24:\         :maxproc=32:\         :memoryuse=16m:\         :tc=default:

Then, use cap_mkdb /etc/login.conf to enable this new class and enforce these limits on any user in it.

Defending Against Springboard Attacks

A springboard attack leverages the resources of your own network to achieve its ends. Whereas brute-force and forking attacks require a high-powered attacker doing a lot of work, an attacker can launch a springboard attack simply by injecting a carefully constructed set of requests into the network. Those requests make the network's own infrastructure its own worst enemy.

An attacker can launch a broadcast ping (or Smurf) attack, for example, by sending normal ping requests to your network's broadcast address (which multiplexes the requests out to all hosts on the network). The hacker spoofs the requests' source address so it appears to be a different host. Typically, that host is a hapless victim who suffers a lot more than you do in this type of attack, because every host in your network turns around and floods the victim with ping responses. The multiplication effect of this kind of attack can be disastrous for the victim, and the source is very difficult (if not impossible) to trace.

Note

Another kind of springboard attack injects a UDP packet between two servers' echo service ports. This packet causes the servers to enter into an "echo war" that can be stopped only by shutting off the echo port (FreeBSD shuts off the echo port by default).

Springboard attacks are best prevented at the network's edge router; Smurf attacks can be prevented by configuring your router not to respond to broadcast ping requests. If your router is a FreeBSD machine (see Chapter 28 for information on using FreeBSD as a router), the icmp_bmcastecho="NO" setting in /etc/defaults/rc.conf prevents it from responding to these kinds of requests, which are almost never used for any good purpose.

ICMP error messages are another common source of springboard attacks. The ICMP_BANDLIM tool (compiled into the GENERIC kernel by default) limits the rate at which responses to ICMP error messages are sent, limiting such an attack's effectiveness. In FreeBSD 5.0 and later, ICMP_BANDLIM is no longer even an optionit can't be disabled. You can, however, tune the number of ICMP responses your machine will handle per second with the sysctl command:

# sysctl net.inet.icmp.icmplim=100 net.inet.icmp.icmplim: 200 -> 100

Use sysctl a to determine what the currently set value for the variable is, as shown here:

# sysctl -a net.inet.icmp.icmplim net.inet.icmp.icmplim: 100