Skip to content

Firewalls and security

Using cloud resources means that you have to do some work to make sure that your deployments are secure. This page contains some suggestions and guidelines for how to do that. If you are unsure about anything related to security for your application or deployment, contact support.

Setting up firewall rules

Firewall rules in OpenStack are also called Security Groups. By default, all external access to a VM is blocked. You can set up a security group under Networks -> Security Groups. A Security Group is just a collection of firewall rules.

Click "Manage Rules" once you have created your security group, then "Add Rule". For e.g. SSH, you will want:

  • Custom TCP Rule
  • Ingress (meaning incoming data)
  • Port 22 (the standard SSH port)
  • CIDR 129.16.0.0/16 (Allow all Chalmers IP:s. Be careful about making this rule more permissive if you are not certain that your machine is locked down.)

Once you have set up a security group and added rules, you can add that security group to a VM by going to Project -> Compute -> Instances, expanding the Actions menu to the far right in the row of the VM, and choosing Edit Security Groups.

Updates

We recommend running automated updates when possible, using packages like dnf-automatic (Rocky, AlmaLinux, Fedora) and unattended-upgrades (Ubuntu, Debian). Once enabled you can configure dnf-automatic to automatically install updates as well as reboot when necessary in /etc/dnf/automatic.conf. Ubuntu comes with unattended-upgrades installed by default, and you can enable automatic restarts if you want at /etc/apt/apt.conf.d/50unattended-upgrades.

Certificates

All IP:s allocated to the OpenStack networks have pre-registered hostnames. They follow the form osXXX-YYY.c3se.chalmers.se, where XXX and YYY are the last two numbers in their IP address. E.g., for 129.16.122.62, the hostname will be os122-62.c3se.chalmers.se. You can use this when requesting certificates with certbot.

To get started with certbot, begin by installing it, e.g. dnf install certbot. Make sure you are not running a web server. Run the command certbot certonly as root, and select the option that makes Certbot host a webserver on port 80. Enter the hostname associated with your IP, osXXX-YYY.c3se.chalmers.se and click enter. You should get a certificate in /etc/letsencrypt/... which you can use for applications that require HTTPS. To auto-renew your certificate, use systemctl enable certbot-renew.timer to start the regular renewal service.

Securing applications

It is important to take application security seriously when allowing access from a wide range of IP:s. For applications that are restricted to e.g. the Chalmers network, it is generally enough to maintain proper password hygiene, to not run unsecured applications (i.e., applications that can be accessed by anyone who knows the URL without a password or token), and to regularly update your operating system and applications.

However, for web applications that are exposed to the world (e.g., the 0.0.0.0/0 subnet), it is much more important to be careful about what you expose and how. In particular, this is true because there are a large number of bots and other web crawlers constantly trying to attack common deployments. Typically, the ports you would expose are port 443 (HTTPS) and port 80 (HTTP). There are a few things to consider here.

  • Don't deploy your application to the public on the same VM that you ssh or otherwise connect to to manage and develop, use a separate jumphost and connect over the internal 10.10.10.0/24 network whcih OpenStack creates for your project. This way you can ensure port 22 is completely blocked on the exposed VM.
  • Your application should be behind a reverse proxy, such as nginx or apache/httpd. In the reverse proxy, you should make sure that port 80 always redirects to port 443. You will still need to have port 80 open to obtain and renew certificates.
  • Make sure that sensitive parts of your application, such as administrative pages, are not exposed publicly, by limiting those pages to the internal 10.10.10.0/24 network of your OpenStack project. Instead, access such pages through e.g. an ssh tunnel from your separate entry VM.
  • It is a good idea to install a security monitoring plugin for your reverse proxy, such as a ModSecurity plugin.
  • The security monitoring plugin can be combined with fail2ban which monitors logs and bans IP:s engaging in suspicious behaviour using a software firewall, like nftables.

Running a VPN

While not necessary in most cases, it can sometimes be a good idea to run a secure VPN, such as wireguard, on a machine in your cloud allocation. There are a few different ways you can use it, but a simple one is to allow you to use the internal IP of the machine when connecting to other machines in your cloud allocation. Wireguard just requires opening a single UDP port on the machine, and reduces or eliminates the need for open SSH ports - you can firewall off port 22 as long as Wireguard is working.

This is most relevant when you have deployments with larger numbers of machines, and/or project members in different locations who don't have access to a single VPN service.