Hallo Steffen, hallo Leute, Am Montag, 30. Januar 2006 20:21 schrieb Steffen Dettmer:
* Christian Boltz wrote on Mon, Jan 30, 2006 at 01:49 +0100: [AllowOverride All]
Was ich wiederum für ein Sicherheitsrisiko halte - dann kann man mit der .htaccess nämlich _zu viel_ überschreiben.
Wenn der Entwickler, dem sozusagen "sein Webserver" gehört, .htaccess anpasst, kann er zu viel ändern? Klingt irgendwie bissel komisch. Obwohl Entwickler eh meist root-Rechte haben, oder? Dafür hat man doch Entwicklersysteme...
Naja, sobald jemand Root-Rechte hat, darf er eh alles ;-)
Lieber eine Datei in /etc/apache2/conf.d/ (Name: *.conf) anlegen und darin mit
# spezielle Einstellungen für /da/gehts/lang hier eintragen </Directory> die nötigen Einträge machen. Ja, das darf nur root - aber das ist IMHO auch gut so ;-) Na ja, falls man keinen Webmaster oder Entwickler hat ;) Sonst hat man vermutlich einen wwwadm oder so, der die Configs schreiben darf, aber ich weiss, Haarspalterei :)
Dieser jemand braucht dann aber auch Rechte für ein rcapache reload (und kann natürlich mit einer kaputten Configdatei den Apache auch abschießen). So, genug Haare gespalten.
AllowOverride AuthConfig Indexes Limit halte ich für OK, FileInfo ist ein Grenzfall und Options will man auf keinen Fall freigeben. [...] (Gründe auf Anfrage - *gähn* ;-)
ANFRAG! :) Paar Stichpunkte (PM?) wären nett - falls die Allgemein gelten (ich kann mir natürlich genügend Spezialfälle denken, wo man Options nicht erlauben möchte, klar).
Ich bin gerade etwas wacher ;-) Fangen wir mit FileInfo an: Allow use of the directives controlling document types (DefaultType, ErrorDocument, ForceType, LanguagePriority, SetHandler, SetInputFilter, SetOutputFilter, and mod_mime Add* and Remove* directives, etc.). Einige dieser Einstellungen sind ja harmlos, allerdings gibt auch ein paar zweifelhafte: - SetHandler: kann dazu führen, dass interne Infos über den Apache (z. B. server-status) nach außen kommen. Sowas macht es im Zweifelsfall einem Angreifer leichter, weil er gezielter handeln kann. - Set*Filter will ich nicht unbedingt jedem erlauben - laut Apache-Doku kann man (mit mod_ext_filter) auch externe Programme als Filter einbinden - die können dann mit wwwrun(?)-Rechten alles mögliche anstellen. Beispielsweise sämtliche Dateien verunstalten, die per PHP-Uploadformular hochgeladen wurden - beim Einsatz eines Content Management Systems sind das einige. Außerdem können sie gemütlich eine Runde MySQL-Passwörter aus PHP-Scripten einsammeln (Apache hat da ja Leserecht) und mit den Datenbanken spielen ;-) Zugegeben, mit PHP (ohne open_basedir-Beschränkung) und CGIs (ohne suExec) geht das auch, aber PHP kann man ja entsprechend einschränken und CGIs muss man nicht jedem erlauben ;-) - Habe ich etwas vergessen? Egal, die beiden genannten reichen schon ;-) Kommen wir zu AllowOverride Options: Allow use of the directives controlling specific directory features (Options and XBitHack). XBitHack on oder full "fördert" die Serverlast, da alle HTML-Dateien geparst werden. Außerdem gibt es da noch eine interessante "Note" im Apache-Manual [1]. Zu den diversen Options: ExecCGI Execution of CGI scripts using mod_cgi is permitted. CGIs will ich zentral halten und nicht quer in allen Verzeichnissen verteilt - deshalb ist diese Option nicht schön. Außerdem gibt es Hosting-Angebote, die (wegen abgeschalteter CGIs) recht günstig zu haben sind. Wenn da AllowOverride All gesetzt ist, laufen CGIs trotzdem ;-)) und der Serverbetreiber kann kein teureres Hosting verkaufen. (IIRC hat ein großer deutscher Serverbetreiber mit 2 gleichlautenden Ziffern im Namen AllowOverride Options gesetzt...) IncludesNOEXEC Server-side includes are permitted, but the #exec cmd and #exec cgi are disabled. [...] Vergleichsweise harmlos (und deutlich sicherer als Includes). Includes Server-side includes provided by mod_include are permitted. Einschließlich Programmaufrufen per #exec... - also nicht wirklich zu empfehlen und etwa so gefährlich wie ExecCGI. Indexes [...] formatted listing of the directory. Harmlos - es sei denn, jemand legt in einem Verzeichnis "geheime" Dateien ohne Passwortschutz ab und hofft darauf, dass niemand den Dateinamen rausfindet ;-) MultiViews Content negotiated "MultiViews" are allowed using mod_negotiation. Das macht Dinge wie die automatische Auswahl der Sprache anhand von Accept-Language (vorausgesetzt, die Seite existiert in der entsprechenden Sprache ;-) und andere Nettigkeiten. Dürfte unproblematisch sein, ich habe es allerdings nirgends im Einsatz und kenne daher die Details nicht. FollowSymLinks The server will follow symbolic links in this directory. Symlink zu /etc/passwd gefällig? ;-) Mehr muss ich dazu wohl nicht sagen, oder? SymLinksIfOwnerMatch The server will only follow symbolic links for which the target file or directory is owned by the same user id as the link. Die sicherere Variante von FollowSymLinks - und Mindestvoraussetzung für den Einsatz von mod_rewrite. Dadurch ist diese Option für mich quasi lebensnotwendig ;-) - oder glaubt hier jemand ernsthaft, dass ich auf www.Landjugend-Insheim.de für jedes Bild in der Galerie eine HTML-Datei geschrieben habe? ;-) [2]# Fazit: Insbesondere AllowOverride Options erlaubt mehr als man möchte. IMHO wäre es ideal, wenn man AllowOverride diesbezüglich etwas feiner einstellen könnte, damit man z. B. _nur_ Indexes und SymlinksIfOwnermatch per .htaccess erlauben kann. Hat jemand Lust, einen feature request für Apache einzureichen? ;-) PHP sollte man mit open_basedir pro vHost "einsperren" und möglichst auch den safe_mode einschalten - wobei letzterer leider oft zu restriktiv ist (Stichwort Dateiupload und dadurch "falscher" Dateieigentümer). Ach ja: Wer einen wirklich sicheren Webserver betreiben will, erlaubt nur statische Dateien (also kein PHP, keine CGIs, kein SSI, ...) und beschränkt natürlich AllowOverride passend. Die englischsprachigen Texte in dieser Mail sind übrigens Zitate aus der Apache-Doku (http://localhost/manual / http://httpd.apache.org/docs/). Dort finden sich auch genauere Beschreibungen und Erklärungen zum Thema. Gruß Christian Boltz [1] You would not want to use the full option, unless you assure the group-execute bit is unset for every SSI script which might #include a CGI or otherwise produces different output on each hit (or could potentially change on subsequent requests). [2] laut der letzten Zählung sind es 925 Bilder... --
Kann man Outook-User nicht von Flatrates ausschliesen? ;-) Nein. Aber vielleicht kann man sie zur ausschliesslichen Benutzung von MSN.com zwingen und selbiges vom Rest des Internets abtrennen ... [> Manfred Tremmel und Wolfgang Weisselberg in linux-liste]