Date: Sun, 8 Jul 2001 17:39:04 -0700 From: "Crist J. Clark" <cristjc@earthlink.net> To: Darren Reed <avalon@coombs.anu.edu.au> Cc: cjclark@alum.mit.edu, Yonatan Bokovza <Yonatan@xpert.com>, "'freebsd-security@freebsd.org'" <freebsd-security@FreeBSD.ORG> Subject: Re: FW: Small TCP packets == very large overhead == DoS? Message-ID: <20010708173904.D307@blossom.cjclark.org> In-Reply-To: <200107082224.IAA08926@caligula.anu.edu.au>; from avalon@coombs.anu.edu.au on Mon, Jul 09, 2001 at 08:24:28AM %2B1000 References: <20010708132629.B307@blossom.cjclark.org> <200107082224.IAA08926@caligula.anu.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 09, 2001 at 08:24:28AM +1000, Darren Reed wrote: > In some mail from Crist J. Clark, sie said: > > > > On Sun, Jul 08, 2001 at 02:54:53PM +0300, Yonatan Bokovza wrote: > > > Hi, > > > This was just on bugtraq. > > > Is net.inet.tcp.min_mss the solution? > > > > To what problem? As I get to below, it is a symetrical DoS attack. As > > a general class, these are not a big threat. > > > > Darren... you came up with this? > > So are most DoS attacks which have anything to do with sending large > numbers of packets. This is somewhat similar to ICMP smurf attacks > that are directed at broadcast addresses. A Smurf attack is asymetrical. The attacker sends out a very small number of packets and the amplifier network does the real work. So, attacker sends low volume of traffic, attackee gets drowned in a large volume, asymetric. Another thing I forgot to mention is that this is "unspoofable" in the sense that the TCP handshake needs to be completed for it to work. This also greatly reduces the risk. > [...] > > The problem for the attacker is that he needs to be ACKing all of > > these segments. It may take more packets to move 2kB, but the packets > > are not going out any more rapidly than they would if we just asked > > for 50kB file (which also requires 20+ more packets without the change > > in MSS). > > Think TCP windows. Do I have to? *think* *ouch* I still don't see anything here that you couldn't do with "Daytona" TCP attack. This might be a way to make them worse. > > > What's most surprising is that there does not appear to be a documented > > > minimum, just as there is no "minimum MTU" size for IP. If there is, > > > please correct me. > > > > The absolute minimum MTU for IP is 68 (RFC791). > > Yeah, enough for 64bytes of header options and 8 bytes of fragmented > data. Not what I'd call a "useful" minimum. How about the 576 byte (IIRC) value? It's not really a network MTU, but all host must be able to handle datagrams of that size. > [...] > > This is a Denial/Degredation of Service attack. I do not believe it > > constitutes a major threat. Like so many such hypothetical DoS > > attacks, it is symetrical. That is, it causes just as much hardship > > for the attacker as the attackee. Yes, the machine being attacked > > needs to send out more packets, but the attacker needs to be > > responding with just as many ACKs[0]. If the attacker wants to > > generate lots of packets from the system being attacked, why not make > > just multple connections or try to do big downloads? What does this > > attack do that more straight forward attempts to consume the attacked > > machine's resources don't? > > PC's can only handle a set number of interrupts per second. Serving an > interrupt is fairly expensive. This attack decreases the efficiency of > the host in servicing interrupts in a dramatic fashion. The smaller > you can force the packets can be, the bigger the hit. Yeah, I understand it boils down to a packets/time issue. I still don't see how a high packet rate can be sustained. > In testing on my LAN, which is connected into a switch, the high packet > rate did not bother the switch (as it ought not to have) but it did the > boxes involved. It's not just about pumping more data through and > saturating the network, it's about causing the server to do more work > than it normally does in order to send the same amount of data. > > In this respect it's not primarily a network DoS attack, but a sytem > resources (CPU/interrupt servicing) DoS attack also. But I'd still like to see it done over the Internet rather than a LAN before anyone gets too excited. Although it might be something fun to mess with people on the LAN at DEFCON this weekend. -- Crist J. Clark cjclark@alum.mit.edu 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?20010708173904.D307>