[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])
- To: misc_(_at_)_openbsd_(_dot_)_org
- Subject: Re: TCP flags to examine, proper resetting (was: no "flags x"? [CVS: cvs.openbsd.org: src])
- From: Camiel Dobbelaar <cd_(_at_)_sentia_(_dot_)_nl>
- Date: Tue, 29 Oct 2002 20:35:02 +0100 (CET)
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
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 & 2 = 2 and tcp != 2 and tcp != 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'.