Topic: remote ftp acces possible or contrib needed>?

[hanscees]

Hi,
I am setting up an ftp-server for acces from the internet.

But although I have enabled remote ftp access and ftp password verification access form the internet is not granted.
From the lan it works fine.

I am using 7.5.1

Do I need a contrib or should this work?

I can see iptables accepts:

Feb 14 21:52:04 ftp kernel: accept-it!IN=eth1 OUT= MAC=00:0c:29:01:0e:dd:00:01:71:10:86:4a:08:00 SRC=78.27.61.89 DST=172.19.0.12 LEN=60 TOS=0x00 PREC=0x00 TTL=60 ID=16113 DF PROTO=TCP SPT=35459 DPT=21 WINDOW=64240 RES=0x00 SYN URGP=0


Feb 14 21:52:04 ftp kernel: accept-it!IN=eth1 OUT= MAC=00:0c:29:01:0e:dd:00:01:71:10:86:4a:08:00 SRC=78.27.61.89 DST=172.19.0.12 LEN=60 TOS=0x00 PREC=0x00 TTL=60 ID=16113 DF PROTO=TCP SPT=35459 DPT=21 WINDOW=64240 RES=0x00 SYN URGP=0
Feb 14 21:52:04 ftp kernel: drop-it!IN=eth1 OUT= MAC=00:0c:29:01:0e:dd:00:01:71:10:86:4a:08:00 SRC=78.27.61.89 DST=172.19.0.12 LEN=60 TOS=0x00 PREC=0x00 TTL=60 ID=16113 DF PROTO=TCP SPT=35459 DPT=21 WINDOW=64240 RES=0x00 SYN URGP=0

but nothing like this:
Feb 14 21:31:52 ftp proftpd[22597]: 192.168.0.12 (192.168.0.8[192.168.0.8]) - FTP session opened.


Any tips?

Hans-Cees

[cactus]

I suggest you use sftp: http://wiki.contribs.org/SFTP , it is more secure.

[hanscees]

I suggest you use sftp: http://wiki.contribs.org/SFTP , it is more secure.

The enduser uses mac, plus ssh access from the internet is not really more secure is it?

So please help me using ftp. I will place security controls by using iptables.

hc

[janet]

hanscees

> From the lan it works fine.

Do a port scan at grc.com, perhaps your firewall or router is blocking FTP port.

[hanscees]

hanscees

> From the lan it works fine.

Do a port scan at grc.com, perhaps your firewall or router is blocking FTP port.

Hi,

The logging above shows that iptables sees the traffic on port 21 from the internet. So  a portscan will not help.

I suspect that the sme 7.5.1 simply does not listen on the external interface on port 21, or that PAM blocks it or something.
But I do not know if that is by design or a bug.

The questions are:
- is sme 7.5.1 designed to give ftp access to the internet  if you configure ftp acces for internet and with password authentcation?
- does anybody use this succesfully

If this is not meant to work by design I should use another solution, rather than tweak sme to do somethin it is designed not to do.

If nobody knows I will file a bug report, but I do not want to bother the bug system if not neccesary.

Hans-Cees

[hanscees]

I suggest you use sftp: http://wiki.contribs.org/SFTP , it is more secure.

that contrib should note that it is meant for ROOT only. I am looking for a solution for endusers.

hc

[Stefano]

hans: is your SME in server and gw mode or server only?

for ftp you have to forward tcp port 20 too

[byte]

What FTP Client are you using? or are you using the ftp command from the terminal on the mac?

[byte]

I can see iptables accepts:

Feb 14 21:52:04 ftp kernel: accept-it!IN=eth1 OUT= MAC=00:0c:29:01:0e:dd:00:01:71:10:86:4a:08:00 SRC=78.27.61.89 DST=172.19.0.12 LEN=60 TOS=0x00 PREC=0x00 TTL=60 ID=16113 DF PROTO=TCP SPT=35459 DPT=21 WINDOW=64240 RES=0x00 SYN URGP=0


Feb 14 21:52:04 ftp kernel: accept-it!IN=eth1 OUT= MAC=00:0c:29:01:0e:dd:00:01:71:10:86:4a:08:00 SRC=78.27.61.89 DST=172.19.0.12 LEN=60 TOS=0x00 PREC=0x00 TTL=60 ID=16113 DF PROTO=TCP SPT=35459 DPT=21 WINDOW=64240 RES=0x00 SYN URGP=0
Feb 14 21:52:04 ftp kernel: drop-it!IN=eth1 OUT= MAC=00:0c:29:01:0e:dd:00:01:71:10:86:4a:08:00 SRC=78.27.61.89 DST=172.19.0.12 LEN=60 TOS=0x00 PREC=0x00 TTL=60 ID=16113 DF PROTO=TCP SPT=35459 DPT=21 WINDOW=64240 RES=0x00 SYN URGP=0

It appears from those logs you also have a non standard SME Server setup as "accept-it!" and "drop-it" have never been a part of a clean SME Server set up.

See snip from my logs

Feb 15 10:49:28 <server-name> denylog: IN=eth1 OUT= MAC=00  SRC=xxx.xxx.xxx.xxx DST=xxx.xxx.xxx.xxx LEN=64 TOS=00 PREC=0x00 TTL=127 ID=56882 CE DF PROTO=TCP SPT=3793 DPT=21 SEQ=1486997470 ACK=0 WINDOW=65535 SYN URGP=0

[cactus]

that contrib should note that it is meant for ROOT only. I am looking for a solution for endusers.

I am perfectly capable of login in with other users than root, so I doubt that is true.

[cactus]

The enduser uses mac, plus ssh access from the internet is not really more secure is it?

As Mac OS X (which you are most likely using) seems to have native support for SCP/SFTP: http://www.cites.illinois.edu/security/ssh/unixscp.html

[hanscees]

It appears from those logs you also have a non standard SME Server setup as "accept-it!" and "drop-it" have never been a part of a clean SME Server set up.

See snip from my logs

Feb 15 10:49:28 <server-name> denylog: IN=eth1 OUT= MAC=00  SRC=xxx.xxx.xxx.xxx DST=xxx.xxx.xxx.xxx LEN=64 TOS=00 PREC=0x00 TTL=127 ID=56882 CE DF PROTO=TCP SPT=3793 DPT=21 SEQ=1486997470 ACK=0 WINDOW=65535 SYN URGP=0

That was the tip I needed! Pretty embarrassing, but I did set up a little bit of iptables when setting up the ftp server a while ago. I just re-found this file:

/etc/e-smith/templates-custom/etc/rc.d/init.d/masq/40allowsome:
##allow 218.149 but log
/sbin/iptables -A INPUT -p tcp --dport 21 -m state --state NEW -j LOG --log-prefix accept-it!
/sbin/iptables -A INPUT -p tcp --dport 20 -m state --state NEW -j LOG --log-prefix accept-it!
/sbin/iptables -A INPUT -s 218.149.0.0/16 -j ACCEPT
/sbin/iptables -A INPUT -s 78.27.0.0/16 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -m state --state NEW -j LOG --log-prefix drop-it!
/sbin/iptables -A INPUT -p tcp -m state --state NEW -j DROP

A good precaution.

I am sure it will work now:-)

Hans-Cees

[hanscees]

I am perfectly capable of login in with other users than root, so I doubt that is true.

OK, that is good information too. Does that mean all users also have ssh shell access? Because that is a big difference form the default sme-server default security policy. It is of course not forbidden, but it is something one should decide clearly.

Hans-Cees

[cactus]

Does that mean all users also have ssh shell access? Because that is a big difference form the default sme-server default security policy. It is of course not forbidden, but it is something one should decide clearly.

I think that is a requirement indeed, but when using private/public keys as described in the wiki it will be  pretty secure.