Immer wieder, kommt das Thema „Security by obscurity“ in den Joomla!-Foren auf. Aus diesem Grund bieten wir hier mehr Informationen zu diesem Thema.
Was ist „Security by obscurity“?
Stellen Sie sich vor, Sie verstecken einen Haustürschlüssel in der Blumenvase vor Ihrem Haus oder einen Schlüssel unter der Fußmatte. Denn wenn Sie sich versehentlich ausgesperrt haben, können Sie so ohne Kosten für einen Schlüsseldienst wieder ins Haus.
Dieses Versteck ist aber nur solange sicher, wie keiner es durch Zufall findet oder Sie beobachtet. Sobald jemand den Schlüssel findet kann er ohne einzubrechen in Ihr Haus.
„Sicherheit durch Verschleierung“ ist ein Extra!
Genau so ist das auch bei einer Website, wenn Sie die „Verschleierung“ als einzige Maßnahme zum vermeintlichen Schutz treffen, haben Sie keine Sicherheit geschaffen. Wenn Sie mehr Sicherheit schaffen wollen, dürfen Verschleierungsmaßnahmen nur zusätzlich zum vorhandenen Schutz ergänzt werden.
Joomla!-Erweiterungen
Gerade Entwicklungen von Drittanbietern, also nicht vom Joomla!-Core-Team, sind besonders anfällig für Sicherheitslücken, wie unsere Liste mit unsicheren Erweiterungen zeigt.
Sicherheit bei Software kann nur durch sichere Programmierung geschaffen werden und nicht durch alleinige Verschleierung!
Nun gibt es mehrere Wege gegen diese unsicheren Joomla!-Erweiterungen. Die erste und sicherste Vorgehensweise wäre, eine gefährdete Erweiterung nicht einzusetzen. Sofern dies möglich ist, ist das unsere Empfehlung. Man könnte aber auch durch eine Htaccess-Datei bestimmte mögliche Sicherheitslücken abfangen und den Angreifer im Dunkeln tappen lassen. Dies ist aber riskant, da man nie alle Lücken kennt und auch mit einer Htaccess-Datei schließen kann.
Nachfolgend einige Fälle der „Verschleierung“, die zur zusätzlichen Sicherheit beitragen können, wenn sogenannte „Script Kiddies“ die Internetseite angreifen. Sollte ein „richtiger“ Hacker Ihre Website angreifen, findet er die Information definitiv, es ist nur alles eine Frage der Zeit.
Umso weniger Informationen die Angreifer erhalten, über die Website, desto schwieriger wird es für den Angreifer und unrentabler. In der heutigen Zeit werden die Angriffe automatisiert. Schlägt dieses fehl, wird der Versuch abgebrochen und es geht zur nächsten Website. Ein gezielter Angriff auf der Website hat meist wirtschaftliche oder politische Interessen und kommt daher nur „vereinzelt“ vor.
Der Tabellenpräfix
In Joomla 1.5 war der Tabellenpräfix noch fest definiert „jos_“. Ab der Joomla 1.7 wurde dieser automatisch generiert. Was die Sicherheit doch sehr erhöht.
An diesem Beispiel, einem Exploit, über die Erweiterung „rapidrecipe“ kann man sehen, dass der Angriff nur dann Erfolg haben konnte, wenn der Tabellenpräfix nicht geändert wurde.
Sollte der Präfix hier geändert worden sein, läuft dieser Exploit ins Leere. Dennoch bleibt die Sicherheitslücke bestehen und MUSS geschlossen werden.
Super Administrator ID
Das gleiche gilt auch für die Super Administrator ID (Link-> zum Artikel)Da seit Joomla! 2.5.5 die ID zufällig aus einem Bereich von 1 und 1.000 gewählt wird, verringert sich auch das Angriffspotenzial. Hier kann zwar noch leicht ein Angriff erfolgen, da es nur 1.000 Möglichkeiten gibt, denn statistisch hat man nach ca. 2/3 bzw. 70% die ID ausfindig gemacht, also braucht man nur noch 700 Versuche. Diese lassen sich wunderbar automatisiert durchführen.
Man muss hier ganz klar sagen, dass die Angriffe zu 99,9% auf Erweiterungen von Joomla! abzielen und nicht auf Joomla! selbst. Das Einfallstor liegt ganz klar bei den Erweiterungen.
Fehlaufrufe
Auch Fehlerseiten können unter Umständen zur Verschleierung beitragen.Hierzu ein kleines Beispiel:
Der Ordner „administrator“ ist durch eine IP-Adressen-Sperre geschützt und kann nur von der bestimmten IP-Adresse aufgerufen werden.
Hier würde standardmäßig die Servermeldung „403“ ausgegeben werden. Das bedeutet, dass der Ordner vorhanden ist, aber dass keine Berechtigung vorliegt den Ordner aufzurufen.
Nun kann man eine Umleitung („Redirect“) auf eine „404“-Seite („Datei oder Verzeichnis nicht gefunden“) erstellen und es so aussehen lassen, als würde der Ordner „administrator“ nicht existieren, obwohl er ja faktisch existiert.
Diese „Verschleierung“ kann man aber schnell enttarnen, dazu schaut man sich einfach den sog. „Header“ der Übertragung an. (Für den Firefox gibt es hier für ein nettes Add-on namens „Live HTTP Headers“)
Hier steht drin, dass man umgeleitet worden ist. Dieses wird auch kein Hacker abhalten, aber unter Umständen die sogenannten „Script Kiddies“.
Robots.txt / Htacces-Sperrung von Bots
Richtig weit her geholte Verschleierung ist die Auffindbarkeit der Website. Sprich die Listung in Suchmaschinen.Leider gibt es eine ganze Menge an sinnlosen und bösen Bots die nach Webseiten suchen, um sie dann in ihren Verzeichnissen zu indizieren. Hier bedienen sich viele „Script Kiddes“ und Datensammler.
Wir haben einige Tests gestartet und waren nach der ersten Auswertung mehr als positiv überrascht.
Im erst Schritt stand die Überlegung, wie wir vorgehen. Es gab folgende Möglichkeiten:
- Alles sperren und nur das Zulassen was wir genehmigen
- Nur das Sperren was sinnlos und böse ist
Im zweiten Schritt haben wir uns Varianten überlegt:
- Robots.txt anpassen und beobachten was nach einiger Zeit passiert
- Wenn sich die Bots nicht an die Regel halten - wovon auszugehen war - entschieden wir uns für eine Sperrung per Htaccess bzw. Firewall-Regel
Nach nur einer Woche mit diesen Änderungen in der robots.txt, konnten wir bei Google sehen, dass viele Seiten wie webwiki.de oder urlspion.de, die ein Dossier zu joomla-security.de ungefragt angelegt hatten, nicht mehr im Index waren. Dieses hat unserer Meinung nach folgende positive Auswirkungen gehabt:
- Wir tauchen nicht mehr auf sinnlosen Webseiten auf, die keine nützlichen Informationen liefern.
- Suchmaschinentechnisch (SEO) sind andere Seiten um 1-4 Plätze nach oben gerutscht. Die relevante Inhalte bieten.
- Weniger sinnloser Traffic auf dem eigenen Server bzw. im Internet. Der Server hat dadurch mehr„ Performance-Reserven“.
Generator-Tag / Template
Wir können hier nur Thomas Kahl sinngemäß zitieren: „Warum muss man auf dem ersten Blick erkennen, dass es sich um eine Joomla!-Website handelt?“ (Joomla!Day 2009 in Bad Nauheim). Recht hat er! Ob jetzt am Template oder am Generator-Tag in dem Meta-Daten, es sollte nicht immer gleich erkennbar sein um was für ein System es sich handelt.Ihre Webseite ist individuell, man sollte nicht auf den ersten Blick erkennen, ob es Joomla!, WordPress oder Drupal ist.
Auch der Meta-Tag muss nicht immer alles verraten:
<meta name="generator" content="Joomla! 1.5 - Open Source Content Mana..."
Serverinformationen
Gehen wir davon aus Joomla! gibt keine Informationen mehr Preis. Was macht aber der Server?In der Regel werden folgende Information im „Header“ mit übertragen:
Server: Apache 2.1
X-Powered-By: PHP/5.3.16
X-Content-Encoded-By: Joomla2.5
Diese Informationen kann man unterdrücken, sofern der Hoster dies nicht verboten hat. Einiges kann man in der PHP-Konfiguration bzw. direkt im Webserver (Apache) einstellen. Oft ist es auch möglich, es über eine Htaccess-Datei abzuschalten, sofern dies erlaubt wurde.
Php.ini
Seiten die andere Seiten bewerten, wie sicher diese sind
Wir arbeiten noch daran das Seiten wie saferpage.de und webutation.net uns nicht mehr einlesen können. Hier tut sich aber ein Problem auf, da diese Webseiten ihre Inhalte meist von anderen Webseiten erhalten und nicht immer direkt die Quellseite anfragen.Die angeblichen Sicherheitstests, dieser Webseiten, sind nach unserer Meinung, eine Vortäuschung falscher Tatsachen.
Begründung:
- Kommentare: Stehen unter keiner Kontrolle bzw. Prüfverfahren und sind daher unseriös.
- Google Safebrowsing: Ist OK, aber von wann sind diese Daten?
- Website Antivirus: Welcher Anbieter hat den Test durchgeführt?
- Norton Safeweb: Was wurde denn angeblich geprüft und wann?
- WoT (Web of Trust): Da kann man viele Meinungen zu haben. Unsere ist: „Äußerst bedenklich".
- Wikipedia Trust Links: Auch Wikipedia irrt sich.
- Jugendfrei / Jugendschutz: Solange das kein Jugendschutzbeauftragter geprüft hat, ist die Aussage unseriös.
- SPAM-Check: Jeder der Server administriert und auf Blacklists vertraut, weiß auch dass hier Fehler auftauchen.
- Skripte: Sicherlich können JavaScripts, Flash-Anwendungen oder Java-Applets Sicherheitslücken aufweisen. Sie müssen es aber nicht grundsätzlich tun.
Leider werden die Tests dieser Seiten mit einen Standard-Agent übergeben wie dem Firefox. Diese Seiten tragen in keinster weise zur Sicherheit bei. Da sie, wenn überhaupt den Ausgabequellcode der Website interpretieren können und nicht ob die Anwendung im Hintergrund sicher programmiert wurde oder Sicherheitslücken aufweist bzw. die Daten die dort übermittelt werden sicher sind.
