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.

 

 

 

 

 

IL2 Sturmovik: Cliffs over Dover erster offizieller Patch

Nun ist es soweit. Der erste Patch für COD wurde heute freigegeben. Das allerdings NUR über Stream. Erfahrungsgemäß dauert es (leider) ein wenig, bis alle Steamserver das Update erhalten. Hier (Europa / Österreich) findet Steam noch kein Update.

Der gestern veröffentlichte BETA Patch brachte bei mir leider nur ein endgültig NICHT MEHR spielbares COD. Launcher.exe wurde immer unerwartet beendet.

Naja, war ja auch ein BETA Patch :-).

Warten wir darauf, wann Steam das Update liefert.

Erste Erfahrungen mit dem ersten offiziellen Patch

Steam lädt das ca. 50MB große File relativ zügig herunter, was mich verwunderte, da ich mit starkem Andrang gerechnet hatte. Nunden, gut so. Natürlich versuche ich zuallererst das, was bei mir mit dem Beta Patch überhaupt nicht funktioniert hat: „Einzelmission, Kampagne starten…“.

Nach diversen Anpassungen zur Mission, klicke ich auf Fliegen und hoffe gleichzeitig, nicht gleich wieder auf dem Desktop zu landen. Der Verlaufsbalken erreicht die kritische 20% Marke, bei der sich die Sim mit dem BETA Patch immer verabschiedet hat.

Zu meiner Erleichterung funktoniert alles ohne Absturz und ich sitze nach kurzer Ladezeit im Cockpit.

Performance

Der nächste Test geht nun die Performance an. Nachdem bekannt ist, dass es vor allem Leistungseinbrüche beim Tiefflug bzw. in Verbindung mit der Darstellung von Bäumen und Gebäuden gibt, starte ich einen „sight seeing“ Flug über London. London = viele Gebäude = guter Performancetest.

Bereits beim drücken der Nase meiner Spitfire, bemerke ich „Microruckler“. Lästig! Je näher ich schließlich dem Boden komme, desto massiver geht die Performance in die Knie und es „ruckelt“ teilweise wirklich heftig. Ok, abbruch und auf in die Grafikeinstellungen: Bäume aus,  Flugzeugdetail hoch, Darstellung der Schäden am Flugzeug hoch, alle andren Einstellungen auf Low, Gras ein, Straßen aus.

Obwohl ich eigentlich angenommen hatte, dass dies deutlich mehr Performance bringt, gibt es wieder lästige Microruckler, die -wie mir erst in diesem Moment auffiel – fast synchron mit der Aktivität der Festplatte  auftreten.

Nebenbei bemerkt: Festplatte trifft es im Fall meines PC nicht ganz, denn ich verwende eine SSD der Firma Corsair und wundere mich deshalb um so mehr. Sollten die Dinger nicht schnell sein? Verursacht das Teil derartige CPU Last? Nein, kann ich mir nicht vorstellen.

Sicher ist im Moment für mich jedoch, dass das Nachladen der Texturen für die lästigen Microruckler verantwortlich ist.

Luftkampf

Auch im Luftkampf läuft es im Moment noch nicht ganz rund. Je mehr Flugzeuge, desto mehr stottert die Grafikengine (auch über Wasser). Ob ein Luftkampf – mit annehmbaren FPS –  über Land möglich ist, werde ich noch testen.

Fazit Stand 08.04.2011

IL2 Sturmovik Cliffs over Dover hat mir anfangs die Zornesröte ins Gesicht getrieben. Hatte ich doch relativ viele EURONEN in diese Simulation investiert und ncht damit gerechnet, dass es derartige Probleme gibt. Am liebsten hätte ich alles wieder zusammen gepackt und zurück gegeben.

Wider erwarten stellte sich  heraus, dass das Entwicklerteam keine Mühen scheut, um die IL2 Community wieder versöhnlich zu stimmen. Es scheint als geben die „Devs“ alles, um die vielen Bugs von CoD zu beheben. Im offiziellen 1cpublishing Forum hat sich sogar Olegg Maddox himself  zum Thema CoD zu Wort gemeldet: http://forum.1cpublishing.eu/showthread.php?t=20885

Zuletzt schließlich, macht es auch unter den oben erwähnten Umständen Laune in einer Spitfire zu sitzen. Es läuft noch nicht rund… aber es läuft und dürfte sehr viel Potential haben.

Weiter so!

 

Working Title: IL2 Sturmovik Cliffs over Dover

Publisher „1C Publishing“ arbeitet derzeit fieberhaft an einem Patch für Cliffs over Dover. Schließlich soll, wie bereits im Vorgängerartikel zum Thema erwähnt, am Freitag ein erster Patch erscheinen. Dieser zielt hauptsächlich auf die immensen Performanceprobleme der Simulation ab und wird von allen „Simulanten“ 😉 sehnlich erwartet. Es soll angeblich bereits heute eine Betaversion des Patches geben!

Mir ist es übrigens gelungen,  CoD auch ohne Patch  ziemlich ruckelfrei zu bekommen. Wie? Man schalte die Details auf Minimum und die Epilepsiefunktionen aus. Juhu, juhu es gibt nur noch Microruckler!

Rein ins Getümmel, dacht ich mir, als ich die Einzelmission „Stuka abfangen“ auswähle. Das Ziel der Mission ist es (lt. Missionbriefing) Stuka-Bomber abzufangen, um zu verhindern, dass alliierte Schiffe getroffen werden.

Also dann… Los! Endlich sitze ich im Cockpit meiner Hurricane ähm Moment, das ist keine Hurricane… Schaut ziemlich genau nach oben genanntem Stuka aus.

Ich soll also Stuka abfangen, jedoch sitze ich selber in so einer Kiste. Da kann was nicht stimmen. Ist wohl ne schlecht gebastelte Einzelmission. Nun gut, ich breche die Mission ab, gibt ja noch den Karrieremodus, der mich ohnehin eher reizt.

Meinen, beim Spielstart gebastelten, Piloten bemühend, werfe ich mich auf Seiten der Briten in die Kampagne. Per kurzem Einleitetext, der die Gedanken des Piloten beschreibt, wird versucht, soetwas wie Stimmung aufzubauen. Klickt man sich dann ins nächste Fenster, bekommt man plötzlich den Einleitungstext der „deutschen Seite“ ebenso vorgesetzt. Wieder „passt irgendetwas“ wohl nicht so ganz und ich bekomme dieses komische Gefühl nicht aus dem Bauch, dass ich gleich wieder enttäuscht werde.

Ich starte trotzdem! Missionbriefing: Bomber abfangen (schon wieder…).

Diesmal steht meine Maschine mit meinen 4 Flügelmännern auf dem Flugfeld und wartet, dass ich ihr die Sporen gebe. Gesagt getan starte ich und fliege den feindlichen Flugzeugen entgegen, bis sie in Reichweite meiner Bordwaffen sind.

Ich erteile meinen Flügelmännern per Funk den Befehl anzugreifen, jedoch kommt keine Bestätigung… Greifen sie nun auch an oder nicht… keine Ahnung. Die Sim lässt einen blöd da stehen. Naja dann werd zumindest ich mal nen Angriff starten.

Gerade habe ich die erste Maschine erwischt, steht auch schon MISSION COMPLETE mitten im Bildschirm, obwohl noch mindestens 20 Bomber übrig sind, die fröhlich vor mir dahinziehen.

Ich entschließe mich, noch 3 weitere Maschinen zu attackieren, bevor ich die Mission schließlich mittels „Verlassen“ beende.

Dumm nur, dass die Mission als gescheitert gewertet wird. War sie doch gerade vorhin complete und die Funksprüche der Flügelmänner deuteten ebenso darauf hin, dass wir es geschafft hatten.

Apropros Funksprüche. Meinen Befehlen folgen die Herren zwar nicht, jedoch gibt es die ganze Zeit wildes Geschnatter, das man kaum mitverfolgen kann.

Fazit mit heutigem Tage: Spielbar mit niedrigsten Einstellungen: JA, Spielspaß aufgrund der vielen zusätzlichen Mängel jedoch stark getrübt.

Ich bin jedoch guter Dinge, dass 1CPublishing ordentlich Gas gibt und das Ganze noch zum Guten wendet.

 

WordPress Upgrade Version 3.1.1

Mit der Version 3.1.1 wird die Sicherheit von WordPress nochmals verbessert. Abseits dessen sorgen diverse Anpassungen für eine bessere Performance. Genaueres zu diesem Thema kann man hier nachlesen: http://wordpress.org/news/2011/04/wordpress-3-1-1/.

WordPress-Deutschland liefert wie immer das komplette Paket in Deutsch. Wenn man bereits eine Version 3.1 laufen hat, kann man sich auch ein Upgradepaket herunterladen.

Genauers hier: http://wordpress-deutschland.org/download/

Zur Verbesserung des Service werden anonymisierte Nutzerdaten mittels Google Analytics verarbeitet. Falls Sie das nicht wünschen - > Hier klicken um dich auszutragen.