Viewable by the world

Services running in the cloud will not have the Lab's security protections applied to them, so we've made the below recommendations for configuring your cloud services to try to provide some visibility and protections. Note that these recommendations are evolving as we learn more about uses of cloud services at LBNL.

1. Enable Multi-Factor Authentication or use LBL's Single-Sign On Service

For AWS, see "Authenticating to Amazon AWS Using login.lbl.gov".

For other Cloud Services, enable Multi-Factor Authentication for the management dashboard. This requires the use of either a software token (like the Google Authenticator app for your phone) or a physical hardware token (like a Yubikey) in addition to a password in order to login to your account, and makes it much more difficult for attackers to compromise your account even if they're able to steal/crack your password. You should ensure anyone who can login to the management dashboard of your cloud service must use MFA.

If someone gains unauthorized access to your management dashboard, they can often compromise any VMs you have running (by default there may be root or service accounts accessible via web console after authenticating to the management dashboard).

2. Restrict open services (ports/protocols)

Only allow inbound connections to the minimum ports/protocols from the outside world and deny all others. For example, a web server may need ports 80/tcp (HTTP) and 443/tcp (HTTPS) open to the world, but 22/tcp (SSH) should be restricted to at least the Lab's IP addresses (if not specific subnets/computers at the Lab).

Ideally, you should do this via the Cloud Service Provider's native firewall (example, AWS Security Groups or GCP Firewall Rules) so that it exists independent of the individual instances, VMs, containers, or cloud resources you use and can be re-deployed more easily across a large number of resources. However, in a pinch you may need to configure this on something like a host-based firewall (iptables, firewalld, ipfw, etc).

3. Send syslogs to Cyber Security 

We've set up a syslog server with Stunnel so you can send logs to us over an encrypted tunnel crossing the public internet. First, see our instructions on the LBNL Central Syslog Server page for generally setting up syslog, then follow the instructions under "Encryption with Stunnel" for setting up the encrypted tunnel. This provides us visibility into attacks against your server from the outside world. Note also that you'll want to set the Hostname in your VM so we can easily identify it among the other logs we receive.

4a. Put HTTP/HTTPS services behind the Lab's Cloudflare reverse proxy

If possible, arrange to have HTTP/HTTPS services placed behind the Lab's reverse proxy, see: Open a Web Server to the Internet. In some cases, this may not be possible, see below for an alternative.

4b. Alternative: Configure web application logging to syslog

If you're not able to place HTTP/HTTPS services behind the Lab's reserve proxy, and you operate a web server, your web application likely logs to a separate file by default (for example, Apache's access_log or ssl_access_log), which won't get sent to us unless specifically configured to do so. However, you can configure this to log to us over the above encrypted tunnel:

    1. Example documentation for Configuring Apache to log to syslog. 
      1. Facility and priority are largely up to your discretion, though we recommend: local7.info
      2. You may need to place the CustomLog config in your VirtualHosts config. Some packages may have a default VirtualHost even, for example, in /etc/apache2/sites-available/000-default.conf or default-ssl.conf
      3. If you've already configured your syslog to send to Cyber Security above, you can generally stop after step #6, Save the Apache configuration file.

6. Block public access to private resources

This is particularly an issue with AWS S3 buckets, which may default to being public (readable by anyone). You should assume any resource is public by default unless you have explicitly changed the setting and tested it (confirmed it's accessible from where it should be, and it's NOT accessible from where it shouldn't be).

    1. AWS S3 example: Go to the S3 dashboard, select your bucket and click "Edit public access settings". Check the box for "Block all public access".
  • No labels