pf and rpi

[Zoran Kolic]

I intent to load pf firewall on rpi and not stay
locked out of the node. The only comminication is
via ssh.
My plan is to try out rules and, for every safety,
reboot the node to state without pf. Like this:

# modload pf
# pfctl -f /etc/pf.conf; shutdown -r +10

If I make permanent move to "pf=YES" and make a
mistake, I would have to install from the scratch.
Does my plan sound sane?
Best regards

Zoran

[J. Lewis Muir]

On 10/1/14 9:57 AM, Zoran Kolic wrote:
> I intent to load pf firewall on rpi and not stay locked out of the
> node. The only comminication is via ssh.

Hi, Zoran.

You're right about putting pf=YES in /etc/rc.conf; I would not do that
until I was confident my configuration was right.

Does "rpi" mean "Raspberry Pi"? If so, then is it easy to power cycle
the device? If so, you can just try your rules, and if you get locked
out, power cycle it.

But normally I wouldn't even plan to power cycle my machine to recover.
Before trying new firewall rules, I just run something to disable the
firewall after a period of time in case I lock myself out. So, I'd do
something like this:

# nohup sh -c 'sleep 15; pfctl -d' < /dev/null > /dev/null 2>&1 &

That runs the sh process in the background, detached from standard
input, standard output, and standard error, and ignoring the SIGHUP
signal. After 15 seconds it runs "pfctl -d" to disable the firewall.

Or you could just start a tmux session, and do the following in a
window:

# sleep 15; pfctl -d

BTW, as of NetBSD 6, there's a new packet filter for NetBSD called
NPF. See npf.conf(5), npfctl(8), and /usr/share/examples/npf.
There's also a document by the NPF author titled "NPF documentation"
<http://www.netbsd.org/~rmind/npf/>. I think it documents the latest
NPF, so if you're not running the latest NetBSD, beware that some things
might be slightly different for your NPF.

Regards,

Lewis

[u***@gmx.net]

On Wed, 1 Oct 2014 16:57:14 +0200
Zoran Kolic <***@sbb.rs> wrote:

>
> If I make permanent move to "pf=YES" and make a
> mistake, I would have to install from the scratch.

Is the serial port not working with netbsd?
With Raspbian I often use a FTDI cable to access the system over the serial
port.

> Does my plan sound sane?
> Best regards
>
> Zoran

regards uhel

[Zoran Kolic]

> Is the serial port not working with netbsd?
> With Raspbian I often use a FTDI cable to access the system over the serial
> port.

I put rpi behind the closet. I see this as a proof of the concept.
Aside my previous idea (pfctl; shutdown -r +10), I got answer:
sleep <sometime>; pfctl -d
My biggest puzzle is syntax for pf. On netbsd it is somewhere about
version 4.2 openbsd. I cannot say for sure if it supports modulate
state and else.
Best regards

Zoran

[Christian Koch]

On Thu, Oct 02, 2014 at 04:06:22PM +0200, Zoran Kolic wrote:
> I put rpi behind the closet. I see this as a proof of the concept.
> Aside my previous idea (pfctl; shutdown -r +10), I got answer:
> sleep <sometime>; pfctl -d
> My biggest puzzle is syntax for pf. On netbsd it is somewhere about
> version 4.2 openbsd. I cannot say for sure if it supports modulate
> state and else.
> Best regards
>
> Zoran

Seriously, why aren't you using NPF? NPF is the packet filter that is actually
being developed on and for NetBSD. And I'm positive it'll work just fine on
Raspberry Pi.

http://www.netbsd.org/~rmind/npf/

-Christian

[David Lord]

On 2 Oct 2014 at 21:20, Christian Koch wrote:

> On Thu, Oct 02, 2014 at 04:06:22PM +0200, Zoran Kolic wrote:
> > I put rpi behind the closet. I see this as a proof of the concept.
> > Aside my previous idea (pfctl; shutdown -r +10), I got answer:
> > sleep <sometime>; pfctl -d
> > My biggest puzzle is syntax for pf. On netbsd it is somewhere about
> > version 4.2 openbsd. I cannot say for sure if it supports modulate
> > state and else.
> > Best regards
> >
> > Zoran
>
> Seriously, why aren't you using NPF? NPF is the packet filter that is actually
> being developed on and for NetBSD. And I'm positive it'll work just fine on
> Raspberry Pi.
>
> http://www.netbsd.org/~rmind/npf/

Hi

I'm not using npf, perhaps because I'm still using ipf as from
1997, and above page doesn't go anywhere on my system with win98
and seamonkey as (as of 2012). My big desktop, nbsd-6, had cd
drive failure during system update repartitioning but why should
I have to use that anyway. I can also use ipv6 which ipf handles.


David

[Zoran Kolic]

> Seriously, why aren't you using NPF? NPF is the packet filter that is actually
> being developed on and for NetBSD.

I'm not familiar with it.
On freebsd I use ipfw, with rules that first one wins.
On pf I know that the last one wins. Cannot be so sure
reading npf howto. My bet is that the last wins too.

I made a little investigation and seems that I could
change from pf to npf. The pf rules:

set skip on lo
block in all
block out all
pass out on usmsc0 proto { tcp, udp, icmp } from any to any modulate state
pass in on usmsc0 proto tcp from any to any port ssh

My version of /etc/npf.conf sounds like this:

group "eth" on usmsc0 {
block all
pass stateful out final all
pass stateful in final proto tcp to usmsc0 port ssh
}
group default {
pass final on lo0 all
block all
}

So far, I'm confused about having to drop secure level to
-1 to load module for pf or npf. Gonna try that as my very
next step.

Thanks all for help and best regards

Zoran

[Rhialto]

On Fri 03 Oct 2014 at 16:25:58 +0200, Zoran Kolic wrote:
> On freebsd I use ipfw, with rules that first one wins.
> On pf I know that the last one wins. Cannot be so sure
> reading npf howto. My bet is that the last wins too.

I've never understood the reason for "last one wins". That seems like
unnecessary work, checking all those rules that may or may not be
winning in the end. And you can get the same effect with a "first one
wins" system (hence more efficiently) if you simply reverse the order of
the rules.

-Olaf.
--
___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl -- 'this bath is too hot.'

[Malcolm Herbert]

On Sat, Oct 04, 2014 at 02:47:52AM +0200, Rhialto wrote:
|On Fri 03 Oct 2014 at 16:25:58 +0200, Zoran Kolic wrote:
|> On freebsd I use ipfw, with rules that first one wins. On pf I know
|> that the last one wins. Cannot be so sure reading npf howto. My bet
|> is that the last wins too.
|
|I've never understood the reason for "last one wins". That seems like
|unnecessary work, checking all those rules that may or may not be
|winning in the end. And you can get the same effect with a "first one
|wins" system (hence more efficiently) if you simply reverse the order
|of the rules.

this is why the 'quick' flag is there - it lets the filter engine stop
processing further rules on matching the one with the flag

I thought the argument went that if you set up rules that worked least
specifically to most, then with quick flag you get the best of both
worlds - you can elect to have the filter skip the remaining rules if
you want to or just let the packet trickle out through them all ...

putting the most specific rules at the top may result in bad performance
if most of your traffic doesn't match that rule

Regards,
Malcolm

--
Malcolm Herbert
***@mjch.net

[Christos Zoulas]

In article <***@deimos.ergonaut.org>,
Malcolm Herbert <***@mjch.net> wrote:
>-=-=-=-=-=-
>
>On Sat, Oct 04, 2014 at 02:47:52AM +0200, Rhialto wrote:
>|On Fri 03 Oct 2014 at 16:25:58 +0200, Zoran Kolic wrote:
>|> On freebsd I use ipfw, with rules that first one wins. On pf I know
>|> that the last one wins. Cannot be so sure reading npf howto. My bet
>|> is that the last wins too.
>|
>|I've never understood the reason for "last one wins". That seems like
>|unnecessary work, checking all those rules that may or may not be
>|winning in the end. And you can get the same effect with a "first one
>|wins" system (hence more efficiently) if you simply reverse the order
>|of the rules.
>
>this is why the 'quick' flag is there - it lets the filter engine stop
>processing further rules on matching the one with the flag
>
>I thought the argument went that if you set up rules that worked least
>specifically to most, then with quick flag you get the best of both
>worlds - you can elect to have the filter skip the remaining rules if
>you want to or just let the packet trickle out through them all ...
>
>putting the most specific rules at the top may result in bad performance
>if most of your traffic doesn't match that rule

Careful with "quick" (or "final" in npf lingo rules). For TCP you also
need to specify "keep state" (or "stateful" in npf lingo), otherwise
you'll get spurious connection drops.

christos

[Zoran Kolic]

> I've never understood the reason for "last one wins". That seems like
> unnecessary work, checking all those rules that may or may not be
> winning in the end. And you can get the same effect with a "first one
> wins" system (hence more efficiently) if you simply reverse the order of
> the rules.

I'm afraid it does not work like that. Last win is firewall's
internal. Having not used npf ever, I might say that "final"
word makes it stop further checking.
At the moment I stranded myself on securelevel. For some reason
I just cannot change it to -1. Not in rc.conf, nor sysctl.conf.
Seems that evbarm does not support boot.cfg module loading and
I don't want to find it out the worst way. Any idea what to do
next?
I'd appreciate if someone says a word or two on rules I made for
simple one user node.
Best regards all

Zoran

[Thor Lancelot Simon]

On Sat, Oct 04, 2014 at 05:03:41AM +0200, Zoran Kolic wrote:
>
> I'm afraid it does not work like that. Last win is firewall's
> internal. Having not used npf ever, I might say that "final"
> word makes it stop further checking.
> At the moment I stranded myself on securelevel. For some reason
> I just cannot change it to -1. Not in rc.conf, nor sysctl.conf.

There is no way to change the security level to -1 except by building a
kernel with options INSECURE. Why are you trying to change the security
level to -1? If you want to load a kernel module, you need simply to do
so before the system is running at securelevel 1 during the boot process.

The npf startup scripts should do this for you.

[Zoran Kolic]

> Why are you trying to change the security
> level to -1? If you want to load a kernel module, you need simply to do
> so before the system is running at securelevel 1 during the boot process.

Exactelly!
I was wondering if it was possible to just load the module
and pfctl/npfctl latter. With help on port-arm, there might
be a solution, adding a file in /etc/rc.d and enabling it in
/etc/rc.conf with "modload=YES". It might look like this:

#!/bin/sh
#

# PROVIDE: modload
# BEFORE: securelevel

name=modload
rcvar=$name
command="/sbin/modload pf"

load_rc_config $name
run_rc_command "$1"

I'm pretty much puzzled if wrong rc.d file could block boot
process and brick the node. All this for a reason pf is old
version, of which I do not recall proper syntax, compared to
current. Never used npf and feel reluctant to load configuration
on remote node, without safe net. First npfctl with addition
to reboot without firewall.
Best regards

Zoran

[Eric Haszlakiewicz]

On October 7, 2014 11:01:45 AM EDT, Zoran Kolic <***@sbb.rs> wrote:
>> Why are you trying to change the security
>> level to -1? If you want to load a kernel module, you need simply to
>do
>> so before the system is running at securelevel 1 during the boot
>process.
>
>Exactelly!
>I was wondering if it was possible to just load the module
>and pfctl/npfctl latter. With help on port-arm, there might
>be a solution, adding a file in /etc/rc.d and enabling it in
>/etc/rc.conf with "modload=YES". It might look like this:
...
>I'm pretty much puzzled if wrong rc.d file could block boot
>process and brick the node. All this for a reason pf is old
>version, of which I do not recall proper syntax, compared to
>current. Never used npf and feel reluctant to load configuration
>on remote node, without safe net. First npfctl with addition
>to reboot without firewall.
>Best regards

If you want to keep the securelevel at 0 so you can load modules by hand after the boot finishes, add securelevel=0 to /etc/rc.conf

Eric

[Zoran Kolic]

> If you want to keep the securelevel at 0 so you can load modules by hand after the boot finishes, add securelevel=0 to /etc/rc.conf

So far, when set to 0, it goes to 1. Kernel option compiled in.

Zoran

[Martin Husemann]

On Wed, Oct 08, 2014 at 04:54:05PM +0200, Zoran Kolic wrote:
> > If you want to keep the securelevel at 0 so you can load modules by hand after the boot finishes, add securelevel=0 to /etc/rc.conf
>
> So far, when set to 0, it goes to 1. Kernel option compiled in.

Of course, this is by design. The point is to finish all work that needs 0
before it rises.

Martin

[Zoran Kolic]

> Of course, this is by design. The point is to finish all work that needs 0
> before it rises.

Yep. /etc/rc.d script might be the solution. Or as you suggested
few days ago, modules.conf or alike.

Zoran