48 replies to this topic

[Erik Slagter]

From the whole story I agree on one point, web interface users shouldn't login as root. I already made a facility in streamproxy to only allow users from a certain group to login, I think something similar should be implemented for the web interface, if we agree on a group name, and the web interface adds this group, the streamproxy can easily follow.

Although this doesn't offer real security (that would be for instance a ssh or openvpn tunnel, and then it would not matter what user you choose to login) at least it somewhat less insecure.

Also I am not a fan of the "hand the user the gun if he wants to shoot his foot" strategy. Practise learns they really don't realise what they're doing and afterwards it's never their own fault (at least as they perceive it).

[Erik Slagter]

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

At least some part of enigma need to run as root afaik (some dvbapi stuff), you can't run one thread as another user, so enigma would have to be split to at least two processes, which is erhm... "some work" to do. It would also add the need for all sorts of IPC that isn't necessary now.

But yes, it would be better. Patch awaited

[theparasol]

If all "default" settings of a fresh image are set to "safe" people will start to complain on the net: "Help cant access webinterface" or fill in any issue you wish.

 

I agree, right now everybody suffers from Zombie devices. But what options do we have? ISP's could take down internet connections that are affected.

But the people that face such a fact will blame most of the time their ISP for it and not themselfs.

[SpaceRat]

If all "default" settings of a fresh image are set to "safe" people will start to complain on the net: "Help cant access webinterface" or fill in any issue you wish.

Well, I know it's basically too late to make these things happen without side effects.

I was more talking about the original design.
But if there had always been a user "user", which was documented everywhere for access to the webif and ftp for file download, nobody would question it ...

It could have been as simple as this:

"user" is for Webif and ftp to /hdd/movie
"root" is for telnet, ssh and ftp to /

That's not excellent but still better than it is now.

[SpaceRat]

It's as easy as

adduser user -H -h /media/hdd -s /bin/false
{Assign a password different from root}
echo root > /etc/vsftpd.chroot_list

Add these settings to /etc/vsftpd.conf :

chroot_list_enable=YES
chroot_list_file=/etc/vsftpd.chroot_list

Modify these settings in /etc/vsftpd.conf to make them read:

chroot_local_user=YES
#local_root=/

Then use user "user" to login to webif and ftpd.
If the credentials of this user get into wrong hands, the attacker can delete the whole harddisk and switch programs, but he can not login using telnet or ssh, modify binaries of the system or something like that.

It's still not perfect, as user root is still able to login to the web interface, so it's a matter of discipline not to use that from outside, but if the user gets used to logging in as "user" and using root only when he really wants to administrate something (from home), it's already a huge step forward.

[MiLo]

vsftpd will fork a process as the given user-id. If you let it run as "user", it will be unable to write to the harddisk because everything there is owned by root with 0o644 permissions. Can you imagine the flood of user complaints if we ever changed the ftp user id to something else than 'root'?

Using the system root login as authentication is a choice that the webinterface made for itself. It could also handle its own authentication, e.g. using any user name and password it would deem fit. That would at least keep you from typing your root password from an internet cafe where webcams and keyloggers are watching your every move...
Since the webinterface runs inside E2, it always runs under root privilege, regardless of what login is being used.

[Erik Slagter]

So there we are again back to my proposal, appoint one or more users in a group that are allowed to use the web interface. Root should not be one of them. In the end, all these users will have root priviledges (as mentioned) when logged in on the web interface, but at least it saves you from typing the root password.

 

@Parasol: I am pro breaking things every now in favour of better security. Better have something that doesn't work for you, than something that works, for someone you don't want it to work for.

Edited by Erik Slagter, 18 April 2014 - 08:04.

[christophecvr]

Very interesting all. About http ok. However users still must be able to execute some enigma2 stuff like zapping enigma2 = root. ???

 

Then for ftp that is used for administration ... means root acces required.

 

Just do not by pas them net.

 

Note in most country's the ports 0 - 1000 are blocked by isp anyway . To have them unblocked Bussines accounts are required.

 

In Belgium ,France, Luxemburg it's like that. Netherlands will follow (if it is not already like that) . From other country's a don't.

It's obvious You can have them unblocked but not as a regular customer . It's done by there modems and as user you can't change that setting .

 

A user can always use a nat translation to by pass off course.

 

From inside You always need the ability to change and edit trough ftp Theparasol and Milo are wright.

[Erik Slagter]

Note in most country's the ports 0 - 1000 are blocked by isp anyway . To have them unblocked Bussines accounts are required.

There is such a simple workaround for that and it's safe too. Simply use ssh with port forwarding or a vpn.

 

In Belgium ,France, Luxemburg it's like that. Netherlands will follow (if it is not already like that) . From other country's a don't.

It's obvious You can have them unblocked but not as a regular customer . It's done by there modems and as user you can't change that setting .

Nope, not going to happen in NL. It's just ports 25 and sometimes 53 that are blocked. But our largest ISP allows you to choose what ports to block yourself.

[christophecvr]

Note in most country's the ports 0 - 1000 are blocked by isp anyway . To have them unblocked Bussines accounts are required.

There is such a simple workaround for that and it's safe too. Simply use ssh with port forwarding or a vpn.

 

Yes if I should have the need off acces my box from out off house trough net off course I will use ssh and or vpn.  But that i don't .

btw https or ftps(ftp over tls) is as secure as ssh if server is correctly configured the problem off course with the last two is correct configs and that's not so simple for everyone. If done wrong there is indeed no security att all. that's not the case with ssh.

 

But what Milo and theparasol mean is that the users (almost) all need ftp to configure and yes for admin you must be root. In Belgium never a problem as the standard used ports are blocked inboud anyway. But yes users should be convinced to always use a router with firewal. Unfortunately i've seen home installations done by so called professionals (they call themself at least so ) It's even so that mostly installation done by newbies self following instructions found on the net and or manuals is often much safer then that from so called pro's .

[Erik Slagter]

If you don't use (even a very simple) firewall, it's like removing the front door from your house. Even a small child understands what that means. Everyone who's still stubborn, is on their own.

[christophecvr]

If you don't use (even a very simple) firewall, it's like removing the front door from your house. Even a small child understands what that means. Everyone who's still stubborn, is on their own.

That's wright. This can't be said better.

[MiLo]

btw https or ftps(ftp over tls) is as secure as ssh if server is correctly configured

NO! IT IS NOT!

Maybe shouting helps. I've been trying to get this message through.

So this message is for people other than you, who read this thread, and have the illusion that they can safely open a port to the web interface if they use HTTPS. It does not work that way. It just allows attackers to securely attack your box, instead of having to hack you using plaintext traffic.

[Erik Slagter]

The funny thing is "normal" browsers do allow to present a certificate to the server (which would make tls safe to use after all, assuming the server actively checks the presented client cert), but exactly the mobile versions do not allow this (at least not on android), rendering tls useless for maximum security.

Edited by Erik Slagter, 18 April 2014 - 13:48.

[SpaceRat]

btw https or ftps(ftp over tls) is as secure as ssh if server is correctly configured the problem off course with the last two is correct configs and that's not so simple for everyone.

If people can set up a VPN using OpenVPN, they can as well create proper certs for the WebInterface(s) and vsftpd.

While OpenVPN supports a rather simple setup using tun and static.key, those who go this hard way usually go the really hard way and create a cert chain, oftenly even adding tap to the PITA ...
Ironically, setups using static.key have to be considered safer than those using a cert chain, as OpenSSL and its heartbleed were never involved in creating or handling the static key.

And MiLo and some other guys still owe me an answer to the question why they believe OpenSSL is safer in conjunction with OpenVPN than when used with OpenWebif or vsftpd.
I know it's not, as it's the very same and belief belongs into church ...

If done wrong there is indeed no security att all.

Well, not entirely true but yes, it is very limited.

that's not the case with ssh.

Not true.
The main problem with improper certs or reluctance to care about certificate failures is a possible MITM attack:
People who add exceptions for https web sites to get rid of the warnings will also send the root-login to ANY sshd, even those which fail validation.

Safety belts are totally useless too ... if not put on.
Still they plus their seat-belt tensioners were able to save my life years ago ... because I never drive without seat-belts put on.

[MiLo]

And MiLo and some other guys still owe me an answer to the question why they believe OpenSSL is safer in conjunction with OpenVPN than when used with OpenWebif or vsftpd.

I never said that, so I don't need to explain.


I can only repeat what I've explained over and over again. If any part of this is unclear, let me know.


The one and only safe method to access your box directly from the internet is to use a secure tunnel. SSH, as pre-installed on the box, does this and has proven to be safe to use. VPN can also be used to create a secure tunnel, so that is potentially safe too.


HTTPS is HTTP tunelled through SSL or TLS. This protects the client, thus NOT the box, which is the server. It encrypts traffic, so that you can safely send your plaintext password over it - as HTTP does for each and every request. It authenticates the server towards the client, so that the client can be sure that it is actually your box it's connecting with, and not some man in the middle. But authentication and authorization of the client is completely handled by the HTTP server. Any exploit available through the normal HTTP link is also available via HTTPS.


The difference is that with a tunnel (like SSH or VPN), you have to authenticate first, before you are able to send any request to the other side. With HTTP (or any other protocol via TLS/SSL), you ALWAYS get a (secure) connection, and then you can send the server whatever request you like. The server is just as vulnerable as through an unencrypted connection.


As Erik correctly mentioned, it IS possible to use a client certificate to authenticate the client at the SSL/TLS level towards the server. Using this two-way authentication would make the connection safe to use. But the server must be configured to require client certificate authentication for this to work. The E2 server does not support this.


Once more, in the text above "server" invariably means "your settop box". And "client" means "either you or a skilled anonymous hacker".

[SpaceRat]

MiLo, on 18 Apr 2014 - 15:35, said:
Any exploit available through the normal HTTP link is also available via HTTPS.

This would still require the user to login first ...

MiLo, on 18 Apr 2014 - 15:35, said:
As Erik correctly mentioned, it IS possible to use a client certificate to authenticate the client at the SSL/TLS level towards the server. Using this two-way authentication would make the connection safe to use. But the server must be configured to require client certificate authentication for this to work. The E2 server does not support this.

Now it does:
https://github.com/E...6fa17758972f202

[OpenWebif] Successful cert authed as:  <X509Name object '/O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/emailAddress=support@cacert.org'>
[OpenWebif] Successful cert authed as:  <X509Name object '/CN=CAcert WoT User/emailAddress=<MyEMailAddress>'>

No fear, it is completely optional and it still requires login/pass (in addition to the client cert, if enabled).

[Erik Slagter]

But does it enforce either:

 

- the cert + cn to be known

- the cert to be signed by a common ca

 

Otherwise it's useless.

[SpaceRat]

Erik Slagter, on 18 Apr 2014 - 14:46, said:
The funny thing is "normal" browsers do allow to present a certificate to the server (which would make tls safe to use after all, assuming the server actively checks the presented client cert), but exactly the mobile versions do not allow this (at least not on android), rendering tls useless for maximum security.

Once again: Wrong.




And Firefox supports client certs too.

[SpaceRat]

Erik Slagter, on 19 Apr 2014 - 13:06, said:
But does it enforce either:

- the cert + cn to be known
- the cert to be signed by a common ca

It trusts certs issued by any of the signers having their certs in /etc/enigma2/ca.pem

You have to fill that file yourself though atm, e.g. using this list:
Exported Mozilla root CAs

In my case, I added CAcert for testing.