gfjardim's owncloud, custom domain, SSL and A+ rating on Qualys SSL Labs

Hi guys,

I just finished setting up owncloud with my domain name and 3rd party SSL certificate for free and got an A+ rating on Qualys SSL Labs, with some modifications. I feel like I have the client side locked up tight. But need some help with securing the server side.

In case anyone is interested, I'll share my steps in the following box:

First of all, startssl provides a free signed SSL for one domain + one subdomain. 
I signed up my existing domain name and signed up a newly created "cloud" subdomain for the certificate. It was very straightforward.

Then I made sure that dynamic dns provider was set up to forward to my home ip. I use duckdns for that and I also have a docker for it in my repo (shameless plug)

My hosting provider is hostgator, where my main domain is hosted. 
On cpanel, I created a CNAME for just the new subdomain "cloud" and pointed it to my duckdns subdomain. 
My main domain name still uses the hostgator hosted site. (I had to set a CNAME record and not a regular forward, because I could not figure out how to do a masked/stealth forward through hostgator's cpanel)

Then replace the server.key and server.pem with the key and the certificate you got from startssl in the owncloud data directory. 
Restart the server. In the settings, check to force https.

On your router, make sure both ports 80 and 8000 are forwarded to the owncloud ip and host port

Now, when you go to cloud.mydomain.com, the browser will try to connect to your ownloud at port 80, owncloud will tell it to connect at port 8000 with https, the browser will do that and you will access owncloud with SSL.

However, due to the nginx settings in the owncloud docker, there are certain vulnerabilities and the Qualys SSL Labs score is a "B".

See the following two sites for the description and remedies:
https://cipherli.st/
https://weakdh.org/sysadmin.html

What you have to do is 
1. exec into the running container with docker exec -it ownCloud bash 
2. Modify nginx.conf with the suggestions from the first link (except for the ssl_session_tickets line and the last two resolver lines as they cause errors in the docker)
3. Generate a unique DH group as described in the second link
4. Modify the sites-enabled as described in the second link under nginx
5. Reload nginx with nginx -s reload

Now your Qualys SSL Labs rating should be an "A+"

Now the next step is to secure the server side. I'm still trying to figure it out. The major issue is that the owncloud data folder contains the  certificate and the private key. And we know that unraid is not really meant to be secure. If someone gets onto my LAN, they can easily get to the private key.

I turned encryption on for the owncloud stored files. But unfortunately the keys for that are also stored in the owncloud data folder. A compromised unraid server would make all that SSL security useless.

Any ideas on how I can secure the server side? I guess I could run owncloud in a VM, with filesystem encryption and no network shares. Or do the same on a separate box altogether. Any other ideas?

Would any security gurus like to chime in?

I don't about you, but if the LAN is not trusted, you might consider:

[*]iptables to restrict telnet to trusted network ip address - or block it altogether and rely on ssh - ssh can be restricted to use private keys only which will make it more secured

[*]run a reverse proxy docker/vm, accept connections only to HTTPS and reverse proxy the connection to local port 80. then block port 80 from access from LAN

[*]do not export the share/disk containing the owncloud data volumes - if its not shared out, they need telnet/ssh access to unraid to get to the private key

If you need harder security, the ssl encryption should be done/terminated using an security appliance, and it will do reverse proxying to the actual owncloud server.

Thanks, Ken-ji

1 and 2 make sense.

With regards to 3, I thought about doing that, but if the files are on the cache drive, and I have to export the cache drive, it creates an issue. Plus, there is no way to encrypt a share, so anyone with access to the physical disks would get the files.

Owncloud does offer server side encryption, however, they only do it for sharing files with other servers like dropbox or google drive. It is not meant to provide security on the server. So they keep the encryption private keys right alongside the files on the server. So again, anyone with physical access to the files on the server, also has access to the encrypted files because the keys are literally right next to them.

What I ended up doing is, I set up an ubuntu VM (KVM) with full disk encryption. Set the data folder to reside on an unRaid share. But I moved the encryption keys to inside the VM, and left symlinks on the unRaid share. That way, I have the encrypted files on an unRaid, but the keys are in an encrypted VM. On VM boot, I have to vnc in and enter the password so the disk can be mounted.

The only annoying thing is, for each new owncloud user account, the encryption keys are put into that user's data folder. So every time a new user account is created, I have to go in, move the keys into the VM and create a symlink. Good thing my company doesn't have too many employees yet, lol.

Well, I had something like that at a previous employer.

They wanted an encrypted Fileserver (so that unauthorized people couldn't get to the data) but this would be running under vSphere with all the bells and whistles and nobody but the IT team (yours truly) had network and physical access. So we encrypted the server, set it up so only the bosses had valid share access, gave them the full disk LUKS encryption keys and password.

So what happens... Every frickin maintenance, I had to remember to "save state" this particular VM, so that I wouldn't need to wait for the bosses, to come in and input the decryption key. In the end, they admit to encryption really wasn't necessary and that we should have at access anyway to do maintenance or emergency fixes. It was a good thing only the people in the boardroom was using this server else it would have been really ugly from the maintenance point of view.

I guess in the end, you really have to:

[*]setup a trusted environment for the server to run in

[*]not trust the environment and trust and safeguards and mitigations

[*]accept that unauthorized physical access (without the extremes of transplanting the HDD) is already a gameover scenario

In regards to your keys in the VM, wouldn't the keys be accessible anyway - since unraid (and the docker) would have access to the keys via the symlink?

Well, I had something like that at a previous employer.

They wanted an encrypted Fileserver (so that unauthorized people couldn't get to the data) but this would be running under vSphere with all the bells and whistles and nobody but the IT team (yours truly) had network and physical access. So we encrypted the server, set it up so only the bosses had valid share access, gave them the full disk LUKS encryption keys and password.

 

 

So what happens... Every frickin maintenance, I had to remember to "save state" this particular VM, so that I wouldn't need to wait for the bosses, to come in and input the decryption key. In the end, they admit to encryption really wasn't necessary and that we should have at access anyway to do maintenance or emergency fixes. It was a good thing only the people in the boardroom was using this server else it would have been really ugly from the maintenance point of view.

 

 

I guess in the end, you really have to:

[*]setup a trusted environment for the server to run in

[*]not trust the environment and trust and safeguards and mitigations

[*]accept that unauthorized physical access (without the extremes of transplanting the HDD) is already a gameover scenario

In regards to your keys in the VM, wouldn't the keys be accessible anyway - since unraid (and the docker) would have access to the keys via the symlink?

 

Haha, I can see how that can be annoying, but in this case I am both the employer and the person maintaining the file server :-) Plus, once I hand over the management (when the company grows enough that we can afford an IT team), I would share the keys with the new person in charge. I wouldn't hire someone I didn't trust for that job anyway.

 

My reasoning for this is, if we end up utilizing a remote server, like a VPS, we would have no control over the environment or the people with direct access to the hardware. While we are not going to be storing government secrets on there, some of the info can still be quite valuable to competitors (ie. trade secrets). I'd rather not take chances on things that can cost the company everything.

 

With regards to the keys, owncloud is now running in the VM that I consider secure. The symlinks point to a location within the VM. So the VM (owncloud) can follow the symlinks, but unRaid cannot because the location is something like /etc/keys

 

I figured there was no way to keep anything secure or encrypted when running owncloud in a docker container.

 

And by the way, this is not my production server (yet), but merely a proof of concept. It is an experiment where I can research the security aspects of data storage and educate myself. At the end, if I'm confident with my knowledge and the results, I may implement the protocols.

 

With all these big name companies getting hacked left and right (especially the recent OPM hack, unbelievable) and viewing the norse map ( http://map.norsecorp.com/ ) I get more than a little paranoid about storing sensitive info anywhere

 

EDIT: Just realized that my previous message was ambiguous. I left out the part about running owncloud in the VM, instead of a docker container. So owncloud running in the secure VM is accessing the data on an unRaid share. Data files are encrypted, and the keys are in the VM.

I'm not sure on how you went on with this, but a word of warning:

It looks like you opted to get a complete package from startssl, including a private key created by them.

Most people might think of this as a mood point, however this little detail compromises everything.

I'll leave it here for everyone else going through the guide.

http://security.stackexchange.com/questions/16685/what-can-an-attacker-do-with-a-stolen-ssl-private-key-what-should-the-web-admin

I think you have the option to provide a csr to startssl. That csr would be created by you, with your private key that you created yourself on your machine and WILL NOT expose to anyone at any time. If they don't provide that option, other free services do.

I'm not sure on how you went on with this, but a word of warning:

It looks like you opted to get a complete package from startssl, including a private key created by them.

 

Most people might think of this as a mood point, however this little detail compromises everything.

I'll leave it here for everyone else going through the guide.

http://security.stackexchange.com/questions/16685/what-can-an-attacker-do-with-a-stolen-ssl-private-key-what-should-the-web-admin

 

I think you have the option to provide a csr to startssl. That csr would be created by you, with your private key that you created yourself on your machine and WILL NOT expose to anyone at any time. If they don't provide that option, other free services do.

That's a security issue with any signed certificate. The private key is meant to be kept private. If it is compromised the system is no longer secure.

The private key should only be kept on the webserver with the correct limited permissions. If you want to store a backup copy in case the server dies, you should keep an encrypted copy.

The only difference between csr vs doing it all on a signing authority is that with csr, your private key is not exposed to anyone but you. But if you have the signing authority generate everything where you enter your details on their website, they generate the private key and let you download it. In other words, your private key is exposed to the signing authority. They don't however keep a copy (they say that if you lose your private key you're toast, so you cancel the certificate and generate a new one). If you don't trust them, then it would be an issue, but I think you have to trust them in the first place because they have the power to sign the certificates and verify. If they wanted to steal your stuff, they could do that in other ways like creating a man in the middle and verifying their fake certificates. They wouldn't need the private key.

Anyway, I sent them the csr in my case but I probably would have trusted them to generate the private key for me as well since I trust them with the signing and everything else.

And a side note, I think most signing authorities provide the csr option because a lot of hosting providers like to create the csr themselves before adding ssl to your account (ie hostgator shared).