• Wenn der Apache fremde Stämme einlädt

    Ja wir kennen ihn wohl alle, den Mister WEB persönlich - den Apache Zwo Null. Hat er mal schlechte Laune, ist Sense mit dem eigenen Webserver - vorausgesetzt man hat einen Apache WebserverApache2 Webserver. Doch wie so oft sitzen Probleme nicht im Server sondern direkt vor dem PC. Ok, Schluss mit dem Gefasel bevor ich noch das Thema vergesse. Gerade saß ich mal wieder auf der Leitung - wie bringt man diesen blöden Testapache nur dazu, dass er mod_rewrite in .htaccess akzeptiert fragte ich mich. Die Config auf dem Produktivsystem wollte ich mir nicht anschauen, das wäre ja zu viel Aufwand gewesen und das Buch, das keinen Meter über meinem Kopf zu schweben scheint mit der Aufschrift “Apache Webserver 2″ wollte ich um diese Uhrzeit auch nicht mehr benutzen, es ist 23 Uhr und wenn das Licht aus ist kann man da rein gar nichts mehr lesen. Nun gut. Ich begebe mich also ins Google-Imperium um nachzuforschen wie ich mod_rewrite laufen lassen kann, wenn das Modul bereits geladen wurde, die .htaccess aber ignoriert wird. Bei einigen Aussagen sowohl in Foren als auch in Blogs war ich aber doch enttäuscht. Zwar bringt

    AllowOverride All

    den gewünschten Effekt, genauso könnte ich aber auch gleich dasselbe bei allen anderen Config-Parametern machen um eine korrekte Funktionsweise zu garantieren. Das Problem bei dieser Lösung ist weniger die Lösung selbst, als viel mehr  die Tatsache, dass bei den meisten der Hinweis fehlt, dass dies nicht auf Produktivsystem angewandt werden sollte. Denn im Allgemeinen gilt das deny_all-Prinzip (deny,allow) und nicht andersrum.

    AllowOverride FileInfo Options

    Hätte im Normalfall ausgereicht. Ein produktiver Webserver sollte immer nur die Optionen offenhalten, die tatsächlich für eine korrekte Funktion nötig sind - nicht mehr, aber in keinem Fall weniger. Es gibt da so einen netten Satz, den ich eigentlich nur jedem Entwickler und Administrator ans Herz legen kann:

    Ein Server, ein System oder eine Software gilt dann als sicher wenn der Aufwand des Hackens in keinem lohnenden Verhältnis zum Ergebnis steht.

    Deswegen sollte man potentielle Risiken von Anfang an dezimieren. Denn ist erstmal eine Lücke gefunden, so stehen dem Hacker mit einer sehr strikten Config noch einige andere Barrieren im Weg.

    geschrieben am 28.02.2009
    Archiviert unter: Linux und Server
    » Kommentare «

Eine Antwort hinterlassen