Disable FTP NAT Helper?

Discussion in 'Tomato Firmware' started by Maniaque27, Oct 14, 2007.

  1. Maniaque27

    Maniaque27 LI Guru Member


    I recently got burned by my router's Active FTP NAT Helper:
    - 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.

    This mechanism can be tested easily with the following site:

    I would like to turn off this "NAT Helper" behaviour, but I cannot figure out where this is configured. I have tried running "iptables --list" in telnet, but the helpers don't seem to show up there (neither the 3 that Tomato already has disable support for ion the UI, nor the FTP Helper that I am looking for).

    Does anyone know enough about iptables / conntrack / netfilter / linux / NAT Helpers to give me any information here?

    I emailed the author before trying the iptables thing, but I don't expect he will have the time to look at my email in a good while, so any help would be appreciated!



    PS for the record here's the email to him, more detailed explanation of the problem than the above post:

    Last week (before I started using Tomato, but the same applies)
    someone accessed a VNC server running on my machine. They actually got
    in because my VNC server was a flawed / vulnerable version where the
    password can be bypassed, but that is not what I am concerned about;
    they should never have reached my VNC Port at all!

    In the meantime I've placed a few posts on newsgroups and learned a
    lot about NAT, and the conclusion I've reached is that the MOST LIKELY
    may that they reached my internal 5900 port (through the router's
    firewall) is by using the FTP NAT Helper trick - from an applet
    running in a browser in a page that I must have viewed, they must have
    "Phoned Home" an Active FTP session request, and their server
    responded with "OK, I'm going to start sending the data on port 5900 -
    open up please!". Trying to be helpful, the router I was using then
    happily obliged, giving the attackers free access to my VNC server.

    I have tested for this with several firmwares on the WRT54G, and so
    far they all exhibit the same behaviour (stock firmware, HyperWRT
    Thibor, and also Tomato 1.10). I thought that one of Tomato's "Disable
    NAT Helper" options must be for this issue, but that doesn't appear to
    be the case because I've disabled all three and the Active FTP Helper
    trick is still working.

    The page I have been using for testing is the following:


    So far the only thing that I have found that stopped access under
    certain circumstances is Thibor's "Filter Port Scanning" option - that
    seemed to kick in to prevent the trick working on the Nth port.

    However now that I've tasted the tomato I don't want to go back! The
    QoS stuff is great, the port forwarding allows you to forward to a
    different port (a feature that is sorely lacking in the stock and
    hyperWRT variants), etc. Tomato is great, but I would love to see this
    security hole filled - not necessarily by default, but at least
    optionally! (is there maybe some command I could run in a script to
    fix this in conntrack / netfilter?)

    Something else that seems strange to me is that even with full logging
    of incoming and outgoing connections, the incoming request on the
    Active FTP return port (in this case 5900) is never recorded... Is
    there any way to fix this?
  2. Maniaque27

    Maniaque27 LI Guru Member

    Update: module not loaded?

    I've kept looking, and the only relevant things I found online are:

    - There is or was a module called "ip_nat_ftp", which may or may not have been related to the issue / functionality that I am describing and trying to disable.

    - In my Tomato (WRT54GL) router, in a telnet session, "lsmod" does NOT show that module loaded, although it does show other nat helpers when I enable them (rstp, h323, pptp, and gre).

    Does that mean that this module has nothing to do with the issue I am describing? Or has its functionality been placed somewhere else now?

    The only relevant thing I found online is this:

    but it seems to suggest that the module would be loaded using insmod, and would therefore show up with lsmod?

    Again, I'm a total linux n00b, so any help / hints / corrections would be enormously appreciated!

  3. Maniaque27

    Maniaque27 LI Guru Member

    I know, answering one's own posts is bad form - but I am quite obscessed with this issue, and can't sleep until I've exhausted all my options.

    I downloaded the source of Tomato, and I think I found something very relevant in the following location:

    It looks like this is where it is decided what will be compiled into the kernel and what will be available as modules... Might it be as simple as changing this "y" to "m" and recompiling the firmware? (and then making sure that it is loaded if / when you want to to be in effect, of course)?

    #   IP: Netfilter Configuration
    # CONFIG_IP_NF_IRC is not set
    # CONFIG_IP_NF_CUSEEME is not set
    # CONFIG_IP_NF_QUAKE3 is not set
    # CONFIG_IP_NF_MMS is not set
    I've never even seen linux source code, never mind firmware-based, and I've scertainly never tried to compile something like this. Rather than banging my head against this any longer, I think I'll ask for help again. Anyone know the answer to the following questions?

    1) Would the simple change I suggested above allow optional loading of the FTP NAT Helper?

    2) Assuming that is the case, what would it take to recompile with this change? Does anyone have the tools / knowledge / experience and is willing?

  4. Maniaque27

    Maniaque27 LI Guru Member

    bump... not sure if I shot myself in the foot by replying to my own posts or whether no-one has any thoughts on the issue...?
  5. Maniaque27

    Maniaque27 LI Guru Member

    Yay, Jon answered my email!

    He will consider making the FTP NAT Helper optional in a future build, much like he did for the three helpers that are already optional.

    In the meantime, he suggests that anyone concerned about this explicitly block incoming traffic to any ports that they never want exposed to outside the network under any circumstances, by placing entries in the firewall script, eg:

    iptables -I FORWARD ! -i br0 -p TCP --dport 5800 -j DROP
    iptables -I FORWARD ! -i br0 -p TCP --dport 5900 -j DROP

    I have done this for all the ports I found open and did not want accessed, and I've confirmed using the above testing tool ( http://bedatec.dyndns.org/ftpnat/test.html ) that it works - the ports now show up as filtered instead of open (and I confirmed that the services still work between hosts within the network)!

    All the best,
  6. mraneri

    mraneri Network Guru Member

    Seems he just did. Tomato 1.11 is out. This option is included.

    THANKS JON!!!!
  7. RonWessels

    RonWessels Network Guru Member

    Let me just chime in here that, despite the vast majority of posts being made by just Tao, I have been watching this thread very carefully. As far as I am concerned, this capability is a very serious breach of firewall security. For example, does anyone have multiple machines behind their routers with shared partitions between them? Well, if you are counting on your router to protect those shares from the outside Internet, think again! Unless your ISP filters out incoming requests to key ports, your shares can be seen if you navigate to the wrong web page. Any browser is vulnerable if you have Java or ActiveX installed and enabled.

    I'll echo my thanks as well, and put in a suggestion that either (a) the FTP NAT helper be restricted to open up only ports >= 1024, or (b) the FTP NAT helper be disabled by default!
  8. Maniaque27

    Maniaque27 LI Guru Member

    Just to confirm, the option works exactly as advertized - I can now remove my custom firewall script, because when testing the Active FTP trick with the URL above the router now tells the remote server to "500 Go away (PORT IP mismatch)".

    Again, thanks for the update Jon!
  9. festering leper

    festering leper Network Guru Member

    i believe there are some legit uses for something like this.. isn't this how STUN for UDP SIP packets works? of course this doesn't stop one from blocking the other ports.... ;)
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice