iptables rule to block FTP-NAT-Helper-Traffic

iptables rule to block FTP-NAT-Helper-Traffic

Post by Kevin Kempfe » Fri, 28 Nov 2008 00:17:29



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

 
 
 

iptables rule to block FTP-NAT-Helper-Traffic

Post by Pascal Hambour » Fri, 28 Nov 2008 01:34:07


Hello,

Kevin Kempfer a crit :

Quote:

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

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

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

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

 
 
 

iptables rule to block FTP-NAT-Helper-Traffic

Post by Kevin Kempfe » Fri, 28 Nov 2008 02:24:45


Hello,

Pascal Hambourg schrieb:

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

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

Quote:> 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

 
 
 

iptables rule to block FTP-NAT-Helper-Traffic

Post by Pascal Hambour » Fri, 28 Nov 2008 03:18:11


Kevin Kempfer a crit :

Quote:

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

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

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

iptables rule to block FTP-NAT-Helper-Traffic

Post by Andrew Gideo » Mon, 01 Dec 2008 05:24:13



> 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

 
 
 

iptables rule to block FTP-NAT-Helper-Traffic

Post by Mark Hobl » Mon, 01 Dec 2008 07:08:12



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

 
 
 

1. iptables: rule to bypass NAT helper?

I know that it's possible to bypass connection tracking with the NOTRACK
target, but is it possible to just bypass a conntrack and/or NAT helper?

The scenario is this: I have a Linux-based firewall serving multiple
clients. At the moment is has 14 zones. There are several SIP-based VoIP
services in use, and unfortunately one is rather braindead; turn on the
SIP NAT helper and it stops working.

What I'd like to do, is to keep using the SIP conntrack/NAT helper, but
somehow let SIP packets from one particular subnet bypass the helper.

Is this possible?

2. Linux still rocking the business world.

3. NetBIOS with NAT using iptables helper module

4. Linux with Adaptec 2842 VL bus scsi card

5. paranoia computers can -cthulu

6. ftp server iptables rules for passive ftp

7. xitalk, the x based talk interceptor

8. iptables, "established" rule for NFS traffic

9. NAT and Block Incoming IP rule

10. Rules from iptables when using NAT

11. counting traffic to individual hosts behind a NAT router using ONLY iptables

12. NAT/iptables Network traffic monitoring