Upgrading FreeBSD to use the NEW pf syntax.

[Ermal Luçi]

On Fri, Nov 23, 2012 at 8:50 AM, Ian FREISLICH <ianf at cloudseed.co.za> wrote:

> > > Today its a null op. So it voids the keyword which should be
> deprecated in
> > > FreeBSD or should be reintroduced!
> > > Also it may break people assumptions on it.
> >
> > So I take it that "set state-policy if-bound" will no longer have any
> > effect either? Is this expected to hit 10.0-RELEASE?
> >
> > It's definitely not ok to break this functionality. SMP changes are
> > far less valuable than being able to filter each packet on ingress and
> > egress.
>
> Except that it does work (Relevant config snippet):
>
> FreeBSD firewall1.jnb1.gp-online.net 10.0-CURRENT FreeBSD 10.0-CURRENT
> #10 r242311: Mon Oct 29 16:31:29 SAST 2012
> ianf at firewall1.jnb1.gp-online.net:/usr/obj/usr/src/sys/FIREWALL  amd64
>
> --- /etc/pf.conf ---
> ...
> # Options
> # ~~~~~~~
> set timeout { \
>         adaptive.start  900000, \
>         adaptive.end    1800000 \
>         }
> set block-policy return
> set state-policy if-bound
> set optimization normal
> set ruleset-optimization basic
> set limit states 1500000
> set limit frags 40000
> set limit src-nodes 150000
> ...
> # Servers
> anchor vlan4 quick on vlan4
> load anchor vlan4 from "/var/db/firewall/vlan4"
> ...
> # L2TP tunnel termination
> anchor vlan24 quick on vlan24
> load anchor vlan24 from "/var/db/firewall/vlan24"
> ...
> #EOF
>
> --- /var/db/firewall/vlan4 ---
> ...
> # Test
> block out log proto tcp from 41.154.88.19 to 41.154.0.151 port { ssh }
> pass   in all
> #EOF
>
> --- /var/db/firewall/vlan24 ---
> pass in  all
> pass out all
> #EOF
>
>
> [41.154.88.19] ~/graphing $ telnet 41.154.0.151 22
> Trying 41.154.0.151...
> telnet: connect to address 41.154.0.151: Operation timed out
> telnet: Unable to connect to remote host
>
>
> [firewall1.jnb1] ~ # tcpdump -envi pflog0 host 41.154.88.19 and host
> 41.154.0.151
> tcpdump: WARNING: pflog0: no IPv4 address assigned
> tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file),
> capture size 65535 bytes
> 09:31:41.323353 rule 3.vlan4.126/0(match): block out on vlan4: (tos 0x10,
> ttl 62, id 25475, offset 0, flags [DF], proto TCP (6), length 60)
>     41.154.88.19.26211 > 41.154.0.151.22: Flags [S], cksum 0x1264
> (correct), seq 3408095044, win 65535, options [mss 1410,nop,wscale
> 3,sackOK,TS val 3679262149 ecr 0], length 0
>
>
> [firewall1.jnb1] ~ # pfctl -s sta |grep 41.154.88.19 |grep 41.154.0.151
> vlan24 tcp 41.154.0.151:22 <- 41.154.88.19:26211       CLOSED:SYN_SENT
>
>
> However, with the #Test rule commented out:
>
> [41.154.88.19] ~/graphing $ telnet 41.154.0.151 22
> Trying 41.154.0.151...
> Connected to inbound01.jnb1.gp-online.net.
> Escape character is '^]'.
> SSH-2.0-OpenSSH_4.3p2 Debian-9etch2
>
> [firewall1.jnb1] ~ # pfctl -s sta |grep 41.154.0.211 |grep 41.154.2.69
> vlan24 tcp 41.154.0.151:22 <- 41.154.88.19:24898
> ESTABLISHED:ESTABLISHED
> vlan4 tcp 41.154.88.19:24898 -> 41.154.0.151:22
> ESTABLISHED:ESTABLISHED
>
>
> I think the only thing that's not working properly is
> set block-policy return
> but I'm not sure if that was working properly before.  I had to
> modify the rule as follows to get a connection refused:
>
This need to be checked in the parser in userland if it does not work that
is the place.

>
> block return out log proto tcp from 41.154.88.19 to 41.154.0.151 port {
> ssh }
>
> The real issue with return is related to routing return information.
If the routing table is not correct your return packet might get routed the
wrong interface.
It is not that easy to solve that problem without reinventing/duplicating a
lot of code paths
to track the information changes in the packet.


> to get:
> [41.154.88.19] ~/graphing $ telnet 41.154.0.151 22
> Trying 41.154.0.151...
> telnet: connect to address 41.154.0.151: Connection refused
> telnet: Unable to connect to remote host
>
> Ermal, do you have a test case that exposes the issue?
>
> What would expose the issue in your test case is that if a packet comes
incoming on VLAN4
with the same info(41.154.88.19 to 41.154.0.151 port { ssh }) that matches
the state created during outgoing VLAN24
the ruleset WOULD NOT be investigated if to allow this packet or not.
It would just match the state created when leaving outgoing on VLAN24.

Meaning that even if you put a rule on VLAN4 as
block in log proto tcp from 41.154.0.151 port { ssh } to 41.154.88.19

it will not be blocked but allowed.
There is where the if-bound state feature has the use case.

Without if-bound a packet leaving an interface can come from any other
interface and still be allowed,
the state scope is global to all the interfaces.
if-bound options segregates the state scope from global to only a specific
interface.

As i said it depends on the use case you have and the policies you
implement and the segregation required.


> Ian
>
> --
> Ian Freislich
>



-- 
Ermal