Pf

2008-09-23T15:41:51Z

Al:

== pf basics ==

If you're using the [[OpenBSD]]'s pf, which also works on [[FreeBSD]], make sure it's enabled. You should watch [[Pflogd]] for the logging interface. If you use pf, you should also check out [[spamd]] while you're here.

# pfctl -si
Status: Enabled

I've been bitten by this while debugging.

# pfctl -N -f /etc/pf.conf

This will reload the nat rules only.. often best to disable the firewall rules when testing nat, so do

# pfctl -Fr

to flush the rules, and just

# pfctl -R -f /etc/pf.conf

to use them again.

# pfctl -Fs

to flush the current nat states, just remember the existing natted connections will drop when you do this.

# pfctl -ss

to show the current nat states.

in summary, -Fn the F means to Flush. -sn the s means to show. -N and -R are to load only the Nat or filter Rules respectively.

If you're satisfied with your pf ruleset, you might be interesting in looking into [http://pf4freebsd.love2party.net/altq.html ALTQ]. Alternate queuing (ALTQ) is a framework that allows to shape network traffic.

== helpful rules for pf.conf ==

These can mostly be found by logging all of your block rules and then watching with:
# tcpdump -vvv -e -ttt -i pflog0
Once you see something you want to block, usually a reoccuring sequence, you can add a block rule without log enabled.

# block Microsoft Calendar
block in quick on $ext_if proto udp from any to any port {1024 1025 1026 1027 1028 1029 1030 }
# block nmap OS detection scans somewhat (-O)
block in quick proto tcp flags FUP/WEUAPRSF
block in quick proto tcp flags WEUAPRSF/WEUAPRSF
block in quick proto tcp flags SRAFU/WEUAPRSF
block in quick proto tcp flags /WEUAPRSF
block in quick proto tcp flags SR/SR
block in quick proto tcp flags SF/SF

Don't let the flags confuse you, the simplest way to block any sort of OS detection scans is to block anything and not return a packet. The scanner will only know that the packet never came back. You need to suit this with the blocking policy of your ISP though. It's interesting to find out when an IP is not allocated by an end-user whether the ISP's network access server reply anything in its place or whether the IP is blackholed. Early access servers showed a routing loop in a traceroute, my particular ISP blackholes non-used IP's. Getting to my point, if your ISP blackholes non-used IP's then using a block that doesn't reply anything shows no distinction whether there is a "live" computer behind an IP. If an ISP replies with some sort of packet perhaps the pf rules should be adapted to reply the same, so that a transparency appears.

== Allowing torrents in pf ==

In this example, $torrentclient is the IP of the host running a torrent client, and I have
specified in my torrent application to only use port 15001. I added the following to my pf.conf and ran "pfctl -f /etc/pf.conf" as root:
rdr on $ext_if proto tcp from !$nat_net to any port 15001 -> $torrentclient port 15001
pass in quick on $ext_if inet proto { udp tcp } from any to any port 15001 keep state

If you have a firewall on $torrentclient, make sure you allow the port 15001 traffic as well.

== Verify your configuration ==

The following parses your configuration without loading the rules
# pfctl -vvnf pf.conf

----
[http://www.openbsd.org/faq/pf/ Official PF page]

== Rules based on user (UID/GID) ==

In the sample below, I will block UID 1012 from accepting packets on the rl0 interface. Then I will also block the outbound on the same interface for the same user. For the second example, I will use the username instead of the UID. You can use either:

block drop in log quick on rl0 all user = 1012
block drop out log quick on rl0 all user = droopy

== pageknock to internal machine ==

First I installed [[http://www.otterhole.ca/knock/ pageknock]]. To start pageknock I used the command:

# pageknock &

Then I setup some rules in my pf.conf:

rdr on $ext_if proto tcp from any to $ext_if port 3233 -> 192.168.1.18 port 22

This means packets hitting 3233 on my external interface will hit port 22 (sshd) on my 192.168.1.18 machine. Now for the firewall rules:

pass in quick on $tun_if proto tcp from <sshknock> to $ext_if port 323 keep state
pass in quick on $tun_if proto tcp from <sshknock> to 192.168.1.18 port 22 keep state

In place of the firewall rules, a simple 'pass' in the rdr rule should have worked:
rdr ''pass'' on $ext_if proto tcp from <sshknock> to $ext_if port 3233 -> 192.168.1.18 port 22

and restarting pf:

# pfctl -f /etc/pf.conf

To debug it you can run tcpdump on your external interface as well as check your pflog

# tcpdump -i hme0 port 3233

# tcpdump -vvv -e -ttt -i pflog0

Now when traveling I can

$ ssh -X $my_machine

after sshknocking.

Hackepedia - User contributions [en]

Pf