MariaDB auf einem VPS absichern: Lokaler Zugriff, minimale Berechtigungen und Sicherungen

Eine im Internet zugängliche Datenbank ist eines der ersten Ziele, nach denen Bots suchen: Der Port 3306 wird ständig gescannt, und Datenbanken, die offen gelassen und mit einem schwachen Passwort geschützt sind, werden geleert oder als Geiseln genommen. In dieser Anleitung wird MariaDB installiert und gesichert. Die Befehle gelten – abgesehen von einigen Dateinamen – auch für MySQL.

1. Die Anlage installieren und sichern

apt update && apt install -y mariadb-server
mariadb-secure-installation

Beantworten Sie die Fragen bitte wie folgt:

• Wechseln Sie zur Unix-Socket-Authentifizierung : n falls diese Frage auftaucht, da dies unter Debian und Ubuntu bereits der Fall ist.
• Das Root-Passwort ändern : n. Das Root-Konto von MariaDB wird über das Root-Konto des Systems authentifiziert, ohne dass ein Netzwerkpasswort erforderlich ist: Dies ist sicherer als ein Passwort.
• Anonyme Benutzer entfernen, Remote-Anmeldung als „root“ unterbinden, Testdatenbank entfernen, Berechtigungstabellen neu laden : Y jedes Mal.

Melden Sie sich anschließend als Root am System an, indem Sie den folgenden einfachen Befehl eingeben: mariadb.

2. Nur lokal anhören

Unter Debian und Ubuntu hört MariaDB standardmäßig nur auf der lokalen Adresse. Bitte überprüfen Sie dies, da eine frühere Änderung oder eine andere Distribution dies möglicherweise geändert haben könnte:

ss -tlnp | grep -E "3306|mariadbd|mysqld"

Das sollten Sie sich unbedingt ansehen 127.0.0.1:3306. Falls Sie sehen, dass 0.0.0.0:3306 oder *:3306, bitte korrigieren Sie in /etc/mysql/mariadb.conf.d/50-server.cnf :

[mysqld]
bind-address = 127.0.0.1
skip-name-resolve

systemctl restart mariadb

skip-name-resolve Vermeiden Sie eine DNS-Auflösung bei jeder Verbindung: Das ist schneller, und die Konten müssen dann mit einer IP-Adresse statt mit einem Hostnamen angegeben werden. Falls Ihre Anwendung in Docker ausgeführt wird, lesen Sie bitte den Abschnitt über Docker weiter unten.

3. Ein Benutzer pro Anwendung

Verwenden Sie das Root-Konto niemals in einer Anwendung. Erstellen Sie pro Website oder pro Spielserver eine Datenbank und einen Benutzer, wobei dieser ausschließlich Zugriff auf die jeweilige Datenbank hat:

CREATE DATABASE boutique CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'boutique'@'localhost' IDENTIFIED BY 'MOT_DE_PASSE_GENERE';
GRANT ALL PRIVILEGES ON boutique.* TO 'boutique'@'localhost';
FLUSH PRIVILEGES;

Erstellen Sie die Passwörter mit openssl rand -base64 24. Sollte eine Anwendung kompromittiert werden, kann der Angreifer lediglich auf seine eigene Datenbank zugreifen. Bei einem reinen Lese-Tool, wie beispielsweise einem Dashboard, sollten Sie die Berechtigungen sogar auf SELECT.

Docker-Beispiele : Ein Container lässt sich nicht verbinden von localhost, jedoch über die Docker-Netzwerkadresse. Am einfachsten ist es, die Datenbank in einem Container derselben Compose-Datei auszuführen, ohne deren Port zu veröffentlichen. Siehe Docker und Docker Compose.

4. Die bestehenden Konten prüfen

Listen Sie auf einem bereits in Betrieb befindlichen Server die Konten und die Standorte auf, von denen aus eine Verbindung hergestellt werden kann:

SELECT user, host FROM mysql.user ORDER BY user;

Jeder Datensatz, dessen Spalte host ist % Akzeptiert Verbindungen von überall her. Falls dies nicht unbedingt erforderlich ist, löschen Sie diese Einstellung oder schränken Sie sie ein:

DROP USER 'ancien'@'%';
RENAME USER 'appli'@'%' TO 'appli'@'localhost';

Überprüfen Sie die Berechtigungen eines Kontos auch mit SHOW GRANTS FOR 'appli'@'localhost';. Ein Anwendungskonto darf niemals ALL PRIVILEGES ON *.*.

5. Fernzugriff, ohne die Basisstation zu gefährden

Um ein grafisches Tool wie DBeaver, HeidiSQL oder MySQL Workbench von Ihrem Computer aus zu nutzen, verwenden Sie einen SSH-Tunnel: Die Datenbank bleibt so für das Internet unzugänglich.

ssh -N -L 3307:127.0.0.1:3306 alex@IP_DU_VPS

Solange dieser Befehl ausgeführt wird, verbinden Sie Ihre Software mit 127.0.0.1 am Hafen 3307. Die meisten Programme können diesen Tunnel auch selbst einrichten, und zwar in einem Reiter „SSH“ der Verbindung.

6. Den Speicher einstellen

Die wichtigste Einstellung ist innodb_buffer_pool_size, der Speicherbereich, in dem MariaDB die am häufigsten verwendeten Daten und Indizes ablegt. Der Standardwert von 128 MB ist bereits bei wachsender Datenbankgröße zu gering. Auf einem VPS, auf dem auch die Website oder der Spielserver gehostet wird, sollten Sie hierfür etwa ein Viertel des Arbeitsspeichers reservieren:

[mysqld]
innodb_buffer_pool_size = 1G     # pour un VPS de 4 Go
max_connections = 100

Um den Bedarf abzuschätzen, vergleichen Sie diesen mit der tatsächlichen Größe Ihrer Daten:

SELECT ROUND(SUM(data_length + index_length) / 1024 / 1024) AS taille_mo
FROM information_schema.tables WHERE engine = 'InnoDB';

Es ist nicht erforderlich, diese Größe – zuzüglich eines Wachstumsspielraums – zu überschreiten.

7. Speichern

Bitte kopieren Sie die Dateien nicht aus /var/lib/mysql während die Datenbank läuft: Die Kopie wäre inkonsistent. Exportieren Sie stattdessen:

mariadb-dump --all-databases --single-transaction --routines --events | gzip > /var/backups/mariadb.sql.gz

--single-transaction Erzeugt einen konsistenten Export, ohne die Anwendungen zu blockieren. Automatisieren Sie den Export und übertragen Sie die Daten vom Server: siehe Datensicherungen mit Borg. Zur Wiederherstellung: gunzip -c mariadb.sql.gz | mariadb.

8. Aktualisierungen

Die Wartungsversionen von MariaDB werden über die regulären Systemaktualisierungen bereitgestellt. Wenn Sie die in den ersten Schritten beschriebenen automatischen Sicherheitsupdates aktiviert haben, werden diese automatisch installiert. Bevor Sie zu einer neuen Hauptversion wechseln, führen Sie bitte einen vollständigen Export durch und starten Sie anschließend mariadb-upgrade nach dem Update, falls sie dies nicht bereits selbst getan hat.

Häufig gestellte Fragen