Date: Tue, 11 Jul 2006 18:21:20 +0800 From: "Ronnel P. Maglasang" <rmaglasang@infoweapons.com> To: Greg Hennessy <Greg.Hennessy@nviz.net> Cc: freebsd-pf@freebsd.org Subject: Re: PF firewall rules Message-ID: <44B37BA0.7030405@infoweapons.com> In-Reply-To: <000c01c6a4d1$1c37b1d0$0a00a8c0@thebeast> References: <000c01c6a4d1$1c37b1d0$0a00a8c0@thebeast>
next in thread | previous in thread | raw e-mail | index | archive | help
Greg Hennessy wrote:
> The notion of UDP keeping state is overstated.
>
> Basic layer 3 'keep state' for UDP is nothing more than a watchdog timer
> tracking how long it was since the last packet for the reverse flow arrived.
>
>
is it safe to say to just remove the "keep state" behavior for udp and
other connectionless
packets? i really think this is a vulnerability. please note the pf
always creates states for
outgoing packets, even its udp.
>> firewall rules using rough careless flags options on a
>> firewall rules where everything is just going out keep state
>>
>
> One cannot 'keep state' for TCP in any meaningful fashion without tracking
> the flags + sequencing.
>
> If you want a primitive packet filtered ACL from point a to b for TCP.
>
> pass out on int inet proto tcp from a to b
> pass in on int inet proto tcp from b to a
>
> will match all packets and allow that flow.
>
>
>> 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.
>>
>
> At layer 3 there is nothing to track in UDP to keep state except the quad in
> the header.
>
> UDP by its very nature is connectionless.
>
>
>> 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)
>>
>
> Oh puhleeze. Get some of idea of the fundamental difference between TCP and
> UDP before making such a ridiculous statement.
>
> In particular I recommend reading TCP Illustrated by W Richard Stevens.
>
>
>>> 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,
>>
>
> We all had to do it, you will find once you get used to it, that the
> equivalent PF policy is about half the size of the IPF one as a consequence.
>
>
>
>> 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.
>>
>
> Err, that's what matching against direction in the rule base does.
>
>
>> 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.
>>
>
> That's what tags are for.
>
>
>> 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.
>>
>
>
> Are you saying that you cannot do a transparent redirect on the inside
> interface of the form ?
>
> rdr pass on inside $TCP from <InsideNets> -> $PublicVIP port something ->
> $DMZ-RFC-ADDRESS port something
>
>
>
>> 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.
>>
>
> If the service sits on the LAN rather than on a DMZ interface, this is most
> likely going to pear shaped unless you start disabling ICMP redirects
> everywhere.
>
> >From a design perspective hosting any external facing service directly on
> the most trusted part of the network is *not* a good idea.
>
>
> 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"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44B37BA0.7030405>