[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TCP flags to examine, proper resetting (was: no "flags x"? [CVS: cvs.openbsd.org: src])



On Tue, 29 Oct 2002, Moritz Grimm wrote:
> Not examining all flags, including ECN (or any other tcp-extending flags
> that might happen/do exist), makes perfect sense. Camiel Dobbelaar uses
> S/SAFR, but I wonder about the remaining standard flags PSH, WND and
> URG. None of those seem to be legal for a connection initiation.

> PSH makes no sense, why should non-existent data payload go through to
> the listening daemon unbuffered, while no connection exists, yet? Same
> applies to WND and URG - flow control or urgent _data_ has nothing to do
> with the initial handshake. Wouldn't S/SAFRPWU be the "ideal" set of
> flags to check?

An ECN-setup packet has SEW set, so W should not be in the mask.

P and U probably don't belong in a SYN packet, but on the other hand:
there are broken stacks out there, and you probably want most of the net
to be able to talk to you and vice versa.

S/SAFR is really a compromise, those are the four flags that really matter
for connection establishment and closing.  I see all the others as just
"hints".


That said, you may want to be more strict with the flags if you want to
protect hosts against fingerprinting.  Here's nmap -O at work (the tcpdump
filters on packets with SYN set, but not plain S or SA).

zigzag$ sudo tcpdump -i lo0 -n 'tcp[13] & 2 = 2 and tcp[13] != 2 and tcp[13] != 18'
tcpdump: listening on lo0
20:13:40.950464 127.0.0.1.50631 > 127.0.0.1.22: SE 249035464:249035464(0)
    win 1024 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol>
20:13:40.950626 127.0.0.1.50633 > 127.0.0.1.22: SFP 249035464:249035464(0)
    win 1024 urg 0 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol>

SFP is obviously invalid.  rfc-3168 says that SE is invalid too: "A host
MUST NOT set ECT on SYN or SYN-ACK packets".

S/SAFR lets SE through, so you may want to block that seperately.

Note that nmap doesn't use SU, SP or SUP for fingerprinting, so I guess
those are harmless (but it's hardly conclusive evidence).  :-)


So, put together, this may be good practice if you're really cautious:
block in proto tcp ... flags SE/SEW
pass  in proto tcp ... flags S/SAFR keep state


BTW.  I'd love to see evidence of SP, SU or SUP 'in the wild'.

--
Cam