Enhance the security of your MAAS setup
Errors or typos? Topics missing? Hard to read? Let us know!
This guide aims to offer actionable steps for fortifying your MAAS installation. By implementing these suggestions, you not only improve the resilience of your setup but also ensure a more secure operational environment.
For a secure MAAS setup, you need to regulate the network ports accessible on your rack controllers. Below is a table outlining the essential TCP ports for MAAS communication:
|HTTP traffic with each region controller. In HA environments, port
80 is commonly used.
|Allocated for MAAS internal services.
|Designated for rack HTTP communication.
|Reserved for region workers (RPC).
To further harden your security, consider configuring your firewall^ to allow only the ports MAAS uses. For example, if you’re using
ufw, the commands would look like:
sudo ufw enable
sudo ufw default deny incoming
sudo ufw allow 5240
sudo ufw allow 5248
sudo ufw allow 5241:5247/tcp
sudo ufw allow 5241:5247/udp
sudo ufw allow 5250:5270/tcp
sudo ufw allow 5250:5270/udp
Note that the above commands are illustrative; your specific setup and MAAS version may require different settings. Always refer to the relevant firewall documentation for your system.
Pro tip: This example assumes you’re using
ufwfor your firewall settings. Always consult your system-specific firewall manual for the most accurate instructions.
Enhancing both security and availability of your MAAS deployment can be achieved by using a TLS-terminating load balancer. For this purpose, we recommend HAProxy^. This guide outlines how to establish one.
Sidebar: Understanding TLS-terminated load balancing
Within MAAS, a load balancer routes incoming Web UI and API requests across several region controllers. This lessens MAAS workload and reduces user request latency. This is usually part of a high-availability (HA) setup, but MAAS also supports other HA configurations for BMC access and DHCP.
A TLS-terminated load balancer carries out encryption and decryption as close to the edge of the network as possible, in this case, right at the load balancer. While “SSL” is an outdated term, we opt for “TLS,” or Transport Layer Security. TLS aims to ensure both privacy and data integrity between multiple applications, achieved through symmetric cryptography and message authentication codes.
Firstly, amalgamate your SSL certificate (
mysite.com.crt) and key pair (
mysite.com.key) into a single PEM file:
cat mysite.com.crt mysite.com.key > mysite.com.pem
sudo cp mysite.com.pem /etc/ssl/private/
Depending on your certificate authority, you may also need to include your root and intermediate CA certificates in the same PEM file.
To deploy HAProxy, run the following:
sudo apt-get update
sudo apt-get install haproxy
/etc/haproxy/haproxy.cfg. In the
global section, set the maximum number of concurrent connections:
maxconn <number of concurrent connections>
Additionally, include the following line to configure temporary DHE key sizes:
defaults section under
mode http, add:
Finally, specify the frontend and backend settings to manage connections between HAProxy and MAAS:
bind *:443 ssl crt /etc/ssl/private/mysite.com.pem
reqadd X-Forwarded-Proto:\ https
timeout server 90s
server localhost localhost:5240 check
server maas-api-1 <ip-address-of-a-region-controller>:5240 check
server maas-api-2 <ip-address-of-another-region-controller>:5240 check
Apply these changes by restarting HAProxy:
sudo systemctl restart haproxy
Optional features like HAProxy logging^ can also be enabled, depending on your needs.
Four types of log files can assist in pinpointing security problems:
- Firewall logs
- Web server logs
- MAAS log files
- System log files
This guide offers insights and references for each category.
Identifying security red flags in UFW and iptables logs is more of an art than a science. However, here are some key patterns to help:
Be wary of traffic probing ports not linked to any application service. Such behaviour often signifies a port scanner in action.
blocked incoming tcp connection request from 18.104.22.168:8240 to 22.214.171.124:6002
Cross-reference unusual port numbers against databases of known hacker tools.
Repeated, failed access attempts from the same domain, IP, or subnet suggest malicious intent.
blocked incoming tcp connection request from 126.96.36.199:49343 to 188.8.131.52:31337
Messages from within your network may indicate a Trojan horse at play.
blocked outgoing tcp packet from 192.168.23.100:5240 to 184.108.40.206:443 as FIN:ACK received, but there is no active connection.
To analyse web server activity, employ a log analysis tool or inspect raw logs stored in paths like
/var/log/apache2. Things to keep an eye on include:
- Multiple, rapid-fire requests
- Multiple failed login attempts
- Requests for non-existent pages
- Signs of SQL injection and Web shell attempts
|Look for failed logins in…
For example, a legitimate login request might resemble:
2020-03-31 21:17:56 regiond: [info] 10.132.172.1 GET /MAAS/accounts/login/ HTTP/1.1 --> 200 OK
In addition to the items mentioned above, you should be aware of a few other ways to harden MAAS.
You should pick good passwords and store them securely (e.g. in a KeePassX password database). Perform user administration only via the web UI. Only share the
root user passwords with administrators.
MAAS configuration files should be set to have permission
640: readable by logins belonging to the
maas group and writeable only by the
root user. Currently, the
regiond.conf file contains the login credentials for the PostgreSQL database used by MAAS to keep track of all machines, networks, and configuration.
|chmod 640 on files…
|About snap security
Snaps are fully confined or ‘sandboxed,’ offering inherent security for the enclosed application. For more detailed information, see this snap blog^.
When you add a new rack or region controller, MAAS asks for a shared secret it will use to communicate with the rest of MAAS. This secret is also exposed in the web UI when you click the ‘Add rack controller’ button on the Controllers page. MAAS automatically generates this secret when your first region controller installed, and stores the secret in a plain text file. This file is automatically protected with the correct permissions, so there is no need for any action on your part.
As a MAAS administrator, it’s crucial to avoid storing secrets associated with your MAAS instance in the database. This includes secrets like the OMAPI key and the RPC secret.
Beginning with version 3.3, MAAS secrets are stored in HashiCorp Vault.
Vault employs identity for securing secrets and encryption keys. Its core component is the
kv secrets engine, which utilizes key-value pairs to store secrets within an encrypted storage managed by Vault. You can explore more about secrets engines if you’re interested.
Vault safeguards the secrets engine using a barrier view, creating a folder with a randomly-generated UUID as the absolute root directory for that engine. This prevents the engine from accessing secrets outside its UUID folder.
If you need help implementing MAAS security, please contact us. We will be happy to assist you in arranging security consulting appropriate to your needs.
Last updated 27 days ago.