Date: Mon, 24 Apr 2000 10:47:56 -0500 (CDT) From: Jonathan Lemon <jlemon@flugsvamp.com> To: rwatson@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: netkill - generic remote DoS attack (fwd) Message-ID: <200004241547.KAA16081@prism.flugsvamp.com> In-Reply-To: <local.mail.freebsd-net/Pine.NEB.3.96L.1000424030249.15998A-100000@fledge.watson.org> References: <local.mail.freebsd-net/200004232202.SAA47172@whizzo.transsys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <local.mail.freebsd-net/Pine.NEB.3.96L.1000424030249.15998A-100000@fledge.watson.org> you write: > >Thus far, this has been a brain-storming session to address a very >specific attack in very specific environments. All ideas thrown in by >various participants have been purely suggestions, and figures (such as >``30 seconds'') were ballparks to be used in back-of-napkin calculations >concerning balancing effectiveness and risk. Given a quick look at netkill, it appears that it mainly acts as a DoS by establishing a connection, then dropping its end, leaving the server to maintain the connection until TCP gives up. The server will wind up with the connection in either ESTABLISHED or FIN_WAIT_1 state, depending on the traffic patterns, and what the attacker does. As was pointed out, it is difficult to discern when a connection in this state is the result of legitimate traffic, or the result of an attack. However, a strong indication that the machine is under attack is a large number of connections from the same IP address. Unlike a SYN flood, the attacker must complete the TCP handshake, so the server will have the IP address of the attacker (leaving the issue of packet sniffing aside at the moment). RFC 2140 (which FreeBSD implements in some form) provides for a shared control block for TCP connections. Would it make sense to add some kind of connection counter to this structure as well? Then, armed with this information (and if the sysctl knob allows), the server can make decisions for connections from a certain host: 1. refuse to accept any more connections 2. drop existing TCP connections 3. accelerate the timeout This might catch most of the "ankle-biter" attacks without interfering with normal traffic, but also might be a problem for people who are connecting through some type of NAT service, where all connections appear to be from a single host. Unfortunately, the shared information is currently stored in a route entry, so this would require a little restructuring of how things work. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004241547.KAA16081>