FreeBSD Firewalls

[Ian Smith]

In freebsd-questions Digest, Vol 653, Issue 6, Message: 4
On Fri, 9 Dec 2016 19:36:16 +0100 Polytropon <freebsd at edvax.de> wrote:

'scuse me popping in at this point; I have been following the thread.

 > On Fri, 9 Dec 2016 09:03:38 -0700 (MST), Warren Block wrote:
 > > Personally, I'd rather have a system where the firewalls were 
 > > modular and did not have to be in the base.  Then we could have only one 
 > > in base, which would probably be IPFW, and others could be installed 
 > > from ports.  (Yes, this is non-trivial.)

Trying to default users to any one or any other is likely a recipe for 
revolution; people are pretty attached to their firewalls, as ipfilter 
staying in base despite few users, as mentioned, ably demonstrates.

But these are modular already, largely.  The kernel includes the hooks 
discussed below and with some exceptions (like recently mentioned ALTQ 
options for pf being some such) firewalls are usually loaded as modules, 
possibly along with optional bits such as dummynet, ipdivert or ipfw_nat 
for ipfw(8) depending on configuration.  This consumes only tiny amounts 
of kernel space, and costs zero runtime when unused.

 > A situation similar to sendmail or lpr would be nice: A functional
 > component is included in the base system, but the user can still
 > choose to install an alternative from ports and use that instead
 > if he wishes _not_ to use the component supplied with the OS. That
 > doesn't make it less non-trivial, but more appealing. :-)

Well, she doesn't _have_ to enable any firewall now, as above, at zero
cost, unless wanting stripped-down kernel for small or embedded system.

Firewalls have to be tightly integrated with the network stack, to the 
extent that every packet arriving at or leaving a network interface 
examines configured pfil(9) hooks, so that any registered firewall may
be invoked to deal with the packet, in different orders as configured.

So you should be able to use ipfw with dummynet for traffic flow control 
while using pf for filtering, and so forth.  Whether a sort of generic 
pfil_hook handler could be added to enable arbitrary firewalls to be 
easily added, in specified orders vs other hooks, I don't know.  Such an
idea may invoke some, er, interesting discussions in freebsd-security@

Parts of firewalls can run in userland, such as configuration, reporting 
and management, but core filtering functions are running in kernel mode, 
much more so than mail or print, or name or time servers and others that 
can now be optionally chosen from ports.

As for one or t'other of pf, ipfilter or ipfw .. I think it's pretty 
much a matter of style and suitability for application according to both 
physical net circumstances and personal inclination of the sysadmin.

In my view of pf and before it, ipfilter which has a similar syntax - 
neither one of which I've used, I hasten to add - express configuration 
more in a higher level, more abstract language, whereas ipfw rulesets 
are much more like an assembly language; entirely linear and procedural, 
first match wins, which rules generate virtual machine instructions that 
kernel code executes sequentially.  For we old assembler hackers, this 
approach is hard to beat :) but most people these days prefer to get as 
far away from the hardware as possible.  Hence, "it depends" :)

Just a thought bubble or two ..

cheers, Ian