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