Joomla

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.

Es gibt ein neues Sicherheitsupdate für Joomla 1.5! Weitere Informationen auf www.joomla.org.

Meine laufende Website wurde von 1.5.22 auf 1.5.23 mittels Updatepaket auf die neueste Version upgedatet.

Vorgang:

• Man ladet sich das Upgradepakete herunter
• Entpackt die ZIP Datei
• Überspielt mittels FTP die Dateien und Verzeichnisse auf den Webspace und überschreibt dabei die bestehenden Dateien / Verzeichnisse.
• Fertig

Jumi ist ein Modul, welches es ermöglicht, auch Code in einen Artikel einzufügen, der sonst vom Joomla eigenen Editor nach dem abspeichern „weggeschnitten“ wird. Man kann mit Jumi auch ein Modul mit Code (PHP, HTML, JAVA…) erstellen, dass dann an beliebigen Modulpositionen erscheint.

Für Joomla 1.6 wurde die Jumiversion schon angepasst und lässt sich sehr einfach über die Erweiterungen installieren. Beim Erstellen des Modules und einfügen des notwendigen Quelltextes in das Jumi Codefenster scheint noch alles glatt zu laufen. Klickt man nun aber auf speichern, verschwindet alles bis auf einen eventuell vorhandenen Klartext aus dem Codefenster.

Jumi macht also genau das nicht, wofür es eigentlich da ist. Warum? Es handelt sich hierbei eventuell um einen Bug.

Google beförderte mich schließlich auf http://edo.webmaster.am/forum/jumi/joomla-jumi-module-problem-t107-10.html. Hier wird ein Workaround angeboten. In der Datei /modules/mod_jumi/mod_jumi.xml ist  bei Zeile 35 folgendes zu ergänzen (fett):

<field name=“code_written“ type=“textarea“ filter=“raw“ default=““ label=“Code written“ description=“PARAMCODEWRITTEN“ cols=“60″ rows=“17″ />

Danach Jumi erneut aufrufen, Quelltext einfügen und speichern. Bei mir hats jedenfalls funktioniert 🙂

Quelle Jumi: http://extensions.joomla.org/

Sachlage: Was hat es mit der Version 1.6 auf sich

Nach meinem letzten gescheiterten Versuch einen Joomla 1.0.x Webauftritt auf 1.5.22 zu bringen, hoffte ich, dass dies zumindest beim Versionssprung von 1.5.x auf 1.6.x einfacher gestaltet wird. Kurz gesagt: Ich hoffte auf ein „einfaches“ Update, wie man es auch von WordPress kennt.

Wie ich nun aber mehrfach bereits gelesen habe, ist wieder nix mit update. Nein, es ist wieder eine Migration nötig. Was heißt das nun? Tja, wieder kann man bangen, ob das Design (Template) übernommen wird, weiter gehts dann mit diversen Plugins und Modulen usw.

Ich finde es sehr schade, dass es nicht möglich ist, ein unproblematisches Update zu realisieren. Vielleicht mag es an der Komplexität von Joomla liegen, dass es eben nicht „einfach mal so“ läuft und man die Installation auf den neuesten Stand bringen kann.

Ich frage mich gerade auch was nun dem Webmaster übrig bleibt? Vielleicht bleibe ich auf 1.5.22, was mir natürlich im Moment ein herumgemurkste erspart? Im Endeffekt bleibt es so oder so egal! Irgendwann wird man den Schritt tun müssen, wenn man eine gewartete Joomlainstallation betreiben und möglichst alle Securityfixes zeitnah einspielen will.

Joomla 1.6 wird es 6 Monate lang geben, danach erscheint die Version 1.7 die ebenfalls nur 6 Monate „aktiv“ sein wird. Nach dieser Zeit, also ungefähr Anfang des Jahres 2012 kommt dann die Version 1.8 heraus. Dieses Release wird – wie Joomla 1.5 – ein Long Term Release sein. D.h. diese Version wird länger die „aktuelle“ Version von Joomla bleiben.

Bis zum Release von Joomla 1.8 wird Joomla 1.5.x noch gewartet. D.h. nun auch, dass man als 1.5er User / Admin bis Anfang nächsten Jahres (2012) noch auf 1.5.22 „bauen“ kann.

Templates von 1.5

Templates von Joomla 1.5 laufen unter 1.6 definitiv NICHT mehr, ohne größere Anpassungen. Hierbei sollte jedoch erwähnt werden, dass es auch aufs Template ankommt, wieviel Arbeit es ist, es auf 1.6 umzubauen. Soviel ich jetzt (nach einigem testen und fragen im IRC) sagen kann, gibt es vor allem bei den Modulpositionen Unterschiede in der Benennung zwischen Templates der Version 1.5 und 1.6.

Templates können ausserdem nicht mehr per FTP überspielt werden, sie müssen über das „Menü Erweiterungen / Erweiterungen installieren“ als ZIP Paket eingespielt werden. Wichtig hierbei ist, dass die Datei TemplateDetails.xml angepasst wird, wenn man ein Template der Jommlaversion 1.5 in Joomla 1.6 importieren will. Die Bennenung der Modulpositionen in der index.php des Template muss mit der Bennenung der Modulpositionen der Datei TemplateDetail.xml identisch sein! Wenn der Import des Templates erfolgreich war, gilt es noch die im Template verwendeten Modulpositionen zu prüfen. Wird einem Modul (zb. Main Menu) eine falsche Position zugeordnet, erscheint es NICHT auf der Website!

Weitere Infos dazu auf:

• http://software-lupe.de/sl-tutorials/422-cms/414-joomla-1-6-template-erstellen-oder-upgraden-tutorial
• http://www.dosonaro.com/joomla-1-6-der-unterschied-der-templatedetails-xml-zu-joomla-1-5/
• http://www.bloggerschmidt.de/blog/item/template-upgrade-15-auf-16.html

Modulpositionen Joomla 1.6.x

Testinstallation

Testhalber installiere ich Joomla 1.5.22 und stelle mir als Aufgabe, diese Installation auf Joomla 1.6.1 upzudaten. Dank der einfachen Installationsroutine läuft Joomla 1.5.22 nach ein paar Minuten einwandfrei.

Eine weitere Recherche im Internet brachte schließlich zu Tage, dass man das Migrationstool Jupgrade verwenden soll, um in den Genuß der neuen Joomlaversion zu kommen. Jupgrade wird als ZIP Datei heruntergeladen und über den Joomlainstaller (Erweiterungen >> Installieren / Deinstallieren und anschließender Auswahl der heruntergeladenen Zipdatei) installiert.

Gut!

Im Menü Komponenten gibt es nun Jupgrade.

Unter Erweiterungen / Plugins soll man anschließend das Mootools Upgrade Plugin (genauer System Mootools-Upgrade) aktivieren, was ich auch mache.

Ich starte Jupgrade, indem ich es unter Komponenten / Jupgrade auswähle:

Ok, klicken wir mal auf Upgrade starten… und klatsch… Fehlermeldung: 406:cURL not loaded

Google sagt mir: http://www.php.net/manual/en/book.curl.php

Offenbar ist bei meiner lokalen Installation des XAMP (zwangsweise momentan unter Windows) Curl für PHP nicht aktiv. Das kontrolliere ich, indem ich mir die Datei php.ini genauer anschaue und CURL suche.

Gesucht gefunden! Der Eintrag extension=php_curl.dll ist mittels vorgestelltem ; auskommentiert. Also weg mit dem ; und restart des Apache Webserver… Erneut rufe ich Jupgrade auf und klicke auf Upgrade starten und:

Es läuft. Joomla 1.6 wird heruntergeladen…  tja… und obwohl der Download eigentlich fertig sein sollte 8021058 von 8021058 bytes heruntergeladen, steht die Sache still…

Vielleicht liegt es an meinen WAMP Servereinstellungen. Wie ich zufällig sehe, gibts es – nachdem man Jupgrade unter Komponenten / Jupgrade gewählt hat – rechts einen Menüeintrag „Einstellungen“ für Jupgrade. Dort aktiviere ich „Download überspringen“, da das Programm ja meiner Meinung nach den Download bereits erfolgreich abgeschlossen hat und speichere das Ganze.

Ich starte Jupgrade nochmals, der Download wird übersprungen und es geht mit dem Entpacken weiter… und ja, es läuft erfolgreich durch!

Aha, anscheinend hat Jupgrade die Joomla 1.6 Version in den Ordner /jupgrade gepackt. Der URL für die Seite lautet nämlich: http://localhost/joomla15/jupgrade/ bzw. für die Adminseite: http://localhost/joomla15/jupgrade/administrator/

Schauen wir mal, ob die Seite überhaupt funktioniert:

Ja, es hat geklappt. Wie schaut eigentlich die Adminseite aus (Backend) und funktioniert die überhaupt?

Ja, sie funktioniert und es wurde sogar der Adminuser (vor allem das Kennwort übernommen).

Fazit

Wenn man als Ausgangsbasis eine „reine“ Joomla 1.5.22 Version verwendet, funktioniert die Migration mit Hilfe von Jupgrade recht einfach. Es bleibt natürlich abzuwarten, wie sich das Tool verhält, wenn es sich um eine Joomla 1.5.22 Webpräsenz handelt, die im Produktiveinsatz ist. Ich denke, dass vor allem  Webauftritte, bei denen viele Plugins und Module verwendet werden, die nicht zum Joomla – Core gehören, Probleme bei der Migration haben werden, solange es diverse Plugins und Module nicht für die 1.6er Version von Joomla gibt.

Mein nächster Versuch wird dann wohl der Einsatz von Jupgrade in Verbindung mit einer aktiven Webpräsenz – Joomla 1.5.22 – (die ich mir in meine Testumgebung „hole“) sein.

Ich rate allen Migrationswilligen 🙂 dazu, immer vorher in einer Testumgebung zu üben und wenn es dann ans Eingemachte geht (Produktivserver) ein Backup zu ziehen. (Datenbank  und Dateistruktur / Dateien)

Update: Nach dem Installieren meiner „Produktivwebsite“ in einer Testumgebung kann ich mittlerweile bestätigen, dass Templates der Version 1.5 nicht mit Joomla 1.6 kompatibel sind. Zum Einsatz kam auf Joomla 1.5 das Beez Template, welches etwas modifiziert wurde. Selbst nach löschen der Overrides, gibt es hier Probleme mit den Menüs. Dies wird dadurch hervorgerufen, dass die Modulpositionen unter Joomla 1.6 umbenannt wurden und ich Anfangs das Template einfach in den Template Ordner kopiert habe, was ja -wie oben erwähnt – unter Joomla 1.6 nicht mehr funktioniert.

Auch mit der Anpassung der TemplateDetails.xml + Erstellung der ZIP und ordnungsgemäßer Installation des Templates über die Erweiterungen (Joomla 1.6), hatte ich kein Glück. Die Menüs blieben weiter verschwunden.

Nach der Prüfung der Modulpositionen und ggf. Neuzuordnung der Modulpositionen erscheinen die Menüs. Es ist aber in jedem Fall mehr oder weniger Handarbeit zu leisten, um den Webauftreitt auf die Version 1.6 umzubauen.

Als Betreuer eines Joomla 1.5 Webauftrittes bin ich der Meinung, dass man auf die Version 1.8 warten sollte, bevor man einen Umstieg auf die neue Version in Erwägung zieht. Will man einen neuen Webauftritt gestalten, sollte man gleich auf die Version 1.6 bauen, um sich Migrationsprobleme zu ersparen. Angeblich werden die Unterschiede zwischen 1.6, 1.7 und 1.8 nicht so gravierend sein wie zwischen 1.5 und 1.6.

Viel Glück!