Date: Tue, 1 Apr 2008 23:39:10 -0700 From: Jeremy Chadwick <koitsu@freebsd.org> To: Diego Salvador <salvador_d13@yahoo.com.ph> Cc: freebsd-pf@freebsd.org Subject: Re: PF and State Table Message-ID: <20080402063910.GA36819@eos.sc1.parodius.com> In-Reply-To: <88224.68960.qm@web57401.mail.re1.yahoo.com> References: <88224.68960.qm@web57401.mail.re1.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 01, 2008 at 10:26:18PM -0700, Diego Salvador wrote: > Hi! Can someone explain the details on how PF state table stores stateful filtering option of "keep state" because I know this will be used and applied to TCP, UDP and ICMP/ICMPv6 protocols for stateful filtering. Because when I use this "keep state" option, it is said that it can help in optimizing firewall rules due to rule evaluation will no longer be evaluated when those information are already stored in the table. Is it only IP address (source->destination or destination->source) are being keep in the state table? If it is then does it matter on IP address source-destination direction entries? What about with TCP and its flags? How does PF stored it in the state table? Is there any varying performance if we should specify TCP flags with keep state as compared to TCP with keep state but without flags? For example, > > pass in on $ext_if inet proto TCP from any to 192.168.100.1 keep state > pass in on $ext_if inet proto TCP from any to 192.168.100.1 keep state flags S/SA I think what you're asking is how pf actually keeps track of state, and how pf rules define when to start tracking state. Looking at the above two rules you provided, the rule #1 would cause any inbound TCP packets destined to 192.168.100.1 to cause pf to begin tracking state -- that means, any TCP packet, with any TCP flags set (including bogus packets which might set FIN+PSH at the same time, or other oddities). This is somewhat risky, because you really don't want to waste a state entry on something that's half-way in the middle of a TCP session (well, I suppose you could, but it seems insecure. You should track state from the point of an initial connection to the end of it -- see below). Rule #2, however, would do the same thing -- except would only begin tracking state when TCP SYN is seen (and only looking at the SYN and ACK flags in the TCP header). This is more along the lines of what you want. The state tracking stuff actually causes pf to monitor each state of a TCP session, ensuring that responses to certain TCP states (that the sender or receiver has sent/received) are correct -- and simultaneously uses the state table to permit packets through. Neither of those rules, however, handle state for UDP or ICMP. They're stateless protocols, but pf does keep track of when the UDP connection closes (or times out after a while), and the same with ICMP. > What file in PF on FreeBSD kernel does state table structure is located? I don't understand this question. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080402063910.GA36819>