Joomla und Sicherheit

Joomla, das einfach zu installierende CMS!

Eine durchaus richtige Behauptung, denn die Installation stellt selbst für unerfahrene Benutzer kaum ein Problem dar.

In Zeiten wie diesen kostet auch ein Rootserver nicht mehr die Welt und schick anhören tut es sich ausserdem, wenn man verlautbaren kann, dass man einen eigenen Rootserver betreibt. Diese Kombination kann in Verbindung mit „Webmaster“, die sich nicht um die Sicherheit der Installation und der Serverdienste kümmern, zu einem großen Problem werden (bzw. ist das schon ein Problem!).

 

Warum?

Auch wenn die Installation von Joomla und anderen CMS heutzutage fast von jedem durchschnittlichen Anwender durchgeführt werden können, heißt das noch lange nicht, dass die Arbeit für den Inhaber des Internetauftritts damit getan ist!

Folgende Schritte sind nach der Installation und im laufenden Betrieb wichtig (ich gehe hier hauptsächlich auf die Komponenten von Joomla ein):

• Ist meine Webserverumgebung möglichst sicher konfiguriert (Apache/PHP/MySQL…)
• Gibt es für die installierte Version des CMS bereits Aktualisierungen, die unbedingt eingespielt werden sollten
• Welche Module / Plugins brauche ich eigentlich für den Betrieb meines Internetauftrittes?
• Wie alt sind Third Party Plugins? Gibt es hier eine laufende Aktualisierung vom Entwickler, oder gammelt da bereits eine Version herum, die eigentlich nicht mehr gewartet wird?
• Kontrolle der Logdateien

 

Absicherung der Webserverumgebung

Natürlich verhält es sich mit der Absicherung des Webserver oft so, dass ein Spagat zwischen Sicherheit und Funktionalität gemacht werden muss. Es gibt aber ein paar grundlegende Einstellungen, die auf jeden Fall kontrolliert werden sollten. (Sämtliche folgende Beispiele beziehen sich auf Debian Linux 6.0 (Squeeze) (LAMP)

PHP Konfiguration

Die Konfiguration von PHP wird in der Datei php.ini durchgeführt, welche sich im Ordner /etc/php5/apache2/php.ini befindet. Um die Datei zu editieren, öffne ich sie mit meinem Lieblingstexteditor „vim“.

Einige empfohlene Einstellungen:

• allow_url_fopen = Off
• allow_url_include = Off
• expose_php = Off (Kein Sicherheitsfeature, jedoch kann hiermit verschleiert werden, ob php verwendet wird)
• register_globals = Off

MySql und phymyadmin

Auch der MySql Server sollte entsprechend abgesichert sein. Dies betrifft meiner Meinung nach vor allem die angelegten Datenbanken und User.

Nach der Installation von MySql gibt es „nur“ einen User „root“. Der Superuser, der ALLES darf. Hier ist unbedingt ein Passwort zu setzen.  Root User ohne Passwort ist verboten!

Genauso sollte man nicht aus Bequemlichkeit alle Datenbanken für eventuell vorhandene CMS Installationen einfach unter Verwendung des Rootuser „root“ laufen lassen!

Für jede Datenbank ist ein eigener User zu verwenden / anzulegen, der mit minimalen / benötigten Datenbankrechten ausgestattet wird. Oft reicht es bereits dem DB User nur DATEN-Rechte  (Select, Insert, Update, Delete) für die jeweilige Datenbank zuzuweisen.

 

Phpmyadmin fragt beim Einloggen zwar nach Benutzername und Passwort, jedoch ist es sinnvoll, das Verzeichnis /phpmyadmin mittels .htaccess Datei zu schützen. Erst nach korrekter Eingabe von Benutzername und Passwort gelangt man zum eigentlichen Phpmyadmin – Login.

Erstellung einer .htaccess / .htpasswd Datei

Einfach mit den vorhandenen Bordmitteln des Apachewebserver möglich. In einer Konsole tippt man:

• htpasswd -c .htpasswd operator
• RETURN
• Abfrage des selbst auszusuchenden Kennwortes
• Fertig!

Nun haben wir eine Datei .htpasswd, die -wenn möglich – NICHT im Document Root des Webserver abgelegt werden sollte, sondern abseits des eigentlchen Document Root des Apache Webserver! Für dieses Beispiel, nehmen wir an, wir hätten die  Datei unter /etc/.htpasswd gespeichert. Wir merken uns den Pfad zur Datei und wechseln in das Verzeichnis, das wir per .htaccess Datei schützen wollen. Per Texteditor öffnen wir eine leere Datei .htaccess:

• vim .htaccess
• RETURN

und tippen folgendes in die Datei:

• AuthType Basic
• AuthName “Service “Servicebereich”
• AuthUserFile /etc/.htpasswd (Pfad zur .htpasswd -> absolut!)
• require valid-user

Wichtig ist ausserdem, dass der Apache Webserver (die entsprechende Directory Directive) so konfiguriert ist, dass die .htacces Datei überhaupt berücksichtigt wird. Stichwort: AllowOverride  All. (siehe auch: http://httpd.apache.org/docs/2.0/mod/core.html#allowoverride)

Wichtige Anmerkung zu phpmyadmin unter Debian Squeeze: Einstellungen in der Directory Directive von phpmyadmin können/sollten in der Datei /etc/phpmyadmin/apache.conf gemacht werden!

Zusätzlich dazu, kann man den Zugriff auch noch auf ein Netzwerk, oder auch einen Netzwerkadresse einschränken. Angenommen, phpmyadmin wird NUR vom internen Netzwerk aus genutzt und ist von diesem auch erreichbar, könnte man folgende Ergänzung in der Datei /etc/phpmyadmin/apache.conf (innerhalb von <Directory> …. </Directory> vornehmen:

• Order deny,allow
• Deny from All
• Allow from 192.168.0.0/24

Nur das Netzwerk 192.168.0.0 – 192.168.0.254 darf auf das so geschützte Verzeichnis zugreifen.

Natürlich würde es hier auch möglich sein, eine statische öffentliche IP (des eigenen Internetzuganges) einzugeben. Man erstellt damit in jedem Fall eine weitere Barriere für eventuelle Einbruchsversuche.

Apache

Die Konfigurationsdatei /etc/apache2/sites-enabled/000-default ist u.a. für diverse Einstellungen des Apache Webserver zuständig. Folgende Änderungen erhöhen auch hier die Sicherheit:

• ServerSignature Off (Apache teilt keine Versionsnummern mehr mit, je weniger Infos nach aussen weiter gegeben werden, desto schwerer hat es ein eventueller Angreifer)

Über den Konsolenbefehl a2dismod können Apache Module deaktiviert werden, die nicht unbedingt benötigt werden. (Mittels Befehl a2enmod können im Gegenzug dazu Module aktiviert werden.

Folgende Module können in der Regel deaktiviert werden, sind jedoch standardmäßig aktiv:

• status
• autoindex
• userdir
• cgi

Nach dem aktivieren bzw deaktivieren eines Modules ist ein /etc/init.d/apache2 restart auszuführen.

 

Zum Schluss: Joomla

Joomla selbst besteht aus einigen CORE Komponenten (Kernkomponenten), die von den zuständigen Programmierern laufend gewartet werden. Dadurch ergibt sich eine relativ hohe Sicherheit. Gemeldete Sicherheitslücken werden normalerweise recht schnell „gefixt“. Auch mit Joomla „Core“ ist es möglich, sehr schöne Websites zu gestalten!

Nun kommt es aber oft zu Sicherheitsproblemen, wenn „nicht Core“ Module installiert werden. Oft wird vergessen, dass nicht nur Joomla selbst immer auf dem aktuellen Stand gehalten werden muss!

Die Plugins und Module müssen ebenso immer aktualisiert werden, um keine Angriffsfläche durch Sicherheitslücken zu bieten. Was aber, wenn der Modulersteller das Modul einmalig erstellt hat und sich in weiterer Folge nicht mehr um sein Werk kümmert? Im schlimmsten Szenario wäre der Programmcode vielleicht unsicher, würde nicht gewartet werden und wird dennoch verwendet.

Ein klaffendes Sicherheitsloch, das vom Joomlaanwender/Admin eventuell nicht gestopft werden kann, da es keine Wartung durch den Modulersteller mehr gibt!

Unsicher sind also in erster Linie später eingespielte Module und Plugins, die nicht zu Joomla Core gehören!

Hier gilt es dann zu unterscheiden, welche Programmierer „saubere“ und „gewartete“ Module zur Verfügung stellen. Nur solche Module sollten dann auch verwendet werden.

Klar ist, dass die Anzahl von tausenden Modulen zwangsläufig schrumpft, wenn man so vorgeht, jedoch würde genau eine solche Vorgangsweise die Sicherheit von zig Joomlaauftritten eklatant erhöhen. Gibts ein Modul nicht, müsste man sich das dann  programmieren lassen. Das kostet… Man bekäme dann aber in der Regel sauberen Code + Wartung und somit Sicherheit.

Aber, da Geiz geil ist, wird sich das wohl kaum durchsetzen lassen.

Abseits dieser Überlegungen sind auch noch die Verzeichnisberechtigungen der Joomlainstallation richtig und sicher zu setzen. Weitere Details zu Sicherheit und Joomla findet man hier.