Date: Tue, 11 Jul 2006 18:17:01 +1000 From: Michael Vince <mv@thebeastie.org> To: Daniel Hartmeier <daniel@benzedrine.cx> Cc: freebsd-pf@freebsd.org Subject: Re: PF firewall rules Message-ID: <44B35E7D.5010107@thebeastie.org> In-Reply-To: <20060711062229.GG27312@insomnia.benzedrine.cx> References: <D5972F49810A69449A9EA72A4B360DC2D0A38F@e1.universe.dart.spb> <44B339D6.7090401@thebeastie.org> <20060711062229.GG27312@insomnia.benzedrine.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Hartmeier wrote:
>On Tue, Jul 11, 2006 at 03:40:38PM +1000, Michael Vince wrote:
>
>
>
>>That still doesn't really answer my question and I also am looking for a
>>flags example of what would guarantee to provide the desired behavior.
>>
>>
>
>If you don't specify a 'flags' option, the rule will match any flags
>combination.
>
>Don't use 'modulate state' in this case. If you remove the state, and
>create a second state from another packet of the ongoing connection,
>'modulate state' will pick a random (most certainly different) sequence
>number modulator, and the connection will immediately stall when the
>endpoints see the new and completely out-of-bounds sequence numbers.
>
>You can only use 'modulate state' when you create state on the initial
>SYN of a connection ('flags S/SA' is recommended there) and preserve
>that state entry for the duration of the connection. If you lose the
>state entry, the connection will stall. So, use 'keep state' instead.
>
>But that won't work, in general, either. Nowadays many hosts enable TCP
>window scaling and use >0 scaling factors. For pf to support that
>properly, it must also create state on the initial SYN. Creating a state
>from any packet later than the SYN will eventually stall the connection.
>If you know TCP window scaling isn't used, you can create state on any
>packet, but in general you should use 'flags S/SA' on state creating
>rules.
>
>
>In short, don't lightly flush your states. There's no reason to flush
>states in normal operation (like, when reloading the ruleset). If you
>don't want to have to reestablish connections when the firewall must be
>rebooted, there's pfsync to synchronize states to a backup firewall and
>carp to do automatic failover.
>
>
So ultimately what your saying is PF is too clever now and can never be
simplified like UDP state modes for single line firewall rules using
rough careless flags options on a firewall rules where everything is
just going out keep state and otherwise blocking all in.
This is fair enough, I just had to ask. To me it just seemed a bit
unreasonable to bit so stricted about TCP while being so lean and easy
going and in one sense clever with UDP and ICMP.
While the inherited TCP flags give you the ability to be more strict
about it all I just would of thought if I want to have a easy/non strict
going firewall I would be able to configure it like that with no problems.
While I don't understand the TCP protocol as well as you guys, I do tent
to see as protocol racism, making it all easy for the white UDP people
and being tough on the TCP black people (if it was a firewall/country of
largely white population in the 50s)
>
>
>>So your saying that to stop packets going *out* its more "natural" to
>>type up a *block in* firewall rule to achieve the desired result, I
>>think its is a hard point of view to argue, and this was something that
>>was never needed with IPFilter and is probably one of its better
>>remaining features over PF.
>>
>>
>
>Maybe you can argue what seems more intuitive to you, but technically,
>it's more straight-forward to block packets as early as possible (for
>forwarded packets that is on the input path). What's the point of
>allowing a packet in on the internal interface, have the stack do a
>route lookup and try forward the packet out through the external
>interface, just to then block it there? Waste of CPU cycles and network
>buffers.
>
>If for some technical reasons you want to filter on the external
>interface based on source address lost due to NAT translation, you can
>try tagging on the internal interface and distinguish based on tags on
>the external interface.
>
>But if you'd just prefer to not have "translation occur before
>filtering", I guess you're way too late to suggest that. It was a
>deliberate design choice, and people grew to appreciate and rely on this
>order.
>
>
Darn, I had wondered about this for a bit now, so all IPFilter users
have to readapt their mind frame for PF, I don't know why but I have had
a little bit of a hard time with this, I guess the reasons I liked
IPFilter and also PF has been because its its very english language like
syntax and mind frame.
One way to kind of add onto the syntax but still keep the "out" word in
there would be to place the keyword "kernel" to help let the user know
which direction the packet is going in and out of the internal
interface. I don't know if it is the best solution but I do get to keep
my "out" word even if its a bit selfish.
block out quick on $int_if kernel proto { tcp, udp, icmp } from
192.168.1.17 to any
Yes, one of the issues I had against blocking so early on the internal
interface is it ruins the ability to run services on internal NAT ip
servers using RDR for internal IPs but providing a single IP to all
users behind the firewall and for those over the Internet.
If I want to block some IPs from reaching the Internet but still be able
to use the web server behind NAT firewall I have to allow extra firewall
rules for those IPs before they hit the firewall rule above that blocks
everything going out on the internal interface.
Considering the above firewall rule depending on how it was implemented
might not work another syntax/feature that could allow packets going in
to the external interface from the kernel side of things
block in quick on $ext_if kernel proto { tcp, udp, icmp } from
192.168.1.17 to any
While I am back to square 1 with the "in" statement it would still me
from having to have special rules allowing stuff back in to internal
redirected services.
Mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44B35E7D.5010107>