Re: status (plans?) of latest *BDS's ipfw2 for OSX/Darwin kernel?
Re: status (plans?) of latest *BDS's ipfw2 for OSX/Darwin kernel?
- Subject: Re: status (plans?) of latest *BDS's ipfw2 for OSX/Darwin kernel?
- From: OpenMacNews <email@hidden>
- Date: Sat, 22 Nov 2003 18:31:57 -0800
Although there, of course, many resources, here's a quick <snip> from the FreeBSD man page (obviously NOT the Darwin
man pg ...) summarizing the ipfw --> ipfw2 diffs ...
<
http://www.kerneled.com/doc/man/freebsd/man8/ipfw.html>
IPFW2 ENHANCEMENTS
This Section lists the features that have been introduced in ipfw2 which
were not present in ipfw1. We list them in order of the potential impact
that they can have in writing your rulesets. You might want to consider
using these features in order to write your rulesets in a more efficient
way.
Handling of non-IPv4 packets
ipfw1 will silently accept all non-IPv4 packets (which ipfw1 will
only see when net.link.ether.bridge_ipfw=1). ipfw2 will filter
all packets (including non-IPv4 ones) according to the ruleset.
To achieve the same behaviour as ipfw1 you can use the following
as the very first rule in your ruleset:
ipfw add 1 allow layer2 not mac-type ip
The layer2 option might seem redundant, but it is necessary --
packets passed to the firewall from layer3 will not have a MAC
header, so the mac-type ip pattern will always fail on them, and
the not operator will make this rule into a pass-all.
Address sets
ipfw1 does not supports address sets (those in the form
addr/masklen{num,num,...} ).
Port specifications
ipfw1 only allows one port range when specifying TCP and UDP
ports, and is limited to 10 entries instead of the 15 allowed by
ipfw2. Also, in ipfw1 you can only specify ports when the rule
is requesting tcp or udp packets. With ipfw2 you can put port
specifications in rules matching all packets, and the match will
be attempted only on those packets carrying protocols which
include port identifiers.
Finally, ipfw1 allowed the first port entry to be specified as
port:mask where mask can be an arbitrary 16-bit mask. This syn-
tax is of questionable usefulness and it is not supported anymore
in ipfw2.
Or-blocks
ipfw1 does not support Or-blocks.
keepalives
ipfw1 does not generate keepalives for stateful sessions. As a
consequence, it might cause idle sessions to drop because the
lifetime of the dynamic rules expires.
Sets of rules
ipfw1 does not implement sets of rules.
MAC header filtering and Layer-2 firewalling.
ipfw1 does not implement filtering on MAC header fields, nor is
it invoked on packets from ether_demux() and
ether_output_frame(). The sysctl variable net.link.ether.ipfw has
no effect there.
Options
The following options are not supported in ipfw1
dst-ip, dst-port, layer2, mac, mac-type, src-ip, src-port.
Additionally, the following options are not supported in ipfw1
(RELENG_4) rules:
ipid, iplen, ipprecedence, iptos, ipttl, ipversion, tcpack,
tcpseq, tcpwin.
Dummynet options
The following option for dummynet pipes/queues is not supported:
noerror.
OpenBSD's (Danielt Hartmeier's) pf is really quite neat.
Loadable kernel modules aside (yeah yeah, I know the old argument that securelevel is a one-way spinlock, and we've
seen the exploits that disprove that), it's well-implemented piece of software.
Some of the finer points that really make it nice are the scrubbing features (dealing with duplicate IP fragments
with overlapping data), the ability to compensate for weak TCP ISNs when acting as a NATting system, queueing, anchor
points for externally generated rules, useful counters....
Rather than go on with glittering generalities, I think I'd like to familiarize myself better with ipfw2 (I haven't
looked at it at all, to be honest).
Hartmeier's pf has some support for sharing nat and filter states among systems (though I'm not sure how advanced
this is at the moment. I think it uses a pseudo device). It can operate in a routing fashion or in a bridging
fashion too which is quite handy. Just like Darren Reid's ipf, Hartmeier's pf uses a configuration file (using a
yacc parser), as opposed to the ipfw/iptables/ipchains method of using the binary for all configuration -- yes, I've
seen the iptables restore format and it's a lot closer to making it maintainable.
- -Jeff
P.S. I sent in a kernel patch to this list a few days ago and never saw it make the list, is anyone else having
problems sending messages to the list?
i could've sworn it "ate" one reply that i have yet to see ...
P.P.S. I submitted the same patch to Apple's patch form and actually received a bounce! (The submission page is a web
form).
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.