Date: Sat, 2 Dec 2000 11:05:28 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: "David G. Andersen" <dga@pobox.com> Cc: Umesh Krishnaswamy <umesh@juniper.net>, freebsd-security@FreeBSD.ORG Subject: Re: Defeating SYN flood attacks Message-ID: <Pine.NEB.3.96L.1001202104006.21765B-100000@fledge.watson.org> In-Reply-To: <200012011906.MAA25650@faith.cs.utah.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 1 Dec 2000, David G. Andersen wrote: > FreeBSD has been synflood resistant for several years. To a first > order, you cannot effectively synflood a decently provisioned FreeBSD > box and deny service to it UNLESS your "synflood" is really just a > bandwidth consumption attack that eats up all of their bandwidth. > > There was a problem that cropped up about a year ago where a *really > high volume* syn flood could cause some kernel problems, but that's > fixed in all of the recent 4.x versions. Really high volume means > 10Mbps+. FreeBSD SYN flood resistance relies on the use of a SYN cache -- essentially a mechanism by which SYNs do not result in full state allocation, and by which that state can be rapidly recycled. In recent versions of FreeBSD, there are additional precautions in the form of avoiding unnecessarily allocating routing state (code contributed by Yahoo!). These techniques help FreeBSD resist moderately bandwidth (>10mbps) SYN floods, depending on CPU and memory capacity of the victim. However, given a sufficiently high bandwidth SYN flood, the system will remain in interrupt processing for extended periods of time, starving the system of CPU for normal processing and continued operation. This does not result in catastrophic unrecoverable failure, but can result in apparent hangs for the duration of the high volume attack. In coordination with Yahoo!, we've been considering implementing some additional steps to limit state and CPU allocation, reduce vulnerability to attacks based on arbitrary (and not hardware-bounded) configuration limits, and increase the rate of state recycling under load (in particular, in response to Naptha-style attacks); as with all denial of service issues, there's a balance between responding to the attack and increasing fragility and complexity of the system. In reality the issue is: can you distinguish "legitimate" requests from "illegitimate" ones without allocating greater resources than you would not distinguishing them; the more sophisticated the attack, the harder it is to identify, and the less you as a victim will be able to respond to the attack. Most SYN attack response mechanisms are heuristics that attempt to balance rapid discarding of incomplete or improper connection attempts while being sensitive to lossy network conditions. Techniques that attempt to address the stateful attack vulnerability associated with SYN attacks (such as traditional SYN cookie implementations) often impose a CPU load comparable or higher than the SYN cache technique on the same hardware. These techniques also reflect the same tradeoffs: your response to a denial of service scenario must avoid resource allocation in excess of allocation prior to introducing the response :-). The traditional SYN cookie implementations exchange increased CPU load for reduced state allocation, but often do a poor job of it, and can result in some protocol violations that make SYN cookies more fragile in adverse network environments (such as those under DoS attack). This means that we should cautiously consider both the positive and negative aspects of the technique before committing to it. Suffice to say that fundamentally it is very difficult to respond to DoS in the current framework of network and resource allocation paradigms, but that we're constantly exploring ways to deal with the current attack mechanisms in more effective ways. Expect to see more work on the FreeBSD IP stack addressing some of these DoS issues in the near future. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1001202104006.21765B-100000>