Steffi und Mikko sind nach Meißen zu den Großeltern aufgebrochen und ich hatte sie vor zwei Wochen besucht. Es ist schon wahnsinn, wie einem der Kleine so ans Herz wachsen kann und nun vermisse ich ihn mit jeder Sekunde mehr. Bei meinem Besuch war er irgendwie noch viel aufmerksamer und aufgeweckter als ich ihn davor das letzte mal gesehen hatte.

Ansonsten bleibt kaum Zeit für andere Dinge.. Ich treibe nun regelmäßig Sport, was meine Freizeit noch ein wenig verringert. Grund ist zu hoher Blutdruck, durch den ich bei hohem Druck Sehprobleme bekomme.. Sehr nervig und auch mit ein Grund, dagegen etwas zu tun. Schließlich möchte ich noch lange etwas von Mikko haben.

Apropos Mikko, leider hatte ich einen Kommentar in der Moderation, den ich erst vorhin gesehen hatte. Warum wir uns für Mikko enschieden haben? Einen wirklich genauen Grund gab es eigentlich nicht.. Er gefiel uns einfach… Wir hatten uns im Vorfeld drei Kriterien überlegt, die ein passender Vorname erfüllen sollte:

1. Der Name sollte von den Großeltern gut ausgesprochen werden können
2. Mikko sollte später einmal keine Probleme im Kindergarten oder der Schule bekommen
3. Der Name sollte zum Nachnahmen passen

Und all das hat Mikko erfüllt.

Ich denke ich habe morgen noch ein wenig was nachzuholen…

Gerade rief mich nämlich ein Mitarbeiter der Kundenbetreuung an und wollte die Daten des Vormieters erfragen, insbesondere Telefonnummer. Klar, dass der Sinn dieser Nachfrage war, den eventuell schon vorhandenen Anschluss weiterzunutzen. Ich habe nun angegeben, dass ich einen QSC-Anschluss habe, ich aber eigentlich einen Neuanschluss haben möchte.

Mal schauen, wie sich das entwickeln wird, wenn es nicht so ganz standardkonform ist…

Wahrscheinlich werde ich in unregelmäßigen Abständen Audio- und Video-Podcasts erstellen.[podcast format="video"]http://www.commy.de/wp-content/uploads/2006/08/VideoBlog_Ausgabe_0.mov[/podcast]

Die Grundidee bei FON gefällt mir, an der Umsetzung hapert es allerdings noch…

FON ist mit dem ehrgeizigen Ziel gestartet, ein weltweit umspannendes Netz von WLAN-Hotspots aufzubauen. Damit es an der richtigen Hardware nicht fehlt, gab es die in der Vergangenheit sogar auch schon kostenlos oder zu stark vergünstigten Preisen. Ich für meinen Teil konnte mich nun über einen WRT45GL von Linksys freuen, der mich gerade mal 17 Euro und ein paar Zerquetschte gekostet hat.

Geliefert wurde das Gerät dann gestern per UPS aus Spanien, bis hierhin, alles perfekt.

Doch beschäftigt man sich dann etwas näher mit FON, schaut vor allem in den Foren und setzt sich mit der Materie etwas intensiver auseinander, kommt man schnell an die Grenzen von FON.

Die FON-Software auf den Routern ist perfekt für den Menschen, der nichts damit zu tun haben möchte. Anschließen, anschalten und registrieren. Doch dann geht es schon los. Um über sein eigenes WLAN zu surfen muss man sich erst per Webbrowser einloggen (natürlich kostenfrei und ohne Verpflichtungen). Das mag für den normalen Nutzer erstmal durchaus vertretbar sein, wird aber schnell zu einem riesigen Nachteil, wenn man Hardware einsetzen möchte, die keinen Webbrowser hat (zum Beispiel WLAN-Telefone).

Natürlich darf bei einem öffentlichen Hotspot auch keine Verschlüsselung aktiv sein. So schwirren dann also die privaten Daten fröhlich durch den Äther.

Abhilfe soll da eine Entwicklung schaffen, mit der hoffentlich bald zu rechnen ist. Aus einem FON-Hotspot werden dann zwei, ein WLAN-Netz, öffentlich und unverschlüsselt für jeden und eines abgeschottet für die private Kommunikation.

Allerdings muss ich gestehen, dass ich bereits gebastelt habe und dazu sicher noch ein wenig was schreiben werde, morgen oder so. Ich habe nämlich jetzt ein Funknetz aufgebaut zwischen dem FONero-Router und meinem bestehenden Access-Point, der nun in der Wohnung meines Nachbarn steht und dort für die Verbesserung seiner bisher eher mauen WLAN-Verbindung sorgt.
Dazu habe ich mir einen eigenen Radius-Server gebastelt, mit dem ich nun auch bestehende Computer ohne Anmeldung in das Funknetz übernehmen kann.

Und am Wochenende, da geht es dann eventuell weiter

Woran das genau liegt ist schwer zu sagen. Ob es nun die lediglich 2 Mbit sind, die dem Server zur Verfügung stehen oder ob der Server an sich eine etwas schlechtere Performance zeigt, Who Knows…

Es werden nun die weiteren Homepages, die sich so auf meinem Server tummeln, folgen, dann kommt der Mailserver dran und dann werde ich hoffentlich alle virtuellen Server umziehen können.

Ja, es hätte sicher bessere und schnellere Möglichkeiten gegeben, aber ich finde die Vorstellung irgendwie cool

Die Ausgangslage

Ein Server, mit ner Menge Dienste. Die wichtigsten sind Apache (Webserver), Bind (Nameserver), Postfix mit Amavis + Spamassassin (Mailserver) und Asterisk (Telefonie). Für den Server steht mir ein Netz mit fünf IP-Adressen zur Verfügung, die bereits sämtlich aufgebraucht wurden, für die verschiedenen Dienste + einer etwas älteren VMWare-Geschichte.

Der Server kann nicht geplättet und dann in Ruhe neu installiert werden, da sich – obwohl er überwiegend privat genutzt wird – doch einige wichtige Seiten und Dienste auf ihm befinden.

Ein Ersatzserver steht mir in erster Linie nicht zur Verfügung.

Der Plan

1. Als Entwicklungssystem dient mir eine virtual machine innerhalb Parallels Workstation. Obwohl ich die VM zunächst dem Server möglichst gut anpassen wollte, hat sich in der Beschäftigung mit OpenVZ gezeigt, dass das grundlegende ziemlich egal ist, solange OpenVZ installiert und konfiguriert ist, da sich hinterher die einzelnen virtuellen Server rasch auf das endgültige System umziehen lassen.
2. Das Grundsystem innerhalb Parallels wird installiert (in diesem Fall ein Gentoo 2006.0 mit den aktuellen OpenVZ-Quellen)
3. Innerhalb OpenVZ werden die Virtual Environments (VE) eingerichtet. Nach dem aktuellen Stand werden dies eigenständige virtuelle Server für
• DNS
• Webserver
• Mailserver + IMAP, POP3
• Telefonie (Asterisk)
• Storage (NFS-Server)
• + eventuell Entwicklungsserver und Server für Freunde
4. Die jeweiligen Server werden installiert und konfiguriert (Debian 3.1) und die entsprechenden Daten werden auf das Entwicklungssystem übertragen
5. Da ich eine SDSL-Leitung mit 2 Mbit/s zuhause habe, wird das Entwicklungssystem für einen Zeitraum von ein paar Stunden die kompletten Serveraufgaben übernehmen (wenn alle Daten hochaktuell synchronisiert sind)
6. der nun alte Server wird geplättet (Backup wird allerdings wohl noch weiterhin vorhanden sein) und mit einem minimalen Grundsystem versehen, so dass lediglich die OpenVZ-Systeme vorhanden sind.
7. Die virtuellen Server werden auf den neuen Server migriert, das Routing der IP-Adressen von mir @home ins Rechenzentrum umgestellt.

Eigentlich schon eine ziemlich verrückte Idee, den Server unter einer VM nachzubilden, aber dafür sind die Dinger ja eigentlich da.

Mehr dann später.

Seit ich Xen kenne, war mir dabei klar, dass der neue Server irgendeine Form von Virtualisierung bekommen sollte. Jetzt am Wochenende wollte ich beginnen und stand erstmal wieder vor der Frage, welches Produkt denn nun einzusetzen sei?

Xen oder OpenVZ hieß es schließlich und ich habe mich nun für OpenVZ entschieden. Für meine Zwecke einer homogenen Serverlandschaft ist OpenVZ absolut ausreichend und bietet – so die verschiedenen Quellen – auch in Punkto Performance und Bedienbarkeit ein paar Vorteile gegenüber Xen.

Doch warum überhaupt eine Virtualisierung?

Ich denke mal die Geschichte meiner Jadzia ist ziemlich ähnlich dem, was mit anderen Servern passiert. Man richtet sich irgendwann mal einen dedizierten Server ein und mehr und mehr kommen neue Dienste auf die Maschine, bis sich schließlich Webserver, Mailserver, Nameserver und Telefonanlage (und das ist noch der günstigste Fall) auf ein und derselben Maschine tummeln.

Und damit beginnen die Probleme. Man nimmt sich vor an einem Abend mal ein Update des Systems zu machen. Pustekuchen. Nach fünf Stunden Arbeit funktionieren manche Pakete dann immer noch nicht wie sie sollen. Gerne und gerade passiert dies auch im Zusammenhang mit der Tatsache, dass man für ein bestimmtes Feature die neuesten Softwareversionen benötigt und die “instabilen” Pakete installiert. Dann darf man die eben genannte Zeit gerne verdoppeln…

Von der fehlenden Sicherheit natürlich ganz zu schweigen. Ich hänge zwar hinter einer prima Security-Appliance mit Firewall, IPS und dem ganzen Zipp und Zapp, aber Sicherheitslücken tauchen immer wieder auf und es ist wie in allen Lebenslagen ein Wettrennen zwischen Jäger und Gejagtem, dass das IPS eventuelle Angriffe erkennt. Kompromitiert nun ein Bösewicht meinen Server, bleiben alle Daten davon unberührt. DAS ist klasse

Wie gehe ich nun weiter vor?

Nun, da ich mitlerweile einen spitzen iMac mit Intel-Prozessor habe, habe ich den Samstag bereits damit verbracht ein neues Gentoo auf einer Parallels-VM einzurichten. Dort habe ich OpenVZ installiert und werden nun die jeweiligen Server einrichten. Ich denke die Vorgehensweise bekommt noch einen eigenen Blog-Eintrag.

Ich werde hoffentlich in den nächsten Tagen zwischendurch immer wieder Zeit finden über meine Fortschritte zu berichten, so dass hier eventuell auch ein kleines How-To entstehen kann, wie ich diesen Umzug gestalte.

Worum geht es eigentlich? Es geht um sichere Webserver. Dabei allerdings weniger um Gefahren von außen, sondern um die Gefahr, die von innen kommt. Zwar gibt es immer mehr Nutzer, die einen eigenen Server verwalten und somit genau kontrollieren können, welche Informationen nach außen dringen, aber noch immer macht das Massenhosting einen Großteil der Homepages aus.

Massenhosting bedeutet, dass ein physikalischer Server von mehreren Homepages gleichzeitig genutzt wird, die allesamt parallel auf dem Server existieren. Zwar ist es kein großes Sicherheitsproblem, wenn die Nutzer per FTP ihre Daten hochladen und über HTTP abrufen können, problematisch wird es aber dann, wenn die hochgeladenen Daten Programme jeglicher Art sind, die auf dem Server ausgeführt werden können.

Gerade mit der unglaublich steigenden Bekanntheit von PHP, stiegen auch die Sicherheitsprobleme. Und ich habe nun einmal einige Gedanken zusammengetragen, wie man einen möglichst sicheren Webserver mit PHP-Unterstützung realisieren kann, da ich bei meiner Suche im Internet bisher leider noch nichts vergleichbares finden konnte.

Das Problem

Sicherheit steht immer im Gegensatz zur Bequemlichkeit. Eine Alarmanlage im Haus bringt große Sicherheit, stört mich aber sehr, wenn ich in der Nacht etwas erledigen muss und sie erst deaktivieren muss. Bodyguards bringen mir auch große Sicherheit nur schirmen sie mich eventuell unnötig ab und ich habe kaum noch Privatspäre.

Daher muss ein Kompromiss gefunden werden, der zum einen eine gute Sicherheit bietet, zum anderen aber auch dem Kunden sowenig Schwierigkeiten macht wie nur möglich.

Das grundlegende Problem ist folgendes:

Die meisten Webserver, auf denen PHP als Scriptsprache angeboten wird, nutzen das PHP-Modul für den Apache. Dieses Modul wird zentral in den Apache-Webserver eingebunden und steht danach allen Homepages, respektive Virtual-Hosts, zur Verfügung. Der Vorteil: Die Ausführung der PHP-Programme ist sehr schnell und die Konfiguration ist sehr einfach. Außerdem sind die PHP-Programme in dieser Konfiguration sehr flexibel und können nahezu jegliche Arbeiten verrichten, die gefordert werden.

Genau hier liegt das Problem. PHP-Programme, die über das Apache-Modul ausgeführt werden, werden im Linux/Unix-System unter dem Benutzer ausgeführt, unter dem auch der Apache ausgeführt wird. Natürlich muss der Apache auf sämtliche Dateien zugreifen können, die er an die Besucher der Internetseiten ausliefern möchte. Das bedeutet, sämtliche Dateien, die ausgeliedert werden sollen oder als PHP-Programm ausgeführt werden sollen, müssen für den Apache lesbar sein.

Im Umkehrschluss bedeutet das dann, ein PHP-Script, egal an welcher Stelle im System, welches über das Internet aufgerufen wird, hat Zugriff auf sämtliche Dateien, die vom Apache gelesen oder vom PHP-Modul ausgeführt werden sollen. Das umschließt die PHP-Programme selbst im Quelltext (jemand anderes kann also das geistige Eigentum stehlen), .inc-Dateien, die zb. Passwörter für den SQL-Zugriff enthalten oder .htpasswd-Dateien, die von Apache zum Schutz von Verzeichnissen genutzt werden.

Und genau diese Sicherheitslücke werden wir uns nun vornehmen.

Der Weg

Es gibt einige Möglichkeiten, das Problem zu lösen:

1. PHP wird nicht mehr angeboten: Zugegeben, ein drastischer Schritt, den kein Anbieter von Webhosting gehen wird, aber sicher der wirksamste
2. Safe-Mode: Safe-Mode sind verschiedene Funktionen innerhalb von PHP, die diese Sicherheitsprobleme gezielt angehen sollen. Zwei Funktionen werde ich in meiner Lösung einsetzen. Generell ist der Safe-Mode allerdings eher unwirksam, da er mehr Probleme erzeugt, denn löst. So streuben sich einige sehr bekannte PHP-Applikationen unter Safe-Mode zu laufen, da zb. populäre Funktionen, wie der Upload von Dateien immer wieder zu Problemen führen.
3. abgespeckter Safe-Mode + disable_functions: Dies dürfte die beste Lösung für Administratoren sein, die einigermaßen “humane” Kunden haben. Der Safe-Mode wird generell ausgeschaltet. Mit der open_basedir-Richtlinie setzt man die PHP-Funktionen für den Dateizugriff auf das eigene Verzeichnis fest, so dass hier nur noch Dateien der eigenen Homepage angezeigt werden können. Schließlich werden mit disable_functions alle PHP-Funktionen ausgeschaltet, die normale Unix-Befehle ausführen können und somit dennoch fremde Dateien ausspionieren können.

   Leider gibt es hier allerdings auch den Haken, dass manche Applikationen diese Funktionen zwingend benötigen, da sie auf externe Software angewiesen sind. Ein Beispiel ist Gallery. Hinzu kommt, dass disable_functions leider nur sehr unflexibel ist, da es nur global definiert werden kann.

4. PHP-CGI + suexec: Fast meine Lösung. PHP wird als externe Software über einen sog. suexec-wrapper ausgeführt. Die genaue Bedeutung kommt später. Allerdings bietet diese Lösung eine generell schlechtere Performance als die Nutzung von PHP als Modul.

Die Lösung

Zunächst, warum PHP als CGI ausführen?

Nun, zusammen mit suexec wird PHP als der Benutzer ausgeführt, dem der virtuelle Webserver gehört. Das bedeutet natürlich, dass ich nur auf Dateien Zugriff habe, die ich mit meinen eigenen Berichtungen lesen darf. Die PHP-Scripte meines “Server-Nachbarn” werden mit seinen Berechtigungen ausgeführt. Sind die Berechtigungen sorgfältig gesetzt, kann diese Lösung als sicher erachtet werden.

Daher ist zu beachten, dass gerade auf die Berechtigungen ein großes Augenmerk gelegt werden. Diese ganze Lösung ist nämlich dann für die Katz, wenn Dateien trotzdem von jedem gelesen werden können.

Um die Abarbeitung der PHP-Scripte auch schnell zu machen, kommt noch eine Komponente hinzu: FastCGI FastCGI ist ein Apache-Modul mit sehr guten Caching-Möglichkeiten, bei dem PHP als Server gestartet wird und so die Aufträge schnell abgearbeitet werden können. Es gibt sogar die Möglichkeit, externe PHP-Server zu nutzen und so zb. ein Loadbalancing der PHP-Last zu erreichen.

Dieses Howto richtet sich weniger an die grundlegende Installation von Apache, FastCGI und PHP, da sie sich unter Gentoo, welches ich nutze, recht einfach gestaltet. Wer von Source installiert, findet dazu einige Howtos im Netz, die dann allerdings meiner Meinung nach zuwenig auf die Berechtigungen der Nutzer eingehen. Wichtig ist nur, dass beim Apache die suexec-Möglichkeiten eingebunden werden und PHP mit FastCGI-Unterstützung kompiliert wird.

Unter Gentoo reicht dazu ein:

emerge -v apache php-cgi mod_fastcgi

Natürlich sollte man sich noch seine entsprechenden USE-Variablen zusammensuchen, gerade PHP bietet da eine sehr umfangreiche Liste:

emerge -pv php-cgi

Wichtig ist natürlich mitlerweile auch USE=”apache2″, da wir für den Apache Version 2 kompilieren werden.

Nach der Installation der drei Komponenten müssen wir in der /etc/conf.d/apache2 das FastCGI-Modul aktivieren:

APACHE2_OPTS="-D SSL -D DAV -D FASTCGI"

Hier ist natürlich nur der Part “-D FASTCGI” der notwendige.

FastCGI unterscheidet zwischen drei Arten von Applikationsservern, also zb. drei Arten von PHP-Servern, die in Zukunft die Arbeit machen sollen.

1. statische Server werden beim Start des Webservers gestartet und stehen dann dauerhaft zur Verfügung.
2. dynamische Server werden dann gestartet, wenn eine Anfrage an den Server gestellt wird, die die Ausführung eines PHP-Scripts beinhaltet.
3. externe Server können per TCP/UDP angesprochen werden und so zb. freie Resourcen anderer Server mit nutzen.

Hier muss man nun entscheiden, ob man virtuelle Server hat, die mit einer hohen Besucherfrequenz einen nutzen aus statischen Servern ziehen würden oder ob man virtuelle Server hat, auf denen nur sehr wenige Besucher sind. Gerade im Massenhosting macht es eher Sinn auf dynamische Server zu setzen, da das Gästebuch des lokalen Taubenzüchtervereins vielleicht einmal pro Monat aufgerufen wird. Natürlich bringt ein dynamischer Server eine leichte Verzögerung bei der ersten Anfrage. Ist der Server geladen steht er auch für weitere Anfragen des gleichen Benutzers zur Verfügung, bis er nach einer konfigurierbaren Zeit stirbt.

Da der dynamische Server zunächst Grundlage auch für die statischen Server ist kümmern wir uns erstmal darum. Folgende Zeilen kommen in den VirtualHost der jeweiligen Webservers:


ScriptAlias /cgi-bin /var/www/private/blog.commy.de/cgi-bin

SuexecUserGroup "matthias" "users"


Sämtliche Anfragen nach .php-Dateien werden auf ein Shellscript unter dem relativen Pfad /cgi-bin/php geleitet. Aus diesem Grunde benötigt man natürlich die Definition eines cgi-bin-Verzeichnisses. Ich nutze dafür die ScriptAlias-Angabe, euch stehen natürlich auch die anderen Möglichkeiten zur Verfügung.

Damit der Server auch unter den korrekten Benutzerdaten läuft, benötigt man die SuexecUserGroup-Angabe. Unter Gentoo funktioniert es nicht, das PHP unter dem Apache-Benutzer apache zu starten. Daher sollte man hier ohnehin den jeweiligen Benutzer des Webservers angeben und eine allgemeine Gruppe (alternativ kann man natürlich auch eine Gruppe webuser o.ä. anlegen).

Um PHP nun zu aktivieren, benötigt man nun auch das Shell-Script im cgi-bin-Verzeichnis. Dazu nutzt man folgendes:

#!/bin/sh
umask 027
PHPRC="/etc/php/cgi-php4/"
export PHPRC
PHP_FCGI_CHILDREN=4
export PHP_FCGI_CHILDREN
exec /usr/bin/php-cgi

Die umask-Angabe werde ich später noch erklären.

PHPRC definiert den Ort, an dem der PHP-Server die PHP-Konfigurationsdateien finden kann. Hiermit ist es also sogar möglich, jedem Kunden zu ermöglichen, mit einer php.ini im entsprechenden Verzeichnis, eigene Parameter des PHP-Servers zu definieren.

PHP_FCGI_CHILDREN definiert die Anzahl von PHP-Instanzen, die initial gestartet werden sollen. Je nach Besucherfrequenz des Servers können dies mehr oder auch weniger sein.

exec startet schließlich PHP. Der Pfad sollte natürlich entsprechend angepasst werden. Hier zeigt sich aber ein weiterer Vorteil von fastcgi; Ohne andere Webserver auf dem Server zu stören, kann hierdurch eine neue PHP-Version getestet oder unterschiedliche PHP-Versionen auf einem physikalischen Server laufen.

In der /etc/apache2/httpd.conf fehlt nun noch die Angabe des zu nutzenden suexec-Wrappers:

FastCgiWrapper /usr/sbin/suexec2

Möchte man nun statische Server nutzen, richtet man diese unter Angabe des Pfades für das obige Shell-Script und der identischen Benutzer/Gruppen-Angaben mit folgenden Zeilen ein:

FastCgiServer /var/www/private/blog.commy.de/cgi-bin/php -user matthias -group users
FastCgiServer /var/www/_SERVICES/cgi-bin/php -user wwwsystem -group users


Mit diesen Zeilen würden dann beim Start von Apache zwei PHP-Server mit jeweils unterschiedlichen Benutzerdaten starten.

Nun wird es spannend. PHP läuft jetzt zwar soweit, aber in den Standardeinstellungen ist es wenig benutzer, weil wir immer noch Sicherheitsprobleme haben. Die können wir jetzt lösen, indem wir einige Dateiberechtigungen ändern.

Durch das suexec haben wir nun erreicht, dass PHP-Dateien und Dateien, die nur von PHP gelesen werden sollen, lediglich vom Benutzer gelesen werden brauchen. Die Gruppe oder alle anderen brauchen die Dateien nicht mehr lesen, was für PHP-Dateien schon einmal ein sehr großer Vorteil ist.

Um nun die größtmögliche Sicherheit zu erhalten, habe ich folgende Berechtigungen erarbeitet:

Es sollten alle Dateien und Verzeichnisse in dem Webserver-Verzeichnis eines Nutzers dem Nutzer gehören (klar). Die Gruppe sollte dem Webserver-Benutzer gehören (im Falle von Gentoo apache). Der Benutzer sollte alles können, die Gruppe sollte nur lesen und alle anderen sollten nichts können.

Das größte Problem sind hierbei Dateien, die durch PHP neu angelegt werden. Standardmäßig bekommen diese Dateien nämlich keine Rechte für Gruppen und alle anderen. Für geheime Daten ist das OK, für Daten die hochgeladen werden und wie bei der Gallery dann zb. resized werden, ist das aber sehr schlecht, da die dann nicht per Webbrowser angezeigt werden können.

Außerdem erhalten diese Dateien die Gruppenzugehörigkeit “users”, da wir unter “users” ja den PHP-Server laufen haben.

Letzteres können wir verhindern, in dem wir mit

chmod -R g+s

die entsprechenden Verzeichnisse mit dem SetGID-Bit versehen. Somit behalten alle Dateien, die inden Verzechnissen erzeugt werden die entsprechende Gruppenzugehörigkeit.

Das Problem der Berechtigungen haben wir schon gelöst. Die Angabe umask 027 im Shell-Script bewirkt, dass neue Dateien mit den entsprechenden Berechtigungen erzeugt werden.

Nun haben wir folgendes erreicht. Dateien gehören dem jeweiligen Benutzer und können so per PHP gelesen und geschrieben werden. Ebenso ist der FTP-Zugriff voll möglich. Die Gruppenzugehörigkeit liegt beim Apache-Server, somit können alle Dateien zwar per Apache gelesen werden, aber die PHP-Scripte, die unter der Gruppe “users” laufen, können nicht auf andere Verzeichnisse zugreifen.

Zusätzlich können wir sensible Daten, die für PHP-Scripte benötigt werden, in Dateien auslagern, die nur für den Benutzer lesbar sind. Somit kann das PHP des Benutzers zwar auf diese Datei zugreifen, Apache aber nicht mehr.

Alle anderen Schutzmechanismen kann der Nutzer mit .htaccess-Dateien selbst herstellen.

Ein Sicherheitsproblem besteht allerdings weiterhin. Es gibt standardmäßig eine Vielzahl von Dateien, die jeder lesen kann. Hier ist zu beachten, dass nicht jeder sie lesen muss. Eine sorgfältige Wahl der Berechtigungen, insbesondere vieler Konfigurationsdateien, ist hier die Lösung.

Größere Sicherheit bietet nur eine chroot-Umgebung, in der der Webserver abgeschlossen läuft.

Ich hoffe dieser Leitfaden hat euch ein wenig geholfen eure Webserver etwas sicherer zu machen.