Diese Anleitung beschreibt Installation und Absicherung von MariaDB (dem von Debian und Ubuntu mitgelieferten MySQL-Ersatz) auf einem Linux-Server: Paket mariadb-server installieren, mariadb-secure-installation durcharbeiten, Benutzer mit minimalen Rechten anlegen und Remote-Zugriff gezielt über bind-address und Firewall freigeben. Backup und Slow-Query-Log sind eigene Themen.

Voraussetzungen

Diese Punkte müssen vorab stehen:

Betriebssystem: Debian 12 (Bookworm) oder Ubuntu 24.04 LTS, beide mit MariaDB 10.11.x (LTS) aus den Distributions-Repos. Debian 13 (Trixie) und Ubuntu 26.04 LTS liefern MariaDB 11.8; die Befehle dieser Anleitung gelten dort unverändert.
Hardware: 1 CPU-Kern und 1 GB RAM reichen für kleine Anwendungen, 2 Kerne und 4 GB RAM für mehrere Anwendungen; x86_64 oder ARM64.
Zugang: ein Benutzer mit sudo-Rechten bzw. root-Zugriff per SSH.
Paketquellen: ein aktuelles System (sudo apt update); die Pakete kommen aus den Standard-Repos.
Optional neuere Version: Eine neuere Serie wie 11.4 LTS oder eine 12.x-Rolling-Version, installieren Sie nur über das offizielle MariaDB-Repo via mariadb_repo_setup. Meist reicht die mitgelieferte LTS-Version.
Netzwerk: standardmäßig lauscht MariaDB nur auf 127.0.0.1 (localhost), Port 3306/tcp. Remote-Zugriff aktivieren Sie erst gezielt und abgesichert.

Schritt 1: MariaDB installieren

Aktualisieren Sie zuerst die Paketlisten und installieren Sie das Metapaket mariadb-server. Es zieht den passenden mariadb-client automatisch mit. Bei der .deb-Installation wird der Dienst direkt aktiviert und gestartet.

sudo apt update
sudo apt install mariadb-server

Stellen Sie sicher, dass der Dienst läuft und beim Booten automatisch startet. Der systemd-Dienst heißt mariadb; mysql.service existiert nur als Kompatibilitäts-Alias.

sudo systemctl enable --now mariadb
sudo systemctl status mariadb

Die Version fragen Sie direkt in der Datenbank ab:

sudo mariadb -e "SELECT VERSION();"

Verifizieren: systemctl status mariadb zeigt active (running) und enabled, die Versionsabfrage liefert z. B. 10.11.x-MariaDB-0+deb12u1.

Schritt 2: mariadb-secure-installation durcharbeiten

Das Skript mariadb-secure-installation entfernt typische Standard-Schwachstellen. mysql_secure_installation ist nur ein Alias darauf und funktioniert identisch. Starten Sie es mit root-Rechten.

sudo mariadb-secure-installation

Das Skript fragt nacheinander ab. So antworten Sie:

Aktuelles root-Passwort: Frisch installiert gibt es keines, drücken Sie Enter.
„Switch to unix_socket authentication“ und „Change the root password?“: root ist bereits über unix_socket geschützt, das Skript meldet „you can safely answer ‚n‘“. Antworten Sie jeweils mit n (empfohlen, siehe Schritt 3). Nur wer bewusst ein root-DB-Passwort will, antwortet bei der zweiten Frage mit Y.
Anonyme Benutzer entfernen: mit Y bestätigen.
Remote-root-Login deaktivieren: mit Y bestätigen.
test-Datenbank entfernen: mit Y bestätigen.
Rechtetabellen neu laden: mit Y bestätigen.

Anonyme Benutzer und die test-Datenbank sind im Auslieferungszustand angreifbar, bestätigen Sie diese Schritte. Bei einem späteren Galera-Cluster führen Sie das Skript nur auf dem ersten Node vor dem Cluster-Aufbau aus.

Verifizieren: sudo mariadb -e "SELECT User,Host FROM mysql.user; SHOW DATABASES;" zeigt keinen Benutzer mit leerem Namen, root nur mit localhost und keine Datenbank test.

Schritt 3: root-Authentifizierung über unix_socket verstehen

Seit MariaDB 10.4 ist root@localhost als IDENTIFIED VIA unix_socket OR mysql_native_password angelegt. Das heißt: Der lokale Login als System-root läuft passwortlos über das Betriebssystem. Ein klassisches root-DB-Passwort ist oft gar nicht nötig.

sudo mariadb
# alternativ identisch: sudo mysql

Sie landen direkt in der MariaDB-Shell. Ein mysql -u root ohne sudo endet dagegen mit Access denied. Das ist kein Fehler, sondern genau die unix_socket-Logik. Verlassen Sie die Shell mit EXIT;.

Optional: root auf Passwort umstellen

Nur wenn es nötig ist (z. B. für ein Tool, das sich nicht als System-root verbinden kann), stellen Sie root auf Passwort-Authentifizierung um. Für die meisten Setups ist unix_socket die sicherere Wahl.

sudo mariadb -e "ALTER USER 'root'@'localhost' IDENTIFIED VIA mysql_native_password USING PASSWORD('STARKES_PASSWORT');"

Verifizieren: sudo mariadb -e "SHOW CREATE USER 'root'@'localhost';" zeigt IDENTIFIED VIA mysql_native_password USING ... OR unix_socket bzw. nach der Umstellung nur mysql_native_password.

Schritt 4: Datenbank und Benutzer mit minimalen Rechten anlegen

Legen Sie für Ihre Anwendung eine eigene Datenbank und einen eigenen Benutzer an. Grundsatz ist Least Privilege: nur die Rechte, die die Anwendung braucht, und ein eng gefasster Host. Öffnen Sie die Shell mit sudo mariadb und führen Sie aus:

CREATE DATABASE appdb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'appuser'@'localhost' IDENTIFIED BY 'STARKES_PASSWORT';
GRANT SELECT, INSERT, UPDATE, DELETE ON appdb.* TO 'appuser'@'localhost';
-- FLUSH PRIVILEGES ist hier NICHT noetig
SHOW GRANTS FOR 'appuser'@'localhost';

Ein häufiges Missverständnis: FLUSH PRIVILEGES ist nach CREATE USER, GRANT, REVOKE, DROP USER oder ALTER USER nicht erforderlich. Diese Anweisungen wirken sofort für neue Verbindungen. Nur wer die mysql-Systemtabellen direkt bearbeitet, braucht FLUSH PRIVILEGES.

Gegenüber dem oft kopierten GRANT ALL PRIVILEGES ON *.* ist die obige Variante deutlich sicherer. Vergeben Sie Rechte gezielt auf die benötigte Datenbank (db.*). Welche Tabellenrechte es gibt und wofür sie typisch sind, zeigt die folgende Übersicht.

Recht	Erlaubt	Typischer Einsatz
`SELECT`	Daten lesen	jede Anwendung
`INSERT`	Datensätze einfügen	schreibende Anwendung
`UPDATE`	Datensätze ändern	schreibende Anwendung
`DELETE`	Datensätze löschen	schreibende Anwendung
`CREATE, DROP, ALTER`	Tabellenstruktur ändern	Migrationen / Schema-Updates
`INDEX`	Indizes anlegen/entfernen	Schema-Pflege
`TRIGGER`	Trigger verwalten	nur bei Bedarf

Braucht die Anwendung Migrationen, ergänzen Sie CREATE, DROP, ALTER, INDEX nur für deren Datenbank.

Verifizieren: mariadb -u appuser -p appdb -e "SELECT 1;" gelingt mit dem Passwort, SHOW GRANTS FOR 'appuser'@'localhost'; zeigt nur die vergebenen Rechte auf appdb.

Schritt 5: Remote-Zugriff bewusst freischalten

Standardmäßig lauscht MariaDB nur auf 127.0.0.1. Das ist die sicherste Variante: Lokale Anwendungen verbinden sich über den Socket oder localhost, von außen ist nichts erreichbar. Für Remote-Zugriff gehen Sie in drei Schritten vor: Benutzer mit passendem Host, bind-address anpassen und Firewall eng setzen.

Remote-Benutzer für einen konkreten Host

Legen Sie den Benutzer mit der konkreten Quell-IP statt mit dem pauschalen Platzhalter % an. Je enger der Host, desto kleiner die Angriffsfläche.

CREATE USER 'appuser'@'10.0.0.50' IDENTIFIED BY 'STARKES_PASSWORT';
GRANT SELECT, INSERT, UPDATE, DELETE ON appdb.* TO 'appuser'@'10.0.0.50';

bind-address anpassen

Maßgeblich ist die Datei /etc/mysql/mariadb.conf.d/50-server.cnf, Abschnitt [mysqld] – nicht eine alte my.cnf. Im LAN ist eine konkrete interne IP des Servers besser als 0.0.0.0 (alle Schnittstellen).

[mysqld]
# nur localhost (Standard):
# bind-address = 127.0.0.1
# konkrete interne IP des Datenbankservers statt 0.0.0.0 (alle Schnittstellen):
bind-address = 10.0.0.10

Danach den Dienst neu starten und prüfen, worauf MariaDB nun lauscht.

sudo systemctl restart mariadb
sudo ss -tlnp | grep 3306

Firewall eng setzen

Öffnen Sie Port 3306 nie für alle, sondern nur für vertrauenswürdige Quellen, also ein Netz oder eine einzelne IP. Mit UFW sieht das so aus:

sudo ufw allow from 10.0.0.0/24 to any port 3306 proto tcp
# oder nur eine Einzel-IP:
sudo ufw allow from 203.0.113.11 to any port 3306 proto tcp
# NICHT verwenden - oeffnet fuer alle:
# sudo ufw allow 3306

Noch sicherer ist ein SSH-Tunnel: bind-address = 127.0.0.1 bleibt stehen, der Client verbindet sich über SSH. Die Datenbank ist von außen nicht erreichbar.

Verifizieren: ss -tlnp | grep 3306 zeigt die gesetzte Adresse, mariadb -h 10.0.0.10 -u appuser -p appdb vom Host 10.0.0.50 gelingt, von einer nicht freigegebenen IP läuft die Verbindung in ein Timeout.

Schritt 6: Basis-Härtung abschließen

Diese Checkliste schließt die Härtung ab:

Starke Passwörter: Für jeden DB-Benutzer ein langes, zufälliges Passwort – nirgends wiederverwenden.
Kein Remote-root: In der secure-installation deaktiviert; nicht nachträglich wieder aufmachen.
Host eng wählen: 'user'@'localhost' oder konkrete IP; '%' nur, wenn wirklich nötig.
bind-address bewusst: localhost belassen, wo möglich; sonst konkrete IP plus Firewall.
Rechte regelmäßig prüfen: mit SHOW GRANTS FOR 'user'@'host'; kontrollieren und Überflüssiges mit REVOKE entfernen.
Pfade kennen: Datenverzeichnis /var/lib/mysql, Socket /run/mysqld/mysqld.sock, Config-Includes über /etc/mysql/my.cnf nach /etc/mysql/mariadb.conf.d/.
Updates einspielen: Sicherheitsupdates über apt regelmäßig anwenden.

Verifizieren: sudo mariadb -e "SELECT User,Host FROM mysql.user WHERE Host='%';" liefert keine oder nur bewusst angelegte Einträge, apt list --upgradable 2>/dev/null | grep mariadb ist leer.

Typische Fehler

Access denied bei mysql -u root: Ursache ist die unix_socket-Authentifizierung. Statt ein Passwort zu raten, nutzen Sie sudo mariadb.
Unnötiges FLUSH PRIVILEGES: Nach GRANT/CREATE USER überflüssig. Nur bei direkter Bearbeitung der mysql-Systemtabellen erforderlich.
GRANT ALL ON *.*: Widerspricht Least Privilege. Nur konkrete Rechte auf die benötigte Datenbank und einen engen Host.
bind-address = 0.0.0.0 ohne Firewall: Exponiert MariaDB im ganzen Netz oder Internet. Immer mit UFW/iptables/Security-Group oder besser SSH-Tunnel kombinieren.
Globale Rechte greifen scheinbar nicht: Rechte auf *.* wirken erst für neue Verbindungen, bestehende Sessions müssen sich neu verbinden.
Falsche Config-Datei editiert: Maßgeblich ist 50-server.cnf unter /etc/mysql/mariadb.conf.d/, und bind-address muss im [mysqld]-Block stehen.
test-DB und anonyme Benutzer behalten: Beide sind im Auslieferungszustand angreifbar; im secure-installation-Lauf mit Y entfernen.
secure-installation falsch im Cluster: Auf einem Galera-Cluster nur auf dem ersten Node vor dem Aufbau ausführen; direkte Tabellenmanipulation repliziert nicht sicher.

Häufige Fragen

Warum bekomme ich Access denied for user 'root'@'localhost'?

Weil root@localhost seit MariaDB 10.4 über unix_socket authentifiziert wird. Der Login funktioniert nicht über ein DB-Passwort, sondern über das Betriebssystem. Melden Sie sich mit sudo mariadb an.

Muss ich nach GRANT immer FLUSH PRIVILEGES ausführen?

Nein. Bei CREATE USER, GRANT, REVOKE, DROP USER und ALTER USER wirken die Änderungen sofort für neue Verbindungen. FLUSH PRIVILEGES ist nur nötig, wenn Sie die mysql-Systemtabellen direkt per INSERT/UPDATE bearbeitest.

Sollte ich ein root-Passwort setzen oder bei unix_socket bleiben?

Für lokale Administration ist unix_socket sicherer: Es gibt kein Passwort, das abfließen kann. Ein root-DB-Passwort brauchen Sie nur, wenn ein Tool sich zwingend mit Benutzer/Passwort als root verbinden muss. Auch dann gilt: kein Remote-root.

Wie gebe ich nur Leserechte für ein Reporting-Tool?

Legen Sie einen eigenen Benutzer an und vergeben Sie ausschließlich SELECT: GRANT SELECT ON appdb.* TO 'report'@'10.0.0.60';. So kann das Tool lesen, aber nichts ändern oder löschen.

Wie öffne ich MariaDB sicher für einen zweiten Server?

Legen Sie einen Benutzer mit der IP des zweiten Servers an, setzen Sie bind-address auf eine interne IP und erlauben Sie Port 3306 in der Firewall nur von dieser Quelle. Noch sicherer ist ein SSH-Tunnel, bei dem bind-address auf 127.0.0.1 bleibt.

Brauche ich eine neuere MariaDB-Version als 10.11?

Meist reicht die mit der Distribution gelieferte LTS-Serie (10.11 bzw. 11.8), sie erhält Sicherheitsupdates über die Distribution. Eine neuere Serie richten Sie nur ein, wenn eine Anwendung sie ausdrücklich voraussetzt, dann über das offizielle MariaDB-Repo via mariadb_repo_setup.

Fazit

Eine sichere MariaDB-Installation ist in wenigen Minuten erledigt: Paket installieren, Dienst aktivieren, mariadb-secure-installation durcharbeiten. Entscheidend sind die Details: unix_socket-Authentifizierung verstehen statt root-Passwörter zu raten, Benutzer nach Least Privilege mit gezielten GRANTs anlegen, kein überflüssiges FLUSH PRIVILEGES. Remote-Zugriff öffnen Sie nur über bind-address plus enge Firewall-Regel oder per SSH-Tunnel.

Weiterführende Anleitungen und Quellen

PostgreSQL Performance-Tuning für Einsteiger für PostgreSQL statt MariaDB.
Linux: Benutzer, Gruppen und Rechte mit chmod, chown und sudo Grundlagen zu sudo und Dateirechten.
Weitere Anleitungen in der Kategorie Datenbanken.

Quellen: offizielle MariaDB-Dokumentation – mariadb-secure-installation, GRANT statement, Authentication Plugin Unix Socket und Configuring MariaDB for Remote Client Access.