Was kann noch passieren, wenn die wp-config.php Datei geklaut wurde...

[Gast]

Aktuell bin ich am überlegen, was passieren könnte, wenn ein potentieller Einbrecher/Hacker durch ein fehlerhaftes Wordpress-Plugin oder einen fehlerhaften Theme in Besitz der wp-config.php kommt (SQL und PHP Injection via GET).

Darin ist ja bekannterweise das Passwort des Datenbank-Users und dessen Loginname gespeichert. Hat er das, kann er den Blog relativ leicht übernehmen, sofern er Zugriff auf den Datenbankserver hat (und WP-Admin).

Nun habe ich auf einem Rootserver, denn ich betreue bestimmte Vorkehrungen getroffen, falls der Fall eintreten sollte:

--> Zugriff auf das wp-admin Verzeichnis nur über eingeschränkten IP-Range (relativ eng!) möglich (global in httpd.conf)
--> Zugriff auf den MySQL-Server von außen nicht möglich (Firewall iptables), Server lauscht nur auf localhost
--> "böse" PHP-Module (fopen, exec, ...) via php.ini verboten
--> phpmyadmin nur über bestimmte Ranges erreichbar und mit vorheriger htaccess Passwortabfrage gesichert
--> ssh nur via certs und anderer Port (lange Passphrases)

Habe ich in der Kette etwas vergessen? Kann man da noch was ausbauen?

[seba86]

Danke für die Aufzählung der Tipps! Einen kann ich ergänzen:

---> FTP-CHMOD-Rechte: NUR Besitzer lesbar, der Rest hat gar keinen Zugriff drauf.
Jedes Mal, wenn du es ändern willst, musst du dir natürlich temporär CHMOD-Lesezugriff gestatten.

Schließlich kann man noch durch irgendeinen Hack die wp-config.php unbennen. Aber dann muss man jedes einzelne Update manuell nachbearbeiten --> lohnt sich nur, wenn es trotz obiger Sicherheitsmaßnahmen mehrfach gecrackt worden ist...

[qiller]

--> eigenen Datenbankbenutzer für die Wordpress-DB anlegen
--> falls mehrere Name-based VHosts auf dem Server laufen sollen, php über (fast-)cgi oder php-fpm verarbeiten lassen und für jeden VHost einen eigenen System-Benutzernamen/Gruppe vergeben
--> für PHP eigene Session-, Upload- und Open-Basedir-Pfade festlegen, die außerhalb vom doc-root Verzeichnis liegen
--> OpenVPN einrichten und Web-Admin-Oberflächen (PHPMyAdmin, Plesk, ISP-Config, Typo3, Wordpress-Backend etc.), FTP- und SSH-Zugänge nur über OpenVPN erlauben
--> falls FTP benutzt wird, nur verschlüsselt über FTP(E)S
--> zusätzlichen http-Auth aufs wp-admin-Verzeichnis schalten
--> bei Zugriff aufs Wordpress-Backend auf https umleiten oder generell Verschlüsselung nutzen

Allgemein sollte man bei einem einigermaßen abgesicherten System nicht in Panik geraten. Solang man nicht alles nach außen hin offen hat und das Wordpress-DB Passwort auch für andere wichtige Schaltstellen im Server nutzt, nützen einem Angreifer die Wordpress-DB Login-Daten herzlich wenig.

mfg Oli

[Milchkanne]

--> OpenVPN einrichten und Web-Admin-Oberflächen (PHPMyAdmin, Plesk, ISP-Config, Typo3, Wordpress-Backend etc.), FTP- und SSH-Zugänge nur über OpenVPN erlauben
Ich lass einfach gewisse Dienste nur auf Localhost lauschen und leite den Port dann per SSH weiter. Beispielsweise irgendeine Adminoberfläche auf Port 9090, dann 'SSH -L 9090:localhost:9090 user@servername' und geh dann auf http://localhost:9090. Damit spart man sich OpenVPN, das ist wieder ein offener Port weniger.

[qiller]

Ja gut, bei mir ist nur OpenVPN und die Dienste offen, die auch nach außen hin erreichbar sein sollen - SSH gehört nicht dazu :>. Oder ums mit anderen Worten zu schreiben, ich trau OpnVPN mehr als SSH, aber das ist wohl Geschmackssache.

mfg Oli

[Gast]

* SSH-Zugriff auf bestimmte Konten einschränken
* Bei Zugriff auf Admin-Oberfläche HTTPS erzwingen
* Phpmyadmin ganz weglassen und stattdessen mit einem SQL-Programm (Toad, MySQL Administrator) auf dem eigenen PC arbeiten, welches per SSH-Portweiterleitung auf die auf Localhost lauschende Datenbank auf dem Server zugreift.
* Jede Webanwendung hat ihre eigene Datenbank und ihren eigenen Nutzer der NUR auf diese Datenbank Zugriff hat. Zusätzlich: Der Datenbank-Benutzer erhält nur die Rechte, die im laufenden Betrieb der Webanwendung benötigt werden. Braucht man zB für den Betrieb von Wordpress kein ALTER TABLES, dann erhält der Benutzer dieses Recht auch nicht.
* Passwörter aller SSH-, VPN-, Datenbank-Konten, etc mindestens einmal im Jahr ändern, auch wenn kein Hinweis auf einen Einbruch vorliegt.


Das größte Einfallstor bei all den Maßnahmen bleibt aber unbeachtet: Die Webanwendungen selbst, in diesem Fall Wordpress.
Wichtig dort ist:
* Die Security- / Announce-Liste der jeweiligen Software per E-Mail / RSS abonnieren und sobald Updates angekündigt werden diese am selben Tag noch einspielen
* So wenig Plugins / Module wie möglich nutzen
* Die Dateien im Document Root des Webservers bzw des VHosts dürfen nicht dem Benutzer gehören unter dem der Webserver bzw PHP läuft. Dieser Benutzer darf auch keine Schreibrechte darauf haben, sondern die Dateien nur lesen können. Ein paar genau definierte Dateien wie zB Upload- oder Cache-Verzeichnis von Wordpress, wo die Webanwendung tatsächlich im Betrieb etwas reinschreibt, sind davon natürlich auszunehmen.
* Den Webserver kann man mit Apparmor oder ähnlichem noch weiter in seinen Rechten einschränken und auf diesem Weg zB unterschiedliche VHosts rechtemäßig voneinander abtrennen. Wenn eine Webanwendung kompromitiert wird hat der Angreifer dadurch keinen Zugriff auf die anderen Webanwendungen.