[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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\
> >
> > 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

> 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

> 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,
> 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

One is better for keeping state the other seams like it's better for
firewalls.  Programicaly they are identical except when handeling a roug

> 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!

Reply to: