Re: Iptables FTP question

From: Peter Eberz (peter.eberzNOSPAM_at_gmx.net)
Date: 10/24/03 

Date: Fri, 24 Oct 2003 23:05:54 +0200

On Fri, 24 Oct 2003 04:07:51 +0000, David wrote:

> 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.
The -m helper "ftp" which was suggested by Cedric will propably do what I
am looking for. Since it is in the office 1.2.8 it is likely to be more
reliable. I will check out the tcp-window-tracking as well to see how it
works and if it will do the job.

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

Yes the active FTP is not so tricky. This is only possible to use from
the command line and a few clients like gftp.
No problem for me, but all browers and most FTP clients use passive FTP as
default.

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

Yes, this is an option that is a little bit stricter than mine but not a
lot. I do not want to open a complete port range just for passive FTP to work.
OK this rule protects the priviledged ports but all others are open.
Additionally it conficts with my security policy (just to open the absolut
minimum, no port ranges).

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

Actually my rules looks different then the once I posted. I posted them in
a way that they represent the logic, not the implementation. I am
currently not using multiport matches, this is a good reminder to change
my rules in that way.
>
> 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.
>
Yes, I am actually doing so but I did not want to post here a long script
so I rewrote it to a short set of rules that show my problem.
 
Thanks for the input,
Bye,
Peter

Relevant Pages

  • RE: FTP Window of opportunity?
    ... does it seemingly accept the connections and drop them once the response ... Subject: FTP Window of opportunity? ... blocked by the firewall. ... the FTP port shows up. ...
    (Pen-Test)
  • Re: Iptables FTP question
    ... for secondary connections. ... Some ftp servers don't allow passive mode because it is less safe from ... algs that allow port mode for client machines. ...
    (comp.security.firewalls)
  • Re: vsftp unable to access
    ... I have tried opening up port 20 and 21 on my router and still no luck. ... from the remote site can you do an nmap to make sure the port is ... # loosens things up a bit, to make the ftp daemon more usable. ... # Make sure PORT transfer connections originate from port 20. ...
    (Ubuntu)
  • Re: Iptables FTP question
    ... think all other related would be from specific modules,the FTP and IRC ... Keep in mind that connection ... source port of 20 if it is for port mode data connections(for a standard ... I would also break down your rules into chains instead of appending such ...
    (comp.security.firewalls)
  • Re: Firewalling on FreeBSD
    ... > basically denies all incoming connections, ... For passive ftp, you need to allow outgoing connections to the ftp server on any ... you need to allow incoming connections from the server on port 21 to your box on ...
    (Security-Basics)