smithi at nimnet.asn.au
Sat Dec 10 14:36:56 UTC 2016
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 ..
More information about the freebsd-questions