Re: Iptables FTP question

• Previous message: Warren: "Can anyone assist me in setting up a router to run with Bittorrent?"
• In reply to: Peter Eberz: "Re: Iptables FTP question"
• Next in thread: Peter Eberz: "Re: Iptables FTP question"
• Reply: Peter Eberz: "Re: Iptables FTP question"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Fri, 24 Oct 2003 04:07:51 GMT

You would have to check some current documentation to see if RELATED now
includes anything more than just ICMP in the core of it. Otherwise I
think all other related would be from specific modules,the FTP and IRC
modules for example. Initially this is all it included. I suspect newer
modules written to handle protocols that include secondary connections
would or at least could be written to include RELATED support, however
if you don't have any such modules loaded it wouldn't pertain. If you
look at some of the modules they have on the patch-o-matic webpages I
bet you'll find a few that do use RELATED. Keep in mind that connection
tracking in netfilter is for efficiency, if you want to make it "truly"
stateful you can add patch-o-matic modules like the tcp-window-tracking
module (patch-o-matic) which adds sequence number tracking etc. This
module is generally regarded as stable but still experimental(AFAIK) so
check to see if there are still some incompatibilities that would affect
you.

Your rule doesn't work because the "related" ftp traffic will have a
source port of 20 if it is for port mode data connections(for a standard
port 21 ftp server control connection) or would be a random high port if
it were for passive mode data connections. The ftp tracking module looks
at the port commands on the control channel to determine related
traffic. Below shows what is necessary to implement FTP through
connection tracking with some checks on the related traffic. It is not
optimized but shows the possibilities.

For the control connection

iptables -A FORWARD -i $EXTIF -o $INTIF -p tcp --sport 21 -m state
--state ESTABLISHED -j ACCEPT
iptables -A FORWARD -i $INTIF -o $EXTIF -p tcp --dport 21 --sport 1024:
-m state --state NEW,ESTABLISHED -j ACCEPT

For Port Mode Data connections

iptables -A FORWARD -i $EXTIF -o $INTIF -p tcp --sport 20 --dport 1024:
-m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $INTIF -o $EXTIF -p tcp --dport 20 -m state
--state ESTABLISHED -j ACCEPT

For Passive mode data connections

iptables -A FORWARD -i $EXTIF -o $INTIF -p tcp --sport 1024: --dport
1024: -m state --state ESTABLISHED -j ACCEPT
iptables -A FORWARD -i $INTIF -o $EXTIF -p tcp --sport 1024: --dport
1024: -m state --state ESTABLISHED,RELATED -j ACCEPT

You would obviously modify the above to optimize it and account for
using connection tracking with other protocols. Put rules to start NEW
connections for the protocols you allow seperate and then you can have a
single rule ahead of most others for established, and various rules for
new and related depending on what you are allowing overall. Do most of
your parameter checking in your rules that establish new connections and
only what is different for rules that handle related traffic(generally
only ports if you deal with ICMP separately), then your established
traffic, which will be a vast majority of the packets, will run through
netfilter quickly. The connection tracking module has to check the
addresses and ports to find a matching entry in the first place for
established traffic so why do these checks in your rules over and over
again and again.

For example:
iptables -A FORWARD -p tcp -m state --state ESTABLISHED -j ACCEPT
iptables -A FORWARD -i $INTIF -o $EXTIF -p tcp -m multiport -dports
21,25,80,110,443 -m tcp -sport 1024: --syn -m --state NEW -j ACCEPT
iptables -A FORWARD -i $INTIF -o $EXTIF -p tcp --sport 1024: --dport
1024: -m state --state RELATED -j ACCEPT
iptables -A FORWARD -i $EXTIF -o $INTIF -p tcp --sport 20 --dport 1024:
-m state --state RELATED -j ACCEPT

I would also break down your rules into chains instead of appending such
rules directly to the forward chains. Then you can order your rules
within individual chains to tighten access, avoid conflicts and
confusion, and optimize the firewall for the specific protocols that
consume the most bandwidth within your particular network. I generally
put rules in the forward chain that jump to either of two other chains
for incoming or outgoing traffic respectively. Then these chains have
rules to first test(or jump to other chains that test)for specific
security violations that I wish to have done on all packets going in a
specific direction(ie, only allow valid tcp flag combinations), then a
rule to jump to a chain for established/related traffic. The remaining
rules then jump to other chains to handle the new sessions which get
more security checks(spoofed/invalid/disallowed addresses, etc.) that
only need to be done on the initial packets that start new sessions.

> beside others I do have the following modules loaded:
>
> $MODPROBE ip_conntrack
> $MODPROBE ip_conntrack_ftp
> $MODPROBE iptable_nat
> $MODPROBE ip_nat_ftp
>
> My version of IPTABLES is: iptables v1.2.7a
>
> It is not that I do not get it working, I am looking for a way how to
> write a more strict rule.
> I read the documentation you mentioned and I think I understood it.
>
> I am looking for a rule somehow like this:
> $IPTABLES -A FORWARD -i $INTIF -o $EXTIF -p TCP --dport 21 \
> -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
> $IPTABLES -A FORWARD -i $EXTIF -o $INTIF -p TCP --sport 21 \
> -m state --state RELATED,ESTABLISHED -j ACCEPT
>
> Since the RELATED does not match the data connection I removed it from the
> rule and handle the related traffic, which is ICMP via a separate rule.
> Somehow the FTP data connection (to or from port 20 depending on active or
> passive FTP) is not marked as a related packet to the connection
> established from port 21.
> For me it seems that the iptables first checks for the specified protocol
> and source or destination port specified before it continues further
> checking in the state module. Am I right with this assumption?
> When I create the following additional rules.
> $IPTABLES -A FORWARD -i $INTIF -o $EXTIF -p TCP -m state \
> --state RELATED,ESTABLISHED -j ACCEPT
> $IPTABLES -A FORWARD -i $EXTIF -o $INTIF -p TCP -m state \
> --state RELATED,ESTABLISHED -j ACCEPT
> Here I only check for the TCP protocol and not for any ports which is
> matched in this case and RELATED or ESTABLISHED packets will be passed.
> Here the FTP data connection is recognized as related.
>
> I would like to define a more strict rule since the last once allow any
> TCP traffic and not only ftp traffic which is related or established to
> pass.
> Am I to paranoic to define the rules always with source and destination
> port?
> Do I have to give it up when I want to use FTP?
>

• Previous message: Warren: "Can anyone assist me in setting up a router to run with Bittorrent?"
• In reply to: Peter Eberz: "Re: Iptables FTP question"
• Next in thread: Peter Eberz: "Re: Iptables FTP question"
• Reply: Peter Eberz: "Re: Iptables FTP question"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]