Date: Wed, 2 Apr 2008 01:55:05 -0700 (PDT) From: Diego Salvador <salvador_d13@yahoo.com.ph> To: koitsu@freebsd.org Cc: freebsd-pf@freebsd.org Subject: Fwd: Re: PF and State Table Message-ID: <699482.47278.qm@web57409.mail.re1.yahoo.com>
next in thread | raw e-mail | index | archive | help
--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 <salvador_d13@yahoo.com.ph>
Subject: Re: PF and State Table
To: Jeremy Chadwick <koitsu@freebsd.org>
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 <koitsu@freebsd.org> 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 <koitsu@freebsd.org> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?699482.47278.qm>