Re: pf state initiator question

[Daniel Hartmeier <daniel@benzedrine.cx>]

On Fri, Mar 01, 2002 at 02:30:43PM +0000, Dirk Rosler wrote:

> pass in quick on $ExtIF inet proto tcp from $IntNet to any port = 22
> block in log quick on $ExtIF from any to any
> pass out on $ExtIF from any to any keep state

I just checked the FAQ, and it indeed contains this combination. I'm not
sure whether this is a good idea or just an oversight. Nick supplied
these examples, maybe he can comment. Maybe it's just a typo, since it
seems ssh connections should only be allowed from internal hosts, which
would mean they never pass the external interface $ExtIF.

The most natural approach (for me) is to create state on the initial SYN
packet, like in

  pass in ... proto tcp from any to any port ssh flags S/SA keep state
  pass out    proto tcp from any to any          flags S/SA keep state

Incoming connections already create state when the initial SYN packet
is passed in (and outgoing replies just match that state), and
connections originating from inside create state when the first SYN
packet passes out.

Note that I'm using 'flags S/SA', so only the initial SYN (and not
SYN+ACK, or other combinations) matches.

I'm not sure why someone would pass SYNs statelessly and create state
from following packets. If it is an attempt to deal with SYN floods,
please explain. Note that the example in the FAQ will also create state
when the internal machine replies with an RST to the SYN, and the
stateless 'pass in quick' rule not only passes SYNs, but any packet. It
only does so for port ssh (which is only allowed from the internal
network).

Creating state on SYN+ACK instead of SYN _could_ make sense in the case
where your firewall runs out of memory creating state during SYN floods.
Passing SYNs statelessly and creating state only when the destination
host can handle the load and accepts the connection with a SYN+ACK reply
could help there. But it depends on the behavior of the destination
host. If it sends a SYN+ACK for every SYN (like a Linux box using SYN
cookies would), you don't gain anything. I think the better approach is
to create state on SYNs and timeout state entries (that are not fully
established) aggressively, taking into account the amount of memory the
firewall has (the maximum number of states it can create), and the speed
at which a SYN flooder can create states.

Maybe I misunderstood the intention of the FAQ example. Does anyone
intentionally create state on SYN+ACK instead of SYN, and can explain
his/her reasons for doing so?

Daniel