OpenBSD Packet Filter Ported To NetBSD, FreeBSD

honold writes "just read this on deadly.org (from Pyun YongHyeon): "Hello there. I have ported pf to FreeBSD 5.0 Currently it works well, though many nice features of pf not tested. I have ported to make FreeBSD users know there is an another excellent stateful packet filter with BSD license. URL is the following. ftp://ftp.kr.freebsd.org/pub/FreeBSD-kr/misc/pf_fr eebsd_0.3.tar.bz2 Thanks." netbsd has a port as well Where are you, Linux?"

Comments

Where are you, Linux?

[Rastor]

"Where are you, Linux?" I'm not sure I understand the question; Linux has had packet filtering for years now...

Re:Where are you, Linux?

[josepha48]

Then use netfilter.. its pretty nice... I'd agree it does change each release. But you can also use the old way still. 2.4.x has all 3 in it so you can pick which one you want to use. So while yes it has changed, it also has more options now (another point of view).

Also both FreeBSD and NetBSD have had for a while ipfilter, which is able to 'keep state'. So they already had stateful filtering. At least that's what I thought the 'keep state' keyword in ipf was supposed to do. In FreeBSD 4.? they introduced ipfirewall or ipfw. FreeBSD 5.0 has ipfw2 which does a great job at keeping state. Just use ipfw -d show and you see what is going through your firewall in the state table. Actual ip:port to ip:port listing. I wish it had something like ipfilters ipfstat -t command.

FreeBSD now has 3 choices as far as stateful packet filtering go, ipfilter, packet filter and ipfirewall. What really needs to be done is metrics on all these to show which is actually better under FreeBSD. Metrics that show performane as well as features. Also ease of understanding.

Re:Where are you, Linux?

[Anonymous Coward]

Come on, dude, think for like two seconds and you'll figure it out. The article is about pf being ported to FreeBSD and NetBSD. When he asks about Linux, he's obviously talking about a port of pf to Linux.

Re:Where are you, Linux?

[Dan Ost]

Linux packet filtering is not as elegant as
what OpenBSD has created.

Sure it works, but it's much easier with pf.

Re:Where are you, Linux?

[Bishop]

Sure it works, but it's much easier with pf.

Says the person who has not bothered to learn Linux Netfilter. I use both. My config files for both are equally easy to read and use.

Re:Where are you, Linux?

[Anonymous Coward]

This is /. man. Not too many people here with a clue... Most of them use RH and the likes; which explains most of them...

Re:Where are you, Linux?

[Anonymous Coward]

Linux? What is ``Linux''? ;-)
So now we have one more reason to upgrade to 5. Can't wait for RELENG_5.
(In fact i like Linux - I just like BSDs more.)

Re:Where are you, Linux?

[rabidcow]

Could you provide an example? Last time I set up a firewall on Linux, I had to use ipchains, which was baffling to no end. I gave up on any manual configuration and went with linuxconf.

pf is practically configured in english, I actually know where the config file is, and I can easily understand it weeks later without digging through the man page again.

I've taken a quick look around www.netfilter.org, but the best I've seen is stuff like:
iptables -t filter -A INPUT -d $PUBLIC -m state --state INVALID -j log
iptables -t filter -A INPUT -s localhost -d localhost -j ACCEPT
iptables -t filter -A INPUT -s $PUBLIC -d $PUBLIC -j ACCEPT
iptables -t filter -A INPUT -d $PUBLIC -m state --state RELATED,ESTABLISHED -j ACCEPT

which is still fairly opaque compared to:
pass in quick on $xif inet proto udp from 10.150.88.1 to 255.255.255.255 keep state
pass in quick on $xif inet proto tcp from any to ($xif) port 22 keep state
block in log all

Re:Where are you, Linux?

[rsax]

From the IPF Howto:

We want convenience and security in one. Lots of people do, that's why Ciscos have an "established" clause that lets established tcp sessions go through. Ipfw has established. Ipfwadm has setup/established. They all have this feature, but the name is very misleading. When we first saw it, we thought it meant our packet filter was keeping track of what was going on, that it knew if a connection was really established or not. The fact is, they're all taking the packet's word for it from a part of the packet anybody can lie about. They read the TCP packet's flags section and there's the reason UDP/ICMP don't work with it, they have no such thing. Anybody who can create a packet with bogus flags can get by a firewall with this setup.

I remember ipfw getting actual state features like IPF has. I'm more accustomed to the BSD operating systems so I'm not sure how Linux accomplishes this, does netfilter maintain a state table as well or does it still act like how the excerpt from the IPF howto describes it?

Then use netfilter.. its pretty nice...

In all fairness, IPF and PF seem to have a way better/intuitive syntax compared to iptables. Since we're talking about Linux here, a community which usually considers having more choice when it comes to software a good thing, I think it would be beneficial to have more choice where packet filters are concerned.

Re:Where are you, Linux?

[dirkx]

Are you sure ? (see http://www.benzedrine.cx/pf.html for a nice 'TODO' list for netfilter/ipchains).

Specific things which are 'killer apps' to me are the ease by which you can configure things like blocks/groups of ports, services, machines - and then re-use those in your cluster config or wider rules.

This has safed us many hours of debugging downtime; and allows a much wider new range of 'new sysadmins to be' to deal with the simpler requests; such as adding a machine, service or port,

As it is fairly safe to modify the right table/macros/lists - without having to have a complete understanding of every detail. And yet, when designed by an experienced hand, robust enough not to be bitten by an overly broad side effect.

Have a look at http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/s rc/etc/pf.conf?rev=1.19&content-type=text/plai n - to see good examples.

Dw.

Re:Where are you, Linux?

[Anonymous Coward]

Why make the Linux remarks?
I do find a lot of *BSD people being frustrated with Linux' success, while *BSD seems to be quite obscure...

Seems to me that if that is neccesary, it must be a less fun community.

Re:Where are you, Linux?

[Strog]

It's out

5.0 was released 2 months ago. Even the /. editors know

Re:Where are you, Linux?

[josepha48]

Hmmmm. ipfw has check-state, setup and established. Yes it does keep track of the state as it does have a state table. To see the state table in ipfw use ipfw -d show. To see the state tables in Linux you can look at the /proc filesystem. Not sure if iptables has an actual option for this. Under one of the /proc directories (can't remember which one) it has the state table of all the connections that the kernel knows about.

Truth is that if you want a secure system shutdown your unused services. Use keywords like setup (ipfw) or NEW (iptables) to keep track of new connections. Log new connections, user -j LOG in iptables, 'log' in ipf and ipfw. Not sure what the syntax is in pf. Lastly use ssh over telnet and ftp and REQUIRE shared keys. Webservers are hard to secure, because of 'stray' or possible badly coded cgi. DNS servers should only be run when necessary, or on the internal lan. Use things like ipsec w/ racoon to secure systems so that connection traffic can be encrypted.

Re:Where are you, Linux?

[TheLink]

AFAIK ipf keeps track of the tcp sequence and ipfw doesn't (it does track the tcp port numbers). So while ipfw2 does keep state, I'm not sure you could say it does a great job of it.

With ipfw you have to rely on the O/S getting the tcp sequence right. Which is probably not a problem.

With ipfw you have a certain degree of control when stateful rules are checked- on first stateful rule or on a check-state ruke. With ipf you don't - stateful rules are checked before all other rules. This means with ipf it is harder to shut down selected stateful connections without affecting other stateful connections.

Netfilter? Still immature, and resembles ipchains too much for my liking. It looks significantly uglier too compared to either ipf or ipfw.

The firewalling stuff was one of the major reasons why I picked FreeBSD instead of Linux for my machine (it has to firewall amongst other things).

Re:Where are you, Linux?

[Everlone]

He means the -STABLE branch of the 5.x series, not the tag for 5.0 Release (which would be the RELENG_5_0)

why this is interesting? think high availability

[ubiquitin]

I'm going to take up the challenge here of explaining why this is interesting. Since November of 2002, OpenBSD's pf has had support for load balancing. RedHat's $2499 Premium Edition of their Enterprise distro features Piranha load balancing which was derived from the Linux High Availability project.

So what the OpenBSD pf project is giving you is enterprise-class high availability and load-balance clustering for a tiny fraction of the price. With a handful of cheap dotcom-throw-away x86 servers, a small company or mildly well-capitalized individual can personally build a multi-datacenter-fault-tolerant clustering setup that will rival Fortune 500 uptime ratings.

In other words, the pf project's list of accomplishments is starting to read like a ToDo list for RedHat's Enterprise Linux development team.

And the linux guys say "Huh?"

[Anonymous Coward]

Yes, they are behind the stick, again...

Re:And the linux guys say "Huh?"

[Anonymous Coward]

Somehow I sense some envy here...
Linux has the publicity and the large userbase.
BSD has got the "we are better" attitude...

Posts like this make *BSD look like a frustrated bunch.

*sigh*

[cperciva]

When porting pf was first proposed on the FreeBSD mailing lists, the general opinion was that it would be a Bad Idea. pf may be great, but having two firewalls built into FreeBSD has caused much confusion in the past.

Remember, perfection comes not when there is nothing left to add, but when there is nothing left to take away.

Re:*sigh*

[smnolde]

I use ipfw's DUMMYNET features for traffic shaping and queuing. I also use ipf and ipnat for the hardcore stateful packet inspection and kernel-level NAT. It works great.

But when pf is fully ported with AltQ and tables, I'll only need one packet filter, not two.

I think porting pf to FreeBSD is great. We'll have more options for packet filtering, queuing, bridging interfaces, etc.... besides, there's so much among the BSDs so this benefits everyone.

Re:*sigh*

[Anonymous Coward]

Agreed.

When I started using Linux, ipfwadm was it. It worked well and I was happy with it. Along came ipchains, and I wasn't happy with the idea of converting. So I decided to wait a while and see if it was going to be around a while. In the mean time I tried out FreeBSD and was quite happy with it and ipfw. Along came iptables. I've seen no reason to switch to it. I'll stick with ipfw. Perhaps I'm lazy for not wanting to learn the reinvented wheel, or perhaps I just don't see the benefits of the new wheel.

Re:*sigh*

[Anonymous Coward]

-- Antoine de Saint-Exupery

Re:*sigh*

[davet]

Remember, perfection comes not when there is nothing left to add, but when there is nothing left to take away.

But on the other hand:
If all you have is a hammer, everything starts to look like a nail.

On my part, I like the idea that there's more than one way to do something.

Re:*sigh*

[cperciva]

If all you have is a hammer, everything starts to look like a nail.

Similarly, if all you have is *three* hammers, everything still looks like a nail.

Re:*sigh*

[Ded Bob]

You would not happen to have a simple example of using dummynet along with ipf or know of a good starter doc? I have ipf and ipnat set up the way I like, but I would love to play around with the traffic shaping and queuing.

That article about giving ARP's higher priority sparked my *need* for it. :)

Re:*sigh*

[smnolde]

try this: h tee tee pee //w ww.smnolde.com: 7080/ipfw/ipfw-queue-bw-only (munged to protect my cable connection)

It's a script (that I wrote to do queuing and traffic shaping with DUMMYNEY. I used IPFW2 in the kernel. If you remove any references to esp, then you've got a good place to start.

The script will queue tcp and udp, in, out, or in both directions. Give it a whirl.

- Scott

Re:*sigh*

[Ded Bob]

Give it a whirl.

Thank you. I will.

P.S. You may want to also munge the link just under your name on each post if you want to protect you cable connection.

Woot.

[xA40D]

I've been waiting for this for sooo long.

Alas, it's lagging behind OpenBSD's PF

From the TO DO section of the readme:

merge new features from OpenBSD 3.3 pf
- traffic shaping using ALTQ
- load balancing between multiple routes
- prevention up-link saturation for xDSL users

Re:Woot.

[Strog]

to be fair, 3.3 isn't out yet so the new features are still in current. Give it a little time and we will be rocking.

A new perspective by having it running on other OSes should improve pf and make it better than it already is.

Question

[Quill_28]

This may be a little offtopic as it applies to firewalls and not BSD, bear with me.

Why all the different firewalls programs, do they function differently, perform different functions?
Different target user or target networks?

They all seem to be trying to do the exact same thing? Why the variety?

Re:Question

[overbom]

Yes, they differ in implementation and configurability. FreeBSD's default firewall, ipfw, is pretty easy to set up and configure, and it's pretty powerful. Darren Reed's ipfilter is arcane to set up and insanely powerful. From what I've heard of obsd's pf is that it's pretty easy to set up and insanely powerful.

Most firewalls more or less do the same thing, but the devil is in the details. Some firewalls can do much more than others can, and that's why there are multiple firewalls available. For example, Darren Reed's ipfilter can process packets based on any of the TCP flags in the packet header -- not an option that an entry-level sysadmin wants to have to worry about, although a security expert might be uncomfortable without it.

Most of the firewalls can be set up to do host-based and network-based packet filtering (that's firewalling).

Hope this helps.

Re:Question

[Quill_28]

So for a home network set-up, ipfw should be fine. It is when you want to get down and dirty you might choose ipfilter.

Re:Question

[overbom]

You got it. The thing that is neato-dandy about 'pf' is that it may be suitable for both home networks (ipfw) and down and dirty firewalling (ipfilter/ipf).

Re:Question

[dohcvtec]

ipfilter is arcane to set up
Whatever gave you that impression? Setting up IPFilter is very straightforward. The rules are modeled after spoken sentences - for example:
pass out quick on le0 proto tcp/udp from any to any keep state
What's arcane about that? If you can't figure out what that line is doing, you probably shouldn't be setting up a firewall anyway. pf's rule syntax is based on IPFilter's, and that's a Good Thing. Other than that, pf adds many new and improved features over IPFilter. By the way, FreeBSD's ipfw isn't terribly difficult to set up, but if you're going to call anything arcane, it should be ipfw's syntax, along with Linux's ipchains.

Re:Question

[overbom]

I'm trying to simply address firewall questions to a kid that doesn't know firewalls -- I'm not trying to broadcast my genius here. My impression, having used ipfw on FreeBSD and ipf on Solaris is that ipfw is easier to use for this kid if he's just getting in to firewalls.

Admit it, if he's not a genius with TCP/IP, seeing all the options for blocking on TCP headers are going to scare the heck out of him.

Re:Question

[Quill_28]

kid? hmpf!

Re:Question

[overbom]

Heh. Sorry about that. I, uh, umm...

Quick, look over there! /poof of smoke /runs away

Re:Question

[phoenix_rizzen]

IPF / PF syntax is fairly easy to read, but nowhere near as clear as IPFW. Using your example:

allow tcp from any to any via le0 keep-state
allow udp from any to any via le0 keep-state
(I'm not sure if IPFW supports multiple protocols on a single line.)

I mean, does it get any closer to English than that??

Re:Question

[empath]

In pf:

pass in on le0 inet proto { tcp, udp } from any to any keep-state

Almost, not quite

[Anonymous Coward]

Yes, they are behind the stick, again...

They are always in front of the "stick," bent over & ready to go.

It's dead Jim

[Anonymous Coward]

Subject says it all.