Document some security guidelines for VM deployed on Cloud Compute

[gwarf]

We could provide some security guidelines to Cloud Compute users, as an example:

• if a service is ACTIVE on port 80 THERE MUST BE a redirection (automatically or not)
  to port 443
• if a service is ACTIVE on port 443 MUST
  • ACCEPT only the following protocols:
    • TLS 1.2
    • TLS 1.3
  • REJECT the following protocols
    • SSLv2
    • SSLv3
    • TLS1
    • TLS1.1

The following tools are available:

• to safely configure the server: https://ssl-config.mozilla.org/
• to check the solution adopted: https://github.com/drwetter/testssl.sh/tree/3.0

Reference https://ggus.eu/index.php?mode=ticket_info&ticket_id=159474.

Thoughts/opionons?

[EGI-ILM]

For the latest application I developed (although I made this decision back in ~2016-2018) I considered some extra things. I put them here in case you want to consider them:

• Forced TLS 1.2 (now 1.3 is also an extended option).
• Preferred exchange of keys via ephemeral ECDH (forward secrecy is guaranteed and it uses NIST P-256), authenticated by 2048-bit key RSA certificates and supported by SHA-384 (as PRF).
• Actual data encryption conducted with AES-256 in GCM mode (which implements encryption and authentication from the same key). AES-128 would be also acceptable (both key sizes use the same block length of 128 bits). There were more theoretical attacks for AES-256 (e.g. there is a known weakness in the key expansion, but it requires related keys), but I chose the longer keys.
• Avoid CBC mode since CBC in TLS is considered susceptible to timing attacks.

[enolfc]

👍 What's the right place for this information? Should we create a security section in the cloud compute docs?
And: can we technically enforce or at least detect if someone has a weak config?

[gwarf]

So detecting can be done if we start scanning the endpoints for this... :)
Currently some NREN are doing this, it's not the first time we get a report from them about having some services not properly configured and possibly at risk.
But it's discussions for another place (there have been discussions related to using Nessus to do similar stuff).

But I think we should at fist at least provide somer proper guidelines for our FedCloud users, and they should be easily discoverable from the documentation on creating VM/using Cloud Compute, so I would start by a page under https://docs.egi.eu/users/compute/ or https://docs.egi.eu/users/compute/cloud-compute/, and linking to that page from other places.

For the SSL config I would not dig into being that specific as documenting and recommending ourselves specific protocols, or maybe only recommending on protocols as it's easier, but I would probably avoid digging into the specific algorithms/ciphers, and mainly suggest to use a configuration generated from a generally accepted/recognised source like https://ssl-config.mozilla.org/ (like suggesting the modern one) and suggest to validate it with a service like https://www.ssllabs.com/ssltest/analyze.html.

Resource providers should definitely look into using services like https://www.shodan.io/ and https://www.shadowserver.org/.

We also have some guidelines for software development at https://docs.egi.eu/internal/guidelines-software-development/, that were meant to be for our central service providers, once we have something for our cloud users, we could think of having something like guidelines for service deployment?