Re: fw on linux and freebsd
On 3 Jul 2004, Mike Mestnik wrote:
> --- Daniel Pittman <daniel@rimspace.net> wrote:
>> On 1 Jul 2004, Mike Mestnik wrote:
>>> --- socrel@gmx.net wrote:
>>>>
>>>> Looking for considered comparisions of firewalling on Linux and
>>>> FreeBSD.
>>>
>>> FreeBSD let's you respond to 'blocked' ports in ""exactly"" the same
>>> way 'closed' ports are. Linux has higher moral standerdes as in the
>>> developers refuse to add this feature on there religious grounds.
>>
>> I am bemused by this claim, since it is untrue to the best of my
>> knowledge. Which protocols do you believe are unable to supply a full
>> protocol-compliant NAK?
>>
>> Possibly you mean to say:
>>
>> Linux does not support generating a protocol "closed port" message
>> that appears to originate from a device behind the firewall
>>
>> Otherwise, you can certainly provide the standard protocol NAK
>> response for all the widely used protocols, to the best of my
>> knowledge.
>
> http://lists.netfilter.org/pipermail/netfilter/2000-May/003863.html
> It's a long outstanding feature request "TCP-RST" vs icmp-unreachable.
iptables v1.2.9, at least, and for at least the last few years that I
recall, support this:
iptables ... -j REJECT --reject-with tcp-reset
It is still possible to determine if this reset was generated by the
firewall or the target device in some cases, since this is a simulated
rather than real RST, but it is certainly a full TCP RST. :)
[...]
>>>> I am especially interested in learning about ease of connection
>>>> tracking
>>>
>>> There is no *inner workings* documantation on ether side and it's
>>> difficult to see how each **workes** for a comparasen.
>>
>> Both systems are equally capable of "easily" providing an active
>> firewall using some form of connection tracking. This can be as trivial
>> as a single line in both, as I understand it.
>
> I'm not realy sure if this is true of Linux, let me take a stab at it.
> iptables -A FORWARD -i $IFACE+ -m state --state\
> ESTABLISHED,RELATED -j ACCEPT
>
> In FreeBSD it's something like...
> allow tcp from any to $Webserver_A http setup keep-state
>
> I would have to say the latter is much cleaner.
ipf certainly seems to have a slightly higher level "raw" form than
iptables, in that you specify the return packet rules in the same
command as the initial connection rules.
That said, you don't need to match 'RELATED' packets in that rule at
all, and you don't need to specify the interface unless you want to.
> The internal workings also seam tobe better... On mach a new rule to
> allow the next pkt in is created(In a kernel prival table). Maby this
> is just a psudo rule based on a connection tracking stuct, like what
> Linux seams to provide.
>
> This is all conjectour on my part, with out docs it's hard to say.
Well, Linux uses an explicit rule and a kernel managed "is this part of
an existing connection" flag. The difference is minor, I think, in
practical terms, since they both have to maintain the same state.
Also, it is worth noting that you don't *have* to use a blanket
"connection tracking" rule with iptables -- you can make it as targeted
as you like, and probably should for security reasons.
My firewall, for reference, allows connections that match the expected
port ranges *and* are part of an existing connection, for each protocol.
> I just like the religion...
> FreeBSD: We skip the whole CT bit and go right on to what is important.
> We see X1 the next thing we will see is X2.
> Is what we see X2?
...but they *do* expire those "keep state" rules eventually, right?
In which case they are tracking the connection, but use a different type
of accounting structure to store it in. No other difference.
> Linux: Lookes like alot of state for a simple concept.
> We see X1 this socket is now in state Y.
> We now see X2, is this valid for state Y?
There are four states with the Linux code for *any* packet, NEW,
ESTABLISHED, RELATED and INVALID. Well, and 'UNTRACKED' with a very
recent iptables.
Of these, 'NEW' and 'ESTABLISHED' are the two key states for a packet.
'RELATED' is a way of making it easy to permit ICMP responses to
established connections, and not to anything else.
I don't know if ipf does that sort of filtering as part of keep-state,
but I presume it must -- otherwise you need to blanket accept ICMP
errors, and open yourself to a (difficult) DoS through forged ICMP
errors.
At the end of the day, most of the state is exposed for completeness,
not because it is widely used.
This does make it marginally more complex for the end user, but it also
marginally increases flexibility...
Other than the possible difference in handling 'RELATED' packets, both
systems are tracking the same state entirely...
[...]
>>> Sticking to the OS's own book keeping should be your goal. In Linux
>>> this means text files in sudo FS.
>>
>> I am not at all clear what you mean by as "sudo FS", but iptables
>> supports logging rule matches via the kernel log mechanism and, thus,
>> through syslog.
>
> That's what I'm talking about, reading the state. "sudo FS" == "proc
> FS".
Ah. That is presumably a BSD term that I am not familiar with. Thanks
for clarifying that.
>> It also supports the "userspace log daemon" protocol, allowing
>> applications to be sent packets for review and logging. The 'ulogd'
>> package supports logging to files and databases out of the box, and
>> should be a good basis for adapting a Linux specific packet capture
>> solution.
>
> Dose FreeBSD have this?
I don't know, sorry. I wouldn't be surprised to find that it did, since
they have generally the same capabilities as Linux, though.
Daniel
--
Most people's C programs should be indented
six feet downward and covered with dirt.
-- Blair P. Houghton
Reply to: