Re: pf compatiblity w/ other unix OS

[Darren Reed <avalon@coombs.anu.edu.au>]

In some mail from Jedi/Sector One, sie said:
[...]
>   FTP/FXP stateful firewalling.

Is FXP standardised yet? Client in OpenBSD ?

>   IRC stateful firewalling.

Impossible to do securely.  If you thought FTP was bad, wait until you
checkout DCC.

>   SNMP stateful firewalling.

Security Not My Problem...in other words, use the UDP port and stateful
filtering with that, as it is generally a 1:1 send/receive protocol.
Afterall, you should only have read communities enabled.

>   RPC stateful firewalling.

Doable and not uncommon in business cases for firewalls.

>   Talk stateful firewalling.

Extinct ?

>   TFTP stateful firewalling.

Hmmm, maybe.

>   ARP packets filtering.

Not something pf should care about.

>   Stealth matching (matches ports where no server is listening).

This is meant to be a firewall, not some sort of hacker-bait-trap, right ?

>   Substring matching.

Across packet boundaries or just within the packet ?

>   Eggdrop stateful firewalling.

Get an IDS.

>   TOS mangling.

Why ?  Well, I can kinda understand "why" for this...

>   TTL mangling.

Why ?

>   Per-MAC address filtering.

Not a useful function for something which filters IP traffic.

Use your bridge filtering for this or maybe convert that into some sort
of generic layer-2 filtering which could concievably handle a backend
that does ATM filtering (for example).

>   IP options stripping.

If someone puts IP options in, they generally should be there.
If you don't want packets with IP options on your network, block them.
 
>   Static 1:1 mapping.

Took them long enough to catch up :)

>   Hosts pools.

Depending on implementation, can be useful.

>   Very flexible filtering against packet states (invalid, established, new,
> related, snat, dnat, expected status, remaining lifetime...)

Just in case life wasn't complicated enough, lets go make it even more so
and increase the liklihood of a security bug creeping in.

>   Matching against packet lenght and time.

Length ?!  Now being able to allow access to port 80 from 9am to 5pm is
different, but you might want to use "other" methods for that since the
kernel has no concept of what the current time of day is (it runs in GMT),
not to mention DST transitions, etc.

>   Portscan match.

Not something firewalls should be doing.

>   Network quotas.

Look at how filesystem quotas work and tell me if you really think any
sort of network quota should exist within the domain of pf.

>   Random match.

For random security ?

>   Ability to send ICMP unreachable messages from fake IP addresses.

So, did you just look at the list of 'features' in netfilter or did you
go and do your own dreaming ?

Linux isn't considered "one big hack" for nothing.  More than half of the
above items have no place in any sort of "firewall" interface and are more
or less in netfilter/iptables because that's an easy and convienient place
for it to get shoe-horned in rather than designed into the system proprely.

Darren