Securing your cloud instances
Learn how to secure cloud instances using firewalls, gateways, overlay networks, and threat intelligence tools like CrowdSec and Coraza for robust protection.
I don’t think I have to expand too much on securing your cloud instances, no one wants to be a ransomware victim or have all their info disclosed or deleted, so lets explore a bit on how we go at it.
List below is by no means extensive, and you should research what works best for you and your environment. If you find anything inaccurate or would like to contribute new options or experiences, you can do so at the comment section at the end.
Some links may be affiliate links that keep this site running.
Firewalls
Firewalls are a great first line of defense, the simplest firewalls block unwanted connections and close off services which may be exposed to the world. The more complex firewalls would look into reputations of IP addresses that are initiating connections, what those are trying to communicate with and other indicators.
Setting up firewalls is not hard, pretty much all operating systems today come with a built-in firewall that you can configure. As Ubuntu and Debian are the most common OS in the selfhosting community, I will mostly focus on those and will cover OPNSense as well.
UFW
UFW stands for Uncomplicated Firewall, it is basically a management layer for the more complex iptables firewall that comes shipped with Debian and Ubuntu. UFW is installed by default on Ubuntu but can be easily installed on Debian with apt install ufw.
Now, it is important to mention that UFW does not abstract everything iptables can do and you might still have to dig a bit into iptables or configuration files of UFW.
The most basic commands you should know are:
-
ufw add <port>- Allow access on all interfaces to a specific port -
ufw status numbered- Show all rules configured -
ufw enable- Enables UFW on the system -
ufw disable- Disables UFW on the system -
ufw delete X- Deletes a specific rule, you should use this withufw status numbered, but do note, that if you delete a lower level rule, the numbering will change, so make sure to check numbers again if you delete more rules.
Everything you don’t use or want to publicly expose should be blocked off by. My bootstrapping command of new instances - which are mostly Ubuntu is:
1
2
3
ufw allow in on wt0
ufw default deny incoming
ufw default allow outgoing
-
ufw allow in on wt0is a command that allows connections over thewt0interface, which is in my environments is a NetBird network - I will expand on this later on. -
ufw default deny incoming- is a command that blocks ALL incoming traffic to your instance. -
ufw default allow outgoing- is a command that allows ALL outgoing traffic from your instance to the world - You might have to tune this later if you want very granular control of all the traffic.
More information on UFW can be found here
OPNSense
OPNSense is a firewall appliance, which is open source. You would not be running this on top of your operating system, but you can run this as a router and firewall if you are running virtualization through Proxmox/Hyper-V/KVM/XCP-ng and others - The virtual appliance would be routing virtual networks in this instance - which does work well for lots of different use cases.
«< Insert Graphic HERE »>
I find OPNSense to supplement UFW in many cases, especially when I am routing in internal networks through a DMZ host such as HA Proxy. The reverse proxy is isolated in it’s own isolated network with very specific rules which allow it to communicate with instances which are in an “internal” virtual network and may have many more rules of interaction with other hosts.
Gateways
There are many gateway options, also called as Bastion host/jump servers/RDP servers and other names.
The idea here is that your workloads would only allow access from your gateway and will block any other access from others, a simple UFW rule would look like this:
1
ufw allow in from 123.123.123.123
The rule above, even though it seems restrictive, it’s actually not. This allows ALL access from the IP address listed there, if we are running databases and other services, those services are exposed to that IP. We would want to probably tune this rule a bit more, if we are running a linux machine, we would restrict this rule a bit more:
1
ufw allow in from 123.123.123.123 proto tcp port 22
This restricts access only to port 22 and protocol TCP to our instance. There are a few more steps to secure this more properly, and we will take a look at those.
warp-gate
A notable project here is warp-gate, it is a SSH gateway that allows you to segregate your SSH/HTTP/MySQL and Postgres databases AND record sessions. It allows for SSO integration with Keycloak and there are several other security capabilities you can set. We love the project and support it as a sponsor.
Windows RDP
This is also quite a simple option, You can set up a windows machine that only allows a connection from your IP or a Tailscale/NetBird network and then that machine connects to the other ones. It’s quite important here to keep your RDP secured properly, but that is a post for another day.
Securing Access
keys
You should be using private and public keys (click here for a great explanation about it) to secure your instances, it’s a very low barrier to implement. When you log in, your SSH client will need to present the key to gain access - without the key, you won’t be able to login or if it’s stolen, others can login with it - it’s imperative you keep those safe and secure.
You could supplement also with a password, but when you run automations and have several hundred severs to manage it becomes counter productive.
Yubikey
Yubico have great instructions on how to use Yubikeys to secure SSH Access, you can use the keys as OTP/Passkeys/Certificates for authentication, this simplifies a lot of the management and can be easily automated with scripts.
SSO
There are several solutions out there that can integrate with your SSO, warp-gate that we mentioned above is one of those. In our implementation, we use Keycloak to authorize sessions that are connecting through warp-gate. Other options would be Ubuntu OIDC, which as of the time of writing this only works with Microsoft Entra ID. SmallStep SSH for short lived certificates and there are many others which also offer enterprise solutions.
User Management
If you are running your instances by yourself, and no one else is connecting to those, while it may be unpopular opinion to some - it is OK to run things as root/Adminstrator.
Where you need to be careful is to not break the functionality of the OS, so make sure to take proper backups and check what you do 3 times. rm / -rf is not a good command to be run with a privileged user.
SSO in combination with access groups is a great way to control who can access a server, you will need to integrate one of the solutions above as SSO only does the authentication part (meaning checking you are who you say you are), while the authorization (what you can do) is done on the OS. Creating groups with access right, even sudo rights is an important part, but it’s quite a lot to unpack for a short blog post. I recommend Jay Lacroix book “Mastering Ubuntu Server” if you want to dive deeper on it.
Overlay Networks
Overlay networks are usually encrypted and virtual networks that can tie in your servers in a secure way. There are quite a few options out there, majority are based on WireGuard and are peer-to-peer, but not all.
We like NetBird, and we have written in the past about it, the ability to selfhost all the components and be dependent from the eyes of large corporations, have unlimited users, SSO tie-in and ease of installation got us hooked.
Tailscale is an option as well if you want a fuss free option (up to 3 users and 100 devices) if you don’t mind having an organization your info on all that you run. Headscale is the alternative if you want to host it yourself.
ZeroTier takes an interesting approach but the management is quite cumbersome is we have found out previously, but it works well.
Open Ziti is more of an enterprise option as you have to route traffic through dedicated “routers” and it is not a fit to many VPS providers where traffic is counted per instance.
Overlay networks also allow you to create secure tunnels to have your instances that are running at home or anywhere else to be exposed through a reverse proxy that directs you to an internal DNS name.
Reverse Proxies
Reverse proxies allow you to expose specific services and their ports behind a web service, what a reverse proxy does is to listen to requests on a port and then tunnel that port to the service that you choose. It can help you pack multiple services behind a domain and subdomains as well as run additional components such as modescurity or coraza and crowdsec.
NPM (Nginx Proxy Manager)
A well written app that has a web interfaces and integration of ACME client for generation of certificates, it’s quite simple and gets the job done well. Has an extremely poorly documented API
NPMPlus
This project extends NPM and does several rewrites to the code, it also integrates CrowdSec and ModSecurity into it, allowing you to better protect applications against various web attacks and bad reputation IPs.
HAProxy
A tad more complicated but quite performant reverse proxy, everything is controlled through a config file and it can scale very well as well as do load balancing between your applications.
nginx
The well known web application and reverse proxy, projects like SWAG by linuxserver are built on top of this, this requires maintenance of several configuration files and may require some expert knowledge.
Apache
A well known web-server, less known for ability of reverse proxy, but it can do the job, albeit mixed reports on performance once it works in that mode, might also require some more expert knowledge to fine tune everything.
Zoraxy
New kid on the block, this is really fit for home environments, I can’t see how this would play well in a large environment due to the more complicated web interface than NPM, and maintenance of all the various options out there.
Threat Intelligence & Vulnerabilities
Even with properly configured firewalls, secure gateways, and strict user management, vulnerabilities can still slip through the cracks. That’s where threat intelligence and vulnerability management tools come into play. They help identify, analyze, and mitigate potential threats before they compromise your systems.
CrowdSec
CrowdSec is an open-source, collaborative intrusion prevention system that leverages community-driven threat intelligence. It analyzes behavioral patterns to detect suspicious activities like port scans, brute-force attacks, and credential stuffing. Once a threat is identified, CrowdSec can automatically block the offending IP addresses using “bouncers,” which are plugins that integrate with your firewall, reverse proxy, or other network components. The beauty of CrowdSec lies in its crowdsourced approach—when one user detects a malicious IP, the information is shared anonymously with the community, enhancing everyone’s security.
Coraza
Coraza is a high-performance, Golang-based web application firewall (WAF) engine that emulates ModSecurity’s functionalities. It provides robust protection against common web attacks such as SQL injection, cross-site scripting (XSS), and remote code execution. Coraza is highly efficient and can be integrated seamlessly with various web servers and reverse proxies. It utilizes the OWASP ModSecurity Core Rule Set (CRS), offering a solid foundation for detecting and blocking malicious requests. While it may require some tuning to fit your specific environment, Coraza is a great tool for safeguarding your web applications. Under the main github repo, you can find plugins that’ll help Coraza work better with your applications, such as this one for NextCloud.
NAXSI
NAXSI (Nginx Anti XSS & SQL Injection) is an open-source WAF module specifically designed for Nginx. It operates on a negative security model, blocking requests that match predefined malicious patterns while allowing legitimate traffic to pass through. NAXSI is lightweight and efficient but does require initial tuning to minimize false positives. It’s particularly effective for protecting against injection attacks and is a solid choice if you’re already using Nginx as your reverse proxy.
ModSecurity
ModSecurity is one of the most widely adopted open-source WAF solutions. It can be deployed with Apache, Nginx, and IIS servers to provide real-time monitoring, logging, and access control. ModSecurity uses the ModSecurity Core Rule Set to detect and block a broad spectrum of web attacks. While powerful, ModSecurity can be resource-intensive and may necessitate significant configuration and tuning to optimize performance and reduce false positives. It’s a veteran in the WAF arena and offers extensive customization for those willing to invest the time.
What do I do?
Overlay Network
All of my services are connected together by NetBird, Netbird offers access control onto which instances can talk to each other on which ports which we utilize quite extensively.
SSO
Keycloak is a great choice and is maintained well, once you get past the learning curve - I recommend the book “Keycloak - Identity and Access Management for Modern Applications” to get a good starting knowledge on it, though some parts of the book are a bit outdated as Keycloak UI changed a bit. Everything we can tie to the SSO we do.
Logins to the SSO are authorized with Passkeys, we don’t use passwords here.
Firewalls
We use both OPNsense and UFW to secure our instances, as mentioned before, we bootstrap all of our instances to block all incoming, allow all outgoing, and allow all connections through NetBird, which is later controlled through the access layer. OPNSense has Crowdsec bouncer installed on it to block unwanted IPs.
Monitoring
All of our instances report to Wazuh that is selfhosted and has alerts configured to it, this is also where we make sure that our instances are up to a baseline. Future plan would be to integrate actions.
Gateway
All the management of instances goes through warp-gate, where sessions are recorded, we use keys for specific users and all authentication is done through the SSO.
User Management
We have a dedicated user that can login on most systems that is done for servicing, the user is mostly limited to updates/upgrades and reading logs.
Threat intellignce & Vulnerabilities
We run HA Proxy that has Coraza and Crowdsec loaded on it, Coraza helps with app vulnerabilities and does require quite some heavy tuning to it. Crowdsec is an additional layer in case there’s something that wasn’t blocked earlier.
Reverse Proxy
I’ve checked pretty much everything on the list and decided to go with HA Proxy, several reasons for it: performance, ease of implementation and integration of crowdsec and coraza over modsec. It also works well with Certwarden (below) as it allows us to have a folder with the specific certificates and HA Proxy matches the certs by itself according to the domain redirection.
Certificate Managment
We use Certwaden for managing certificate renewals and distributing those to all of the services that we run, check out the project, I’ve also contributed a few scripts for automating different parts.