FTP Bounce Attack.

FTP Bounce Attack.

[Vinod Chandran]

Hi,

I am currently using iptables 1.2.11 with the patch-o-matic patch applied.
Its documented that netfilter is patched to  protect against FTP bounce 
attacks, when an invalid IP is given in the FTP PORT command.
I can detect the PORT command reaching the FTP server through the 
router( containing netfilter), even when I give an ivalid IP.
I would like to know whether the patch is not working or whether the 
patch is meant to not allow the resulting bounce attack, even with 
allowing the PORT command to pass through.

Thanks and Regards,
Vinod C

FTP Bounce Attack

[Vinod Chandran]

Hi,

I am currently using iptables 1.2.11 with the patch-o-matic patch applied.
Its documented that netfilter is patched to  protect against FTP bounce 
attacks, when an invalid IP is given in the FTP PORT command.
I can detect the PORT command reaching the FTP server through the 
router( containing netfilter), even when I give an ivalid IP.
I would like to know whether the patch is not working or whether the 
patch is meant to not allow the resulting bounce attack, even with 
allowing the PORT command to pass through.

Thanks and Regards,
Vinod C

Re: FTP Bounce Attack.

[dwhite]

Vinod,

I was able to confirm this (iptables 1.2.11, kernel 2.6.9).  The PORT 
command is indeed forwarded and unmangled, even if NAT is being used for 
the control session.

However, it appears that, while the PORT command is allowed and passed on 
to the server, the resulting "EXPECTING" connection (data channel) is not 
made available.  So in that way the bounce attack is stopped.  It appears, 
by glancing through the code, that this is the intended design.

But, this amounts to only disabling a bounce attack *through* the 
firewall.  It does *not* restrict me from connecting to another device 
*behind* the firewall (or more specifically, to any host on the same side 
of the firewall as the server).

I think this has some significant security implications.  I think you're 
right to raise the issue.

-dave

On Fri, 28 Jan 2005, Vinod Chandran wrote:

> Hi,
>
> I am currently using iptables 1.2.11 with the patch-o-matic patch applied.
> Its documented that netfilter is patched to  protect against FTP bounce 
> attacks, when an invalid IP is given in the FTP PORT command.
> I can detect the PORT command reaching the FTP server through the router( 
> containing netfilter), even when I give an ivalid IP.
> I would like to know whether the patch is not working or whether the patch is 
> meant to not allow the resulting bounce attack, even with allowing the PORT 
> command to pass through.
>
> Thanks and Regards,
> Vinod C
>
>

Dropping in Conntrack during PRERouting/FTP Bounce Attack

[Vinod Chandran]

Hi all ,

Dave,

Thanks for confirming my understanding.

I need PORT command with invalid ip to be dropped. I did certain 
modifications in ip_conntrack_ftp.c, where the checking of the PORT 
command is done , and if its an invalid ip , I return NF_DROP instead of 
NF_ACCEPT.


if (htonl((array[0] << 24) | (array[1] << 16) | (array[2] << 8) | array[3])
        == ct->tuplehash[dir].tuple.src.ip) {
        exp->seq = ntohl(tcph->seq) + matchoff;
        exp_ftp_info->len = matchlen;
        exp_ftp_info->ftptype = search[i].ftptype;
        exp_ftp_info->port = array[4] << 8 | array[5];
    } else {
        /* Enrico Scholz's passive FTP to partially RNAT'd ftp
           server: it really wants us to connect to a
           different IP address.  Simply don't record it for
           NAT. Vinod - Commented the next two lines
        DEBUGP("conntrack_ftp: NOT RECORDING: %u,%u,%u,%u != %u.%u.%u.%u\n",
               array[0], array[1], array[2], array[3],
               NIPQUAD(ct->tuplehash[dir].tuple.src.ip)); */

        /* Thanks to Cristiano Lincoln Mattos
           <lincoln@cesar.org.br> for reporting this potential
           problem (DMZ machines opening holes to internal
           networks, or the packet filter itself). */
        /* Vinod - Commented the next line  and added two lines of code*/
        /*if (!loose) goto out;*/
        DEBUGP("DROP should be done\n");
        printk("Again\n");
        UNLOCK_BH(&ip_ftp_lock);
        return NF_DROP;
    }





This return value is checked in the call ip_conntrack_in ( 
ip_conntrack_core.c), I have modified it so that when the value returned 
is NF_DROP, nf_conntrack_put is called to destroy the conntrack.

if (NF_DROP == ret) {
            /*atomic_set((*pskb)->nfct->master->use,1);
            nf_conntrack_put((*pskb)->nfct);*/
            (*pskb)->nfct->master->destroy((*pskb)->nfct->master);
            (*pskb)->nfct = NULL;
            DEBUGP("Are we here?\n");
            return NF_DROP;


However with all these modifications the packet is still getting 
forwarded, in short never getting dropped. I have seen places in ftp 
helper itself where NF_DROP was getting returned, I wonder if they are 
working too.
I have seen the packets reaching the DROP case in nf_hook_slow, without 
any success.
Is there something that I am missing out or PREROUTING conntrack cannot 
drop packets?

Thanks and Regards,
Vinod C