From owner-freebsd-pf@FreeBSD.ORG Wed Apr 2 09:07:49 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D4A2106570C for ; Wed, 2 Apr 2008 09:07:49 +0000 (UTC) (envelope-from salvador_d13@yahoo.com.ph) Received: from n2.bullet.mail.re4.yahoo.com (n2.bullet.mail.re4.yahoo.com [206.190.56.21]) by mx1.freebsd.org (Postfix) with SMTP id C8BA38FC1C for ; Wed, 2 Apr 2008 09:07:48 +0000 (UTC) (envelope-from salvador_d13@yahoo.com.ph) Received: from [68.142.237.87] by n2.bullet.re4.yahoo.com with NNFMP; 02 Apr 2008 08:55:07 -0000 Received: from [216.252.110.140] by t3.bullet.re3.yahoo.com with NNFMP; 02 Apr 2008 08:55:07 -0000 Received: from [127.0.0.1] by omp210.mail.re3.yahoo.com with NNFMP; 02 Apr 2008 08:55:07 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 265653.47583.bm@omp210.mail.re3.yahoo.com Received: (qmail 48835 invoked by uid 60001); 2 Apr 2008 08:55:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.ph; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=4Ujr795CIE5acg+UzQBzLTpdVpCDrnRGskXbng1gN0ZCHR31VdkDuW3are6y0S/ZUK5hfnw2BvQRqoe/a5Sj/I3gk9UPJKWL2uF74kRO3wzW7ToIu59LyPH/a/uwAfPlKEnb6PQx6pin7GxwAxeEUvLfZfrZYCdyHBYJRrIIRN8=; X-YMail-OSG: PwkRMrwVM1msw04a2eSYlUWxMzadeih2PRUTIk_G0kFeb5X15g19bO_fpaoNtI8yvPYX5Xmtb3Qs55srClXrmwupxPWReLqng0O5hv8HQtx3shbgBkzFNxfbPXupQfQL Received: from [58.71.34.138] by web57409.mail.re1.yahoo.com via HTTP; Wed, 02 Apr 2008 01:55:05 PDT Date: Wed, 2 Apr 2008 01:55:05 -0700 (PDT) From: Diego Salvador To: koitsu@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1209350812-1207126505=:47278" Content-Transfer-Encoding: 8bit Message-ID: <699482.47278.qm@web57409.mail.re1.yahoo.com> X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-pf@freebsd.org Subject: Fwd: Re: PF and State Table X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2008 09:07:49 -0000 --0-1209350812-1207126505=:47278 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Note: forwarded message attached. --------------------------------- Tired of spam? Yahoo! Mail has the best spam protection around http://ph.mail.yahoo.com --0-1209350812-1207126505=:47278 Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Received: from [58.71.34.137] by web57413.mail.re1.yahoo.com via HTTP; Wed, 02 Apr 2008 00:56:10 PDT Date: Wed, 2 Apr 2008 00:56:10 -0700 (PDT) From: Diego Salvador Subject: Re: PF and State Table To: Jeremy Chadwick In-Reply-To: <20080402063910.GA36819@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-388257216-1207122970=:57670" Content-Transfer-Encoding: 8bit Content-Length: 2601 --0-388257216-1207122970=:57670 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sir Jeremy, Thanks for the immediate reply sharing your good ideas! Yes you are right! I was asking of how PF keeps track of the state when used in filtering rules. So, when keeping track of the state, the basis of the state tracking is the source and destination IP address regardless of each direction either in or out of a certain interface? For example, pass in on $ext_if inet proto tcp from any to 192.168.100.1 keep state flags S/SA pass out on $ext_if inet proto tcp from 192.168.100.1 to any keep state flags S/SA wherein the first rule will keep a state on the state table and another state is keep on the table even the same upper layer protocol TCP is being keep track? I'm sorry on that question, I was pertaining to the source code of PF in FreeBSD where I can locate the PF state table structure so that I can analyze the code well in order to understand its framework. Thanks you! Sincerely Yours, Diego Salvador Jeremy Chadwick wrote: 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 | --------------------------------- Tired of spam? Yahoo! Mail has the best spam protection around http://ph.mail.yahoo.com --0-388257216-1207122970=:57670 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Sir Jeremy, Thanks for the immediate reply sharing your good ideas! Yes you are right! I was asking of how PF keeps track of the state when used in filtering rules. So, when keeping track of the state, the basis of the state tracking is the source and destination IP address regardless of each direction either in or out of a certain interface? For example, pass in on $ext_if inet proto tcp from any to 192.168.100.1 keep state flags S/SA pass out on $ext_if inet proto tcp from 192.168.100.1 to any keep state flags S/SA wherein the first rule will keep a state on the state table and another state is keep on the table even the same upper layer protocol TCP is being keep track? I'm sorry on that question, I was pertaining to the source code of PF in FreeBSD where I can locate the PF state table structure so that I can analyze the code well in order to understand its framework. Thanks you! Sincerely Yours, Diego Salvador Jeremy Chadwick wrote: 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 | _________________________________________________________________ Tired of spam? Yahoo! Mail has the best spam protection around [1]http://ph.mail.yahoo.com References 1. http://sg.rd.yahoo.com/mail/ph/footer/def/*http://ph.mail.yahoo.com --0-388257216-1207122970=:57670-- --0-1209350812-1207126505=:47278--