Diese Anleitung führt dich durch eine saubere Installation und Absicherung von MariaDB (dem von Debian und Ubuntu mitgelieferten MySQL-Ersatz) auf einem Linux-Server. Sie richtet sich an Admins im Mittelstand, die einen Datenbankserver für eine Anwendung bereitstellen und ihn von Anfang an sicher betreiben wollen. Du installierst das Paket mariadb-server, aktivierst Dienst und Autostart, arbeitest mariadb-secure-installation Schritt für Schritt durch und legst Benutzer mit minimal nötigen Rechten an. Anschließend steuerst du den Remote-Zugriff bewusst über bind-address und Firewall. Der Fokus liegt auf Installation und Härtung – Backup und Slow-Query-Log sind eigene Themen.

Voraussetzungen

Bevor du loslegst, sollten diese Punkte stehen. Fehlt etwas davon, scheitert entweder die Installation oder der spätere Zugriff.

Betriebssystem: Debian 12 (Bookworm) oder Ubuntu 24.04 LTS. Beide liefern MariaDB 10.11.x aus der LTS-Serie (z. B. Patch-Stand 10.11.14) aus den Distro-Repos.
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: Brauchst du eine neuere Serie wie 11.4 LTS oder eine 12.x-Rolling-Version, geht das nur über das offizielle MariaDB-Repo via mariadb_repo_setup. Für die meisten Mittelstands-Setups reicht die mitgelieferte LTS-Version.
Netzwerk: standardmäßig lauscht MariaDB nur auf 127.0.0.1 (localhost), Port 3306/tcp. Remote-Zugriff aktivierst du erst bewusst und abgesichert.

Schritt 1: MariaDB installieren

Aktualisiere zuerst die Paketlisten und installiere 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

Stelle 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

Im Status sollte active (running) stehen. Die Version prüfst du bei Bedarf direkt über die Datenbank.

sudo mariadb -e "SELECT VERSION();"

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. Starte es mit root-Rechten.

sudo mariadb-secure-installation

Das Skript fragt sechs Punkte nacheinander ab. So beantwortest du sie:

Aktuelles root-Passwort: Frisch installiert gibt es keines – einfach Enter drücken.
root-Passwort setzen bzw. unix_socket: Du kannst die unix_socket-Authentifizierung bestätigen (empfohlen, siehe Schritt 3) oder bewusst ein root-DB-Passwort vergeben.
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 per Default angreifbar – bestätige diese Schritte unbedingt. Wenn du MariaDB später als Galera-Cluster betreibst, führst du das Skript nur auf dem ersten Node vor dem Cluster-Aufbau aus.

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

Du landest direkt in der MariaDB-Shell. Versuchst du dagegen mysql -u root ohne sudo, bekommst du Access denied – das ist kein Fehler, sondern genau die unix_socket-Logik. Verlasse die Shell jederzeit mit EXIT;.

Optional: root auf Passwort umstellen

Nur wenn du es bewusst brauchst (z. B. für ein Tool, das sich nicht als System-root verbinden kann), stellst du 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');"

Schritt 4: Datenbank und Benutzer mit minimalen Rechten anlegen

Jetzt legst du für deine Anwendung eine eigene Datenbank und einen eigenen Benutzer an. Der wichtigste Grundsatz lautet Least Privilege: Vergib nur die Rechte, die die Anwendung wirklich braucht, und binde den Benutzer an einen engen Host. Öffne dazu die Shell mit sudo mariadb und führe folgende Anweisungen 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 wenn du die mysql-Systemtabellen direkt manipulierst, brauchst du FLUSH PRIVILEGES.

Gegenüber dem oft kopierten GRANT ALL PRIVILEGES ON *.* ist die obige Variante deutlich sicherer. Vergib 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änzt du gezielt CREATE, DROP, ALTER, INDEX – aber eben nur dort, wo es nötig ist, und nicht pauschal über alle Datenbanken.

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. Brauchst du Remote-Zugriff, gehst du in drei Schritten vor: Benutzer mit passendem Host, bind-address anpassen und Firewall eng setzen.

Remote-Benutzer für einen konkreten Host

Lege 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. Setze die bind-address bewusst. Im LAN ist eine konkrete interne IP besser als 0.0.0.0 (alle Schnittstellen).

[mysqld]
# nur localhost (Standard):
# bind-address = 127.0.0.1
# besser eine konkrete interne IP statt aller Schnittstellen:
bind-address = 0.0.0.0

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

sudo systemctl restart mariadb
sudo ss -tlnp | grep 3306

Firewall eng setzen

Öffne Port 3306 niemals für alle. Erlaube ihn nur für vertrauenswürdige Quellen – ein einzelnes 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 als ein offener Port 3306 ist ein SSH-Tunnel: Du lässt bind-address = 127.0.0.1 stehen und tunnelst die Verbindung über SSH. Dann ist die Datenbank von außen gar nicht erreichbar, der Zugriff aber trotzdem möglich.

Schritt 6: Basis-Härtung abschließen

Mit der secure-installation und Least-Privilege-Benutzern hast du den Großteil erledigt. Diese kurze Checkliste rundet 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.

Typische Fehler

Access denied bei mysql -u root: Ursache ist die unix_socket-Authentifizierung. Statt ein Passwort zu raten, nutze sudo mariadb.
Unnötiges FLUSH PRIVILEGES: Nach GRANT/CREATE USER überflüssig (Cargo-Cult). Nur bei direkter Bearbeitung der mysql-Systemtabellen erforderlich.
GRANT ALL ON *.*: Widerspricht Least Privilege. Vergib 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 per Default angreifbar – im secure-installation-Lauf unbedingt 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. Melde dich mit sudo mariadb an, dann landest du passwortlos in der Shell.

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 du 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 die sicherere und bequemere Wahl – kein Passwort, das auslaufen oder leaken kann. Ein root-DB-Passwort brauchst du 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?

Lege einen eigenen Benutzer an und vergib 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?

Lege einen Benutzer mit der konkreten IP des zweiten Servers an, setze bind-address auf eine interne IP und erlaube 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?

Für die meisten Mittelstands-Anwendungen reicht die mit Debian 12 bzw. Ubuntu 24.04 gelieferte 10.11-LTS-Serie völlig aus und erhält Sicherheitsupdates über die Distribution. Eine neuere Serie wie 11.4 LTS richtest du 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 auf Debian 12 oder Ubuntu 24.04 in wenigen Minuten erledigt: Paket installieren, Dienst aktivieren, mariadb-secure-installation mit konsequentem Y durcharbeiten. Der eigentliche Unterschied liegt im Detail – verstehe die unix_socket-Authentifizierung statt root-Passwörter zu raten, lege Benutzer nach dem Least-Privilege-Prinzip mit gezielten GRANTs an und spar dir das überflüssige FLUSH PRIVILEGES. Remote-Zugriff öffnest du nur bewusst über bind-address plus enge Firewall-Regel oder, besser noch, per SSH-Tunnel. Wer diese Punkte beachtet, betreibt einen aufgeräumten, gehärteten Datenbankserver, der weder anonyme Benutzer noch eine offene test-DB oder einen exponierten Port 3306 mitschleppt.

Weiterführende Anleitungen und Quellen

PostgreSQL Performance-Tuning für Einsteiger – wenn du statt MariaDB PostgreSQL betreibst oder vergleichen willst.
Linux: Benutzer, Gruppen und Rechte mit chmod, chown und sudo – Grundlagen zu sudo und Dateirechten, die du hier nutzt.
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.