Hallo Liste, unser PHP Programmierer meint, ich soll die Register_Globals von off auf on stellen. Wie stelle ich das denn an nem Server um? Meines Wissens stellt dies doch ein Sicherheitsrisiko dar ne oder habe ich das falsch im Gedächtnis? Grüße Taner
Am Samstag, 28. Januar 2006 00:12 schrieb Taner Ayaydin:
Hallo Liste,
unser PHP Programmierer meint, ich soll die Register_Globals von off auf on stellen. Wie stelle ich das denn an nem Server um?
Meines Wissens stellt dies doch ein Sicherheitsrisiko dar ne oder habe ich das falsch im Gedächtnis?
Der soll lieber seine Scripts umstellen. register_globals ist etwas, was man schon seit längerem nicht mehr verwenden sollte. Es gibt massenweise Tipps zur Anpassungen für ältere Scripts, ansonsten setzt man von vorneherein auf die globalen Variablen $_GET, $_POST und $_REQUEST. Gruß Udo -- The more complex the mind, the greater the need for the simplicity of play. -- Kirk, "Shore Leave", stardate 3025.8
Hallo Taner;
unser PHP Programmierer meint, ich soll die Register_Globals von off auf on stellen. Wie stelle ich das denn an nem Server um?
Die Einstellung findest Du in /etc/php.ini. Such da mal nach register_globals und dann einfach auf on stellen.
Meines Wissens stellt dies doch ein Sicherheitsrisiko dar ne oder habe ich das falsch im Gedächtnis?
Richtig, und wird deswegen warscheinlich ab PHP6 auch nicht mehr zur Verfügung stehen. Dein Programmierer verschiebt also nur den Aufwand ;-) Ciao, der Fion
Hallo Taner, Taner Ayaydin wrote:
Hallo Liste,
unser PHP Programmierer meint, ich soll die Register_Globals von off auf on stellen. Wie stelle ich das denn an nem Server um?
Du kannst das einerseits direkt in der php.ini Datei machen. Zu finden ist die unter /etc (find /etc -iname php.ini) Da gibt es den Eintrag: register_globals Off/On Oder (meiner bescheidenen Meinung nach die bessere Moeglichkeit) Der Entwickler soll in der .htaccess Datei seine Einstellungen die er benoetigt Taetigen koennen. Dazu musst du in der Apache Konfiguration fuer sein Verzeichnis AllowOverride auf All setzten. Dann kann er in der .htaccess Datei schreiben: php_value register_globals On Und das ganze gillt dann nur fuer das Verzeichnis wo die .htaccess Datei drinne ist (rekursiv) und betrifft nicht noch andere Domains.
Meines Wissens stellt dies doch ein Sicherheitsrisiko dar ne oder habe ich das falsch im Gedächtnis?
Kommt auf den Programmierer an. Wenn er mit register_globals On gewissenhaft programmiert ist es ok. Es schleicht sich aber leichter eine Sicherheitsluecke ein. Gruss Jan
Hallo Jan, hallo Taner, hallo Leute, Am Sonntag, 29. Januar 2006 16:33 schrieb Jan Friedrich Gehring:
Taner Ayaydin wrote:
unser PHP Programmierer meint, ich soll die Register_Globals von off auf on stellen. Wie stelle ich das denn an nem Server um?
Am Besten gar nicht. Stell es am Programmierer um, nicht am Server ;-))
Oder (meiner bescheidenen Meinung nach die bessere Moeglichkeit) Der Entwickler soll in der .htaccess Datei seine Einstellungen die er benoetigt Taetigen koennen. Dazu musst du in der Apache Konfiguration fuer sein Verzeichnis AllowOverride auf All setzten.
Was ich wiederum für ein Sicherheitsrisiko halte - dann kann man mit
der .htaccess nämlich _zu viel_ überschreiben.
Lieber eine Datei in /etc/apache2/conf.d/ (Name: *.conf) anlegen und
darin mit
Dann kann er in der .htaccess Datei schreiben: php_value register_globals On
Das kann er lang probieren - IIRC braucht man entweder php_flag oder man muss eine 1 statt On verwenden.
Meines Wissens stellt dies doch ein Sicherheitsrisiko dar ne oder habe ich das falsch im Gedächtnis?
Kommt auf den Programmierer an. Wenn er mit register_globals On gewissenhaft programmiert ist es ok.
Wenn heutzutage jemand gewissenhaft PHP programmiert, verwendet er definitiv *nicht* register_globals. Dein "ist es OK" wurde durch diese Schlussfolgerung gerade widerlegt ;-) Ach ja: Wenn man in der php.ini error_reporting = E_ALL setzt, fördert das zusätzlich die Codequalität ;-)
Es schleicht sich aber leichter eine Sicherheitsluecke ein.
Das auf jeden Fall - insbesondere, wenn man nicht damit rechnet, also bei Programmfehlern und/oder unerwarteten ("bösen") Eingabedaten. Gruß Christian Boltz -- Widerstand ist zwecklos (wenn er kleiner als 1 Ohm ist).
* Christian Boltz wrote on Mon, Jan 30, 2006 at 01:49 +0100:
Oder (meiner bescheidenen Meinung nach die bessere Moeglichkeit) Der Entwickler soll in der .htaccess Datei seine Einstellungen die er benoetigt Taetigen koennen. Dazu musst du in der Apache Konfiguration fuer sein Verzeichnis AllowOverride auf All setzten.
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...
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 :)
AllowOverride AuthConfig Indexes Limit halte ich für OK, FileInfo ist ein Grenzfall und Options will man auf keinen Fall freigeben.
mmm... Ich mach das mit den Options gern (nicht global sondern für <Directory>) und zwar für CGI-Scripte. Die sind dann halt nur in speziellen Verzeichnissen erlaubt (und nicht /cgi-bin/, sondern in den Verzeichnissen, wo sie hingehören, das RPM sie hininstalliert etc). Aber sicherlich Geschmackssache.
(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). [...]
Kommt auf den Programmierer an. Wenn er mit register_globals On gewissenhaft programmiert ist es ok.
Wenn heutzutage jemand gewissenhaft PHP programmiert, verwendet er definitiv *nicht* register_globals. Dein "ist es OK" wurde durch diese Schlussfolgerung gerade widerlegt ;-) [...]
Es schleicht sich aber leichter eine Sicherheitsluecke ein.
Das auf jeden Fall - insbesondere, wenn man nicht damit rechnet, also bei Programmfehlern und/oder unerwarteten ("bösen") Eingabedaten.
... was selbst gewissenhaften Programmieren hin- und wieder passieren soll ;)
Widerstand ist zwecklos (wenn er kleiner als 1 Ohm ist).
(der fetzt ja auch :)) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
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]
* Christian Boltz wrote on Thu, Feb 02, 2006 at 22:12 +0100:
* Jan Friedrich Gehring
Oder (meiner bescheidenen Meinung nach die bessere Moeglichkeit) Der Entwickler soll in der .htaccess Datei seine Einstellungen die er benoetigt Taetigen koennen. Dazu musst du in der Apache Konfiguration fuer sein Verzeichnis AllowOverride auf All setzten.
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 ;-)
Eben, also kann er auch AllowOverride All haben :)
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).
Einen Entwickler, der nicht in der Lage ist, einen Apache abzuschiessen, auf dem er entwickelt, kann ich mir kaum vorstellen ;) Ob nu mit oder ohne rcapache :)
So, genug Haare gespalten.
Ein hab ich noch :-) rcapache reload ginge auch via sudo. So, aber jetzt fertig.
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.).
- 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.
Und mit PHP und CGI soll das nicht nachzubauen gehen?
- 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.
Da reicht ein AllowOverride, um externe Programme einzubinden? Wie bekommt ein Angreifer sein Programm in das wwwrun-exec-Verzeichnis um das zu überschreiben? CGI kann ja auch externe Programme starten (wenn auch bei suexec nicht unbedingt als wwwrun). Na, und gerade für'n Entwickler, mmm....
Beispielsweise sämtliche Dateien verunstalten, die per PHP-Uploadformular hochgeladen wurden - beim Einsatz eines Content Management Systems sind das einige.
Dann lädt man die halt nochmal hoch. Falls man wirklich so viel auf'm Entwicklersystem hat...
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 ;-)
MySQL-Passwörter kriegt man doch nicht raus? Die sind doch sicherlich nirgendwo im Klartext gespeichert und den Hash darf man nur vergleichen, nicht lesen...
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 ;-)
Na, weiss ja nicht, ob ich dem PHP da trauen würde... Ich mein, so ziemlich die wurstigste der verbreiteten Sprachen, linkt gegen /usr/lib/lib*a, in der Vergangenheits Bugs ohne Ende, oben aufgeklatschtes "Sicherheitssystem", etc. aber anderes Thema. Ja, und eure Entwickler drüfen kein CGI? Ist schon komisch. Na ja. Also klar, wenn man jetzt ein Produktionssystem hätte, dann nimmt man natürlich am besten gar kein PHP und suExec-CGIs, klar.
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.
lol, das ist ja ne schöne Beschreibung. Durch das Verwenden von PHP wird die Serverlast aber bestimmt noch mehr erhöht hihi Ich verwende viel SHTML, das ist IMHO auch richtig, kann heut bloss kaum noch einer, aber das Internet muss ja auch so schlecht wie alle Software sein, klar. Da macht man dann Menüs mit Java oder so, aber ist ja auch egal.
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.
iihhh, /cgi-bin/? Find ich sowas von hässlich... Da hab ich dann Dienst X mit /xdata und /cgi-bin/xexec/ etc, furchtbar... Nee, ich möchte /vendor/package-version/ haben, und da ist alles drin. Manchmal tauscht man ja auch Bilder gegen JPEGs, und welcher Package gehört /cgi-bin/show.jpg? Na egal.
IncludesNOEXEC Server-side includes are permitted, but the #exec cmd and #exec cgi are disabled. [...]
Vergleichsweise harmlos (und deutlich sicherer als Includes).
ja OK, aber wie soll denn ein Entwickler entwickeln, wenn er keinen Code benutzen darf? Dann kann man ihm ja gleich ein Frontpage oder so'n GUI Mist hinschmeissen. Dann darf man sich natürlich nicht wundern, dass die Webseiten genauso schlecht sind wie die, die man durchschnittlich so im Internet findet... Die sind dann redundant, verwenden vielleicht Javascript und sind Browserabhängig, obwohl man alles Serverseitig hätte machen können. Meiner Meinung nach der falsche Weg (aber ich weiss, dass 99% der Internetnutzer anderer Meinung sind).
FollowSymLinks The server will follow symbolic links in this directory.
Symlink zu /etc/passwd gefällig? ;-) Mehr muss ich dazu wohl nicht sagen, oder?
Doch: wo ist das Problem? Dass der Entwickler die Useracountnamen rauskriegt? Er kann dazu auch "cat" verwenden. Hier ist meine passwd, jedenfalls der Anfang: root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/bin/bash Oder hast Du das einzige Linux-System, das ich kenn, das kein shadow verwendet?
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.
Geht aber halt auch nur, wenn der Owner matcht. Wenn man ein RPM installiert, und die Files dadrin root gehören (z.B. damit wwwrun die nicht ändern darf), funktioniert das schon nicht mehr.
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]#
(URL geht bei mir nicht) mod_rewrite verbraucht bestimmt Serverlast :) In meiner Galarie hab ich für jedes Bild eine HTML-Datei. Natürlich nicht selbst geschrieben, sondern "make" und "wml".
Fazit: Insbesondere AllowOverride Options erlaubt mehr als man möchte.
Mehr als /Du/ in bestimmten Fällen möchtest, ja. Ich hoffe, ich konnte zu jedem Punkt mindestens ein überzeugendes Gegenbeispiel finden :)
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).
(oder deinstallieren, ist noch sicherer und spart Serverlast SCNR.)
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.
Oder er erlaubt CGIs und SSI und erlaubt AllowOverride halt. Wie soll denn ein Angreifer, der nur HTTP sprechen kann, das CGI missbrauchen, nur allein weil es da ist? Banken verwenden bei Online-Banking-Frontends CGI, weil statisches HTML für Kontostände bissel schwer ist. ( Gut, Banken sind nicht unbedingt Biespiele für "wirklich sichere Webserver", aber im Durchschnitt schon nicht schlecht. SCNR. ) Ich halte das nach wie vor für situationsabhängig, gilt also alles nicht allgemein, sondern nur in verschiedenen, speziellen Fällen. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Hallo Steffen, hallo Leute, Am Freitag, 3. Februar 2006 10:16 schrieb Steffen Dettmer:
* Christian Boltz wrote on Thu, Feb 02, 2006 at 22:12 +0100: [...]
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).
Einen Entwickler, der nicht in der Lage ist, einen Apache abzuschiessen, auf dem er entwickelt, kann ich mir kaum vorstellen ;) Ob nu mit oder ohne rcapache :)
Den ganzen Apache abschießen ohne root-Rechte wird (hoffentlich ;-)) schwierig.
So, genug Haare gespalten.
Ein hab ich noch :-) rcapache reload ginge auch via sudo. So, aber jetzt fertig.
Wenn Du schon mit sudo kommst: Apache-Neustart nur per sudo erlauben und in folgendes kleine Script packen: rcapache2 configtest && rcapache2 reload ;-)
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.).
- 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.
Und mit PHP und CGI soll das nicht nachzubauen gehen?
Doch, aber man muss es erst nachbauen ;-) Dagegen ist das Freigeben von server-status deutlich schneller gemacht. Nenne es von mir aus "security by laziness" (Sicherheit durch Bequemlichkeit / Faulheit) ;-)
- 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.
Da reicht ein AllowOverride, um externe Programme einzubinden? Wie bekommt ein Angreifer sein Programm in das wwwrun-exec-Verzeichnis um das zu überschreiben?
Gute Frage - mangels Erfahrungen mit diesem noch recht neuen Feature halte ich mich vornehm zurück ;-)
CGI kann ja auch externe Programme starten (wenn auch bei suexec nicht unbedingt als wwwrun).
Eben - dann kann er nur seine eigenen Dateien kaputtmachen, was mich etwas weniger stört ;-) Ja, so Nettigkeiten wie /tmp volllaufen lassen kann er natürlich auch, das ist dann aber zumindest über den Usernamen identifizierbar bzw. per Quota verhinderbar.
Na, und gerade für'n Entwickler, mmm....
Habe ich gesagt, dass ich über "Serverkonfiguration für Entwickler" schreibe? Das wäre dann "jeder darf alles", damit man sich nicht selbst im Weg steht ;-)) (Sowas mach ich auf meinem Laptop auch manchmal, aber für einen Produktivserver kann und will ich das nicht empfehlen.)
Beispielsweise sämtliche Dateien verunstalten, die per PHP-Uploadformular hochgeladen wurden - beim Einsatz eines Content Management Systems sind das einige.
Dann lädt man die halt nochmal hoch. Falls man wirklich so viel auf'm Entwicklersystem hat...
Siehe oben - ich rede nicht (nur) von Entwicklersystemen.
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 ;-)
MySQL-Passwörter kriegt man doch nicht raus? Die sind doch sicherlich nirgendwo im Klartext gespeichert und den Hash darf man nur vergleichen, nicht lesen...
Doch, die MySQL-Passwörter findet man zuhauf - guck Dir ein beliebiges PHP-Script an, das auf MySQL zugreift und Du wirst fündig.
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 ;-)
Na, weiss ja nicht, ob ich dem PHP da trauen würde... Ich mein, so ziemlich die wurstigste der verbreiteten Sprachen, linkt gegen /usr/lib/lib*a, in der Vergangenheits Bugs ohne Ende, oben aufgeklatschtes "Sicherheitssystem", etc. aber anderes Thema.
Ich traue PHP jedenfalls mehr als manchen CGIs, die jemand irgendwo[tm] gefunden und für lustig befunden hat ;-)
Ja, und eure Entwickler drüfen kein CGI? Ist schon komisch. Na ja.
Auf dem Server, den ich betreue, laufen hauptsächlich Webseiten auf Typo3-Basis - somit wird vor allem PHP benötigt. Aus naheliegenden Gründen sind dann auch Erweiterungen, die innerhalb dieser Seiten erscheinen sollen, in PHP programmiert - CGIs in einem <iframe> sind nicht wirklich schön ;-) Falls jemand unbedingt CGIs braucht, darf er die natürlich verwenden.
Also klar, wenn man jetzt ein Produktionssystem hätte, dann nimmt man natürlich am besten gar kein PHP und suExec-CGIs, klar.
*LoL* Die beste Methode zur Absicherung des Systems ist ja bekanntlich der Befehl "init 0" *g* - man wird also immer einen Kompromiss zwischen Sicherheit und Funktionalität finden müssen.
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.
lol, das ist ja ne schöne Beschreibung. Durch das Verwenden von PHP wird die Serverlast aber bestimmt noch mehr erhöht hihi
Das bestreite ich nicht ;-)
Ich verwende viel SHTML, das ist IMHO auch richtig, kann heut bloss kaum noch einer, aber das Internet muss ja auch so schlecht wie alle Software sein, klar. Da macht man dann Menüs mit Java oder so, aber ist ja auch egal.
Wenn SHTML wirklich verwendet wird (also die Dateien entsprechende Befehle beinhalten), ist das OK. Mir ging es um die _unnötige_ Serverlast durch das Parsen aller HTML-Dateien...
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.
iihhh, /cgi-bin/? Find ich sowas von hässlich... Da hab ich dann Dienst X mit /xdata und /cgi-bin/xexec/ etc, furchtbar... Nee, ich möchte /vendor/package-version/ haben, und da ist alles drin.
Ist wohl Ansichtssache - ich bevorzuge jedenfalls /cgi-bin ;-)
Manchmal tauscht man ja auch Bilder gegen JPEGs, und welcher Package gehört /cgi-bin/show.jpg?
Da in /cgi-bin/ nur Programme/Scripte existieren, sollte das irgendwo im Programmcode zu erkennen sein ;-))
IncludesNOEXEC Server-side includes are permitted, but the #exec cmd and #exec cgi are disabled. [...]
Vergleichsweise harmlos (und deutlich sicherer als Includes).
ja OK, aber wie soll denn ein Entwickler entwickeln, wenn er keinen Code benutzen darf?
Habe ich das gesagt? Siehe CGIs - wenn er es braucht, wird er es bekommen. Bis dahin verzichte ich lieber darauf.
Dann kann man ihm ja gleich ein Frontpage oder so'n GUI Mist hinschmeissen. Dann darf man sich natürlich nicht wundern, dass die Webseiten genauso schlecht sind wie die, die man durchschnittlich so im Internet findet... Die sind dann redundant, verwenden vielleicht Javascript und sind Browserabhängig, obwohl man alles Serverseitig hätte machen können.
Welche Punkte willst Du serverseitig machen? Die Dinge, die sonst JavaScript macht, beispielsweise Menüs bauen (sinnvoll), oder eine Browserweiche (serverseitig keine gute Idee IMHO)?
Meiner Meinung nach der falsche Weg (aber ich weiss, dass 99% der Internetnutzer anderer Meinung sind).
Ich zähle mich frecherweise zum verbleibenden Prozent ;-) Man kann Seiten bauen, die auch ohne JavaScript funktionieren. Das heißt nicht, dass JavaScript unnütz ist - man kann es durchaus sinnvoll einsetzen (beliebtes Beispiel: Curser automatisch ins erste Eingabefeld platzieren). Die Seite sollte allerdings auch ohne JavaScript funktionieren - Menüs per JS bauen ist demzufolge dämlich. Auch Browser-Unabhängigkeit ist machbar - man kann problemlos Seiten erstellen, die auf allen Browsern gut aussehen. "Exakt gleich aussehen" ist ein anderes Thema, aber "sehr ähnlich" ist ja auch OK. BTW: Exakt gleich ist sowieso unmöglich, da man nie weiß, welche Schriftarten der User installiert hat, ob er eine Mindestschriftgröße eingestellt hat usw. - es sei denn, man liefert die Seite als eine große Grafik aus.
FollowSymLinks The server will follow symbolic links in this directory.
Symlink zu /etc/passwd gefällig? ;-) Mehr muss ich dazu wohl nicht sagen, oder?
Doch: wo ist das Problem? Dass der Entwickler die Useracountnamen rauskriegt? Er kann dazu auch "cat" verwenden.
Vorausgesetzt, er darf überhaupt irgendwas ausführen ;-)
Hier ist meine passwd, jedenfalls der Anfang: [...] Oder hast Du das einzige Linux-System, das ich kenn, das kein shadow verwendet?
Nein, ich mag LDAP nicht ;-)
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.
Geht aber halt auch nur, wenn der Owner matcht. Wenn man ein RPM installiert, und die Files dadrin root gehören (z.B. damit wwwrun die nicht ändern darf), funktioniert das schon nicht mehr.
Klar.
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]#
(URL geht bei mir nicht)
Der Server war kurzzeitig weg (jemand -nicht ich- hatte in Plesk an der Netzwerkkonfiguration gespielt :-/ - ich durfte es dann wieder zurechtflicken.)
mod_rewrite verbraucht bestimmt Serverlast :)
CPU schon. Dafür habe ich dann weniger Festplattenzugriffe, weil alle Einzelansichten aus derselben PHP-Datei, die dann im RAM gecacht ist, liegt.
In meiner Galarie hab ich für jedes Bild eine HTML-Datei. Natürlich nicht selbst geschrieben, sondern "make" und "wml".
Auch eine Methode ;-)
Fazit: Insbesondere AllowOverride Options erlaubt mehr als man möchte.
Mehr als /Du/ in bestimmten Fällen möchtest, ja. Ich hoffe, ich konnte zu jedem Punkt mindestens ein überzeugendes Gegenbeispiel finden :)
Konntest Du ;-)
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).
(oder deinstallieren, ist noch sicherer und spart Serverlast SCNR.)
Es steigert aber den Load desjenigen, der das Menü in 100 HTML-Dateien aktualisieren muss *SCNR2*
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.
Oder er erlaubt CGIs und SSI und erlaubt AllowOverride halt.
Wie soll denn ein Angreifer, der nur HTTP sprechen kann, das CGI missbrauchen, nur allein weil es da ist?
Kommt auf das CGI an - ich hatte schon etliche Zugriffsversuche auf formmail.cgi (aber: not found ;-)
Banken verwenden bei Online-Banking-Frontends CGI, weil statisches HTML für Kontostände bissel schwer ist.
( Gut, Banken sind nicht unbedingt Biespiele für "wirklich sichere Webserver", aber im Durchschnitt schon nicht schlecht. SCNR. )
*LoL* Naja, zumindendest meistens - http://www.heise.de/security/news/meldung/67698
Ich halte das nach wie vor für situationsabhängig, gilt also alles nicht allgemein, sondern nur in verschiedenen, speziellen Fällen.
Stimmt - ich hätte wohl meine ganze mail in <security mode="paranoid"> packen sollen ;-) Erfahrungsgemäß wird aber oft zu viel erlaubt, gerade durch AllowOverride All - deshalb wollte ich auf die möglichen Risiken hinweisen. Dass man das ein oder andere erlauben muss, ist mir schon klar - nur sollte man es möglichst selektiv machen. Bist Du mit dieser Zusammenfassung als Schlusswort einverstanden? Wenn ja, schlage ich EOT vor - die Argumente sind ja inzwischen bekannt. Wenn nicht, darfst Du natürlich gern wieder mailen ;-) Gruß Christian Boltz --
Danke an alle, die mir bei der Geburt geholfen haben, das Baby brennt ;) Hat das weh getan, ein brennendes Baby zu gebären? *scnr* ;))) Qualmt es der Mama neben dem Schenkel, weiss der Opa, es gibt 'nen heißen Enkel! [> Michael Raab und Thorsten von Plotho-Kettner in suse-linux]
participants (6)
-
Christian Boltz -
fion -
Jan Friedrich Gehring -
Steffen Dettmer -
Taner Ayaydin -
Udo Neist