All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.