On 2007-02-22 15:52, RW <[EMAIL PROTECTED]> wrote: >On Thu, 22 Feb 2007 17:04:18 +0200 >Giorgos Keramidas <[EMAIL PROTECTED]> wrote: >>On 2007-02-22 14:30, RW <[EMAIL PROTECTED]> wrote: >>>On Wed, 21 Feb 2007 19:38:39 +0100 >>>J65nko <[EMAIL PROTECTED]> wrote: >>>> For keeping state on TCP connections you should only create state >>>> on the first packet of the 3 way TCP handshake. Using "flags S/SA" >>>> will ensure this. This will prevent problems with TCP windows >>>> scaling.. >>> >>> Why? Creating a state entry causes subsequent packets, in the same >>> tcp connection, to bypass the rules altogether. >> >> Because a state entry is a rule by itself. A special 'rule', but >> still a rule. As such, each state-table entry requires a finite >> amount of resources. Conserving resources, whenever possible, is a >> good idea. >> >> Creating 10 packets for a connection whose 'traffic' requires 10 TCP >> segments to be transmitted, and 9000 state entries for a TCP >> connection whose data payload needs 9000 segments to be transmitted >> is kind of silly. Especially since it is entirely legal and easy to >> do the same thing with only 2 state entries (one for each connection). > > The way PF works is that it first checks if there is a state entry > matching the packet's address, port and protocol , if there is the > state entry is used to determine what is done with the packet. Only if > there is no matching entry is the script used instead. As I already > said "Creating a state entry causes subsequent packets, in the same > tcp connection, to bypass the rules altogether". > > The point of testing for s/sa is to avoid creating long-lived state > entries for illegal or out-of-sequence packets. The state created by > s/sa has a very short lifetime. This conserves resources and protects > against some DOS attacks.
I see. I've recently discovered that IPFilter v4.0.2 on Solaris 10 had a bug in the state expiry code. States for packets without S/SA expire after 10 days, instead of a few seconds like the S/SA states. I haven't verified that this doesn't apply to PF, but since PF is a very different firewall I'll extract my foot from my mouth and go read the source now :) _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
