In message <20010907204853.F1E142A51@orchard.arlington.ma.us>, Bill Sommerfeld 
writes:
>> Over the past week I've noticed a couple of hosts with 15000-17000
>> bytes waiting in the Send-Q .. they were all attached to port 80, but
>> for the most part weren't showing up in my apache logs and weren't really
>> causing too much of a lag.  I wrote an ipf rule for them and the lag went
>> away.  
>
>Before you go and claim "i'm under attack! man the barricades" you
>should be aware that a system just dropping off the net in the middle
>of a fetch would cause this.
>
>You could just have a popular web page which causes internet exploder
>to bluescreen as it loads it ;-)

Right -- this certainly doesn't sound like traditional DDoS attacks.  
In fact, if it is an attack it's worth further investigation, just on 
those grounds.

If the source addresses are real -- that is, if the remote machine 
really did open such a connection, under the influence of an attacker 
-- then the attacker found some way to flow-control the connection.
Web browsers typically don't want to do such things.

If the addresses are forged, the attacker is doing sequence 
number-guessing or the like to create a real TCP connection that's 
going nowhere.  Not out of the question, though NetBSD is pretty good 
(though not perfect) about deflecting them.  (I still prefer RFC 1948, 
but hey, I wrote it...  It's in -current, I see, though not in 1.5.2.)
There are other techniques, but they're unusual.

And none of that explains why there's nothing in your Apache logs.  
That's something that your machine should create in response to more or 
less any connection to port 80; you might want to supplement that with 
an ipf log (but not "block") of incoming port 80 SYN packets.

It's also unclear why you say that the addresses are random or forged.  
Have you tried traceroute and/or ping?  If you can build or find a 
tool to emit a hand-built TCP packet on one of these connections, you 
could learn a lot.  Send a 0-length TCP packet with the immediately-previous
sequence number, and see what you get back.  If you get back RST, the 
remote host knows nothing of the connection, and that's suspicious.
If you get back an ACK, the connection exists but is flow-controlled -- 
look at the window size in that ACK.

For that matter, run tcpdump on a few of these connections.  If you're 
really experiencing flow-controlled connections, your machine will 
periodically probe the closed window, and get back an ACK with a 
window size of 0.  If there's no remote host, you'll get back nothing, 
and the connections will time out.  



		--Steve Bellovin, http://www.research.att.com/~smb
				  http://www.wilyhacker.com