The security problems of hosting

What a hosting provider fights

A provider runs thousands of machines for thousands of customers it has never met. Its security problems are not the problems of one website: they are the problems of a shared platform, where one bad customer can damage everybody. These are the ones every provider knows by name.

DDoS. A flood of requests or packets that exhausts a link, a firewall or a web server. Volume attacks are measured in gigabits, application attacks in requests per second, and both aim at making the service unavailable rather than reading its data. Mitigation lives at the network edge, before the traffic reaches a customer.

Abuse by customers. Spam from a compromised mailbox, a phishing page on a free subdomain, malware offered for download, a booter or a proxy service. The provider must find it, suspend it and keep the evidence, or its whole address range loses reputation.

Hacked customer sites and accounts. A stolen panel password or an outdated plugin turns one site into a platform for attacks. The provider sees the outgoing traffic, not the intention, so the first signal is usually an abuse report from another network.

Credential stuffing on panels. Lists of email and password pairs from other breaches are replayed against the login page. It works because people reuse passwords, and it is the reason a panel needs two-factor authentication and a login limit by address.

Breaking the isolation between customers. A kernel bug, a misconfigured pool or a shared temporary folder can let one customer read another customer files. Providers patch kernels fast and separate services on purpose; a customer should still not keep secrets in a world-readable folder.

Panel and hypervisor vulnerabilities. The control panel runs as root and the hypervisor runs every virtual machine. A flaw in either is a flaw in everything above it. This is why panels are updated on a schedule of their own and why a provider is careful with third-party software on the host.

Supply chain. A compromised update, a malicious package, a backdoored dependency. The provider inherits the trust you place in every library it installs, and so do you.

Ransomware. Not only on office computers: an encrypted backup server or a hosting storage volume can be held for ransom. Offline and immutable copies are the answer, for the provider and for you.

Insiders. An employee with access to the billing system, the hypervisor or the backup store can do what no external attacker can. Logging, separation of duties and background checks are the provider side of this problem.

Fake sign-ups and payment fraud. Stolen cards buy servers that are used for spam and attacks before the chargeback arrives. Providers check new accounts and limit what a fresh account may do.

Crypto mining. A compromised server or a free trial account mines coins at the provider expense. The signs are a pegged processor, a hot chassis and an electricity bill nobody expected.

Open resolvers and amplification. A DNS server or a mail server that answers anyone can be used to multiply attack traffic. An open resolver is a weapon pointed at someone else, with your address on it.

IP reputation and blocklists. When one address in a range sends spam, the whole range lands on a blocklist and every customer loses mail. Reputation is shared property, and it takes weeks to rebuild.

Hijacking: names, routes and accounts

Three attacks do not need a bug in your code at all. They take the address instead of the server.

• BGP hijacking. A network announces routes for addresses it does not own, and traffic for them goes to the wrong place. The defence is at the provider and the regional internet registry: route filtering and RPKI. You cannot fix it from your server, but you can notice that your visitors suddenly come from nowhere.
• DNS hijacking. Someone changes the records of your domain, or poisons a resolver cache, and the name points at another server. The defence is a locked registrar account, two-factor authentication, DNSSEC and monitoring of the records you published.
• Domain hijacking through the registrar account. The most common of the three. A reused password, a phishing email that looks like the registrar, or a mailbox that was taken over is enough to move the domain away. The lock on the domain slows the thief down; two-factor authentication on the registrar and on the mailbox stops the theft.

The lesson for a site owner is short: your domain is more valuable than your server, because a server can be rebuilt and a lost name cannot. Protect the registrar account as carefully as the root password, and check the WHOIS record once a month.

The threats a server owner meets

A VPS with a public address is scanned within minutes of coming online. Automated bots try the SSH port, common web paths, database ports and leaked credentials, all day, without a person watching. The list below is ranked by how often a small server meets each one, and each row names the lesson that closes it.

The ranking is not a law, but it is a fair bet. Rows 1 to 3 account for most real break-ins on small servers, and all three are closed in one evening. Rows 4 to 6 are configuration mistakes rather than attacks, and a checklist catches them. Row 7 is the only one that needs work in the application itself.

Databases and panels on the internet

A database that listens on 0.0.0.0:3306 is found by a scan in hours, and the login page of phpMyAdmin is found just as fast. The mistake is almost always the same: a tutorial said to open the port for a remote connection, and nobody closed it afterwards. Check what actually listens, and close what does not need to:

sudo ss -tlnp

LISTEN 0 151 127.0.0.1:3306 0.0.0.0:* users:(("mariadbd",pid=944,fd=21)) LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=812,fd=6)) LISTEN 0 511 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=812,fd=7)) LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=701,fd=3))

Only Nginx and SSH face the internet here, which is the goal. If MariaDB shows 0.0.0.0:3306, set bind-address = 127.0.0.1 in the server configuration and restart it. If a panel is reachable from every address, put it behind a firewall rule, a VPN or at least two-factor login, and update it as often as the kernel.

Exposed files and web shells

The web root is public by definition. Anything inside it can be downloaded unless the server refuses: the .git folder with the whole history of the code, a .env file with database passwords and API keys, a backup.sql from last month, an editor swap file with a fragment of a config. Check with curl, from outside, the way an attacker would:

curl -sI https://example.com/.git/config

HTTP/2 403

A 403 or 404 is the answer you want. A 200 means the file is readable by anyone on the internet. Keep such files outside the web root, and add a rule that denies every dot file:

sudo vi /etc/nginx/sites-available/example.com

location ~ /\.(?!well-known/) { deny all; }

The .well-known exception stays open because the Let's Encrypt HTTP check puts its proof file under /.well-known/acme-challenge/; a plain location ~ /\. would block it and certificate renewal would fail.

A web shell is the next step after an upload hole: a small PHP file that lets an attacker run commands on the server. The signs are a PHP file nobody wrote, in an uploads folder, with a name that looks like an image. Finding it is part of the routine in lesson 8; preventing it means never trusting the file type a browser claims, and refusing to execute PHP in the uploads folder at all. This rule must come before the location ~ \.php$ block from lesson 5, because nginx uses the first regular expression location that matches, and the server block is read from top to bottom:

sudo vi /etc/nginx/sites-available/example.com

server { listen 443 ssl; server_name example.com www.example.com; root /var/www/example.com/html; # the ssl_certificate lines stay as certbot wrote them location ~* ^/uploads/.*\.php$ { deny all; } location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php8.3-fpm.sock; } }

The block uses the default PHP-FPM socket that the site already has from lesson 5. Lesson 8 switches this line to the socket of the site's own pool, after that pool exists.

Mail abuse and small floods

A mail server is valuable to an attacker for two reasons. An open relay sends spam for anyone who asks, and a spoofed domain lets someone send mail that claims to be you. Both damage the reputation of your address, and reputation is the one thing you cannot rebuild with a reinstall.

An open relay is a Postfix configuration mistake: a mynetworks entry that is too wide, or a permit rule without authentication. Test it from outside with an address that is not yours; if the server accepts the message for delivery, it relays. The correct settings and the test are in lesson 9.

A small flood is the last item because it is the easiest to survive. A few hundred requests per second against a page that runs a search query can exhaust a 2 GB VPS; the same traffic against a cached static page is nothing. Rate limits in Nginx and a cache in front of the database turn a small attack into a slow day. A very large attack is a provider problem: the traffic must be filtered before it reaches your machine.

What to do first

If you have one free evening and a fresh server, do these five things in this order. They close the first six rows of the table, which are the ones you will meet.

1. Turn off password login for SSH and allow keys only.
2. Install fail2ban and switch on the firewall, allowing only the ports you need.
3. Switch on automatic security updates.
4. Move the database and any admin page behind localhost or a firewall rule.
5. Take a backup, put it on another machine, and restore it once into a test folder.

Lesson 8 turns this list into commands, and lesson 9 covers the mail part.

Quiz

Article author: Arthur Isaev