Bacula File/Storage Connection Woes using PF

[David DeSimone]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greg Hennessy <Greg.Hennessy at 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 at 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/qvrQQCgo67w
oOpUudaxHqtN70S6oURstns=
=IQZw
-----END PGP SIGNATURE-----