48 replies to this topic

[nouveau]

Hi,

 

I'm running the latest openpli image for DM8000 and I have serious issues to get vsftpd to work over ssl. I have created cert and I have these options in /etc/vsftpd.conf

 

ssl_enable=YES
allow_anon_ssl=NO
force_local_data_ssl=NO
force_local_logins_ssl=NO
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO
rsa_cert_file=/etc/vsftpd.pem

 

(.pem cert file is located in /etc)

 

 

When connecting ftplog says "OOPS: SSL: ssl_enable is set but SSL support not compiled in" and according to some googleing, it means vsftpd is not compiled to work with ssl.

Does that mean the vsftpd version thats in latest openpli dosen't have ssl support?

I can't compile myself since I cant install any compiler, like "make" on the DM8000. I've tried and no luck.

 

root@dm8000:/etc# ldd /usr/sbin/vsftpd

libcrypt.so.1 => /lib/libcrypt.so.1 (0x7722c000)
libcap.so.2 => /lib/libcap.so.2 (0x77218000)
libc.so.6 => /lib/libc.so.6 (0x770a0000)
/lib/ld.so.1 (0x77270000)

Shouldn't I have some kind of libssl.so file here?

 

 

Also, the latest openpli image for DM8000 dosen't seem to have the latest openssl 1.0.1g?

 

OpenSSL> version
OpenSSL 1.0.1e 11 Feb 2013

 

 

 

I'm grateful for any help.

 

 

regards

 

nouveau

 

[christophecvr]

It is wel compiled no problem ssl is on box .

 

To use sftp connection just telnet you're box and

 

opkg install openssh-sftp-server

[christophecvr]

possibly ftpd over tls (also called ftps ) will not work sorry sftp is not same as ftps .

[christophecvr]

I double checked the bitbake recipe into pli4 and the ssl support is not included. So it will not work for ftp over tls

[nouveau]

I double checked the bitbake recipe into pli4 and the ssl support is not included. So it will not work for ftp over tls

 

Aha, okay

[christophecvr]

I double checked the bitbake recipe into pli4 and the ssl support is not included. So it will not work for ftp over tls

 

Aha, okay

Yes I'm wondering why the ssl support isn't included since for the rest everything is on the box anyway.

 

Normally it's just a mather off adapting the builddefs.h changing the #undef VSF_BUILD_SSL into #define VSF_BUILD_SSL before compiling.

[MiLo]

It's not compiled in because it might tempt users into opening the (SSL) FTP port to the public internet.

For example, when you flash new firmware on the box, the box's root password will be empty, and even if you recover a backup to quickly restore your password, there's an interval of about half a minute where an attacker can get unlimited root access to your box.

SSH does not have this vulnerability, so it is safe to forward. And you can use it to safely transfer files.

Why use a known-to-be-vulnerable protocol if the box already supports another protocol that is easier to use and does not have any (known) vulnerability.

[christophecvr]

It's not compiled in because it might tempt users into opening the (SSL) FTP port to the public internet.

For example, when you flash new firmware on the box, the box's root password will be empty, and even if you recover a backup to quickly restore your password, there's an interval of about half a minute where an attacker can get unlimited root access to your box.

SSH does not have this vulnerability, so it is safe to forward. And you can use it to safely transfer files.

Why use a known-to-be-vulnerable protocol if the box already supports another protocol that is easier to use and does not have any (known) vulnerability.

Ok yes that's trough if the users leave firewall port open during flash.

 

Once it's installed and box has root password its' secure this only and only if users have strong password. (I noticed that the basic login.defs now has SHA512  that's ok but password lenght is still defailt lenght off 8 that should be greater to have an almost unhackable password 12 is a minimum now)

 

But now users will do even worse, and for example open the samba ports to the net which currently is completely unprotected in pli4. And this is those days pretty targeted by hackers as is all windows stuff.

 

So enabling this VSF_BUILD_SSL  and compiling with -lssl -lcrypto  added does not on it decrease security.

 

Now there are users which even open there ftp port which even with password is crazy or samba also crazy.

 

The real only secure way is having not internet att all (pull the plug), but then it will be a bit difficult a guess

 

Iff users want to start using ftp tls They already studied a bit about security . And are security aware . If they then are able to configure there vsftpd create their certificate ans so on,,, do not think it's such a real security issue.

 

It's just a mather of choice ssh or secure ftp.

 

Neverthless I'm  just bussy with trying out the vsftpd with ssl for test (I do this only internally my ports to net are not open trough nat and blocked by a firewall)

[littlesat]

Users should simply not open standard ftp.... They should use the better more secure alternative ssh....

[christophecvr]

small note : off course no configs to have this server set . Users who wan't to use that hould have a knowledge to configure or obtain the required knowledge first, that's for shure

[MiLo]

Iff users want to start using ftp tls They already studied a bit about security . And are security aware . If they then are able to configure there vsftpd create their certificate ans so on,,, do not think it's such a real security issue.

Those users studied a BIT about security, but did not really understand it. They will end up THINKING their setup is secure, even when it is not, and this is far worse than having an insecure system and knowing it.

TLS (or SSL) does not protect your box (regardless of whether it's HTTP or FTP underneath) against attacks. It only protects the client, not the server. Your box is just as vulnerable through HTTPS as through HTTP. The same for FTP.

[christophecvr]

Iff users want to start using ftp tls They already studied a bit about security . And are security aware . If they then are able to configure there vsftpd create their certificate ans so on,,, do not think it's such a real security issue.

Those users studied a BIT about security, but did not really understand it. They will end up THINKING their setup is secure, even when it is not, and this is far worse than having an insecure system and knowing it.

TLS (or SSL) does not protect your box (regardless of whether it's HTTP or FTP underneath) against attacks. It only protects the client, not the server. Your box is just as vulnerable through HTTPS as through HTTP. The same for FTP.

Almost 100 % wright except. ......

 

Off course and that's is going up for every server broadcasting on the web. They are ALL vulnerable and in those theys will be under attack. and there whatever server it is

samba,ftp,sftp,ftps,http,https or .....

 

But the statement that https (sftp or ftps) is as vulnerable like http (ftp) is very very wrong if a strong password is used. (with open authetinfication for the certificate)

 

Trough is also that due to the fact that for an stb you're open the root user to whole world makes you indeed very vulnerable to not only attack's pishing and data stealing, also to viruses

[christophecvr]

But indeed even worse with ftp over tls is that the standaard 21 port is used . If you do not disable the non ssl the full ftp is open to world.

 

No indeed in stb enviroment it's a very very bad idea. to use it and not secure at all.

 

It's only interesting with much more advanced configs and delimiation like for example creating virtual server other ports acces limitation and certainly not with a super user

[Erik Slagter]

Actually no one should be using FTP anyway. At least not exposed to outside. Not even using TLS. FTP is a braindead protocol from begin 1970's, when firewalls didn't exist (and weren't necessary yet), so it has never been designed with any security in mind at all. Besides that, it uses a very dodgy method setting up an extra connection (the "data" connection) for every transfer (including a "dir" or "ls") command, which is more or less okay on your lan, but is very difficult to secure on a firewall (either "passive" or "active", that does NOT make a difference).

 

There are several modern/GOOD alternatives to FTP which obsolete FTP. For downloading from a website, they really should be using http instead of ftp. For transferring files one should really use scp or sftp (both are extensions to ssh, they are NOT related to ftp in any way). On windows you can use filezilla, which supports these protocols. These protocols are both safe and clean.

[littlesat]

There are still users that access their box locally via FTP... while the box is available via Network on the explorer on any windows PC... Even settingseditors are still using FTP, while this is not required at all...

[Erik Slagter]

Yes don't get me started on settings editors.

 

BTW I don't run samba on my receivers, but I realize I am an exception.

Edited by Erik Slagter, 16 April 2014 - 19:11.

[christophecvr]

There are still users that access their box locally via FTP... while the box is available via Network on the explorer on any windows PC... Even settingseditors are still using FTP, while this is not required at all...

First off all Yes inside (behind router) I'm using ftp like a lot. It's the best fastest and very reliable protocol to transfer big files (binary mode) (in despit the fact that it is very old)

 

I do not have windows pc att all and i'm not using the samba network att all . and security wise there is no difference between samba (while the box is available via Network on the explorer on any windows PC... that's samba server) ,telnet or ftp. Even due to the fact that there is no password in the samba it's even less secure then ftp. (that last is well very relatif whitout strong user password ftp telnet are as insecure like samba). But for them all they are not suposed to pass trough a router or firewall.

[SpaceRat]

Two facts:

• E2 - while based on Linux - is exactly on the opposite side of a security nightmare as Linux is
  Linux is a nightmare to use due to all that paranoid bullshit, like excluding the cwd from path (It is called current WORK dir and not current IGNORE dir), while E2 is a security nightmare due to total ignorance of easy configuration steps that would make it decently safe.
• People always have and always WILL open the silliest things to the net
  MiLo tends to say "Your foot, your gun", but it isn't. We all will suffer from zombie machines out there ...
• About point 1:
  • Images keep shipping with default certs
    OpenWebif for example can and will create own certs if there aren't any. Those wouldn't be great either, as they still do not ensure the authenticity of a specific box (address), but at least you wouldn't trust ALL E2 boxes using that image if you add an exception to the browser, but only YOUR box.
    Personalized own certs are still the way to go anyways.
  • Setups keep using user root for everything
    Just

    adduser webuser -H -h /nonexistent -s /bin/false

    and enter a password different from that of the root user and you get a user which can log in using the Web Interface easily but would be entirely useless if hacked.
    
    Something similar can be done for an ftpuser, which could be jailed in /media/hdd
    Such a hacked ftpuser could delete all your recordings, but it could neither login (due to /bin/false as shell) nor access the internals of the box (due to being jailed).
    
    Actually, one of those users would be already good for both, web and ftp or you could go even further and create a pure virtual user for ftp, which doesn't exist on the system.
  The above points aren't complete, but they would greatly enhance the security of an E2 box without doing ANY harm to it's functionality or "ease" of use.
• 
  

[littlesat]

Why not using dropbear/ssh... You can securaly access the webinterface, stream interface and ftp from there...?

[SpaceRat]

Why not using dropbear/ssh... You can securaly access the webinterface, stream interface and ftp from there...?

I didn't say I need ftp access from outside, I was just wondering why so few effort has been spent to implement at least basic security.

To have two users wouldn't have made E2 any more complicated.