There are at least 2, maybe three reasons active ftp does not work with NAT.
As short explanation:
active ftp works like this:
for this example we download ftp://ftp.kernel.org/pub/README with user anonymous and password guest
> means the server sends something to us,
< means we send something to the server.
On connect the server says hello
> 220 Welcome to ftp.kernel.org.
we send our username
< USER anonymous
and the server asks for the password
> 331 Please specify the password.
we send the password
< PASS guest
server sends its message of the day
> 230-... Welcome to the > 230- > 230-...LINUX KERNEL ARCHIVES > 230-... ftp.kernel.org > 230- > 230-.. "Much more than just kernels" > 230- > 230-. IF YOU'RE ACCESSING THIS SITE VIA A WEB BROWSER > 230-..PLEASE USE THE HTTP URL BELOW INSTEAD! > 230- > 230-----> If you are looking for mirror sites, please go <---- > 230----->.. to mirrors.kernel.org instead <---- > 230- > 230-This site is provided as a public service by the Kernel Dot Org > 230-Organization, Inc. Bandwidth is provided by The Internet Software > 230-Consortium, Inc. This server is located in San Francisco, California, > 230-USA; use in violation of any applicable laws strictly prohibited. > 230- > 230-Due to U.S. Exports Regulations, all cryptographic software on this > 230-site is subject to the following legal notice: > 230- > 230- This site includes publicly available encryption source code > 230- which, together with object code resulting from the compiling of > 230- publicly available source code, may be exported from the United > 230- States under License Exception "TSU" pursuant to 15 C.F.R. Section > 230- 740.13(e). > 230- > 230-This legal notice applies to cryptographic software only. Please see > 230-the Bureau of Industry and Security (http://www.bis.doc.gov/) for more > 230-information about current U.S. regulations. > 230- > 230-Neither the Kernel Dot Org Organization, Inc. nor its sponsors make > 230-any guarantees, explicit or implicit, about the contents of this site. > 230-Use at your own risk. > 230- > 230-This site is accessible via the following mechanisms: > 230- > 230-.FTP..ftp://ftp.kernel.org/pub/ > 230-.HTTP..http://www.kernel.org/pub/ > 230-.RSYNC..rsync://rsync.kernel.org/pub/ > 230- > 230-NFS and SMB/CIFS are no longer available. > 230- > 230-For comments on this site, please contact <ftpadmin@kernel.org>. > 230-Please do not use this address for questions that are not related to > 230-the operation of this site. Please see our homepage at > 230-http://www.kernel.org/ for links to Linux documentation resources. > 230- > 230 Login successful.
the “230 ” indicates the login was successfull, the “230-” just says 'wait, there is more I'm going to send right now, you are not logged in yet, wait before running further commands'.
we ask the server to send the file in binary mode
< TYPE I
server replies he changed to binary mode
> 200 Switching to Binary mode.
the 200 indicates the command was successfull
we request to change the current working directory to pub/
< CWD pub/
server replies he changed the current working dir
> 250 Directory successfully changed.
And this is the line we have been waiting for, the PORT command
< PORT 112,201,131,57,246,26
we will come to its meaning later
server replies
> 200 PORT command successful. Consider using PASV.
we request the readme file getting send to our previous replied address
< RETR README
server sends us the file
> 150 Opening BINARY mode data connection for README (1819 bytes).
Now the ftp server connects the ip address and port we provided and actually uploads us the file.
now he is done sending the file
> 226 File send OK.
we quit
< QUIT
and he says goodbye
> 221 Goodbye.
The line
< PORT 112,201,131,57,246,26
is the problem. the comma seperated values are our ip the server shall connect to, and the port.
On a natted host the host will not know its external address, so he will send something like
< PORT 192,168,0,43,246,26
and the server cant connect this address, as its a private address which is not routed in the internet.
If a natted hosts knows its external ip address, there is still a problem left, the port the server connects the client has to be forwarded by the router to the client.
When using iptables and using standard ftp servers you can rely on the ip_conntrack_ftp and ip_nat_ftp kernel modules, they will monitor the packets on port 21, the default ftp port, and
So this works when using ftp on port 21, but as the kernel modules just monitor the standard ftp port 21, this does not work with malware using some random port for their ftp service.
I have to admit my look at this was not that deep, as the UPnP protocol is not that wide spread, and the Linux UPnP Internet Gateway Device seems dead.
In short, UPnP specifies a protocol where clients can connect the router, and ask for port forwardings in time.
A true nightmare from a security point of view, as the trojan could ask the gateway to forward a port so one can connect the backdoor for doing malicious things, from a users point of view, nice idea, some bittorrent clients have support for UPnP as far as I know.
Some Hardware routers and Windows XP support UPnP, but for me it does not look that wide spread and solid to rely on it.
Such specific solutions turn out to be real problems longterm, so … UPnP got no point here.
Going back to what you read some time ago, there is two problems
shrinking the problem to this size, there is a easy solution without patching kernel modules or digging in the UPnP specs.
We can
So we extended the download-ftp module to use a configuration file with nat settings
download-ftp
{
use_nat "0";
nat_settings
{
dyndns "foobar.dyndns.org"; // the dyndns pointing to your external ip
forwarded_ports ("62001","63000"); // the port _range_ from -> to
};
};
set some forwarding rules in our linux routers iptables
iptables -t nat -A PREROUTING -p tcp -i ppp0 --dport 62001:63000 -j DNAT --to-destination 192.168.53.206
and it works
[ info down handler ] download-ftp nat settings; uses foobar.dyndns.org for external ip and ports 62001->63000 for transfer [ debug down mgr ] Registerd ftp download handler as handler for protocol ftp (3 protocols supported)
When asked to download something via ftp in nat mode, the module will
So, we are looking for testers for this patch, if you run nepenthes behind NAT, and want to give this a shot, please drop us a line.
The reported problem about broken gcc compilers in Ubuntu is fixed in dapper.
According to the docs, dapper is the ubuntu development tree, maybe it will come to the stable tree some day.
Shipping broken gcc versions seems to be a great problem, even cygwin ships with a broken gcc, not to mention this bug stabs nepenthes in the back, it just quits with
Aborted (core dumped)
Even though this 'quit message' is pretty small, google'ing for it helped us verifing the problem is cygwin side, and using gcc 3.3.3 as mentioned on the cygwin mailing lists fixed it without any code changes.
http://64.62.136.189/cygwin@cygwin.com/msg58246.html (as the url contains @, the wiki links it as mailto:// instead of http ...)
I just setup nepenthes on cygwin, and now I'm proud looking at the working active ftp behind NAT.
To my great pleasure some rbot using the name plscd.exe is quite active right now, and … its works, the active ftp natting, and the cygwin build.
[2006-01-30T01:28:13] ftp://1:1@XXX.XXX.28.29:18694/plscd.exe 19f531b289e0a22d3ca7aa6714e65c7b [2006-01-30T01:29:54] ftp://1:1@XXX.XXX.83.180:31096/plscd.exe dfc47fd1034fd759313f2d5ffb81761d
