iptables rule to block FTP-NAT-Helper-Traffic

Discussion in 'Linux Networking' started by Kevin Kempfer, Nov 26, 2008.

  1. Hi everybody,

    I just got aware of the FTP-NAT-Helper security problem. Here's what
    happens:

    - I visit a page with a hostile java applet
    - the applet calls home with what seems to be a legitimate FTP session
    - the remote server responds with "sure, I'll send that data on port
    5900" (which just happens to be the standard VNC port)
    - the router opens port 5900 for that remote host to this local host,
    and that remote host now has access to a local port that it should not.

    (dicussed here: http://www.linksysinfo.org/forums/showthread.php?t=54999)


    Is there a way to block this kind of traffic? I tried some standard
    linux firewall GUIs (firestarter, gufw, guarddog) but none of them
    produced rules that block the evil traffic. Tested it using
    http://bedatec.dyndns.org/ftpnat/test.html

    It still shows open ports which should not be reachable from outside my
    network.

    What can I do to block that traffic?

    Thanks,

    Kevin
     
    Kevin Kempfer, Nov 26, 2008
    #1
    1. Advertisements

  2. Hello,

    Kevin Kempfer a écrit :
    Here is the actual security problem.
    Actually it's the local FTP client which chooses and tells the remote
    server which port to connect to. This happens in active mode only. In
    passive mode, the server tells the client which port to connect to.
    Sure. As I wrote, the security problem happens only with FTP active
    mode, so you can block active mode data connections, which are incoming
    connections. You can identify packets related to the FTP conntrack/NAT
    helper with the "helper" match.

    iptables -A FORWARD -i external_interface -m state --state RELATED \
    -m helper ftp -j DROP

    In order to be effective, this rule must be placed before the general
    "-m state ESTABLISHED,RELATED -j ACCEPT" rule.

    For a more fine-grained filtering, you can also DROP FTP-related
    connection attempts to ports ranges that you know are used by other
    applications.

    Even simpler : DROP incoming packets to ports you don't want to be open
    from the internet before the general state rule.

    Anyway, is this really efficient ? Couldn't the hostile applet just
    connect locally to the VNC port and relay the communication with the
    hostile server ?
     
    Pascal Hambourg, Nov 26, 2008
    #2
    1. Advertisements

  3. Hello,

    which I have in mind, but I cannot stop all users on my network to use java.
    Isn't this to be done on the router? As I don't have access to the
    router, I would like to secure my own machine against this attack. What
    I need is a rule which is running locally on my computer. Is there still
    a helper match?
    Sure, it could, but it isn't as trivial as it is now ;)

    Thank you!

    Kevin
     
    Kevin Kempfer, Nov 26, 2008
    #3
  4. Kevin Kempfer a écrit :
    Oh, I didn't understand that. Well, you can use this kind of rule in the
    INPUT chain of your local machine too, before the general state rule.
    This depends on your setup. "iptables -m helper -h" will tell if the
    match is supported by the installed iptables, and "grep MATCH_HELPER
    /boot/config-$(uname -r)" will tell if it is supported by the running
    kernel. The FTP conntrack helper module ip_contrack_ftp or
    nf_conntrack_ftp must be loaded. Actually, if the FTP conntrack helper
    module is not loaded on your local machine and the firewall drops
    incoming NEW connections, your machine is not at risk. Of course this
    means you cannot use FTP active mode either.
     
    Pascal Hambourg, Nov 26, 2008
    #4
  5. Alternatively, why bother using FTP for this? Could the applet not open
    a connection from the local machine's port P to some specified port on
    the malicious remote server? That remote/malicious server could then
    connect to port P on the victim machine from that specific port. This
    should work for any port P greater than 1024 and for either UDP or TCP.

    I can envision a way to prevent this for TCP: Add to the
    ESTABLISHED,RELATED rule logic which blocks a SYN w/o the ACK. But I'm
    not sure how one could prevent UDP from sliding through in this attack.

    - Andrew
     
    Andrew Gideon, Nov 29, 2008
    #5
  6. Kevin Kempfer

    Mark Hobley Guest

    Is there a particular reason that they need to run Java applets?

    Java is insecure by design IMHO.

    I would just filter this out using some sort of dynamic page modifying
    filtering proxy system like proximodo to remove the Java related
    content, and make sure all clients can only connect to the world wide
    web via this proxy.

    If your users need specific Java applets, there could be a pool of
    approved applets hosted locally.

    Mark.
     
    Mark Hobley, Nov 29, 2008
    #6
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.