Re: fw on linux and freebsd
--- Daniel Pittman <daniel@rimspace.net> wrote:
> 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 ...]
>
> >> 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. :)
>
It's also worth noting that some public FTP servers may not use sport 20.
I agree that these servers are as broken as thoes sites that don't yet
allow the use of TCP_ECN, but thay may exist in grate numbers.
> >> 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.
>
Once again broken systems should not be supported. In this case I would
say that thay must not be supported. For local security's sake and since
this is uncommon.
> >>> 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.
>
I have fully enjoyed this thread, thank you for exchanging your ideas.
Mike
> 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_
>
>
> --
> To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
>
>
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail
Reply to: