Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Vinod Chandran <vinod_chandran@multitech.co.in>
To: netfilter@lists.netfilter.org
Subject: Dropping in Conntrack during PRERouting/FTP Bounce Attack
Date: Tue, 01 Feb 2005 09:37:04 +0530	[thread overview]
Message-ID: <41FF0068.8030700@multitech.co.in> (raw)
In-Reply-To: Pine.LNX.4.61.0501311608270.13730@willie

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







      reply	other threads:[~2005-02-01  4:07 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-28 15:24 FTP Bounce Attack Vinod Chandran
2005-02-01  0:28 ` dwhite
2005-02-01  4:07   ` Vinod Chandran [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41FF0068.8030700@multitech.co.in \
    --to=vinod_chandran@multitech.co.in \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox