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

TCP Flags question



I have a question about TCP flags.  I read through the FAQ (see, it actually
*is* useful!) and it cleared it up somewhat.
So, if you add a TCP-based rule with flags S/SA, it will allow an initial
"SYN" packet, but deny an initial packet with both the SYN and ACK flags
set?
e.g.  pass  in on $ExtIF inet proto tcp from any to any port $Services \
	flags S/SA keep state
(From the FAQ)
If this is correct, then once a SYN packet is sent, a state entry is set up
(with a timeout) that allows the corresponding SYN-ACK back (from the
target) and then the final SYN-ACK from the session initiator to establish
the TCP session?  Is this right?
I like the the FUP/FUP trick!  I don't suppose someone has compiled a list
of "acceptable" flag combinations?
Also, is flags S/SAFPRU better than flags S/SA?
Why is using flags S by itself so bad?
What is modulate state?
Sorry to ask so many questions.  Is there someplace I should be reading up
on TCP flags?  I read Stevens TCP/IP Illustrated book.  It's a great book,
but it didn't talk as much about malicious/sneaky use of the flags.  Of
course I would much rather read a great book then bug everyone with
questions...
<> Jim
---------------------------------------
(Borrowed from Alejandro's post)
I also usually add some rule against well know scanning codes
  #Drop some port scannings
  block in quick on $ext_if inet proto tcp from any to any \
        flags FUP/FUP label "anti_scanning"
I usually also add a "flags S/SAFPRU". This improves the security of
tcp connections. Never use S because that implies S/SAFRUPEW. So since
we don't want to screw up ECN signals (I hope :-) you have to be
explicit about that. "flags S/SA" should sufice, though. You may need
to customize the timing setting. But that has already been covered.
I also add a "modulate state" if that connection is going to an NT
box. Note that this implies keep state, so you don't have to put it.
The xBSD and IOS are safe, Linux 2.2 is "safe enough", 2.4 should be
too.