|
List Info
Thread: RE: Bacula File/Storage Connection Woes using PF
|
|
| RE: Bacula File/Storage Connection Woes
using PF |
  United States |
2008-03-25 17:53:15 |
> > Is there another way of writing rules that will
enable the
> Bacula client to
> > pass packets to the correct port number?
> >
> Yes, make the 1st rule
>
> block log all
>
> to drop both ingress and egress traffic by default.
>
> Secondly get rid of the stateless rules. Use keep state
> everywhere, with
> flags S/SA if matching tcp traffic.
>
>
I hate to bug you guys but I ain't a pf guru like you guys.
I am not
understanding the significance of the "keep state"
and the "flags S/SA
synproxy state" qualifiers. I have been copying some
rules from articles
here and there. Thus these rules are not unified in the
sense that these are
designed from the beginning to work harmoniously.
Would it be helpful if I supplied the actual pf.conf below
and let you have
at it? See the new addition I added today below in which I
added "keep
state" at the end of the rule. Would this enable the
Bacula client to accept
packets from the Bacula server and send packets out to port
9103 on the
Bacula server?
Here's my pf.conf:
# $FreeBSD: src/etc/pf.conf,v 1.2.2.1 2006/04/04 20:31:20
mlaier Exp $
# $OpenBSD: pf.conf,v 1.21 2003/09/02 20:38:44 david Exp $
#
# See pf.conf(5) and /usr/share/examples/pf for syntax and
examples.
# Required order: options, normalization, queueing,
translation, filtering.
# Macros and tables may be defined and used anywhere.
# Note that translation rules are first match while filter
rules are last
match.
# Macros: define common values, so they can be referenced
and changed
easily.
ext_if="rl0" # replace with actual external
interface name i.e., dc0
int_if="xl0" # replace with actual internal
interface name i.e., dc1
internal_net="192.168.1.1/24"
external_addr="xxx.xxx.xxx.xxx"
vpn_net="xxx.xxx.xxx.xxx/24"
# Added by DSS - 2/28/07
NoRouteIPs = "{ 127.0.0.0/8 192.168.0.0/16
172.16.0.0/12 10.0.0.0/8 }"
# machines inside
webserver ="192.168.1.4"
set skip on lo0
set skip on gif0
# Normalization: reassemble fragments and resolve or reduce
traffic
ambiguities.
scrub in all
# Translation: specify how addresses are to be mapped or
redirected.
# nat: packets going out through $ext_if with source address
$internal_net
will
# get translated as coming from the address of $ext_if, a
state is created
for
# such packets, and incoming packets will be redirected to
the internal
address.
nat on $ext_if from $internal_net to any -> ($ext_if)
nat on $ext_if from $vpn_net to any -> ($ext_if)
# rdr: packets coming in on $ext_if with destination
$external_addr:1234
will
# be redirected to 10.1.1.1:5678. A state is created for
such packets, and
# outgoing packets will be translated as coming from the
external address.
#rdr on $ext_if proto tcp from any to $external_addr/32 port
1234 ->
10.1.1.1 port 5678
rdr on $ext_if proto tcp from any to $external_addr/32 port
80 -> $webserver
port 80
# spamd-setup puts addresses to be redirected into table
<spamd>.
table <spamd> persist
table <spamd-white> persist
table <spamd-mywhite> persist file
"/usr/local/etc/spamd/spamd-mywhite"
# redirect to spamd
#rdr inet proto tcp from <spamd> to any port smtp
-> 127.0.0.1 port 8025
rdr pass inet proto tcp from <spamd-white> to
$external_addr port smtp ->
127.0.0.1 port smtp
rdr pass inet proto tcp from <spamd> to $external_addr
port smtp ->
127.0.0.1 port spamd
rdr pass inet proto tcp from !<spamd-mywhite> to
$external_addr port smtp ->
127.0.0.1 port spamd
# block all incoming packets but allow ssh, pass all
outgoing tcp and udp
# connections and keep state, logging blocked packets.
block in log all
# allow inbound/outbound mail!
pass in log inet proto tcp from any to $external_addr port
smtp flags S/SA
synproxy state
pass out log inet proto tcp from $external_addr to any port
smtp flags S/SA
synproxy state
pass in log inet proto tcp from $internal_net to $int_if
port smtp flags
S/SA synproxy state
# added by DSS - 2/28/07
pass in quick log on $int_if proto tcp from any to $int_if
port 22 flags
S/SA synproxy state
block in quick log on $ext_if from $NoRouteIPs to any
block out quick log on $ext_if from any to $NoRouteIPs
antispoof log quick for $int_if inet
# pass all traffic to and from the local network
pass in on $int_if from $internal_net to any
pass out log on $int_if from any to $internal_net
pass out quick log on $int_if from any to $vpn_net
pass out on $ext_if proto tcp all modulate state flags S/SA
pass out on $ext_if proto { udp, icmp } all keep state
pass in on $ext_if inet proto tcp from any to $webserver
port 80 flags S/SA
synproxy state
pass in on $int_if proto tcp from any to $int_if port 22
keep state
# added by DSS - 3/25/08
pass in on $int_if proto tcp from any to $int_if port 9102
keep state
# end of DSS's additions
Thank you!
~Doug
_______________________________________________
freebsd-pf freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribe freebsd.org"
|
|
| Re: Bacula File/Storage Connection Woes
using PF |
  United States |
2008-03-26 10:42:17 |
On Wed, Mar 26, 2008 at 04:02:02PM +0100, Dalibor Gudzic
wrote:
> On Wed, Mar 26, 2008 at 3:53 AM, Jeremy Chadwick
<koitsu freebsd.org> wrote:
> > I'll try to explain it with a very small ruleset
and a couple scenarios:
> >
> > $ext_if = network interface that's got a public
IP address
> > 4.4.4.4 = our public IP address
> >
> > pass out quick all flags S/SA keep state
> > pass out quick all
> > block in log all
> > pass in quick on $ext_if inet proto tcp from any
to 4.4.4.4 port ssh
> >
> > Two scenarios:
> >
> > 1) When an incoming TCP packet from <any> to
4.4.4.4 on port 22 is seen,
> > that incoming packet is permitted (rule #4).
Outbound responses from
> > 4.4.4.4 to <whoever sent the original incoming
packet> are also
> > permitted (rule #1). Note the "keep
state".
> >
> Correct me if I'm wrong, but I think the outbound
packet will be matched
> against the #2 rule, as the rule #1 has "flags
S/SA" and will not match the
> packet since the packet would have "ACK" flag
set. Thus, the state will not
> be created in state table.
The pf.conf(5) manpage for STATEFUL INSPECTION has this to
say:
If a packet matches a pass ... keep state rule, the
filter creates a
state for this connection and automatically lets pass all
subsequent
packets of that connection.
I read this as: "if a packet matches a pass ... keep
state rule, pf
begins permitting all I/O for that now-state-tracked
session". One of
the entire points of state tracking is that it lets pf avoid
having to
reiterate the rule table for every packet.
This is how I understand it, at least on RELENG_6 with the
above rules:
pfbox (4.4.4.4) tries to connect to some host on the
Internet via TCP
(ignoring port numbers for now):
pfbox -> somehost = TCP flags SYN set, ACK not
set
= PASS: matches rule #1
= pf creates state-table entry for
tracking
somehost -> pfbox = TCP flags: SYN set, ACK set
= PASS: has state-table entry
pfbox -> somehost = TCP flags: SYN not set, ACK
set
= PASS: has state-table entry
Things in this case should work fine, relying on the
state-table entry
for permitted I/O.
Now the opposite, where some host on the Internet attempts
to connect to
4.4.4.4 on port 22:
somehost -> pfbox = TCP flags SYN set, ACK not
set
= PASS: matches rule #4
pfbox -> somehost = TCP flags: SYN set, ACK set
= PASS: matches rule #2
somehost -> pfbox = TCP flags SYN not set, ACK
set
= PASS: matches rule #4
A state-table entry won't be created for this one, since
rule #1
specifies "flags S/SA" (won't match SYN+ACK both
set).
If one was to add "keep state" to rule #4
(RELENG_6), or use RELENG_7
(where "keep state" is implied) and some host on
the Internet attempts
to connect to 4.4.4.4 on port 22, we should see:
somehost -> pfbox = TCP flags SYN set, ACK not
set
= PASS: matches rule #4
= pf creates state-table entry for
tracking
pfbox -> somehost = TCP flags: SYN set, ACK set
= PASS: has state-table entry
somehost -> pfbox = TCP flags SYN not set, ACK
set
= PASS: has state-table entry
Do we agree?
--
| 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 |
_______________________________________________
freebsd-pf freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribe freebsd.org"
|
|
| Re: Bacula File/Storage Connection Woes
using PF |

|
2008-03-26 11:20:41 |
On Wed, Mar 26, 2008 at 4:42 PM, Jeremy Chadwick
<koitsu freebsd.org> wrote:
>
> Now the opposite, where some host on the Internet
attempts to connect to
> 4.4.4.4 on port 22:
>
> somehost -> pfbox = TCP flags SYN set, ACK not
set
> = PASS: matches rule #4
> pfbox -> somehost = TCP flags: SYN set, ACK
set
> = PASS: matches rule #2
> somehost -> pfbox = TCP flags SYN not set, ACK
set
> = PASS: matches rule #4
>
> A state-table entry won't be created for this one,
since rule #1
> specifies "flags S/SA" (won't match SYN+ACK
both set).
>
> If one was to add "keep state" to rule #4
(RELENG_6), or use RELENG_7
> (where "keep state" is implied) and some host
on the Internet attempts
> to connect to 4.4.4.4 on port 22, we should see:
>
> somehost -> pfbox = TCP flags SYN set, ACK not
set
> = PASS: matches rule #4
> = pf creates state-table entry
for tracking
> pfbox -> somehost = TCP flags: SYN set, ACK
set
> = PASS: has state-table entry
> somehost -> pfbox = TCP flags SYN not set, ACK
set
> = PASS: has state-table entry
>
> Do we agree?
>
> --
> | 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 |
>
> Seems to be OK now. Sorry, I should have made it more
clearer in the
previous message; I meant, and should've said,
"SYN-ACK" i.e. the response
packet from host.
_______________________________________________
freebsd-pf freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribe freebsd.org"
|
|
| Re: Bacula File/Storage Connection Woes
using PF |
  United Kingdom |
2008-03-26 04:09:30 |
Jeremy Chadwick wrote:
> This isn't a reply to you (Doug), but -- do not blindly
use "keep state"
> everywhere!
>
Hard cases make for bad laws. I have got to point out the
error in the
above statement.
> There's been too many cases I've experienced where
using "keep state"
> blindly results in state-mismatch increasing at a very
fast rate. When
> I implemented this mentality on our production servers,
our users
> started pointing out that scp's between machines would
randomly get
> severed mis-stream, same with ssh sessions where large
TCP windows were
> used (such as doing 'dmesg' over and over):
>
> http://lists.freebsd.org/pipermail/freebsd
-pf/2008-January/004050.html
>
Which (taking a rough guess) looking at your rule set in the
above has
very little to do with 'keep state' and a lot to do with
'modulate
state'. IIRC there is a filed bug which displays all of the
aforementioned symptoms when modulate state meets selective
acknowledgement (SACK). I'm sure Max has the gory detail, it
may even be
fixed.
> The "use keep state on everything!" attitude
seems to stem from people
> reading the OpenBSD pf.conf documentation, which states
that as of
> OpenBSD 4.1, "keep state" is implicit on
every rule (meaning it's done
> whether you say "keep state" or not).
FreeBSD's pf isn't like this.
>
You miss out the most important bit of the new PF 4.1 state
keeping
defaults, 'flags S/SA'.
Our cousins over the road in the OpenBSD neighbourhood have
done this
precisely because of the issues caused in prior versions of
PF by using
stateless rules and/or establishing TCP state on anything
other than the
3 way handshake.
>
> It gets more confusing when you consider the fact that
even though UDP
> and ICMP are stateless protocols, pf can keep track of
their state too,
> though I don't know if FreeBSD pf supports that
(OpenBSD pf does).
>
This is not a flame, but if you really do not know that, you
really
should not be publicly advocating a position on the basis of
incomplete
information.
Regards
Greg
_______________________________________________
freebsd-pf freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribe freebsd.org"
|
|
| Re: Bacula File/Storage Connection Woes
using PF |
  United States |
2008-03-26 06:47:10 |
On Wed, Mar 26, 2008 at 09:09:30AM +0000, Greg Hennessy
wrote:
> Jeremy Chadwick wrote:
>> There's been too many cases I've experienced where
using "keep state"
>> blindly results in state-mismatch increasing at a
very fast rate. When
>> I implemented this mentality on our production
servers, our users
>> started pointing out that scp's between machines
would randomly get
>> severed mis-stream, same with ssh sessions where
large TCP windows were
>> used (such as doing 'dmesg' over and over):
>>
>> http://lists.freebsd.org/pipermail/freebsd
-pf/2008-January/004050.html
>
> Which (taking a rough guess) looking at your rule set
in the above has very
> little to do with 'keep state' and a lot to do with
'modulate state'. IIRC
> there is a filed bug which displays all of the
aforementioned symptoms when
> modulate state meets selective acknowledgement (SACK).
I'm sure Max has the
> gory detail, it may even be fixed.
Which is interesting for two reasons:
1) I never got an explanation in aforementioned thread, thus
I had no
knowledge of this bug until now -- thank you for telling
me!
2) The documentation for FreeBSD pf is minimal. The best
we've got is
pf.conf(5), /etc/pf.conf (which tells you to read
pf.conf(5)), and
/usr/share/examples/pf/* which doesn't give you much in
the ways
of education either.
This forces users to turn to the official OpenBSD pf
documentation,
which strongly advocates the use of "modulate
state" with TCP
packets: http:
//www.openbsd.org/faq/pf/filter.html#state
With these facts at hand, surely you can see how someone
would end up in
this situation? And I am not the only one: Doug Sampson's
mail is
further proof of this.
Now that you have educated me in regards to said bug, I will
have to go
back and try using "keep state" instead. Again,
thank you!
>> The "use keep state on everything!"
attitude seems to stem from people
>> reading the OpenBSD pf.conf documentation, which
states that as of
>> OpenBSD 4.1, "keep state" is implicit on
every rule (meaning it's done
>> whether you say "keep state" or not).
FreeBSD's pf isn't like this.
>>
> You miss out the most important bit of the new PF 4.1
state keeping
> defaults, 'flags S/SA'.
I assume "pf 4.1" means "OpenBSD 4.1's
pf", or is there some internal
pf versioning number?
This brings up another situation: there's no version number
of pf in
FreeBSD that I can find. The OpenBSD docs continually say
"as of
OpenBSD x.y". This confuses people, who when using pf
under FreeBSD,
have no knowledge of what version of pf we're using. What
version is in
RELENG_6? 7? CURRENT? I didn't know until a few minutes
ago --
because I went to cvsweb and had to look up the CVS commit
messages
myself:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/c
ontrib/pf/net/pf.c
Now that I know, I can make appropriate adjustments. But
requiring
users to look at CVS commit messages is a bit unrealistic,
don't you
think? Maybe I should submit a PR asking that the version
of pf pulled
into FreeBSD be kept in the pf(4), pf.conf(5), and pfctl(8)
manpages?
What do you suggest?
> Our cousins over the road in the OpenBSD neighbourhood
have done this
> precisely because of the issues caused in prior
versions of PF by using
> stateless rules and/or establishing TCP state on
anything other than the 3
> way handshake.
Yep, aware of that -- except that users have no idea as to
whether the
implicit "keep state" on every rule applies to
FreeBSD or not, or if
it's "safe" or not, because OpenBSD != FreeBSD.
They read the OpenBSD
docs and go "errr... so what version is FreeBSD
using?"
>> It gets more confusing when you consider the fact
that even though UDP
>> and ICMP are stateless protocols, pf can keep track
of their state too,
>> though I don't know if FreeBSD pf supports that
(OpenBSD pf does).
>>
> This is not a flame, but if you really do not know
that, you really should
> not be publicly advocating a position on the basis of
incomplete
> information.
And "incomplete information" is induced by what I
described in my above
paragraphs. Please don't be so harsh under the
circumstances -- I was
going off of all the available information I had at the
time.
--
| 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 |
_______________________________________________
freebsd-pf freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribe freebsd.org"
|
|
| Re: Bacula File/Storage Connection Woes
using PF |
  United States |
2008-03-25 21:53:16 |
On Tue, Mar 25, 2008 at 03:53:15PM -0700, Doug Sampson
wrote:
> > > Is there another way of writing rules that
will enable the
> > Bacula client to
> > > pass packets to the correct port number?
> > >
> > Yes, make the 1st rule
> >
> > block log all
> >
> > to drop both ingress and egress traffic by
default.
> >
> > Secondly get rid of the stateless rules. Use keep
state
> > everywhere, with
> > flags S/SA if matching tcp traffic.
This isn't a reply to you (Doug), but -- do not blindly use
"keep state"
everywhere!
There's been too many cases I've experienced where using
"keep state"
blindly results in state-mismatch increasing at a very fast
rate. When
I implemented this mentality on our production servers, our
users
started pointing out that scp's between machines would
randomly get
severed mis-stream, same with ssh sessions where large TCP
windows were
used (such as doing 'dmesg' over and over):
http://lists.freebsd.org/pipermail/freebsd
-pf/2008-January/004050.html
The "use keep state on everything!" attitude seems
to stem from people
reading the OpenBSD pf.conf documentation, which states that
as of
OpenBSD 4.1, "keep state" is implicit on every
rule (meaning it's done
whether you say "keep state" or not). FreeBSD's
pf isn't like this.
> I hate to bug you guys but I ain't a pf guru like you
guys. I am not
> understanding the significance of the "keep
state" and the "flags S/SA
> synproxy state" qualifiers. I have been copying
some rules from articles
> here and there. Thus these rules are not unified in the
sense that these are
> designed from the beginning to work harmoniously.
The easiest way to explain "keep state" is: with
rules that use "keep
state", every time a packet matching that rule is
encountered, pf keeps
track of the current TCP state and permits/denies based on
the TCP
state, rather than having to reiterate through all of your
rulesets over
and over.
I'll try to explain it with a very small ruleset and a
couple scenarios:
$ext_if = network interface that's got a public IP
address
4.4.4.4 = our public IP address
pass out quick all flags S/SA keep state
pass out quick all
block in log all
pass in quick on $ext_if inet proto tcp from any to
4.4.4.4 port ssh
Two scenarios:
1) When an incoming TCP packet from <any> to 4.4.4.4
on port 22 is seen,
that incoming packet is permitted (rule #4). Outbound
responses from
4.4.4.4 to <whoever sent the original incoming packet>
are also
permitted (rule #1). Note the "keep state".
pf will begin keep tracking of the TCP state from that point
forward,
which means it doesn't have to reiterate through your rules
to continue
passing inbound/outbound traffic for that TCP session.
2) An outbound TCP packet from 4.4.4.4 port 50345 to
12.90.124.50 port
25 is attempted. That packet is permitted (rule #1), and
the TCP
state is tracked in pf.
The *response* packets from 12.90.124.50 port 25 to 4.4.4.4
port 50345
are also permitted -- yet you see no rule for such, do you?
This is
because pf's state tracking ("keep state") is
doing the pass/deny
for you.
It gets more confusing when you consider the fact that even
though UDP
and ICMP are stateless protocols, pf can keep track of their
state too,
though I don't know if FreeBSD pf supports that (OpenBSD pf
does).
Now, about flags S/SA -- you need to understand how TCP
works to really
understand what purpose this serves.
"flags" causes pf to look at only certain TCP
flags (bits), and check to
see which of those bits are set or clear. You can check
against FIN,
SYn, RST, PSH, ACK, URG, ECE, and CWR. That criteria must
be matched
for the rule in question to be used. The official docs are
here, which
also describes synproxy (which I haven't used):
ht
tp://www.openbsd.org/faq/pf/filter.html#tcpflags
Let's take rule #1 in the above ruleset:
pass out quick all flags S/SA keep state
This means pass any outbound traffic (from any IP address of
ours) with
the TCP flag SYN set (but only look at the SYN and ACK flags
when doing
that comparison) -- and keep track of TCP state.
This explanation should also provide you an answer to what
rule #2 is
for -- permitting outbound packets which DO NOT match that
criteria.
You might be wondering "so why not nuke rule #1 and
just use #2?", to
which my reply would be, "see Scenario #2 -- incoming
packets from
12.90.124.50 port 25 to 4.4.4.4 port 50345 would then get
blocked!"
Does this make more sense to you?
--
| 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 |
_______________________________________________
freebsd-pf freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribe freebsd.org"
|
|
| Re: Bacula File/Storage Connection Woes
using PF |

|
2008-03-26 09:41:02 |
On Wed, Mar 26, 2008 at 12:47 PM, Jeremy Chadwick
<koitsu freebsd.org>
wrote:
> This brings up another situation: there's no version
number of pf in
> FreeBSD that I can find. The OpenBSD docs continually
say "as of
> OpenBSD x.y". This confuses people, who when
using pf under FreeBSD,
> have no knowledge of what version of pf we're using.
What version is in
> RELENG_6? 7? CURRENT? I didn't know until a few
minutes ago --
> because I went to cvsweb and had to look up the CVS
commit messages
> myself:
>
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/c
ontrib/pf/net/pf.c
>
> Now that I know, I can make appropriate adjustments.
But requiring
> users to look at CVS commit messages is a bit
unrealistic, don't you
> think? Maybe I should submit a PR asking that the
version of pf pulled
> into FreeBSD be kept in the pf(4), pf.conf(5), and
pfctl(8) manpages?
> What do you suggest?
>
> > Our cousins over the road in the OpenBSD
neighbourhood have done this
> > precisely because of the issues caused in prior
versions of PF by using
> > stateless rules and/or establishing TCP state on
anything other than the
> 3
> > way handshake.
>
> Yep, aware of that -- except that users have no idea as
to whether the
> implicit "keep state" on every rule applies
to FreeBSD or not, or if
> it's "safe" or not, because OpenBSD !=
FreeBSD. They read the OpenBSD
> docs and go "errr... so what version is FreeBSD
using?"
>
From: http://pf4freebsd.l
ove2party.net/
Status
The port is part of the base system of FreeBSD 5.X as of
March, 8th 2004.
- In RELENG_5 - pf is at OpenBSD 3.5
- In RELENG_6 - pf is at OpenBSD 3.7
- In RELENG_7 - pf is at OpenBSD 4.1
- In HEAD - pf is at OpenBSD 4.1 - at this time.
-
It has been said several times on the list as well.
_______________________________________________
freebsd-pf freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribe freebsd.org"
|
|
| Re: Bacula File/Storage Connection Woes
using PF |

|
2008-03-26 10:02:02 |
On Wed, Mar 26, 2008 at 3:53 AM, Jeremy Chadwick
<koitsu freebsd.org> wrote:
> I'll try to explain it with a very small ruleset and a
couple scenarios:
>
> $ext_if = network interface that's got a public IP
address
> 4.4.4.4 = our public IP address
>
> pass out quick all flags S/SA keep state
> pass out quick all
> block in log all
> pass in quick on $ext_if inet proto tcp from any to
4.4.4.4 port ssh
>
> Two scenarios:
>
> 1) When an incoming TCP packet from <any> to
4.4.4.4 on port 22 is seen,
> that incoming packet is permitted (rule #4). Outbound
responses from
> 4.4.4.4 to <whoever sent the original incoming
packet> are also
> permitted (rule #1). Note the "keep state".
>
>
>
Correct me if I'm wrong, but I think the outbound packet
will be matched
against the #2 rule, as the rule #1 has "flags
S/SA" and will not match the
packet since the packet would have "ACK" flag set.
Thus, the state will not
be created in state table.
That is if the rule #4 doesn't include "keep
state" (which is default in
RELENG_7).
_______________________________________________
freebsd-pf freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribe freebsd.org"
|
|
| Re: Bacula File/Storage Connection Woes
using PF |
  United States |
2008-03-26 10:51:26 |
On Wed, Mar 26, 2008 at 03:41:02PM +0100, Dalibor Gudzic
wrote:
> From: http://pf4freebsd.l
ove2party.net/
> Status
>
> The port is part of the base system of FreeBSD 5.X as
of March, 8th 2004.
>
> - In RELENG_5 - pf is at OpenBSD 3.5
> - In RELENG_6 - pf is at OpenBSD 3.7
> - In RELENG_7 - pf is at OpenBSD 4.1
> - In HEAD - pf is at OpenBSD 4.1 - at this time.
That's the official home page for FreeBSD pf(4)? Wow, I had
no idea.
I'd have expected it to be on freebsd.org somewhere,
especially since
it's such a heavily-relied upon piece of FreeBSD. Thank you
for
pointing me to this!
Regardless, I'll submit a PR to have the version number
mentioned in
some pf-related manpages, since users are going to look
there first,
logically.
> It has been said several times on the list as well.
Users aren't going to check a mailing list every time they
want to know
what version of a program they're using.
--
| 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 |
_______________________________________________
freebsd-pf freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribe freebsd.org"
|
|
| Re: Bacula File/Storage Connection Woes
using PF |

|
2008-03-28 11:44:01 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Greg Hennessy <Greg.Hennessy nviz.net> wrote:
>
> Jeremy Chadwick wrote:
> > Do not blindly use "keep state"
everywhere!
>
> Hard cases make for bad laws. I have got to point out
the error in
> the above statement.
To expand upon this (for further education), "keep
state" is beneficial
for two reasons:
1. A state table lookup is more efficient than parsing the
rule base
for every packet.
2. It is MORE SECURE to use state tables to pass packets,
because PF
watches the state very closely, and permits only the
specific
sequence numbers that should be active on the
connection. Of
course, if that state tracking is buggy, this leads to
the failures
referenced here:
> > There's been too many cases I've experienced where
using "keep
> > state" blindly results in state-mismatch
increasing at a very fast
> > rate. When I implemented this mentality on our
production servers,
> > our users started pointing out that scp's between
machines would
> > randomly get severed mis-stream, same with ssh
sessions where large
> > TCP windows were used (such as doing 'dmesg' over
and over):
What's being described here is a failure of PF to track
state correctly.
If a user types a command that results in a large amount of
output, like
"dmesg" or "ls -lR /", the connection
will stall because PF isn't
permitting the entire window to advance.
Greg makes reference to the "modulate state" bug,
which I was not aware
of, but it is also important to be aware of this:
> You miss out the most important bit of the new PF 4.1
state keeping
> defaults, 'flags S/SA'.
> Our cousins over the road in the OpenBSD neighbourhood
have done this
> precisely because of the issues caused in prior
versions of PF by
> using stateless rules and/or establishing TCP state on
anything other
> than the 3 way handshake.
The reason that it's so important to ONLY create state on
the initial
handshake is that crucial information (namely window-scaling
factors)
are exchanged ONLY at this time. If PF were to boot up and
see a
connection only in the middle, it would assume
"unscaled" window factors
in use, and thus would only permit a very small range of the
allowed
window, causing severe performance degradation.
Establishing state on
the initial SYN avoids this problem entirely.
> > It gets more confusing when you consider the fact
that even though
> > UDP and ICMP are stateless protocols, pf can keep
track of their
> > state too, though I don't know if FreeBSD pf
supports that (OpenBSD
> > pf does).
Of course PF supports this, but "state" on a
"stateless" connection is
maintained purely with timers. When the timers expire, the
state
expires.
- --
David DeSimone == Network Admin == fox verio.net
"This email message is intended for the use of the
person to whom
it has been sent, and may contain information that is
confidential
or legally protected. If you are not the intended
recipient or have
received this message in error, you are not authorized to
copy, dis-
tribute, or otherwise use this message or its attachments.
Please
notify the sender immediately by return e-mail and
permanently delete
this message and any attachments. Verio, Inc. makes no
warranty that
this email is error or virus free. Thank you."
--Lawyer Bot 6000
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFH7SBRFSrKRjX5eCoRAvE0AJ4vxqFWA2lhSajoDHc3jX7R/qvrQQCg
o67w
oOpUudaxHqtN70S6oURstns=
=IQZw
-----END PGP SIGNATURE-----
_______________________________________________
freebsd-pf freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribe freebsd.org"
|
|
[1-10]
|
|