DSM-G600, DNS-3xx and NSA-220 Hack Forum

Im still looking for help here.  When I ran a windows-based FTP server I was able to specify a port ranger for the ports used after a connection is established .. with the DNS-323 there is no such setting, so is it hard coded to something?

The following is available in 1.01 FW variant of ftpaccess:

passive  ports  0.0.0.0/0    65501   65510

If essence, this means that you need to open up 65501-65510 in your router.

Partly relevant findings in wu-ftpd configurations:

The file /etc/ftpconversations is not setup properly as it refers to non-existent files:

:.Z:  :  :/bin/compress -d -c %s:T_REG|T_ASCII:O_UNCOMPRESS:UNCOMPRESS
:   : :.Z:/bin/compress -c %s:T_REG:O_COMPRESS:COMPRESS
:.gz: :  :/bin/gzip -cd %s:T_REG|T_ASCII:O_UNCOMPRESS:GUNZIP
:   : :.gz:/bin/gzip -9 -c %s:T_REG:O_COMPRESS:GZIP
:   : :.tar:/bin/tar -c -f - %s:T_REG|T_DIR:O_TAR:TAR
:   : :.tar.Z:/bin/tar -c -Z -f - %s:T_REG|T_DIR:O_COMPRESS|O_TAR:TAR+COMPRESS
:   : :.tar.gz:/bin/tar -c -z -f - %s:T_REG|T_DIR:O_COMPRESS|O_TAR:TAR+GZIP
:   : :.crc:/bin/cksum %s:T_REG::CKSUM
:   : :.md5:/bin/md5sum %s:T_REG::MD5SUM


I.e., functions COMPRESS, UNCOMPRESS doesn't work either for .Z or .gz files. Neither does CKSUM and I doubt that MD5SUM works properly. But, I guess these are old bastards that no longer is being used - at least not in a home NAS.

But; if D-Link scans this forum - here's a message: The DNS-323 is not properly setup when it comes to ftp. You're missing a bunch of files (cksum, gzip and compress).

Another interresting finding is that the ftp deamon is setup to allow FXP. This is good for those who enjoys FXP (site-to-site) transfers, but bad for the ones wanting a strict system:

pasv-allow all *


Well, that's all for now.

Ok, it doesn't work out of the box using PASV. I can confirm this as I've now tested this but the problem can be resolved. The solution is obvious, but you need to understand why it is a problem.

The problem relates to NAT'ed addresses. IPv4 servers really shouldn't be behind NAT as it'll ruin their protocol. The ftp protocol was not written for NAT'ed devices - but some servers "understand" NAT and find's the external IP by "pinging" external nodes.

Neither was ftp inteded to be used with dynamic IP's. A ftp server is a server which should be there - out in the open. But; I surely don't want my DNS in "the open".

Some (most?) routers which implements NAT understand the imposed problems and interferes with the communication (changing 192.168... addresses to external) and hides this problem. This is the most reliable way, but most routers also have problems if you don't used standard ports (i.e. port 21 for ftp).

So; first try to make your router solve this - otherwise, proceed:

Next is to ask your friends to at least try to use PORT instead of PASV. If that is not an option, proceed:

I made this work in the following configuration:

DNS-323 IP: 192.168.0.200
- Listens to port 10021 for FTP, configured via GUI.

External IP: 80.73.10.10 (FAKE, just an example)

Router with ports 10021, 65501-65510 opened. No fancy, no DMZ - just portmapped to IP of DNS-323.


First I stopped ftpdeamon (via GUI)

Then I added the following to /etc/ftpaccess:
passive  address 192.168.0.200 192.168.0.0/16
passive  address 80.73.10.10 0.0.0.0/0

Finally I re-started the ftpdeamon.

The first line will make sure 192.168.0.200 is sent back to ftp client when client is within the NAT. The second line will return the "external IP" when the rest of the world ftp's in.

I'm not sure this will survive a reboot and if you have dynamic external IP you need to change the file whenever you have a new external IP.

I've tested the above in small steps and it "should work" but I'm still awaiting confirmation from external user. Will report back when test is performed.

edit: I can now confirm that the 'hack' above work both behind the firewall/NAT and from external source.

HTH/Apan

Last edited by Apskaft (2007-01-29 08:10:39)

Can say what went wrong, but you must have modified the file in such a way that the GUI app can no longer parse the file properly. Restore to original file, reboot the device and try again. What editor did you use? Do you have your CRLF properly? You know that file format differ between DOS (Windows) and Linux whenit comes to CRLF vs LF.

So; restore to original file. Use an editor that are 'nice' on Unix file formed (i.e. UltraEdit) and only add the two lines I mention above, right after the passive *** already present.

If you cannot get it to work, post you ftpaccess file here and I'll have a look at it.

HTH/Apan

First you telnet into the device. Then, copy the file /etc/ftpaccess to /mnt/HD_a2. Note that you're now on a Un*x system and not a PC. The command to copy a file is "cp". So, "cp /etc/ftpaccess /mnt/HD_a2/." should do it. Then you can access the file from your PC in \\DNS_xxx\HDD_1\ftpaccess.

I noticed that there is a ftpaccess.default in the /etc directory, which you could use to replace your modified version with: cp /etc/ftpaccess.default /etc/ftpaccess"


Please be warned that all commands you execute on the DNS are volatile. You might brick your device if you don't know what you're doing. It's VERY VERY easy to brick it....

/Apan

This is now covered in the WiKi: http://dns323.kood.org/howto:open_ports_ftpd /Apan