Mastodon and Self-Hosting

Cyberpunk mastodon instances, via Neural Love

With the advent of the Musk era happening on Twitter, some people are leaving that platform behind. My account is still there, but it points to my Mastodon account. [Edit 16Feb2023: My old Twitter account is now deleted.] I won't belabor the point of explaining Mastodon and how it works - searching through your preferred Internet search engine to find a video or article on the topic shouldn't be that hard, especially now.

After odd rumblings in the Twitterverse started earlier this year, I managed to get an invite in April 2022 onto chaos.social, an excellent instance being run by wonderful people (FYI as of right now, registration on that instance has been closed). Even so, I decided to try my hand at running my own instance. This blog post is about my reasons, and some tips if you decide to do the same yourself.

Reasons Why I Self Host

As a security person with an eye on privacy, I tend to lean towards self-managed services where possible. This all started with the hacking group I formed in 1995 called NMRC. The idea of self-hosting started with mail services, and if all of the nmrc.org mail spools were located in my house, I would at least know about it when the government wanted a copy (since they’d break down the front door to get it). Currently the government can approach any mail hosting service with a subpoena (at least in the USA) and get a copy of the spool (yes I am drastically simplifying but you get the idea). The point is that I am the admin, and I will know about it.

I've covered mail server stuff in a blog post about the Sendmail server I manage (yes, I said Sendmail). While slightly outdated, it does give some deeper insight into my reasonings. But really, the main point is that I learn from doing it. I have learned so much setting this up and maintaining it over the years! And truthfully, this is the main reason to self-host Mastodon - learning.

Now I could state that I don't want some perv Mastodon admin reading my DMs or some other similar reason, but as administrators on other social media platforms (including Twitter, Facebook, etc) can already read DMs I really don't see that as an argument unique to Mastodon. The people that talk about how intrusive a Mastodon admin could be probably don't think twice about using Gmail or some other mail service where those services’ admins can read everything anyway. So while I see the privacy point, I can state that is not one of the reasons I self host.

All that being said, I deem Mastodon to be as private as any other social media platform - I assume the information on it is public, and even things that are “restricted” in a DM for example are simply a screenshot away from public disclosure, and I post accordingly.

The Hosting System Itself

The server - rigor-mortis.nmrc.org - was already configured and running nginx. It was already running a couple of domains including www.nmrc.org and already set up with Let's Encrypt. Additionally the host/subdomain itself of rigor-mortis had it's own web server running (also with Let's Encrypt) just sitting there waiting for me to use it. It was simply redirecting any traffic to www.nmrc.org, but the idea was if something came along in the future I could easily adapt it. And then the Twitter collapse began.

As far as hardware itself goes, rigor-mortis is a custom-built PC constructed during the height of the pandemic when I was replacing all of the aging hardware in my humble server room here at the house. It is definitely overkill for its purpose - 6 CPU/12 cores with 16GB RAM and a terabyte of drive space. The server software is Ubuntu 22.04, it's been easy upkeep, and as I intend to limit Mastodon accounts to myself and fellow NMRC members, I wasn't worried about pushing the limits at all.

I’d say if you’ve never set up and run a web server before, it might be easier to set up and run one well before you install Mastodon on it. Get the server up and running first, and then add Mastodon later. The same for the email component - get that running, configured, and fully tested well before Mastodon comes along. If you’re doing all of this new stuff all at once, an odd problem can seem daunting if you’re not even sure which subsystem is the problem. So make it easy on yourself: web server first, then email, then Mastodon.

Steps to Self-Hosting Mastodon

I had read the Learn Linux blog post as well as the Linuxbabe blog post. I more or less followed the steps between the two (which are similar), but things were approached differently as nginx was already installed and functioning. I altered the default nginx.conf file that comes with Mastodon, opting for a few parameters of my own. Here are the relevant changes:

server {
  listen 443 ssl http2;

  server_name rigor-mortis.nmrc.org;
  server_tokens off; ## Don't show the nginx version number, a security best practice

  root /var/www/mastodon/public;

  ## Only modern TLS...
  ssl_protocols TLSv1.2 TLSv1.3;
  ## These ciphers (FIPS 140-3 standard when that "ships")
  ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256';
  ## Regen'd dhparams.pem for 4096 instead of default 1024
  ## openssl dhparam -out /etc/ssl/certsdhparam.pem 4096
  ssl_dhparam  /etc/nginx/ssl/dhparams.pem;
  ssl_ecdh_curve secp384r1;
  ## My choice on the ciphers, not the client side:
  ssl_prefer_server_ciphers on;

  ssl_session_cache builtin:1000 shared:SSL:10m;
  ssl_session_tickets off;

  ## letsencrypt stuff:
  ssl_certificate     /etc/letsencrypt/live/rigor-mortis.nmrc.org/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/rigor-mortis.nmrc.org/privkey.pem;

  ## Common sense params
  add_header X-Content-Type-Options "nosniff" always;
  add_header X-Frame-Options SAMEORIGIN always;
  add_header X-XSS-Protection "1; mode=block" always;
  add_header Referrer-Policy strict-origin-when-cross-origin;
  ## Trying CSP out, style-src barely works
  add_header Content-Security-Policy "default-src 'none'; script-src https: 'self'; object-src 'self'; style-src 'self'; img-src * blob: data:; media-src 'self' data:; frame-src 'self' https:; font-src 'self' data:; form-action 'self';";

...remainder of normal config file...

The rest of the configuration file is pretty standard, and looking at the headers and whatnot using Mozilla Observatory gives it an A+, so fairly decent. There are a few additional tweaks I will be introducing (more CSP additions, etc) to lock it down even further, but it works for now.

Other Additions

For administrative access to the host itself, this is via SSH access which is limited to a single address that is the gateway from my internal network. I use both SSH keys as well as Duo Security's Duo Unix to help lock things down, as it provides "out-of-band" push as opposed to TOTP for both SSH access as well as even using "sudo". For more on how to do this, check out this blog post. Ubuntu upgrades are automated, and very soon I will work out all of my Ansible configurations for easier backups and other administrative tasks, including Mastodon upgrades and backups (for now, it’s manual).

I don't have a way to enforce it, but all NMRC members will have to use 2FA on their Mastodon accounts. I did set up extra toot capacity to get the default toot limit increased from 500 to 5000 characters. Media is set up to "expire" locally after 14 days to help manage space, although I will probably lengthen that as initial disk space usage is such a low percentage of existing storage space I am not worried about it at all.

Moderation

I’m not going to cover this in great detail, as I already understand my very small user base and we are all pretty much on the same page. If you need more information, check out this blog post from the main moderator from chaos.social to get an idea. If you’re considering a larger instance or making it completely open to anyone to sign up, you’re going to have to deal with possible unpleasantness, and this might be enough to completely put you off of the idea of self-hosting.

The one thing I will recommend is going ahead and setting up an “About” section, your server “rules”, and a privacy policy - even for a single user instance. This will help give others an idea about the overall vibe of the site, and sometimes when people are looking to follow someone on a small instance they might decide to check out your instance to see if you actually care about things like moderation even if it is self-moderation. I’ve also set up a number of domain blocks that are public, so again it tells a bit of a story about the overall philosophy of the site. If you’re unsure where to begin, check out a few other instances with a vibe you like and see what they’ve written, and simply adapt it to your needs.

Final Thoughts

I am lucky in that I pay for 5 static IP addresses (via an AT&T business account) and already had the host in place I’m now using for Mastodon. Additionally, as I have run multiple servers under constant attack for well over two decades out of my home, so this is not any more work than anything else I already do. In fact, the amount of time I have freed up by not doomscrolling on Twitter more than makes up for any additional time spent administering a Mastodon instance anyway, so for me it is totally worth it.

Granted this is not a taxing instance when it comes to resources. This setup works out of the box easily for a handful of users, but if you were going to scale things up, I’d recommend checking out this blog post talking about scaling up Mastodon. As you can see, there was nothing wrong with chaos.social and where I was as it is a well-managed and well-moderated instance.

I do realize running your own server or instance, whether it be Mastodon or something else, is not for everyone - especially if there will be other users on the system. But if you're up for it and have the resources (hardware, money for a cloud instance, etc) it could end up being totally worth it.