Skip to content

3. Security

zxcmehran edited this page Mar 27, 2018 · 4 revisions

There are two control interfaces in this setup. The first and the more fundamental one is Aria2 RPC Interface, and the second interface is the Web Interface that acts like a layer over the Aria2 RPC. We should secure these interfaces to achieve minimum security essentials.

Aria2 RPC Sercet

Aria2 RPC Interface can be secured by defining a secret token as validation key. Every client accessing Aria2 RPC should be aware of this value; It means that Web Interface and python scripts need this token to be able to talk to Aria2.

At first, we must define a Secret key in configuration.conf file using rpc-secret option. Use a long random string as the key.

Then, we should let the clients know about it. For python scripts, edit file scripts/configuration.py and enter the secret key under conf_auth_token() option. For Web interface, you should edit auth.token option under $authconf in webui/configuration.js file.

There is a problem that, it's not safe to place secret token on configuration.js as it will be publicly available to every user that can access the host. There are two workarounds for this problem:

  1. Omit secret token and require every user accessing Web Interface to enter it manually. This way the token might get stored in user cookies.

  2. Protect Web Interface from unauthorized access using a username/password combination.

Web interface Authentication

LoadBox can protect the web interface from unauthorized access. All you have to do is to set WEBUSER and WEBPASS options in configuration.sh file.

It provides a basic authentication. This method is not a trustworthy workaround for achieving maximum security. A man-in-the-middle (MITM) attacker who monitors HTTP Headers can easily extract authentication data and access the web interface.

Even worse, the attacker can monitor the traffic between Web interface and Aria2 RPC endpoint to extract RPC secret token. The solution is to use HTTPS protection to encrypt all traffic to prevent eavesdropping.

HTTPS

Using HTTPS is important in public networks especially over the internet. You need a certificate and key pair to enable HTTPS encryption. Set CERTFILE and KEYFILE options in configuration.sh file.

Certificate file should be in PEM format and can optionally contain complete certificate chain as described in Python Documentation. Please note that certificate chain should not contain the private key. It should be defined in a seperate file introduced in KEYFILE option.

You can use self-signed certificates but it will not be quite secure.

Using Let's Encrypt for HTTPS

Loadbox can handle generating and automatically renewing Let's Encrypt certificates. Let's Encrypt provides free and secure certificates backed by big playes of the internet, including Mozilla, Cisco and Chrome. I recommend it.

Setting up

Let's Encrypt aims to provide certificates for web servers accessible over the internet. Thus, if you want to get a certificate, your system should be accessible through the internet. As a requirement, you should set up port forwarding on your router and connect a domain name to it (using direct IP or dynamic DNS solutions like NoIP.com). There are plenty of guides online covering this subject and we're not going to dive deeper.

Assuming you've set up port forwarding and your system is visible through the internet, as the first step you should set CERT_RENEW_HOSTNAME directive in configuration.sh file to your domain name, like myhost.ddns.com or mydomain.net.

Let's Encrypt agent verifies your host name by placing a special file in your webroot and try accessing it through the internet. You'll need a web server running on your system. If you don't have anything running on port 80, then you should set CERT_RENEW_START_80_WEBSERVER to 1. It makes LoadBox to fire up a standalone web server right before issuing certificate.

If you currently have a web server running on port 80, set CERT_RENEW_START_80_WEBSERVER to 0, then set the path to your webserver root directory on CERT_RENEW_WEBROOT directive, like /var/www/mywebsite.

LoadBox uses certbot to generate certificates. If you have a globally installed version of certbot, then LoadBox manages to use it; Otherwise it downloads a standalone version and installs it's dependencies on first run with your consent.

Issuing certificate

Certificates are handled by sh/cert-renew.sh file. For the first time, you need to manually run it using root privileges explicitly by invoking sudo sh/cert-renew.sh and follow interactive wizard until it installs new certificates.

Now you can check the system using HTTPS.

Setting up renewal task

We just need to run this script once a month or two. It would renew the certificate automatically. We can define a cronjob to handle it for us. Run sudo crontab -e. Use nano if asked you to choose a editor.

Note: It's mandatory to run crontab on sudo. Renewal process needs root privileges and should be ran on root's cronjobs.

Assuming you installed LoadBox on /home/[username]/LoadBox directory, add a line in the bottom of the file:

0 0 1 * * /home/[username]/LoadBox/sh/cert-renew.sh

It makes it so that the script would run on 1st of every month on 00:00. You can generate your own cron job syntax at Crontab Guru.

After adding the line, save the changes and exit. Tip: If you were working on nano editor, press Ctrl-O and then Enter to save, and then Ctrl-X to exit.

That's it.

More

If you want to host your system in a public network, you should do some security tweaks. You can change default ports including default SSH port and use DoS Blocker services like DenyHosts and Fail2Ban.

You should change default hostname and user password. For instance, everybody knows the password of pi@raspberrypi: It's obviously raspberry! And, try not to run aria2c or web server as root user.

You can’t perform that action at this time.