Server Setup Basics for Self Hosting

This is a post I’ve been meaning to do for a while. While it’s simple to
explain how to set up an app for self-hosting, it’s pointless to host an app on a weak foundation.
It’s a massive pain in my ass to start every how to with a section on server setup, so I’m
also making this post for myself as a reference on how I like to set up a server for apps I’m
hosting. I’ll start with basic stuff like proper login with SSH and non-root user set up and making
users for each app. I’ll also touch on NGINX setup, some quality of life tools that make server
management easier, log management and basic network security.
‍

• SSH

• Users

• Logs

• Backups

• Basic Network Safety

• NGINX

• Quality of Life Tools

• DNS

• Docker

SSH

First is login. You’ll need a way to access your device securely. Don’t even
mess with username and password. You want to use SSH (Secure Shell) and make sure that SSH is the only
way to log in. To do that, you’ll need an SSH key and a new user account. On a newly provisioned VPS,
you’ll be logged in as root, and you want to protect the root account. First off on the VPS or
remote machine make a new regular user with and add them to the “sudo” group with:

sudo adduser newuser

sudo usermod -aG sudo newuser

Now on your local machine run:

ssh-keygen -t ed25519 -C "[email protected]"

Follow the instructions, it should ask you where you want to save the file and
if you want a password or not. Make sure you set a string one. To copy the public key over to your
server run on your local machine:

ssh-copy-id -i ~/.ssh/id_ed25519.pub newuser@your_server_ip

Keep in mind newuser@your-server-ip is the username and the remote device you
are trying to copy your public key into. When you get prompted for a password, it will be the password
for the account on the remote device, NOT the password you just made for the SSH key. Once verified, it
will copy over the public key, and you can now log in Via SSH. To turn off username and password login,
type in:
‍

sudo nano /etc/ssh/sshd_config

Find these values and set them as you see them here.
‍

Port 2222     # Change default port (use a number between 1024 and 65535)
PermitRootLogin no                 # Disable root login
PasswordAuthentication no          # Disable password authentication
PubkeyAuthentication yes           # Enable public key authentication
AuthorizedKeysFile .ssh/authorized_keys # Specify authorized_keys file location
AllowUsers newuser                 # Only allow specific users to login

This disallows every login method besides SSH under the user you copied your
public key to. Stops login as Root and only allows the user you specify to log in. Hit CTL+S to save and
CTL+x to get out of the file editor. Restart SSH:
‍

sudo service ssh restart

This might boot you out of the session. If it does, this is a good time to test
the other login methods to see if they are declined before continuing. Also, it should go without
saying, but you need to keep the private key safe and if you lose it you will not be able to get in
remotely anymore.You can further lock down your login with:
‍

Protocol 2                 # Use only SSH protocol version 2
MaxAuthTries 3             # Limit authentication attempts
ClientAliveInterval 300    # Client alive interval in seconds
ClientAliveCountMax 2      # Maximum client alive count

Now, let’s dive into users a bit more and see how we can leverage them for
a bit of organization and security.

Users

sudo useradd -rms /usr/sbin/nologin -c "a comment" youruser

This command makes a user and gives them a home directory for app
data but does not allow login as the user. The -c flag is optional, but It’s nice to know what the
user is for, like “Running Nextcloud” or whatever. Clone app files into the /opt directory with:
‍

sudo mkdir /opt/myapp

This command makes a user and gives them a home directory for app
data but does not allow login as the user. The -c flag is optional, but It’s nice to know what the
user is for, like “Running Nextcloud” or whatever. Clone app files into the /opt directory with:
‍

sudo chown appuser:appuser /opt/myapp

Ok, with this your login is locked down, and you should have a decent
idea about how to use users. Next is logs.
‍

Logs

Logs are crucial to system administration. They keep track of system
health, help troubleshoot issues and detect threats. So you want to set up proper log rotation so they
do not take up too much space on your system, plus are easier to read and manage. To set up proper log
rotation, you want to edit the logrotate.conf file located in /etc. Individual application
configurations are typically stored in /etc/logrotate.d/, so an example configuration for NGINX would
look like:
‍

/var/log/nginx/*.log {
    weekly
    missingok
    rotate 52
    compress
    delaycompress
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
    endscript
}

This configuration rotates logs weekly, keeps 52 weeks of logs,
compresses old logs, makes new logs with the right permissions and then signals NGINX to reopen log
files after rotation. You can test it with:

sudo logrotate -d /etc/logrotate.conf

This will show what it will do without actually rotating logs. With
this all set up, you can start to do more advanced stuff like triggering alerts based on log entries.
Now this is good for a single server but if you manage more than one server it’s a good idea to
look into tools like Grafana Loki, Graylog and Fluentd. I won’t go into detail here, but if
you’re looking to up your log game, these a decent place to start.
‍

Backups

Basic Network Safety

The next step in securing a server is to lock down ports that need
don’t need to be exposed to the internet and banning things that try to log in when they should not. UFW
and Fail2Ban are two tools that are in widespread use for this. They are simple and easy to use, UFW
lets you set traffic rules for ports and Fail2Ban will ban and IP address when it knocks on a port they
should not be or if they fail to log in after some predefined rules. UFW or uncomplicated firewall often
comes preinstalled on a lot of VPS services, same with Fail2Ban, but if you are on a new machine and
you’re unsure, run:
‍

sudo apt install ufw

sudo apt install fail2ban

UFW

We will worry about Fail2Ban later, for now let’s focus on UFW
setup. First run some default policys with:

sudo ufw default deny incoming
 
sudo ufw allow outgoing

This is considered best practice, as it follows the “the least
privileges” idea I touched on earlier. It reduces attack surface on your machine and gives you precise
control over what you do expose. In short, this configuration creates a balance between security and
functionality. Your server can reach out to the internet as needed, but external entities can only
connect to your server in ways you’ve explicitly allowed. Now let’s allow some stuff
in.
‍

sudo ufw allow ssh
sudo ufw allow 80
sudo ufw allow 443

If you are going to be running a web server, you need port 80 and
port 443 open. 80 is HTTP and 443 is HTTPS. By default, port 22 is SSH, if you changed this you need to
specify the port instead of using the “allow ssh” command. Here are some other useful commands:

‍

#List rules with numbers:
sudo ufw status numbered
#Delete by number:
sudo ufw delete NUMBER
#Delete by rule specification:
sudo ufw delete allow 80
#You can allow connections from specific IP addresses:
sudo ufw allow from 192.168.1.100
#You can also only allow an IP to connect to a specfic port with: 
sudo ufw allow from 192.168.1.100 to any port 22
#If you neeed to allow a range of ports: 
sudo ufw allow 6000:6007/tcp
#To further protect from brut force attacks you can rate limit specific ports with: 
sudo ufw limit ssh
#This would limit port 22 to 6 connections in 30 seconds from a single IP. To see the status of the firewall you can use: 

#Adding this goves you more info
sudo ufw status verbose
#and to reset incase you need to start over: 
sudo ufw reset
#and to enable and disable: 
sudo ufw enable 
sudo ufw disable 

#finaly to enable logging and adjusting the log level: 
sudo ufw logging on
sudo ufw logging medium # levels are low, medium, high, full 

On to Fail2Ban now.

Fail2Ban

‍
The main configuration is located in /etc/fail2ban/jail.conf, but
it’s recommended to create a local configuration file:
‍

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

sudo nano /etc/fail2ban/jail.local

‍
There are some basic settings in the [DEFAULT] section of the
jail.local section those are:
‍

bantime = 10m
findtime = 10m
maxretry = 5

‍
Ban time is how long an IP is banned. Find time is the time frame in
witch Fail2Ban looks for repeated failure, and max retry is the number of failures before an IP is
banned. You can tune these as you see fit. There are also custom jails you can set, Fail2Ban also
supports jails for commonly used services like SSH. There are even more steps you can take, but I think
this covers the basics.

NGINX

ln -s /etc/nginx/sites-available/yoursitefile /etc/nginx/sites-enabled

Then reload nginx and double check nginx status with:
‍

sudo systemctl reload nginx

sudo systemctl status nginx

Basic Static Website Configuration:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    root /var/www/example.com/html;
    index index.html index.htm;
    location / {
        try_files $uri $uri/ =404;
    }
    # Security headers
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "no-referrer-when-downgrade" always;
    add_header Content-Security-Policy "default-src 'self' http: https: data: blob: 'unsafe-inline'" always;

    # Logging
    access_log /var/log/nginx/example.com.access.log;
    error_log /var/log/nginx/example.com.error.log warn;

    # SSL configuration (uncomment after running Certbot)
    # listen 443 ssl http2;
    # listen [::]:443 ssl http2;
    # ssl_protocols TLSv1.2 TLSv1.3;
    # ssl_prefer_server_ciphers on;
    # ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;

    # Certbot will add its own SSL certificate paths
    # ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    # ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

Proxy Pass Configuration:

server {
    listen 80;
    listen [::]:80;
    server_name app.example.com;
    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
    # Security headers
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "no-referrer-when-downgrade" always;
    add_header Content-Security-Policy "default-src 'self' http: https: data: blob: 'unsafe-inline'" always;

    # Logging
    access_log /var/log/nginx/app.example.com.access.log;
    error_log /var/log/nginx/app.example.com.error.log warn;

    # SSL configuration (uncomment after running Certbot)
    # listen 443 ssl http2;
    # listen [::]:443 ssl http2;
    # ssl_protocols TLSv1.2 TLSv1.3;
    # ssl_prefer_server_ciphers on;
    # ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;

    # Certbot will add its own SSL certificate paths
    # ssl_certificate /etc/letsencrypt/live/app.example.com/fullchain.pem;
    # ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;
}

WebSocket Upgrade Configuration:

server {
    listen 80;
    listen [::]:80;
    server_name ws.example.com;
    location / {
        proxy_pass http://localhost:8080;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
    # Security headers
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "no-referrer-when-downgrade" always;
    add_header Content-Security-Policy "default-src 'self' http: https: data: blob: 'unsafe-inline'" always;

    # WebSocket timeout settings
    proxy_read_timeout 300s;
    proxy_send_timeout 300s;
    # Logging
    access_log /var/log/nginx/ws.example.com.access.log;
    error_log /var/log/nginx/ws.example.com.error.log warn;

    # SSL configuration (uncomment after running Certbot)
    # listen 443 ssl http2;
    # listen [::]:443 ssl http2;
    # ssl_protocols TLSv1.2 TLSv1.3;
    # ssl_prefer_server_ciphers on;
    # ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;

    # Certbot will add its own SSL certificate paths
    # ssl_certificate /etc/letsencrypt/live/ws.example.com/fullchain.pem;
    # ssl_certificate_key /etc/letsencrypt/live/ws.example.com/privkey.pem;
}

sudo apt install certbot python3-certbot-nginx

Once it’s installed you can simply run “certbot” in your
terminal, this will detect the configs in your sites-enabled folder and ask what you want to do (renew,
reissue, etc…). Follow the walk-through, certbot gives you It’s pretty straight forward.
‍
So
nowadays certbot when getting a new cert will set up auto-renew for you, so it’s a sit-and-forget
kinda task. But to make sure it worked you can run:

sudo systemctl status certbot.timer

if this is up and running, you should be good to go if you’re
using systemd.
‍

Quality Of Life Tools

DNS

Docker

I’m not gonna cover how to install docker here. It’s best to
follow the official
installation guide anyway. But I want to touch on a few things. First off, docker is useful as
hell for testing new apps. But that’s about as far as I take it. I personally do not like using
docker all that much, and where possible run applications directly. Here are some pros and cons to keep
in mind.

Docker Pros

Consistency is a big one it can make things more constant between
development, testing, and deploying if your system can run docker you can run most docker apps. It can
help with isolation, reducing conflicts between apps. In some cases it can help with efficiency as it
takes less resources than traditional VM’s. It can help with scaling as it’s pretty easy to spin up
more containers and the microservice architecture can be useful because you can break down an
application into smaller manageable services, allowing for independent scaling of said services. Lastly
the community is large, so the documentation is good, and community support is always helpful, plus
there is a wide range of ready to go docker images for deployment.

Docker Cons

網站平台

Wrap Up

Well, that about does it for the basics of server setup and tools. There
is a a script that I wrote that will do most of this for you. I wrote it to make my own server setup faster.
You can get that here, it includes all of my must-haves and does some basic configuration. Tweak it to
your own needs, and as always stay safe out there and ping me on nostr or simplex if you have questions
or if I fucked something up in this post.