gijsbert points us to this comprehensive guide to setting up and configuring PF, the BSD packet filter. PF is one of the more robust enterprise firewall applications available today.
PF for Beginners
About The Author
Adam Scheinberg
Technology Executive • Web Developer • Father • Foodie • Music Snob • OS enthusiast
Follow me on Mastodon @[email protected]
i would not exactly call it ‘a comprehensive guide’
https://solarflux.org/pf/
or
http://openbsd.org/faq/pf/
are two of the better resources i can think of. There’s much much information that was not covered here.
This: pass in log quick on $EXT_NIC proto icmp from any to $EXT_IP echoreq keep state
Always block/drop ICMP ping replies. Allowing them through encourages port scans.
The article also says nothing about creating aliases for groups of port numbers. I guess that and a lot more is left up to RTFM the pf man.
Sorry guys i’m an Linux user, but what are the biggest differents between PF and Iptables?
I absolutely prefer “Building firewalls with openbsd and pf” by mr artymiak. Available here: http://books.kd85.com/
.
Always block/drop ICMP ping replies. Allowing them through encourages port scans.
What have you been smoking?
Does openbsd have such options as:
net.inet.udp.blackhole
net.inet.tcp.blackhole
DESCRIPTION
The blackhole sysctl(8) MIB is used to control system behaviour when con-nection requests are received on TCP or UDP ports where there is no socket listening.
Normal behaviour, when a TCP SYN segment is received on a port where there is no socket accepting connections, is for the system to return a RST segment, and drop the connection. The connecting system will see this as a “Connection refused”. By setting the TCP blackhole MIB to a numeric value of one, the incoming SYN segment is merely dropped, and no RST is sent, making the system appear as a blackhole. By setting the MIB value to two, any segment arriving on a closed port is dropped without returning a RST. This provides some degree of protection against stealth port scans.
In the UDP instance, enabling blackhole behaviour turns off the sending of an ICMP port unreachable message in response to a UDP datagram which arrives on a port where there is no socket listening. It must be noted that this behaviour will prevent remote systems from running traceroute(8) to a system.
taken from man blackhole
http://openbsd.org/faq/pf/options.html#block-policy
pf gives you even more granular control than the linux options you mention. You can set the type of response to blocked packets to the port level (send RST for port 80, drop packet for port 25, send icmp-unreachable, etc etc)
I’m a big fan of pf over iptables and ipchains. The rulesets are much easier to read (no chain hopping to track down) but you can still use built-in skip-steps to optimize the rule traversal. My only complaint is the difficulty in setting up strong egress filtering while still supporting ftp outbound. With 3.3 I was finally able to do it, but it took a bit of trial and error, as the documentation on ftp-proxy and it’s interaction with pf is weak.
pf gives you even more granular control than the linux options you mention. You can set the type of response to blocked packets to the port level (send RST for port 80, drop packet for port 25, send icmp-unreachable, etc etc)
I’m not trying to advocate neither Linux or OpenBSD here as I use them both and find them both useful, but in my opinion, IPTables/Netfilter is a bit easier to read and write than OpenBSD’s PF.
iptables -A input -p tcp –dport 21 -j ACCEPT
iptables -A input -p tcp –dport 22 -j REJECT
iptables -A input -p tcp –dport 25 -j REJECT –reject-with icmp-host-unreachable
Just as granular.
I’m no expert on either of these, but what I’d like to see is matching based on a random variable of random length in any part of the IP/TCP/UDP header. Kinda like tcpdump can do it.
jan.de.boer
Sorry guys i’m an Linux user, but what are the biggest differents between PF and Iptables?
As both a Linux and OpenBSD user, I can say that PF is infinitely simpler than IPtables. Instead of storing three or four or five arrays of packet rules, all the rules are in one cleartext file. Read a pf.conf file and you’ll know immediately how it works. I love it =)
comprehensive??
i would not exactly call it ‘a comprehensive guide’
https://solarflux.org/pf/
or
http://openbsd.org/faq/pf/
are two of the better resources i can think of. There’s much much information that was not covered
here.
The point is that it is a basic setup for starting with PF ……
if your looking round on the net there is al lot writing about PF and what it can do, but not a “simple” tutorial for a beginner
quote
The goal of this article is to give you a good step-by-step on setting up your PF firewall, and explains each step
sufficiently, but not so deep that it would confuse.
/quote
my 2 cts
I definitely agree that a pf ruleset is MUCH easier to read than an iptables one. And for a personal firewall an openbsd machine with pf is an excellent choice, probably the best.
But when talking about high traffic networks where performance is important, iptables shines for stateless packet filtering. There is a nice paper on this here:
http://www.benzedrine.cx/pf-paper.html
The conclusion:
“In summary, iptables perform the best for stateless rules and pf performs the best when using stateful filtering.”
PS Eugenia- PLEASE don’t mod me down. I can’t seem to make any sort of post here anymore with out getting instantly modded down.
Fully agree PF beeing better
PF can do more. PF syntax is like English. It’s more simple. It’s easier to read. It’s fault tollerant. And if it’s ot fault tolerant it’ll tell you were the error is. And you can then check the manuals then and see the syntax. Good manuals as well. Except for the manuals, this be in contrast to IPTables… which i find an unlogic hell to use.
A difference which is not by default better or worse is that PF has one config file. You change it. You reload it. Rule syntax incorrect? Error is given, no reload. Stays on previous target then. OTOH IPtables is a command. It is a program. Doesn’t need a config file. With one command something new can be added. Although PF can do this with AuthPF, it’s one of the few differences on which i’m not outspoken. Because one command is easier to do from a program then AuthPF. Hope you get my point. It’s a minor one for me, though.
I comment PF. Really. Try it. I wish Linux had it. Luckily it also runs on FreeBSD and NetBSD. It might even become default in NetBSD as a choice. For a home router, try NSH (Network SHell – cisco like interface), PF, bridging and OpenBSD (or another one if you wish and if it works with NSH) on one floppy/flash.
Those benchmarks on the site are old. A date isn’t noted at them, but i’ve seen it years ago already.
Also see deadly: http://www.deadly.org/article.php3?sid=20030919231901
it has some criticism on the document, like (minor) corrections
pf is the OpenBSD packetfilter, although implementations exist on FreeBSD (and maybe NetBSD–thought I’m not sure). pf was designed and built by the OpenBSD team after ipf became unusable due to weird restrictions and ego problems on the part of its main developer.