Re: fw on linux and freebsd
On 3 Jul 2004, Mike Mestnik wrote:
> --- Daniel Pittman <daniel@rimspace.net> wrote:
>> On 3 Jul 2004, Mike Mestnik wrote:
>>> --- Daniel Pittman <daniel@rimspace.net> wrote:
>>>> On 1 Jul 2004, Mike Mestnik wrote:
>>>>> --- socrel@gmx.net wrote:
[... iptables vs ipf ...]
>> 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.
>>
> ??? I'm puzzeled again ???
> I was allways trying to setup non-passive FTP by using related.
I wasn't quite clear there - you don't *need* to match 'RELATED' packets
if you don't want to, but you usually do.
For active FTP, IRC and a handful of other protocols with in-kernel
support, 'RELATED' can match additional connections that are part of the
protocol by inspecting the content.
For, say, HTTP, 'RELATED' is only any ICMP error related to that
connection.
Sorry, I should have said that in the first place.
[...]
>> 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.
>
> Then you miss the related FTP connections, if it's even posible to track
> them.
No, you just need a targeted 'RELATED' match, like this:
iptables -A INPUT -p tcp --sport 20 --dport <local range> \
-s <internet> -d <my IP>
-m state --state RELATED
That would allow any specifically related FTP data connection back if:
* it comes from the right source port
* it is going to a legal destination port
* it comes from the internet, etc
* it is part of an existing FTP session
This prevents, for example, the trick of sending a 'PORT' command
through the FTP connection and having that fool the firewall into
opening any random port you feel like talking to. :)
>> My firewall, for reference, allows connections that match the expected
>> port ranges *and* are part of an existing connection, for each protocol.
>
> If you don't accept all related icmp? You can miss some valid state.
I was referring to the ability to limit the 'connection tracking' stuff
as per the FTP example above, not about limiting ICMP specifically.
It is true that you can miss some errors by limiting it to 'expected
ICMP' rather than 'any ICMP'; for a brief period I had issues when my
employer had a FreeBSD firewall with a bug that would byte-swap some
fields in the "original packet" part of an ICMP dest-unreachable packet.
The connection tracking system would then reject that ICMP as invalid
because it could not match up the ICMP content with the original
session.
I have not encountered this in the wild in quite some time, though.
>>> 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?
[...]
>>> 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.
>>
> Umm, netstat(8) under State I.E. SYN_RECV. Next packet is a sent ACK, is
> it not better to say that "There will be an ACK" vs "There has been a
> SYN"?
>
> One is better for keeping state the other seams like it's better for
> firewalls. Programicaly they are identical except when handeling a roug
> FIN.
Ah, now I see what you were driving at. I agree - there is a difference
in policy there. In practice, I don't believe it makes any difference,
but thank you for explaining it.
Daniel
--
If you think of yourselves as helpless and ineffectual, it is certain
that you will create a despotic government to be your master.
-- Frank Herbert, _Dune_
Reply to: