From nlawson@kdat.calpoly.edu Sat Sep 14 11:11:32 1996 Received: from kdat.calpoly.edu (kdat.csc.calpoly.edu [129.65.54.101]) by suburbia.net (8.7.4/Proff-950810) with SMTP id LAA20395 for ; Sat, 14 Sep 1996 11:09:02 +1000 Received: (from nlawson@localhost) by kdat.calpoly.edu (8.6.12/N8) id SAA13467; Fri, 13 Sep 1996 18:08:22 -0700 From: Nate Lawson Message-Id: <199609140108.SAA13467@kdat.calpoly.edu> Subject: Re: BoS: Tool for stopping SYN floods To: route@onyx.infonexus.com Date: Fri, 13 Sep 1996 18:08:21 -0700 (PDT) Cc: best-of-security@suburbia.net In-Reply-To: <19960913201635.2522.qmail@onyx.infonexus.com> from "route@onyx.infonexus.com" at Sep 13, 96 01:16:35 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > | With the routers for most ISP, they should be blocking any non-internal > | addresses from leaving their network and going to the Internet. This will > | stop an attacker if their ISP implements this. Unfortunately, this does > | not stop an attack from areas on the Internet that do not block that. But > | at least the ISP can feel comfortable to know that an attacker can not > | launch his attack from that ISP. > > Two ways to circumvent this: > > 1) Modify the TCP kernel on the attacking machine to ignore the > incoming SYN|ACKs. This will have the same effect as a 'normal' > TCP SYN flood. As you state later on, this provides no anonymity, but also provides an easy signature for an AI engine: hundreds of connections from one machine. This allows for the easy solution of temporarily firewalling that host and/or RSTing further connections from it. > 2) Play one machine off another. SYN flood a machine internal to > the gateway router using an IP address unreachable to it (or, as in the > first scenario), while at the same time SYN flood the desired target > outside the router, using the first target's IP address and flooded port > as the sources... Once again, this gives an easily matchable signature. The key part is doing careful traffic analysis. Any type of denial of service attack, no matter how random the headers, will fit into a very specific category. In fact, the randomness of the header can be a signature in itself. > Neither of these are ideal. The first scenario destroys the anonimity > of the attack. The second is adds much complexity to an otherwise > simple DOS attack. Both of them destroy the anonyminity of the attack by limiting the source of the attack to one very specific network. At the present, attacks have to be traced back through the NAPs. This requires manual analysis, time, and extra effort. However, if each entry point into the Internet blocked incorrect source addresses, syn floods would instantly be localized to a single group of modems or at least one network. This will never happen in real life, however. > | Another way to fix this is to set the kernel maximum number of half open > | connections allowed (SO_MAXCONN) to a higher number than the default value. > >Bad idea. It is trivial for an attacker to simply send more packets. >It quickly becomes non-trivial for the target to allocate memory structures >or all the pending connection requests... You are correct that this is not a solution in itself, but coupled with other measures like he suggested further on, can be effective against such attacks. > | We have a tool that will look for SYN packets that do not get followed with > | ACK and clean the half open connections by sending a RST packet. This > > Another way to detect and eradicate SYN floods: > >Kernel mod or daemon that will: > -listen for all incoming SYNs > -keep a list of the x most recent incoming SYNs (x=backlog?) This is already done to handle the incoming requests. > -if x amount of connection-requests take more than y amount of time > to complete and(other heuristics) This is what the mentioned product does (among other things). > -x SYNs arrived in z time relative to each other. > -x SYNs have a,b,c features in common (source IP addr,TTL,port,seq#) > -etc... These are some of the other things. Additionally, it does these checks for the entire network, not just one host (as your hypothetical kernel module would). I don't see any valid reasons for doing this in the kernel other than performance. The disadvantages of doing it in the kernel are that it's not very portable and the kernel patch must be installed on every host that is Internet-connected. My limited testing has shown that a decently fast machine (unloaded 586-75), running RealSecure, was quite able to meet the demands of a syn flood on a loaded ethernet. As always, I speak for myself. -- Nate Lawson "There are a thousand hacking at the branches of CPE Senior evil to one who is striking at the root." CSL Admin -- Henry David Thoreau, 'Walden', 1854