[TriLUG] Re: IPTables help

[Corey Mutter]

> You have this rule on the nonew chain:
> 
> > # New connections are okay on eth1 only
> > iptables -A nonew -m state --state NEW -i eth1 -j RETURN
> 
> And then have this on the INPUT chain:
> 
> > # Anything on eth1 OK
> > iptables -A INPUT -i eth1 -j ACCEPT
> 
> Are these redundant?  I think I would prefer the second
> one so as to keep the nonew chain clean and to just
> make it very explicit that eth1 is a trusted network.

Yes, good catch. I have other redundancies that may make even less
sense, in the parts I cut out. What's probably best is to leave any
interface checking out of "nonew", and conditionally jump to that
chain with an interface check, like:

iptables -A INPUT -i eth0 -j nonew

> Second question.  I assume I can just remove the -s [ip address]
> from the ssh and allow ssh connections from anywhere?

Yes. You also need to put any of those services before
connection-state tracking or the "accept" rules won't get reached. 

> And, finally, is there anything else I need to do to support
> an ftp server setup?  I seem to remember seeing a special module
> for that (and for irc too).  Can you talk a bit about those modules?

You shouldn't need the modules. The FTP/IRC conntrack modules are
there to handle the client side. From a non-passive FTP client, when a
file is about to be transferred, the FTP server opens a data
connection (separate from the control connection on port 21) back to
you. If the client's connection-state-tracking firewall is unaware of
FTP, it will classify the connection as NEW instead of RELATED (and
get dropped). This module lets the connection-tracking tell (from the
presence/data in? the control connection) that the connection back is
related to the FTP session. 

I don't know what IRC does to make connection-state tracking difficult
(by the way, these are all the same things that makes NAT difficult),
but it's probably something like FTP. 

Corey