[71190] in North American Network Operators' Group
Re: AV/FW Adoption Sudies
daemon@ATHENA.MIT.EDU (Steven M. Bellovin)
Thu Jun 10 15:42:01 2004
From: "Steven M. Bellovin" <smb@research.att.com>
To: Valdis.Kletnieks@vt.edu
Cc: EKR <ekr@rtfm.com>, Paul G <paul@rusko.us>,
"'Nanog'" <nanog@merit.edu>
In-Reply-To: Your message of "Thu, 10 Jun 2004 15:19:31 EDT."
<200406101919.i5AJJVUM000657@turing-police.cc.vt.edu>
Date: Thu, 10 Jun 2004 15:41:24 -0400
Errors-To: owner-nanog-outgoing@merit.edu
In message <200406101919.i5AJJVUM000657@turing-police.cc.vt.edu>, Valdis.Kletni
eks@vt.edu writes:
Actually, it was Morris, not me, who first pointed it out.
>
>Data point: When did Steve Bellovin point out the issues with non-random
>TCP ISNs? When did Mitnick use an exploit for this against Shimomura?
>
>And now ask yourself - when did we *first* start seeing SYN flood attacks (whi
>ch
>were *originally* used to shut the flooded machine up while and prevent it
>from talking while you spoofed its address to some OTHER machine?)
>
That's not quite correct. While flooding can work, Morris found an
implementation bug that made it easier to gag the alleged source. I'd
have to spend a while trying to figure out the exact details; roughly,
though, you picked a port on which the alleged source was in LISTEN
state, created enough half-open connections to fill its queue, and then
used that port (in the privileged range) in launching your spoofing
attack on the real victim. The SYN+ACK packets would be dropped,
rather than eliciting an RST, because they appeared to be SYNs for a
service with a full queue. The difference is is that this scheme takes
many fewer packets than a SYN flood -- 5, back in 1985 when the attack
was published -- and works very reliably, with no statistical
dependencies. That bug has long-since been fixed on just about
everything out there, but in the mean time we've seen lots more ways to
take hosts off the air...
--Steve Bellovin, http://www.research.att.com/~smb
