What not to do

Module 10: Staying secure · Reading time: 12 minutes

Learning objective: After this lesson you will recognise the mistakes that most often lead to a hacked or broken server, you can explain why they are dangerous, and you know what to do instead.

Key concepts: root login with a password, weak or default password, open database, Docker API on port 2375, docker.sock in a container, chmod 777, curl | bash, secrets in Git, admin panel without two-factor authentication, firewall off "just for a moment", no updates, no backup

Why a lesson about mistakes?

Most servers are not hacked by a brilliant attacker with an unknown vulnerability. They are hacked by bots that crawl the entire internet looking for known mistakes: a password that can be guessed, a database that is left open, a program that has been missing an update for months. If you avoid the mistakes in this lesson, those bots will pass you by. That is most of the protection you can get.

For each mistake you will find why it is dangerous and what to do instead. You learned almost all of this in earlier lessons; this lesson puts it all in one place.

1. Root login with a password

The problem. Every server gets login attempts on root all day long (lesson 5.3). If root can log in with a password, that password is the only thing standing between a bot and full control. Reused or short passwords will be guessed sooner or later, or are already on a leaked list.

Do this. Log in with keys only: PasswordAuthentication no and KbdInteractiveAuthentication no, root at most with a key (PermitRootLogin prohibit-password) or not at all (no), and do your daily work as a regular user with sudo (lessons 2.2 and 3.2). Check from the outside which login methods your server offers (exercise Z2.2).

2. A database, cache or search cluster open to the internet

The problem. MySQL/MariaDB (3306), PostgreSQL (5432), Redis (6379), Elasticsearch or OpenSearch (9200) and MongoDB (27017) are built for trusted programs on a trusted network. If they listen on 0.0.0.0 without a firewall, scanners will find them quickly. Redis states in its own documentation that it should not be exposed to the internet and that anyone with access can wipe the entire dataset; with the CONFIG command an attacker can even write files on the server. Open databases and search clusters have for years been a well-known cause of major data breaches and of "ransom" messages in place of your data.

Do this. Let these services listen on 127.0.0.1 (lesson 5.1), keep them behind the firewall (lesson 5.2), and in Docker don't publish them at all, or only on 127.0.0.1 (lesson 9.3). Need to reach them from your laptop? Use an SSH tunnel (lesson 2.3). Check from the outside (exercise Z5.1).

3. The Docker API open, or docker.sock in a container

The problem. Anyone who can control the Docker daemon is effectively root on the server: the Docker documentation says that only trusted users should be allowed to control the daemon and treats access to the daemon as equal to root access. There are two versions of this mistake:

• The daemon listens on a TCP port without TLS (usually 2375). Anyone who can reach that port can start containers with your server's disk mounted inside.
• A container gets /var/run/docker.sock as a volume ("so it can manage containers itself"). If that container is hacked, the whole server is lost.

The docker group is also equivalent to root (lesson 9.2): only add administrators to it.

Do this. Let Docker work through the local socket only. Remote management goes over SSH (docker context with ssh://), or if it really has to be over TCP, with TLS on port 2376 and client certificates. Only mount docker.sock in a container you fully trust and really need, and preferably read-only through a restricting proxy.

4. chmod 777 to make an error go away

The problem. You get "Permission denied" on an upload, and a forum says: chmod -R 777 /var/www. After that, every user and every process on the server can write anything into your website, including a hacked plugin or another account. Code that the web server can write to can be replaced with a backdoor through a vulnerability.

Do this. Work out who needs to write and where (lesson 3.1): usually only the web server user, in one folder for uploads or cache. Code owned by a user other than the web server, permissions 644/755, uploads 750/640 or similar.

5. curl ... | bash and software from anywhere

The problem. A script you run unseen as root can do anything: add sources and keys, overwrite files, open up a service. Even if the intention is good, afterwards you don't know what has changed, and it breaks at the next release upgrade (lesson 4.3).

Do this. Download the script and read it. Prefer installing from your distribution's package repository or the maker's official source, with its own key (Signed-By, lesson 4.1). Write down what you install and why.

6. No updates, or updates "later"

The problem. Vulnerabilities get fixed and then exploited, often within days. A server that goes months without updates, or runs a release that is no longer supported, has a list of known ways in. Containers are not updated by apt.

Do this. Turn on automatic security updates (lesson 4.2), set a fixed time for reboots, put your release's end-of-life date in your calendar (lesson 4.3), and update your containers regularly (lesson 9.4).

7. No backup, or a backup that has never been tested

The problem. A snapshot on the same storage is not a backup (lesson 8.1). A backup stored on the server itself disappears along with it in a hack or ransomware attack. And a backup that has never been restored is a hope, not a certainty.

Do this. Encrypted backups off the server (restic, lesson 8.2), monitoring that they run, and a restore test at least every quarter.

8. Admin panels open to everyone, without two-factor authentication

The problem. An admin panel for a database (such as phpMyAdmin), for Docker (such as Portainer), for your application or for your password vault is an attractive target: one password gives access to everything. Default passwords such as admin/admin and registration that is left open (Vaultwarden, lesson 9.4) make it even easier.

Do this. Don't expose admin panels to the internet: reach them through an SSH tunnel or only from a fixed address. If a panel really has to be public: https, a strong unique password from your password manager, two-factor authentication, and registration closed. Always change default passwords.

9. Secrets in Git or in your compose file

The problem. A password, API key or private key in a file that ends up in a Git repository stays in the history forever, even if you remove it later. Bots search public repositories for exactly these keys.

Do this. Keep secrets in a separate file with permissions 600 (EnvironmentFile, lesson 6.3; .env with Docker Compose, lesson 9.3) that is listed in .gitignore. Has a secret leaked anyway? Replace it immediately (a new password, a new key); cleaning up Git alone is not enough.

10. Firewall off "for a moment", everything as root, and no notes

The problem. "I'll just turn the firewall off to test" gets forgotten. "I'll just do it as root" becomes a habit. And a server where nobody knows what runs on it and why cannot be managed or recovered.

Do this. Test with a temporary, narrow rule (one port, one source address) and remove it afterwards. Work as a regular user with sudo. Keep a short server file: what is running, which ports are open, where the backups are, when the release reaches end of life (lesson 10.4).

In practice

You can make all of these mistakes on any VPS, at WebOké just as much as at other providers: what happens inside your server is yours to manage. The provider can, however, take a server off the network if it sends spam or carries out attacks, because that affects other customers. So prevention also matters for keeping your own server reachable.

Summary

• Most hacks use known mistakes, not unknown vulnerabilities.
• Log in with keys and switch off password login; never expose databases, caches or the Docker API to the internet; no docker.sock in containers you don't fully trust.
• No chmod 777 and no curl | bash: know who is allowed to do what and what you install.
• Automatic updates, backups off the server and tested, admin panels behind a tunnel or with two-factor authentication.
• Secrets outside Git and outside compose files; leaked means replaced.

Quiz

Exercise

Exercise Z10.2: Which mistake is it? The sample file casussen-z10-2.md contains eight short cases of servers where something is wrong. For each case, choose which mistake it is from the list in this lesson (A to J) and what the best first step is. The program compares your answers with the fixed answer key and then shows the explanation for each case.

Further reading

• Securing your VPS: the first five minutes
• Password manager and passkeys: here's how to secure your logins
• Docker documentation, Docker security (Docker daemon attack surface): https://docs.docker.com/engine/security/
• Docker documentation, Protect the Docker daemon socket: https://docs.docker.com/engine/security/protect-access/
• Redis, Security: https://redis.io/docs/latest/operate/oss_and_stack/management/security/