Date: Sun, 11 Dec 2016 01:36:29 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Polytropon <freebsd@edvax.de> Cc: freebsd-questions@freebsd.org, Warren Block <wblock@wonkity.com>, David Demelier <demelier.david@gmail.com> Subject: Re: FreeBSD Firewalls Message-ID: <20161211001419.B26979@sola.nimnet.asn.au> In-Reply-To: <mailman.107.1481371202.73060.freebsd-questions@freebsd.org> References: <mailman.107.1481371202.73060.freebsd-questions@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In freebsd-questions Digest, Vol 653, Issue 6, Message: 4 On Fri, 9 Dec 2016 19:36:16 +0100 Polytropon <freebsd@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20161211001419.B26979>