Securing Mastodon Instances

#decentralization#infosec#older

This post tries to consolidate information available across multiple websites on the topic of securing a Mastodon server. (Where available, I linked to archive.org’s wayback-machine for long-term access.)

Basic Server Security

  • Use an OS that is supported through frequent security updates
  • Configure automated security updates (instructions for Ubuntu/Debian)
  • Use public key authentication for SSH (guide)
  • Disable password based authentication for SSH (instructions for Ubuntu)
  • Install Fail2Ban (instructions for Ubuntu)
  • Enable the host firewall and only allow incoming traffic on TCP ports 443, 80, and 22 (instructions for iptables)
  • Properly secure access to your hosting provider’s backend with strong passwords and 2FA

Mastodon Admin Account

  • Don’t use the instance’s admin account as your day-to-day micro-blogging account! (Create separate accounts instead.)
  • Use a random password with at least 16 characters for the admin account (store it in a password manager)
  • Enable 2FA on the admin account

Advanced Security Considerations

  • Use a bastion host (aka jump-host) to access the Mastodon server via SSH, and restrict SSH access to the bastion host on the Mastodon server’s host firewall
  • Use a cloud firewall from your hosting provider to only temporarily allow SSH access from your IP address
  • Create a free account with CrowdSec and add the Mastodon server as an instance to auto-block (crowd-sourced) known bad IP addresses
  • Test the server’s SSL/TLS configuration (Qualys SSL Test) and disable weak ciphers (NginX hardening guide)
  • Put a WAF (Web Application Firewall) in front of the Mastodon server (FOSS example: ModSecurity; other options are WAF-as-a-service from Cloudflare or any of the hyper-scalers)
  • Install an EDR agent on the Mastodon server (FOSS example: Wazuh)
  • Restrict egress traffic through a headless OpenSnitch installation

Some relevant links:

← back to the garden