Daniel

Samsung Galaxy S1 (DREI) und Gingerbread 2.3

von

…und die Geschichte der Gier

Mein  gutes altes Smartphone *hehe* nämlich Smartphone und dann das ->> (LG KP500) hat nach 4 Jahren leider Gottes seinen Geist aufgegeben. Nun stand ich vor der Qual der Wahl. Was soll ich mir gönnen? Naja es wurde schließlich ein Samsung Galaxy S (Version 1).

Gebranded ist das SGS (Abkürzung für Samsung Galaxy S) auf den Anbieter Drei. Genauso enthält es einen Simlock. Als OS kommt es mit Android in der Version 2.2 (Froyo).

Ein genauerer Blick auf die Firmware sagt: Firmware Version: PDA:JP5 PHONE:JP2 CSC: JP2 (DRE)

Unter CSC sieht man, dass es Version JP2 ist. Das DRE in der Klammer besagt wiederum, dass es sich hier um ein Handy handelt, dass spezifisch für DREI (3) konfiguriert ist. Die CSC Datei beinhaltet u.a. providerspezifische Daten. Diese Datei sollte im späteren Verlauf meiner Flashorgie noch von enormer Wichtigkeit sein!

Wie komme ich in der Überschrift auf „Gier?“. Nun, ich habe mit Android Smartphones absolut nix am Hut. Das ist mein erstes Smartphone. Keine Frage es funktioniert auch mit der Firmware (Original von Drei), aber irgendwie gierte ich danach, doch die neuere – wenn nicht gleich die neueste – Firmware zu flashen.

Wie gesagt ich hatte keine Ahnung. Deshalb nervte ich dann im Forum „www.android-hilfe.de“  die armen Profis, die dort wirklich tolles leisten, denn es gibt Tutorials zu Hauf. Unmengen an Informationen… Tja, solche Mengen, dass sich ein Anfänger in Sachen „Android“ schnell überfordert sieht. Ich fasse hier ganz kurz zusammen was man alles machen muss, um zu flashen. Alle Details findet ihr im tollen Portal von www.android-hilfe.de (Samsung Galaxy Rubrik) (unter Root Hacking … ->> Samsung Originalfirmwares)

Wichtig ist ab hier, dass man die Garantie des Herstellers (Anbieters) verliert / verlieren kann, wenn man selbst mit der Firmware herumspielt und etwas schief geht!

Ab hier übernehme ich weiters keine Verantwortung für eventuelle Schäden und Probleme, die durchaus entstehen können, wenn etwas schief geht, oder falsch gemacht wird!

Ausgangsbasis

  • Installiertes aktuellstes KIES + Treiber (normalerweise bei KIES dabei)
  • USB Kabel (im Lieferumfang des SGS)
  • Android Froyo Firmware 2.2
  • Handy wird ordnungsgemäß erkannt, wenn es angesteckt wird

Zuallererst Prüfen ob der Downloadmodus aufrufbar ist

  • Handy abschalten
  • Lautstärke nach unten + mittlere Taste unter dem Touchscreen + Powertaste gedrückt halten
  • warten bis ein Gelber Android mit Schaufel am Screen erscheint (Downloading… erscheint)
  • Wenn er erscheint ist alles klar, Downloadmodus ist aufrufbar (ohne Downloadmodus nicht weitermachen!) Es gibt allerdings einen Workaround der ebenso auf www.android-hilfe.de zu finden ist.

Dann prüfen ob man in den Recovery Modus kommt

  • Handy ausschalten
  • Lautstärke nach oben + mittlere Taste unter dem Touchscreen + Powertaste gedrückt halten
  • warten bis man in ein Menü gelangt in dem man zb auswählen kann,  dass ein wipe gemacht wird etc.

Details zum Download bzw. Recoverymodus findet man HIER

 

Datensicherung – Unbedingt machen!

Nein, ein überlesen gibt es nicht. Ohne diese Datensicherung, hätte ich jetzt nur noch ein halb funktionsfähiges Handy. Also macht unbedingt die Datensicherung – OHNE WENN UND ABER! Für die Datensicherung braucht man einen Terminal (vom Market -> zb ConnectBot) und muss das Handy rooten.

Die Anleitung hierfür findet ihr HIER (Sicherung des Ordners EFS bzw,. des Produktcodes)

Nachsatz:

Mit dem Programm (Superoneclick) kann man das SGS bis zur Android Version Gingerbread 2.3 rooten.  (Funktioniert unter Gingerbread Version 2.3.3 NICHT MEHR!) Wenn man Gingerbread rooten will (Hier nachlesen Post Nr. 4 hat bei mir ohne Probleme funktioniert.)

Über ein Terminalprogramm ist es dann möglich, die Daten des Ordners /efs in den Ordner /sdcard wegzusichern, auf den man dann per PC (USB Verbindung -> Wechseldatenträge) zugriff hat. Details, wie erwähnt, in dem Link weiter oben)

Der Flashvorgang

Ich bin mir nicht sicher, ob dies unbedingt nötig ist, jedoch habe ich die Simkarte und die SDCard vor dem Flashvorgang heraus genommen.

Der eigentliche Flashvorgang von Froyo (2.2) zu Gingerbread 2.3.3 ist HIER erklärt, ebenso findet man die Firmware dort. BITTE UNBEDINGT DIE FIRMWARE MIT BOOTLOADER RUNTERLADEN!

Kurz gesagt wird mit Hilfe des Programmes ODIN + der Firmwaredatei (ich habe immer die 3 Teile Firmware = 3 Dateien) verwendet, die neue Firmware aufs  SGS gespielt.

Ihr dürft am Handy während des Flashvorganges nichts machen, der AKKU sollte möglichst voll sein. Odin zeigt mit Hilfe eines Verlaufsbalkens den Fortschritt an. Auch am SGS selbst erscheint nach einiger Zeit ein Verlaufsbalken. Das Handy startet – wenn nötig – von selbst neu. Ihr müsst nichts machen.

Am Besten ist es zu warten, bis das SGS wieder hochgefahren ist und auf die Eingabe des Pin wartet.

Factory Reset und Wipe

Es wird angeraten, nach dem Flash ein Factory Reset und Wipe zu machen. Das hab ich auch getan. Und ab da gabs dann Probleme, die ich selbst noch immer nicht genau nachvollziehen kann. Jedenfalls roamte mein Samsung Galaxy S immer. Obwohl ich APN und sämtliche weitere wichtige Einstellungen im SGS eingetragen hatte, funktionierte das Internet nicht.

Schließlich bin ich dahinter gekommen, dass es funktioniert, wenn ich Roaming einschalte.

Vor dem Flashvorgang musste Roaming jedoch nicht eingeschaltet werden und alles funktionierte. Es schien so, wie wenn DREI mich nicht mehr als „Dreiuser“ erkannte.

Über die Telefoninformation Stichwort Auflandsaufenthalt, kam ich dann dahinter , dass mein Phone glaubte, es wäre im Ausland. (vor dem Flash stand da: Auslandsaufenthalt -> kein Roaming, jetzt Auslandsaufenthalt -> Auslandsaufenthalt -> also Roaming).

Und jetzt kommt der Punkt, weshalb die Datensicherung von immenser Wichtigkeit ist.

Ich musste meine Originaldateien nv_data.bin von der Datensicherung (auf der sdcard im Verzeichnis /sdcard d. SGS wieder in den Ordner /efs kopieren und die bestehenden Dateien überschreiben!

Hierfür muss man Rootrechte haben und braucht ein gerootetes SGS (Gingerbread 2.3.3 -> Erklärung dazu oben verlinkt)

Somit hab ich wohl den Productcode d. Handy wiederhergestellt. Warum sich das ganze so abgespielt hat bzw. was schließlich der Grund für das Dilemma war, weiß ich im Moment noch nicht genau.

 

 

 




 

 

Sonnensturm 08.06.2011

von

Wie man heute in diversen Medien lesen kann, gab/gibt es auf unserer Sonne wohl einen gewaltigen Sonnensturm.  Dieser wiederum löst geomagnetische Stürme aus, die lt. Angabe der NASA unsere Stromversorgung und auch GPS Satelliten beeinträchtigen können. Als Laie kann man sich hier genaugenommen kaum etwas darunter vorstellen. In Diskussionen wird oft die Abkürzung „EMP“ verwendet. Das wiederum bringe ich hauptsächlich mit dem Film Matrix in Verbindung…. 😉

Warten wir mal ab, was passiert…

Auf Youtube schaut das ziemlich beeindruckend aus:

Sonnenwind

Nicht auffindbarer Trojaner verursacht Blacklisting

von

Hatte ich heute noch gar nicht daran gedacht, dass es eventuell ein typischer Montag werden sollte, wurde ich jedoch alsbald wieder auf den Boden der Realität zurückgeholt. Ein typischer Montag nimmt seinen Lauf. 🙂

Mein Server auf der Blacklist – na toll. Ein paar Emailprovider rejecten meine Emails bereits, da selbige die Blacklists zum eigenen (Spam)Schutz abrufen. Ich bemühe besagte Website des  „Blacklistinganbieters“, um zu sehen, was denn da los ist und werde auch sofort und sehr detailliert auf die Sachlage aufmerksam gemacht.

Offenbar hat einer meiner LAN Rechner eine Verbindung zu einer IP Adresse aufgenommen, die nur ein bereits seit 2008 im Umlauf befindender Bankingtrojaner nutzt. Um nun herauszufinden, welcher Rechner es genau ist, bemühe ich mein GOTT SEI DANK sehr umfangreiches Logging auf der Firewall. Hätte ich hier keine Logs, wäre ich ganz schön aufgeschmissen!

Nach kurzer Recherche ist der betroffene Rechner auch ausfindig gemacht. Nach Studie der „Charakteristiken“ des Trojaners, wird zu allererst mal nach einem Removaltool für diesen „Bösling“ gesucht und gefunden.

Nicht zu vergessen gilt es, die automatische Systemwiederherstellung von Windows XP auszuschalten. Und nun feuer frei… der Remover sucht… und sucht… und findet: NICHTS…?!?!

Ratlosigkeit?

Nein, als Präventivmaßnahme blocke ich alle ausgehenden Connections zu besagter Schädlings-IP, die anscheinend immer dieselbe ist. Natürlich ist das keine Problemlösung, jedoch verhindere ich hiermit weitere Kommunikation. Weitere Scanvorgänge mit 3 anderen Utilities und auch Antivirensoftware verpuffen ebenso ohne Ergebnis. Alle meinen: „Die Maschine ist clean.“

Handarbeit

Gut! Dann geh ich halt selbst suchen! Aufgrund der detaillierten Beschreibung des Trojaners, suche ich selbst nach Dateien und Registryeinträgen, die hinterlassen werden. Zu meiner Verwunderung finde ich aber auch hier keinen einzigen Hinweis darauf, dass ein Schädling am Werke ist.

Ok, zusammenfassend:

  • Virenscanner und div. Tools finden nichts
  • Manuelle Suche nach Spuren des Trojaner sind erfolglos. Es sind keine Spuren (abgelegte Dateien in /Temp oder /Windows/temp) zu finden

Nächster (letzter) Lösungsansatz, bevor eine Neuinstallation des Rechners die letzte Variante ist, ist das neu schreiben des MBR (MasterBootRecord) mittels XP CD und Recoverymodus, da sich der Schädling im MBR versteckt.

Der MBR wird erfolgreich neu geschrieben. Ich reboote das System und werfe, nachdem der PC hochgefahren ist, erneut einen Blick auf meine Logdateien. Normalerweise hat der PC bei jedem Neustart eine Verbindung zur „bösen“ IP aufgenommen.

Aha, siehe da – es wird keine Verbindung mehr aufgebaut. Schaut nach einem Erfolg aus.

Nichts desto trotz ist in so einem Fall, die bessere Variante, den PC neu aufzusetzen!

Übrigens handelte es sich lt. Spamlisting um diesen Schädling (obwohl einige Details nicht dafür sprechen), der nur unter Windows sein Unwesen treibt: http://www.symantec.com/security_response/writeup.jsp?docid=2008-010718-3448-99

 

 

 

Joomla 1.6 Templates selbst erstellen

von

Obwohl es unzählige Templates für das CMS Joomla gibt, kann es durchaus sinnvoll sein, sich genauer mit der Templateerstellung in Verbindung mit Joomla zu beschäftigen. Eines vorweg: Es ist nicht so kompliziert, wie es auf den ersten Blick vielleicht scheinen mag!

Grundvoraussetzungen

Auch wenn man kein Guru auf dem Gebiet von HTML, CSS und eventuell auch PHP sein muss, sind gewisse grundlegende Kenntnisse (vor allem in HTML und CSS) sinnvoll und erleichtern die Templateerstellung erheblich. Bezogen auf CSS kann ich nur sagen, dass selbst CSS Gurus oft mit dem einen oder andren Problem zu kämpfen haben. Dies nicht zuletzt durch die teilweise sehr kreative CSS Interpretation diverser Browser, die sich eher weniger um geltende CSS Standards gekümmert haben.

Ich behaupte hier einfach, dass man – um möglichst gute standardkonforme CSS Unterstützung zu bekommen – auf Mozilla Firefox zurückgreifen sollte. Optimalerweise hat man dann auch gleich Firebug oder die WebDeveloper Toolbar installiert!

Ein guter Editor (z.B. Notepad++) sollte ebenso zum Fundus des angehenden „Joomlatemplatedesigner“ zählen :-).

Zuerst ist das Design

Egal ob auf Papier gezeichnet, oder auf dem PC im Lieblingsgrafikprogramm erstellt, hauptsache man weiß, wo man hin will. Ich mache es immer so, dass ich auf GIMP zurückgreife. Das heißt, ich „zeichne“ mir in Gimp die „Website“.

Zu allererst öffnet man eine neue Datei. Die Leinwand (= in Gimp die Arbeitsfläche) sollte hierbei so groß sein (vor allem in der Breite!) wie der Webauftritt später.

Bsp: Will man eine Website mit fixer Breite von 1024px, bietet es sich an, die Leinwand in der Dimension 1024px x 768px zu erstellen.

Nun zeichnet man sich auf erwähnter Leinwand seine Website. Grundlegend könnte man die Elemente der Website aufteilen in:

  • Hintergrund (hier ist der Body in HTML gemeint, dem man zb ebenso eine Grafik als Hintergrundbild geben kann)
  • Header
  • oberes Menü (horizontal)
  • Breadcrumbleiste (horizontal)
  • linkes Menü
  • Inhalt
  • rechts Menü
  • Fußleiste

Um alle Elemente komfortabel bearbeiten zu können, sollte man auf jeden Fall auf Ebenen in Gimp zurückgreifen. Was heißt das? Nun, jedes Element sollte auf einer eigenen Ebene liegen. Der Vorteil liegt darin, dass sich die Ebenen untereinander nicht in die Quere kommen. Man kann jede Ebene und somit auch jedes Element der Homepage separat bearbeiten, sieht aber trotzdem immer das Gesamtbild (da ja auch die anderen Ebenen angezeigt werden).

Kann man sich rein vom lesen her sicherlich schwer vorstellen.

Deshalb biete ich hier eines meiner ersten Joomla  1.6 Template als GIMP XCF Datei zum Download an. Bitte herunterladen und sich die Ebenen ansehen! (Man benötigt dafür GIMP)!

Das Konzept dahinter ist, dass man quasi jede Ebene nach Fertigstellung des Design in Gimp in eine separate Grafik (JPG oder auch PNG) speichert und diese Grafiken dann in die Homepage per CSS einbinden kann. Um es nochmals zu verdeutlichen:

  • Als erstes hat man in Gimp das Gesamtdesign, die Elemente sind in unterschiedlichen Ebenen aufgeteilt
  • Ist das Design in Gimp soweit fertig, speichert man die einzelnen Elemente (siehe oben -> Elemente der Website) in separaten Grafikdateien (PNG oder JPG Format)
  • Diese separaten Grafiken bindet man später per CSS ein, damit der Webauftritt dann so aussieht wie im Gimpentwurf

 

Weiter gehts

Ich gehe davon aus, dass sämtliche Grafikelemente nun als JPG oder PNG Datei vorliegen, man CSS soweit beherrscht,  dass man ein Design erstellt hat und die Grafikelemente entsprechend eingebunden hat (Die Elemente kann man sich im Beispieltemplate für Joomla 1.6 (ZIP) ansehen. Es ist hier noch nicht wichtig, dass man in irgend einer Form an Joomla denkt! Inhalte kann man in diesem Stadium der Entwicklung noch „hardcoded“ einfügen, um zu sehen wie sich das Design macht.

Beim Entwickeln sollte man eventuell bereits einen Hauptordner mit der Datei index.php haben und 2 Unterordner /images und /css. Die CSS Datei, die in die index.php eingebunden wird, liegt im Unterordner /css die einzelnen Bilder und Designelemente im Unterordner /images!

Joomla „Modulpositionen“  einfügen

So, nun ist es ander Zeit sich über Joomla Gedanken zu machen. 🙂 Joomla behandelt fast alle seine Komponenten als Module (im Quelltext type=“modules“) die an gewissen Positionen (im Quelltext name=“position-1″ usw) und in einer gewissen Darstellung (im Quelltext type=“xhtml“) eingebunden werden. Im Quelltext muss man nun noch darauf „hinweisen“, dass nun Joomla in Aktion tritt UND dass ein Modul an einer bestimmten Position eingebunden wird.

Module bindet man im Quelltext (index.php) wie folgend ein:

  • <jdoc:include

folgend dann oben erwähnte Details also:

  • <jdoc:include type=“modules“ name=“position-1″ style=“xhtml“

und abschließend — wichtig!

  • />

Gesamt also:

  • <jdoc:include type=“modules“ name=“position-1″ style=“xhtml“  />

Unterschieden wird hier ausschließlich nach name=“irgend eine Position“.  Es ist vollkommen egal, wie diese Position heißt! Es muss nur im Backend von Joomla nach erfolgreicher Templateinstallation eine Zuordnung von Modul zu Position im Template erfolgen. (hier spielt auch die Datei templatedetails.xml, die ich ganz am Ende erwähne, eine wichtige Rolle).

Einbindung von Modulen für verschiedene Aufgaben

Man könnte  z.B. für ein oben darzustellendes Menü folgendes einbinden:

  • <jdoc:include type=“modules“ name=“position-1″ />

für die „Breadcrumbs“:

  • <jdoc:include type=“modules“ name=“position-2″ />

und für die linke Seite eines 3 Spalten Layout folgende Modulpositionen berücksichtigen:

  • jdoc:include type=“modules“ name=“position-7″ style=“xhtml“ />
  • <jdoc:include type=“modules“ name=“position-4″ style=“xhtml“ />
  • <jdoc:include type=“modules“ name=“position-5″ style=“xhtml“ />

Weiters zB für die rechte Seite:

  • <jdoc:include type=“modules“ name=“position-12″ style=“xhtml“  />
  • <jdoc:include type=“modules“ name=“position-6″ style=“xhtml“ />
  • <jdoc:include type=“modules“ name=“position-8″ style=“xhtml“ />
  • <jdoc:include type=“modules“ name=“position-3″ style=“xhtml“ />

Joomla „Contentbereich“ einfügen

Das Schema bleibt fast das selbe. Dort wo im Quelltext der Content  – also die Beiträge – erscheinen soll, schreibt man im Quelltext (index.php):

  • <jdoc:include type=“component“ />

Hier wird keine Position angegeben bzw. ist keine Position nötig, da ohnehin klar ist, dass es sich um den Beitragsbereich handelt!

Gut, gehen wir davon aus dass man nun also für das linke und auch das rechte Menü per jdoc:include… Module und entsprechende Positionen eingebunden hat und der Contentbereich ebenso per jdoc:include… in die index.php eingetragen worden ist.

Zurück zum Anfang der index.php

Ganz wichtig: als ERSTE ZEILE der index.php des Template sollte folgendes stehen:

  • <?php defined(‚_JEXEC‘) or die; ?>

Dies erlaubt nur Joomla einen direkten Zugriff auf Joomladateien und dient so der zusätzlichen Sicherheit

Bei jedem HTML Dokument ist es ausserdem immens wichtig, den richtigen Doctype anzugeben, damit der Browser weiß, wie er die ihm vorgesetzte Datei „interpretieren“ soll. Was ich vorhin auch noch vergessen habe zu erwähnen ist, dass es auch für den Headbereich ein „jdoc:include…“ gibt nämlich:

  • <jdoc:include type=“head“ />

Dieses „include“ bindet u.a. diverse meta tags und auch den Titel der Website ein. Es ist also auch immer hinzuzufügen!

Der gesamte Kopfbereich der index.php sieht also so aus:

  • <?php defined(‚_JEXEC‘) or die; ?>
  • <!DOCTYPE html PUBLIC „-//W3C//DTD XHTML 1.0 Transitional//EN“ „http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd“>
  • <html xmlns=“http://www.w3.org/1999/xhtml“ xml:lang=“de-de“ lang=“de-de“ dir=“ltr“ >
  • <head><jdoc:include type=“head“ />
  • <link rel=“stylesheet“ href=“<?php echo $this->baseurl ?>/templates/simply_orange/css/template.css“ type=“text/css“ media=“screen,projection“ />
  • </head>

Info : <?php echo $this->baseurl ?> bindet automatisch das korrekte Basisverzeichnis ein.

templatedetails.xml, template_preview.png, template_thumbnail.png

Die Datei templatedetails.xml beschreibt das erstellte Joomlatemplate im sogenannten XML Format. In dieser Datei müssen u.a. alle oben festgelegten Positions eingetragen werden, die Verzeichnisse des Template und die Dateien die im Hauptverzeichnis liegen.

Für das Template simply_orange sieht die templatedetails.xml so aus:

 

Ein Screenshot des fertigen Template (der Website) wird nun noch als template_preview.png in einer Auflösung von ca. 800×600 in das Hauptverzeichnis des Template gepackt. Danach verkleinern wir den Screenshot auf ca. 200×150 und speichern diesen unter dem Namen template_thumbnail.png ebenso im Hauptverzeichnis des Template ab.

Template Zippen

Zuletzt, nachdem nun alles passen sollte, zippen wir unseren Ordner, der unser Template enthält inkl. aller Unterverzeichnisse und Dateien. Diese Zip Datei kann man dann per Joomlabackend -> Erweiterungen installieren hochladen und in der Templateverwaltung als Standardtemplate definieren.

Ist auch das geschehen, muss man den aktiven (bzw. den gewünschten) Modulen noch die entsprechende Position im Template zuordnen (zu finden in der Modulverwaltung) und schon sollten die Module auch auf der Website erscheinen.

Kritik und Anregungen nehme ich gerne per Kommentar oder Email entgegen 😉

Danke fürs lesen…

Joomla und Sicherheit

von

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.