FTPS auth error over WAN

[rchalwin]

Hi All, I'm having a problem accessing the secure FTP (explicit TLS) server on a Thecus N4800 remotely.

The process on the N4800:
Enabled FTP and secure FTP
Set port 21
Set external IP to my WAN public IP
Passive port 30000-32000
Char set: UTF-8
No anon access

Connecting when in this config on LAN works so I know the FTP server works

I then set the router to forward ports 20, 21 and 30000-32000 to N4800's LAN ip

Connecting remotely with FlashFXP (4.2.5) using settings:
FTP explicit TLSv1
domain registered with no-ip.org DDNS entered and correctly pointing
port 21
PASV

yields the following and won't connect:
[R] Connecting to Remote Home FTP -> DNS=xxxxxxxxx.no-ip.org IP=xxx.xxx.xxx.xxx PORT=21
[R] Connected to Remote Home FTP
[R] 220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
[R] 220-You are user number 1 of 300 allowed.
[R] 220-Local time is now 21:12. Server port: 21.
[R] 220-This is a private system - No anonymous login
[R] 220-IPv6 connections are also welcome on this server.
[R] 220 You will be disconnected after 15 minutes of inactivity.
[R] AUTH TLS
[R] 234 AUTH TLS OK.
[R] Connected. Negotiating SSL/TLS session
[R] Failed SSL/TLS negotiation, disconnected
[R] Connection failed (Connection closed by server)

It made no difference setting PORT(Active) instead of PASV

Nor did putting the N4800 in DMZ.

Both unsecured FTP and SFTP-over-SSH connect remotely with no errors so I'm at a loss to explain why FTPS in particular is playing up.

P.S: I've lodged a similar query on the Thecus forum too

[hggomes]

What software version is being used on Thecus server? Is the server running a .conf file or it runs based on command line switch?



Enabled FTP and secure FTP
Connecting when in this config on LAN works so I know the FTP server works



Were you able to connect FTPS internally? If so please post session log.

Does the server "error.log" file shows something when trying to connect FTPS from the outside? If so please post log.

[rchalwin]

Thanks for helping out.

My NAS (thecus 4800) runs a Pure-FTP daemon. Sorry but I can't find the assoc .conf file anywhere on the system.

I can confirm that FTPS with explicit TLSv1 works on my LAN:


[R] Connecting to Local Home SFTP -> IP=192.168.xxx.xxx PORT=21
[R] Connected to Local Home SFTP
[R] 220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
[R] 220-You are user number 1 of 300 allowed.
[R] 220-Local time is now 22:09. Server port: 21.
[R] 220-This is a private system - No anonymous login
[R] 220-IPv6 connections are also welcome on this server.
[R] 220 You will be disconnected after 15 minutes of inactivity.
[R] AUTH TLS
[R] 234 AUTH TLS OK.
[R] Connected. Negotiating SSL/TLS session
[R] TLSv1 negotiation successful...
[R] TLSv1 encrypted session using cipher DHE-RSA-AES256-SHA (256 bits)
[R] PBSZ 0
[R] 200 PBSZ=0
[R] USER xxxx
[R] 331 User xxxx OK. Password required
[R] PASS (hidden)
[R] 230-This server supports FXP transfers
[R] 230 OK. Current restricted directory is /
[R] SYST
[R] 215 UNIX Type: L8
[R] FEAT
[R] 211-Extensions supported:
[R] EPRT
[R] IDLE
[R] MDTM
[R] SIZE
[R] MFMT
[R] REST STREAM
[R] MLST type*;size*;sizd*;modify*;UNIX.mode*;UNIX.uid*;UNI X.gid*;unique*;
[R] MLSD
[R] AUTH TLS
[R] PBSZ
[R] PROT
[R] UTF8
[R] ESTA
[R] PASV
[R] EPSV
[R] SPSV
[R] ESTP
[R] 211 End.
[R] OPTS UTF8 ON
[R] 200 OK, UTF-8 enabled
[R] PWD
[R] 257 "/" is your current location
[R] TYPE A
[R] 200 TYPE is now ASCII
[R] PROT P
[R] 200 Data protection level set to "private"
[R] Listening on PORT: 49527, Waiting for connection.
[R] PORT 192,168,0,197,193,119
[R] 200 PORT command successful
[R] LIST -al
[R] Connected. Negotiating SSL/TLS session
[R] TLSv1 negotiation successful...
[R] TLSv1 encrypted session using cipher DHE-RSA-AES256-SHA (256 bits)
[R] 150 Connecting to port 49527
[R] 226-Options: -a -l
[R] 226 16 matches total
[R] List Complete: 1 KB in 0.04 second (1.1 KB/s)


Trying the exact same settings across WAN dumped the following error into syslog:


N4800 pure-ftpd: PAM _pam_init_handlers: no default config /etc/pam.d/other
N4800 pure-ftpd: pam_winbind(pure-ftpd:auth): internal module error (retval = PAM_AUTHINFO_UNAVAIL(9), user = 'xxxx')


It seems pure-ftpd is using PAM for authentication:


#! /bin/sh
/app/bin/auth.sh ${AUTHD_ACCOUNT} ${AUTHD_PASSWORD}
check=$?
echo ${check}
if [ $check -ne 0 ]; then
echo 'auth_ok:0'
else
echo 'auth_ok:1'
echo 'uid:'`/opt/bin/getent passwd | /bin/grep "^$AUTHD_ACCOUNT:"|/usr/bin/awk '{FS=":";print $3}'`
echo 'gid:'`/opt/bin/getent passwd | /bin/grep "^$AUTHD_ACCOUNT:"|/usr/bin/awk '{FS=":";print $4}'`
echo 'dir:/raid/ftproot/'
fi
echo 'end'


And the PAM.d conf shows:


auth sufficient pam_ldap.so
auth sufficient pam_winbind.so
auth required pam_unix.so use_first_pass
account sufficient pam_ldap.so
account sufficient pam_winbind.so
account required pam_unix.so
session sufficient pam_ldap.so
session sufficient pam_winbind.so
session required pam_unix.so


I don't understand any of this, especially why the authentication should go through perfectly across LAN yet fails on WAN with exactly the same login details. :confused:

Perhaps there is some problem with my ISP passing encrypted packets inbound? Especially since my NAS sits in DMZ.

[hggomes]

Hi, you're welcome. ;)


Perhaps there is some problem with my ISP passing encrypted packets inbound? Especially since my NAS sits in DMZ.


I really don't think that's what is happening, it could not be a ISP blocking. I believe it's related with PAM Auth somehow, why are you using DMZ instead of port forwarding?

Thanks for helping out.

My NAS (thecus 4800) runs a Pure-FTP daemon. Sorry but I can't find the assoc .conf file anywhere on the system.


Probably because it's not running with .conf files, maybe its running via command line switch. Try a 'ps -aux' and see the complete command sequence of 'pure-ftpd' process running on the system. It's similar to the described below, but you sould see the '-l pam' switch instead.

The Pureftpd PAM error could be explained due the non-existance of file in '/etc/pam.d/other'.

You should try to change the authentication mode from PAM to PUREDB, and see if the problems when trying to connect from the outside (WAN) using SSL/TLS encryption still exist:

1. # killall pure-ftpd

2. # pure-ftpd -l puredb:/etc/pureftpd.pdb (Change the Auth login to puredb) -S DNS or IP,PORT (Bind address and port) -Y 1 (Enable SSL/TLS Auth, if you want allow only encrypted logins change the value to '2') -I 1 (Idle Timeout) -A (Chroot) -B (Daemonize) -g /var/pure-ftpd.pid (pidfile) -O stats:/var/xfer.log (logfile) -w (allowuserfxp) -p firstport:lastport (Passive port range)

3. Create users:
# pure-pw useradd USER -u UID -g GID -d HOMEDIR
# pure-pw mkdb

PS:
(The Italic words explain what the switchs are for)
The Bold words can/should be changed for your specific case.

Give a try, good luck.

[rchalwin]

why are you using DMZ instead of port forwarding?

Just a quick'n'dirty way of excluding my router as the problem after reading that some ftp servers have problems in a NAT environment. Before that it was setup as a virtual server with the relevant ports pointing at the NAS.


Probably because it's not running with .conf files, maybe its running via command line switch. Try a 'ps -aux' and see the complete command sequence of 'pure-ftpd' process running on the system. It's similar to the described below, but you sould see the '-l pam' switch instead.


The unix version running this NAS seems to be rather unusual and "ps" doesn't support any option parameters other than "w". The best I can get out of it is:

5493 root 51952 S pure-ftpd (SERVER)

Other processes (incl httpd) have command parameters, but none show up for the ftpd so perhaps it does have a conf somewhere after all?




You should try to change the authentication mode from PAM to PUREDB ... Give a try, good luck.

Thanks for the detailed help ... your suggestions are appreciated. Unfortunately I couldn't get beyond the first step since "pure-ftpd" isn't recognised by shell. Even though it seems to be a process :confused:

Looking deeper into the system, there isn't even a pure-ftp binary. Instead there's just a generic "ftp" file which I'm guessing is it. Thecus seem to have done some unconventional things with this system and it is a looooong way from vanilla unix.


My hunch is this one ain't going to be fixed easily and is probably not worth further effort. I can connect just fine as FTP-over-SSH which is a reasonable compromise and secure enough. Other users can just use unencrypted FTP and I'll set the permissions to -ro

This is probably a hint that I should buy a server and get on friendly terms with Fedora. ;)
Thanks again.

[hggomes]

Hi again ;)

In the past i had the exact same problems with an SMC NAS, manufacters put conditions on the firmware (software) and that restricts alot users in many cases. I had also a QNAP NAS that suffered from the same limitations, you only can do what they allow you to, or you need to waste alot of your time trying to "hack" on it, if you know what i mean...


Other processes (incl httpd) have command parameters, but none show up for the ftpd so perhaps it does have a conf somewhere after all?

No, using .conf file or running via command line switch will always show the same way as you posted, you can try take a look on xined directory and edit the pureftpd file if thats the case and see the parameters used to launch the server.

Have you searched on the entire filesystem structure for 'pure-ftpd' binary? If you assume that the file 'ftp' is the right one, can you run it? Does it bring pure-ftpd server up?


This is probably a hint that I should buy a server and get on friendly terms with Fedora.


You are quite right when you say it, you can build your own NAS box and install a Linux Distro and be free to whatever you need/want, prebuild NAS are always very restricted for some users.

I'm gonna take a look at opensource code (http://www.thecus.com/Downloads/GPL/N16000_2.03.08_GPL.tar.bz2) just for curiosity and i will catch you later.

[hggomes]

I found on the source code file that it's running pure-ftpd.conf located at '/etc/pure-ftpd/pure-ftpd.conf'.

[rchalwin]

Hi again ;)

Have you searched on the entire filesystem structure for 'pure-ftpd' binary? If you assume that the file 'ftp' is the right one, can you run it? Does it bring pure-ftpd server up?



Ah, found pure-ftpd. Located on /opt/ftpd/sbin

But no further luck as I still can't invoke it with shell commands.

It has an associated pure-authd that presumably passes the authentication requests to pam.d or elsewhere. This is an assumption since the NAS doesn't provide the facility to create specific ftp users. It just seems to use the global "user" accounts.

And no sign of a .conf anywhere.

[rchalwin]

I found on the source code file that it's running pure-ftpd.conf located at '/etc/pure-ftpd/pure-ftpd.conf'.

OK ... thanks for looking at that.

On my system ... nada. Looked all through /etc (and subdirectories) with "ls -a" and no sign of pure-ftpd.conf

EDIT: also ran "find / -name pure-ftpd.conf -print" and no return

[hggomes]

It seems a dead end, sorry to hear that. :confused: I'm afraid that pure-ftpd is not compiled on the NAS with all flags, so probably you will never be able to use puredb auth.

If you're able find pure-ftpd.conf and change it, probably you could run it then via WEB GUI.

[rchalwin]

It seems a dead end, sorry to hear that. :confused: I'm afraid that pure-ftpd is not compiled on the NAS with all flags, so probably you will never be able to use puredb auth.

If you're able find pure-ftpd.conf and change it, probably you could run it then via WEB GUI.

Thanks again for at least looking at this. I got no help from the Thecus forum and an official support ticket was useless as they couldn't reproduce my problem. My guess, as you said, is that they're trying to discourage tinkering.

After doing a little digging, it seems the conf parameters for the pure-ftpd server are located in an sqlite database along with most of the other system settings. So technically I could have a go at modifying this ... but with such a bespoke setup there's too much risk of bricking the whole unit.

So I think it's time to do it properly and make Michael Dell a little wealthier.

[hggomes]

I agree with that ;) Good luck.