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 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.
>
> 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. :)
>
How could I have missed that. Thans for clearing that up.
> [...]
>
> >>>> 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.
>
You could duplicate the rules in ethere case, AFAIK thay both support all
kinds of rules. Sorry for that copy/paste.
allow tcp from any to any keep-state
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
> 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.
> > 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.
>
It's unclear wathere or not the way "state" or "statefull rules" get
stored is any differant. They do get expresed to the users in the same
way.
> 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.
> 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 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.
>
I get your point, it's how the info is used that's important.
> > 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.
> 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.
>
You have to explicitaly 'icmp keep-state'.
> 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.
>
Ohh, one of FreeBSDs problems is there are too many proc and sys like FS.
'sudo' however is not one of them, try 'pseudo' is also not a FreeBSD FS.
There is no FreeBSD equiv for '/proc/net/ip_conntrack' exept 'ipfw ${args}
|'.
>
> Daniel
> --
> Most people's C programs should be indented
> six feet downward and covered with dirt.
> -- Blair P. Houghton
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
Reply to: