iptables rule to block FTP-NAT-Helper-Traffic

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/sh...ad.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

Hello,

Kevin Kempfer a écrit :
>
> I just got aware of the FTP-NAT-Helper security problem. Here's what
> happens:
>
> - I visit a page with a hostile java applet

Here is the actual security problem.

> - 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)

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.

> - 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.

Right.

> Is there a way to block this kind of traffic?

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 ?

Hello,

Pascal Hambourg schrieb:
>> - I visit a page with a hostile java applet
>
> Here is the actual security problem.

which I have in mind, but I cannot stop all users on my network to use java.

>> Is there a way to block this kind of traffic?
>
> 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.

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?

> 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 ?

Sure, it could, but it isn't as trivial as it is now

Thank you!

Kevin

Kevin Kempfer a écrit :
>
> Pascal Hambourg schrieb:
>>
>> 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.
>
> Isn't this to be done on the router?

Yes.

> As I don't have access to the
> router, I would like to secure my own machine against this attack.

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.

> What
> I need is a rule which is running locally on my computer. Is there still
> a helper match?

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.

On Wed, 26 Nov 2008 17:34:07 +0100, Pascal Hambourg wrote:

> 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 ?

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

Kevin Kempfer <(E-Mail Removed)> wrote:

> which I have in mind, but I cannot stop all users on my network to use java.

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
Linux User: #370818 http://markhobley.yi.org/