IPFW or PF?

Hi,

Probably this question has been asked already, but I can't find it here - too many hints. I have a production server that does not need to do NAT. It would be good to have a kind of DOS protection against clients that send too many requests (to slow them down). The external link is 100 Mb. Do these two types of FW firewall equally do this? Which one is preferable?

Thanks,

Vadim.
 
I have used both and I have to say IPFW has a few more capabilities like L2 filtering but it's quite hard to get it to do what you want because the whole rule formalism is very ad-hoc compared to the elegance of PF. Just to get stateful filtering with outbound NAT you have to resort to rule structures that resemble the classic don't-do-this spaghetti code with GOTO-statements.
 
vadimk said:
Hi,

Probably this question has been asked already, but I can't find it here - too many hints. I have a production server that does not need to do NAT. It would be good to have a kind of DOS protection against clients that send too many requests (to slow them down). The external link is 100 Mb. Do these two types of FW firewall equally do this? Which one is preferable?

Thanks,

Vadim.

PF on OpenBSD in general as a firewall solution but if you must use FreeBSD for firewall IPFW would be a natural choice. PF is not really portable software and the version which comes with FreeBSD is obsolite.
 
Oko said:
vadimk said:
Hi,

Probably this question has been asked already, but I can't find it here - too many hints. I have a production server that does not need to do NAT. It would be good to have a kind of DOS protection against clients that send too many requests (to slow them down). The external link is 100 Mb. Do these two types of FW firewall equally do this? Which one is preferable?

Thanks,

Vadim.

PF on OpenBSD in general as a firewall solution but if you must use FreeBSD for firewall IPFW would be a natural choice. PF is not really portable software and the version which comes with FreeBSD is obsolite.

It uses the older (OpenBSD 4.5 I think?) syntax but internally it has many improvements over the original implementation. For example on FreeBSD 10 it is no longer locked to a single core but can fully make use of multiple cores.
 
kpa said:
Oko said:
vadimk said:
Hi,

Probably this question has been asked already, but I can't find it here - too many hints. I have a production server that does not need to do NAT. It would be good to have a kind of DOS protection against clients that send too many requests (to slow them down). The external link is 100 Mb. Do these two types of FW firewall equally do this? Which one is preferable?

Thanks,

Vadim.

PF on OpenBSD in general as a firewall solution but if you must use FreeBSD for firewall IPFW would be a natural choice. PF is not really portable software and the version which comes with FreeBSD is obsolite.

It uses the older (OpenBSD 4.5 I think?) syntax but internally it has many improvements over the original implementation. For example on FreeBSD 10 it is no longer locked to a single core but can fully make use of multiple cores.

PF depends on OpenBSD network stack which is very different from FreeBSD network. While getting PF to work on multi cores on FreeBSD is an admirable attemt to add the features which will eventually be added to the real PF the fact remains that IPFW is only native firewall for FreeBSD. As an OpenBSD users I would certainly welcome native PF like syntax implementation of new firewall on FreeBSD. Updating PF on FreeBSD is I am afraid lost battle due to PF design.
 
Does that mean PF has flaws at FreeBSD implementations or it just have less features than one at OpenBSD? From your words I understood, that PF was ported to FreeBSD and it's development under FreeBSD is not going well ?
 
vadimk said:
Does that mean PF has flaws at FreeBSD implementations or it just have less features than one at OpenBSD? From your words I understood, that PF was ported to FreeBSD and it's development under FreeBSD is not going well ?
Development is going excellent, just look at the changes in PF on FreeBSD 10.0. But you have to keep in mind that FreeBSD used the PF from an older version of OpenBSD. It's not the latest version we have.
 
I am not so mature to benefit from the latest PF version in use. Features that I use right now at 10 are enough for me. More important is to have stable version that is still going to be improved. If there is plan to support PF at FreeBSD - it is OK.
But thank you for comments - in a case I feel PF is old for me - can look into alternative distribution. :h
 
Pf might be developing rapidly but that doesn't change the fact that is a rapid development of the 5 year old version of pf which had so many new features and optimization added in the mean time on OpenBSD. I am afraid that this time NetBSD guys got it right by developing new firewall from ground up optimized for mult threading.
 
I am afraid that this time NetBSD guys got it right by developing new firewall from ground up optimized for mult threading.
Not necessarily. Quite often this development of new software meant to replace the old but working one ends up in product that doesn't do the same old job much better than the old one does it -- though it may have some "new features"... and always a bunch of bugs to fix. And then... some people still use IPFW and prefer it over everything else, as you can see.
 
Multithreading hasn't been shown to be that benefical for packet filtering. Sure, some of the load can be spread over multiple cores if you have multiple interfaces but you very quickly run into a wall because the incoming packets have a natural order and you can't process any of them out of order because in TCP for example there are sequence numbers and you can't break the bounds set by them.
 
I think that PF would be a better option for the situation, when some your server wants to add quickly and effectively a long list of IPs to block temporarily, i.e. for 3 hours or so and later drop it. This could happen during something like DDoS attack, if I'm not mistaken, is it right? However, IPFW has a better and clear syntax, suitable for shorter rules.
 
This could happen during something like DDoS attack, if I'm not mistaken, is it right?
Think of your internet connection as a funnel. Think of a DDoS as someone that fills that funnel faster than it can empty at the bottom. As a result the funnel starts to overflow. Even if you put your finger on the bottom hole (closing your local firewall) the funnel would still be completely full and overflow.
 
I think that PF would be a better option for the situation, when some your server wants to add quickly and effectively a long list of IPs to block temporarily, i.e. for 3 hours or so and later drop it.

I must say I started off with IPFW and stayed with it, never used PF. But I think it is easy to do this with IPFW with the "table" construct: a table can hold an arbitrary number of IPs and can be changed dynamically at any time, without touching any rules.

The other statement further above, that IPFW tends to create spaghetti code: indeed I see many people starting to write IPFW rules and then creating more and more of spaghetti (which I think is very dangerous because one must be able to logically verify a firewall).
I think this is mostly caused by conceptional mistakes: people tend to think of a firewall as a "wall", which implies that it has exactly two sides (an inside and an outside), and then they know they want to block certain traffic and start to code from that point onwards.

I achieved better results by first understanding where in the system IPFW sits and how it works, and then devising some primitives to handle e.g. statefulness, nat, forwarding, etc in a general way.
The desired rules can then be written in a pseudocode and automatically converted into the proper IPFW commands: no problems, no spaghetti, and no need to even look into the actual rules.

As an example, for statefulness I use such a construct (assuming that incoming and outgoing flows have already been properly separated):
Code:
/sbin/ipfw add 1350 set 16 call 65525 all from any to any
/sbin/ipfw add 65525 set 16 count tag 1 tcp from XXXXX to YYYYY setup keep-state :f13rd
/sbin/ipfw add 65526 set 16 return all from any to any
/sbin/ipfw add 1360 set 16 ACTION1 untag 1 all from any to any tagged 1
[...]
/sbin/ipfw add 380 set 16 call 410 all from any to any
/sbin/ipfw add 390 set 16 ACTION2 untag 1 all from any to any tagged 1
/sbin/ipfw add 400 set 16 skipto 430 all from any to any
/sbin/ipfw add 410 set 16 check-state :f13rd
/sbin/ipfw add 420 set 16 return all from any to any
 
The other statement further above, that IPFW tends to create spaghetti code: indeed I see many people starting to write IPFW rules and then creating more and more of spaghetti (which I think is very dangerous because one must be able to logically verify a firewall).
It's usually just bad organization. I've seen this happen with any and all firewalls I've ever managed, not just the software ones from FreeBSD. Even something like Checkpoint's Firewall/1 (which had a really nice GUI) can result in an extremely disorganized mess if it's not managed properly.
 
You guys have inspired me to study IPFW. Up to now I thought it was archaic, but your comments seem to make it worth looking into. Thankfully, I"ve found some interesting paper about it.
 
Great. :)
Maybe that's correct, it is somehow 'archaic', in a way that there is no full-featured GUI ready to employ.
But then it is also archaic in a way so that you could easily write such a GUI for your specific purposes and attach it, and that would perfectly work.

(I started to write such a GUI recently - it now sits somewhere half-ready on my webserver, after I got bored fighting the bootstrap CSS stuff...)
 
Great. :)
Maybe that's correct, it is somehow 'archaic', in a way that there is no full-featured GUI ready to employ.
But then it is also archaic in a way so that you could easily write such a GUI for your specific purposes and attach it, and that would perfectly work.

(I started to write such a GUI recently - it now sits somewhere half-ready on my webserver, after I got bored fighting the bootstrap CSS stuff...)
That's it, getting bored with it... that's why I only get to learn things when there's a real application for my needs. BTW, they promised bootstrap 4 would be better.
 
Back
Top