Date: Sun, 23 Mar 2003 13:33:17 -0800 From: John Fitzgibbon <fitz@jfitz.com> To: Giorgos Keramidas <keramida@ceid.upatras.gr> Cc: freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Repeated ACKs - possible DoS? Message-ID: <200303231333.17886.fitz@jfitz.com> In-Reply-To: <20030321020253.GA3174@gothmog.gr> References: <200303201408.53238.fitz@jfitz.com> <200303201715.32293.fitz@jfitz.com> <20030321020253.GA3174@gothmog.gr>
next in thread | previous in thread | raw e-mail | index | archive | help
Note to "freebsd-net" readers: I'm cc'ing this email because this seems like a
"net" issue - full thread is in freebsd-questions.
I've been looking at the code in sys/netinet/tcp_input.c.
The behavior seems consistent with inducing tcp_input() to jump to the
"dropafterack" label for every incoming ACK.
The most promising way to do this seems to be to set the T/TCP options when
initializing the connection, then just stop using them on some subsequent
ACK, (or give the wrong CC value). The code is around line 1420:
/*
* T/TCP mechanism
* If T/TCP was negotiated and the segment doesn't have CC,
* or if its CC is wrong then drop the segment.
* RST segments do not have to comply with this.
*/
if ((tp->t_flags & (TF_REQ_CC|TF_RCVD_CC)) == (TF_REQ_CC|TF_RCVD_CC) &&
((to.to_flags & TOF_CC) == 0 || tp->cc_recv != to.to_cc))
goto dropafterack;
It may also be possible to cause the jump to "dropafterack" with the timestamp
option, (RFC 1323 - the code is just above the previous T/TCP code). This
would "jive" with the fact that the client connection seemed to be a Windows
98 machine, (from the Apache logs), and apparently the Windows 98
implementation of RFC 1323 is flawed. However, I'm less sure what kind of
invalid options scenario would be required.
In any case, I haven't done enough research to be 100% sure that either of
these approaches can cause the behavior I observed. All I AM sure of is that
I observed the repeated ACK situation, and it was a pretty darn effective
DoS. I'm also sure that banging ACKs back and forth at full speed is NOT how
TCP/IP is supposed to work.
Hopefully this might be enough of a lead to get someone's thought processes
going.
Fitz.
On Thursday 20 March 2003 06:02 pm, Giorgos Keramidas wrote:
> On 2003-03-20 17:15, John Fitzgibbon <fitz@jfitz.com> wrote:
> >On Thursday 20 March 2003 04:43 pm, Giorgos Keramidas wrote:
> >>> X is remote. Y is server, (FreeBSD 4.7-STABLE, built 2003/01/06)
> >>>
> >>> tcpdump shows 2 remote connections repeatedly sending "ack 1":
> >>>
> >>> 09:16:10.236812 X.64670 > Y.http: . ack 1 win 32589
> >>> 09:16:10.236879 Y.http > X.64670: . ack 489 win 58400 (DF)
> >>
> >> Hmmm, is this repeatable? Can you try to grab the output of the
> >> following command in a log file while it happens?
> >>
> >> # tcpdump -n -v -s 128 -XX port 80
> >
> > I haven't seen this behavior before, and I don't know how to recreate it
> > :(
>
> Damn :(
>
> If this is a bug that you've hit upon, please note that command and
> run it if it ever happens to appear again. The log file is going to
> be large, but I'll help a lot to have it around when trying to find
> out what happens.
>
> - Giorgos
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?200303231333.17886.fitz>