FTP Bounce Attack.

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

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

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
          <[email protected]> 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