OpenBSD Packet Filter Ported To NetBSD, FreeBSD 48
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?"
Where are you, Linux? (Score:1)
Re:Where are you, Linux? (Score:5, Interesting)
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? (Score:1)
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
Re:Where are you, Linux? (Score:3, Informative)
Truth is that if you want a secure system shutdown your unused services. Use key
Re:Where are you, Linux? (Score:3, Interesting)
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
Re:Where are you, Linux? (Score:2)
what OpenBSD has created.
Sure it works, but it's much easier with pf.
Re:Where are you, Linux? (Score:2)
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? (Score:1)
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 [netfilter.org], but the best I've seen is stuff like:
iptables -t filter -A INPUT -d $PUBLIC -m state --state INVALID -j
Re:Where are you, Linux? (Score:2)
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
Re:Where are you, Linux? (Score:1)
5.0 was released 2 months ago. Even the
Re:Where are you, Linux? (Score:1)
why this is interesting? think high availability (Score:5, Insightful)
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 [deadly.org]. RedHat's $2499 Premium Edition [redhat.com] of their Enterprise distro features Piranha load balancing [redhat.com] which was derived from the Linux High Availability project [linux-ha.org].
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 [benzedrine.cx] is starting to read like a ToDo list for RedHat's Enterprise Linux development team.
*sigh* (Score:4, Interesting)
Remember, perfection comes not when there is nothing left to add, but when there is nothing left to take away.
Re:*sigh* (Score:3, Interesting)
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* (Score:2)
That article about giving ARP's higher priority sparked my *need* for it.
Re:*sigh* (Score:2)
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* (Score:1)
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.
Re:*sigh* (Score:2, Interesting)
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* (Score:2)
Similarly, if all you have is *three* hammers, everything still looks like a nail.
Woot. (Score:2)
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. (Score:1)
A new perspective by having it running on other OSes should improve pf and make it better than it already is.
Question (Score:2)
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 (Score:3, Informative)
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 examp
Re:Question (Score:1)
Re:Question (Score:1)
Re:Question (Score:2)
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, Fr
Re:Question (Score:1)
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 (Score:1)
Re:Question (Score:1)
Quick, look over there!
Re:Question (Score:1)
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 (Score:1)
pass in on le0 inet proto { tcp, udp } from any to any keep-state