Zum Inhalt springen
clausvb.de

phpMyAdmin sicher einrichten

Installation, Zugriffsbeschränkung, eigener Datenbanknutzer und die Alternativen über SSH-Tunnel – damit die Datenbankoberfläche nicht zur offenen Tür wird.

Zuletzt geprüft: Gedacht für: Datenbankzugriff auf Shared Hosting

Das Wichtigste

  • Eine erreichbare phpMyAdmin-Instanz unter dem Standardpfad wird binnen Stunden von Scannern gefunden. Der Pfad allein ist kein Schutz, aber er senkt das Rauschen deutlich.
  • Verzeichnisschutz vor der Anmeldemaske ist die wirksamste Einzelmassnahme – der Angreifer erreicht das Loginformular gar nicht erst.
  • Nie mit dem Datenbank-Administrator arbeiten. Ein Nutzer mit Rechten auf genau eine Datenbank begrenzt jeden Schaden.
  • Auf eigenen Servern ist ein SSH-Tunnel die sauberere Lösung: die Datenbank bleibt an localhost gebunden und nichts davon steht im Netz.

phpMyAdmin ist bequem und deshalb weit verbreitet – und aus demselben Grund eines der ersten Ziele automatisierter Scanner. Die folgenden Schritte machen aus einer Standardinstallation eine vertretbare.

Zugriff einschränken

Die wirksamste Massnahme ist ein Verzeichnisschutz vor der Anmeldemaske. Ein Angreifer bekommt dann nicht einmal das Loginformular zu sehen und kann keine Zugangsdaten durchprobieren:

AuthType Basic
AuthName "Datenbankverwaltung"
AuthUserFile /var/www/secure/.htpasswd

<RequireAny>
  Require ip 203.0.113.42
  Require valid-user
</RequireAny>

Aus dem Büro mit fester IP kommt man ohne Passwort durch, von unterwegs mit. Steht keine feste IP zur Verfügung, entfällt die erste Zeile und Basic Auth gilt immer.

Ergänzend gehört phpMyAdmin nicht unter den Standardpfad. /phpmyadmin, /pma und /dbadmin sind die ersten Pfade, die jeder Scanner probiert. Ein eigener Name senkt die Zahl der Versuche im Log um Grössenordnungen – als alleinige Massnahme genügt er nicht, als Ergänzung ist er kostenlos.

Konfiguration

<?php
// config.inc.php

$cfg['blowfish_secret'] = '…32 zufällige Zeichen…';

$i = 1;
$cfg['Servers'][$i]['auth_type']  = 'cookie';
$cfg['Servers'][$i]['host']       = 'localhost';
$cfg['Servers'][$i]['AllowRoot']  = false;
$cfg['Servers'][$i]['AllowNoPassword'] = false;

$cfg['LoginCookieValidity']  = 1800;   // 30 Minuten
$cfg['ForceSSL']            = true;
$cfg['ShowServerInfo']      = false;
$cfg['VersionCheck']        = false;

AllowRoot = false ist der wichtigste Schalter. Wer sich als Administrator anmelden kann, kann alle Datenbanken lesen und ändern – auch die anderer Projekte auf demselben Server.

auth_type = 'cookie' bedeutet, dass Zugangsdaten pro Sitzung eingegeben werden. Die Alternative config legt sie in der Konfigurationsdatei ab, sodass jeder mit Zugriff auf die URL angemeldet ist. Das ist nur in einer Umgebung vertretbar, die ohnehin komplett abgeschottet ist.

Das Installationsverzeichnis setup/ gehört nach der Einrichtung gelöscht.

Eigener Datenbanknutzer

CREATE USER 'app_shop'@'localhost'
  IDENTIFIED BY 'langes-zufaelliges-passwort';

GRANT SELECT, INSERT, UPDATE, DELETE
  ON shop.* TO 'app_shop'@'localhost';

FLUSH PRIVILEGES;

Für Strukturänderungen während einer Migration:

GRANT CREATE, ALTER, DROP, INDEX ON shop.* TO 'app_shop'@'localhost';
-- nach der Migration wieder entziehen
REVOKE CREATE, ALTER, DROP, INDEX ON shop.* FROM 'app_shop'@'localhost';

@'localhost' bindet den Nutzer an Verbindungen vom Server selbst. Ein @'%' erlaubt die Anmeldung von jeder IP – das braucht man nur, wenn die Datenbank tatsächlich von aussen erreichbar sein soll, und dann gehört sie hinter eine Firewallregel.

Die bessere Lösung auf eigenen Servern: SSH-Tunnel

Wer SSH-Zugang hat, braucht gar keine Weboberfläche im Netz:

ssh -N -L 3307:127.0.0.1:3306 benutzer@server.example.com

Danach verbindet sich ein lokaler Client auf 127.0.0.1:3307 und landet auf der Datenbank des Servers. Vorteile:

  • Der Datenbankport bleibt an localhost gebunden und ist von aussen unerreichbar.
  • Es läuft keine PHP-Anwendung mit Datenbankzugriff im Web.
  • Die Authentifizierung läuft über SSH-Schlüssel statt über ein Formular.
  • Lokale Clients wie DBeaver oder TablePlus arbeiten sich deutlich angenehmer als eine Weboberfläche.

Auf Shared Hosting ohne SSH bleibt phpMyAdmin die praktikable Wahl – dann aber mit Verzeichnisschutz davor.

Sicherungen

phpMyAdmin kann exportieren, ist dafür aber nicht das richtige Werkzeug: Bei grösseren Datenbanken läuft der Export in die Zeitbegrenzung von PHP. Der zuverlässige Weg:

mysqldump --single-transaction --quick --default-character-set=utf8mb4 \
  -u app_shop -p shop | gzip > shop-$(date +%F).sql.gz

--single-transaction erzeugt bei InnoDB einen konsistenten Stand ohne Tabellensperre. --quick hält den Speicherbedarf niedrig, indem zeilenweise gelesen wird.

Und der Teil, der regelmässig fehlt: den Import testen. Ein Dump, der nie zurückgespielt wurde, ist eine Vermutung, kein Backup.

Häufige Fragen

Reicht es, phpMyAdmin unter einem anderen Pfad zu installieren?

Es reduziert das automatisierte Rauschen erheblich, ist aber kein Schutz gegen einen gezielten Zugriff. Der ungewöhnliche Pfad gehört mit einem Verzeichnisschutz und einer IP-Beschränkung kombiniert.

Wie beschränke ich den Zugriff auf meine IP?

Mit Require ip in der .htaccess oder im VirtualHost. Bei wechselnder IP im Homeoffice ist das unpraktisch – dann ist Basic Auth vor der Anmeldemaske die passendere Lösung, oder ein VPN in das Netz des Servers.

Welche Rechte braucht der Datenbanknutzer?

Für die tägliche Arbeit SELECT, INSERT, UPDATE und DELETE auf genau einer Datenbank. Strukturänderungen brauchen zusätzlich CREATE, ALTER und DROP – die kann man vorübergehend geben und danach wieder entziehen.

Gibt es Alternativen ohne Weboberfläche?

Ja. Ein SSH-Tunnel auf Port 3306 und ein lokaler Client wie DBeaver, TablePlus oder das mysql-Kommando. Die Datenbank bleibt dabei an localhost gebunden und ist von aussen gar nicht erreichbar.

Weiterlesen