Tipps für Apache httpd.conf

Kuttengeier

Kuttengeier

0
Hallo,

vor einigen Tagen habe ich begonnen meine erste httpd.conf Datei selbst zu schreiben. Dabei sind die Anforderungen nicht sonderlich hoch, da es sich um eine lokale Entwicklungsumgebung handelt. Ich setze den Websever also nicht in einem Netzwerk ein.

Ich möchte an dieser Stelle einen Thread starten, in dem zu allererst einmal Tipps gesammelt werden, wie eine gute httpd.conf Datei ausschauen sollte. Diskussionen und Meinungsverschiedenheiten werden hoffentlich Bestandteil dieses Threads sein. Dabei möchte ich euch bitten nicht auf meinen konkreten Fall einzuegen, sondern zu versuchen es allgemein zu halten. Wenn es im etwas Spezielles geht, kennzeichnet das bitte.

Textbeispiele sind von meiner Seite erwünscht, schreibt sie jedoch bitte in einem Spoiler, wenn sie zu lang werden.

Also, ich glaube ja, dass es gut ist die "Handler" für externet Skriptsprachen (z.B. PHP oder Python) nicht global zu definieren, sondern sie nur in den Directorys zu aktivieren, in denen sie benötigt werden. Ich verspreche mir dadurch, dass php Dateien nur in diesem Directory ausgeführt werden dürfen und somit einen Sicherheitsvorteil.

Standart in Internet Tutorials
Code: 
ServerName localhost
listen 8080AddHandler application/x-httpd-php .php
Meine Version
Code: 
<directory /var/www/htdocs/meine_seite/public/>
AddHandler application/x-httpd-php .php
</directory>
What do you think?
Kuttengeier
 
Die meisten Webprojekte haben zig Unterordner in denen Skripte liegen und auf den meisten Webservern liegen fast ausschliesslich skriptbasierte Projekte, so dass eine Pflege der Directory-Direktiven enorm aufwändig wäre und deswegen die Handler global definiert sind. Wenn dann sollte man die Handler auf jene VHosts beschränken, die sie benötigen, es also VHost-spezifisch machen. In einem PHP-Projekt muss man ja keine Perl- oder Python-Skripte laufen lassen.

Der Sicherheitsvorteil ist auch nicht wirklich gegeben, denn zumeist werden Skripte in das Temp-Verzeichnis eingeschleust und via CLI ausgeführt. Daher ist es eher wichtig, dass Verzeichnisse (mit Ausnahme der CGI-Verzeichnisse), in die der Webserver schreiben können muss, mit noexec-Flag gemountet sind. So wird eine Ausführung via CLI erschwert bis verhindert. Ausserdem sollte er einem User und einer Gruppe angehören, die allgemein keine Programme als den Webserver selbst aufrufen kann und Dateien, die nur gelesen werden müssen, auch nur lesen und nicht schreiben kann.

Die Sicherheit beim Apache kommt aber primär durch das System dahinter und die Webapp selbst und nur geringfügig durch die Config. Klar sollte man CGI-Skripte nur in bestimmten Verzeichnissen zulassen, weil dort zwingend ein exec-Flag benötigt wird. Und klar sollte man unnötige HTTP-Methoden wie TRACE und TRACK via Config verbieten, wenn die Kiste live ist. Aber sonst wirst du mit der Konfiguration nur wenig erreichen. Eher helfen da Dinge wie mod_security und mod_evasive um Sicherheitsaspkete einzubauen.
 
Hi,

ok, aber mod_security wird doch auch in der httpd.conf konfiguriert, oder sehe ich das falsch? Welche Direktiven sind denn in der Praxis wirklich sinnvoll und welche sind eher Overhead. Ich hatte leider bisher noch keinen ernsthaften Kontakt damit.
Gibt es dort eine Möglichkeit die maximale Dateigröße für die Log-Files zu diefinieren?

Würdest du denn dann die Standart-Konfiguration nochmal überarbeiten? Denn da sieht es denn ja soweit nicht ganz so schlecht aus, oder?

Grüße,
Kuttengeier
 
Ob die Standard-Config sonderlich viele Änderungen braucht, hängt vom Anwendungszweck des Webservers ab. Bei der Entwicklung von Webapps können z.B. die HTTP-Methoden TRACE und TRACK ganz brauchbar sein, während sie bei einem Live-System ein Sicherheitsrisiko (XSS etc.) darstellen können. Ein Tuning bei den Worker-Einstellungen kann Sinn machen um Überlastungen des Servers zu vermeiden, wobei da auch wieder die Limit-Einstellungen des Systems notwendig sind, damit alle möglichen Überlastungsmethoden auszuschliessen sind und da hakt es bei den meisten Webservern erfahrungsgemäss eher.
 
Viel interessanter finde ich A) wie die verwendete Scriptsprache in Apache eingebunden wird und B) wie diese wiederum abgesichert werden...

Ich zum Beispiel habe hauptsächlich mit Servern zu tun, wo mehrere Benutzer ihre (Sub-)Domains drauf haben (Rootserver für eigene Projekte und Projekte von Freunden und einen Development-Server für mich und meine Kollegen auf Arbeit) und da schwöre ich auf mod_suexec und PHP nicht über mod_php sondern über mod_fcgid.
Für jede (Sub-)Domain kann ich eine eigene php.ini erstellen, jede (Sub-)Domain läuft unter einem eigenen User und mit open_basedir sorge ich in der php.ini dafür, dass die Scripte außerhalb des Verzeichnisses des entsprechenden Users nix zu suchen haben.

Auf dem Livesystem eines Onlineshops dagegen macht es durchaus Sinn, mod_php einzusetzen, da dort eher mehrere Server für 1 Projekt genutzt werden und somit keine unterschiedlichen Nutzer auf ein und demselben Server benötigt werden.
 
@beavisbee: Dann hast du hoffentlich nicht zuviele User/VHosts auf deinem Server, weil mit fcgi prinzipiell mehr RAM verbraucht wird und auch der Overhead an CPU-Last durchaus zum Problem werden kann.

Ich denke jedenfalls, dass dieser Thread nur dann sinnvoll ist, wenn Konfigurationsbeispiele/Optimierungen für spezifische Webserver-Aufgaben gesammelt werden.
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben