Re: OT: Sicherer Webserver - Bitte wie?

Marian Hettwer <MH(at)kernel32.de> wrote:
> On Fr, 20.05.2005, 15:55, Oliver Fromme sagte:
> > [...]
> Alles sehr schön gesagt, aber, ich zum Bleistift bin nur sysadmin und kann
> kein PHP.

Damit bist Du sicherlich nicht allein.

> Mitfinanziert wird der Server von Freunden von mir, und es läuft
> auch mod_php4. Nun bekomme ich jedoch von freshports.org ne eMail wenn
> sich was am mod_php4 Port ändert. Und wenns nen Sicherheitsupdate ist, was
> wie du schon sagtest oft genug vorkommt, dann wird das von mir auch sofort
> installiert ;)

Das klingt doch schonmal nach 'nem guten Plan. Unbedingt
empfehlenswert ist auch, Port-Audit auf dem Server zu in-
stallieren (ports/security/portaudit). Das kann man dann
im Daily-Cronjob mitlaufen lassen, und es sagt Dir immer,
wenn irgendwelche Deiner installierten Ports bzw. Packages
bekannte Sicherheitsprobleme haben und aktualisiert werden
sollten.

Und wie gesagt: Man sollte den/die Webserver am besten in
jeweils eigenen Jails laufen lassen, um im Fall der Fälle
den Schaden zu begrenzen.

> Eigentliche Frage nun: Wie würdest du ein code-auditing von php scripten
> anfangen ? Gibt's da einschlägige Richtlinien, oder im Idealfall sogar
> (perl/sh/*)Scripte die sowas übernehmen ? :)

Das ist eine gute Frage, die ich leider nicht konkret be-
antworten kann. Es gibt sicherlich typische Konstrukte,
die ein automatisches Audit-Tool erkennen kann, aber ein
manuelles Durchsehen und Prüfen der Skripte läßt sich
damit auf keinen Fall völlig ersetzen.

Um ein manuelles Audit durchführen zu können, sollte man
natürlich die Programmiersprache beherrschen und bereits
hinreichend Erfahrungen damit gesammelt haben -- das ist
bei PHP nicht anders wie bei jeder anderen Programmier-
sprache.

Es gibt sprachunabhängige Konzepte, die für die Sicherheit
beachtet werden müssen, zum Beispiel, daß die Werte von
Benutzereingaben (und allgemein jeder Input, der von außer-
halb des Programmes kommt) nicht ungeprüft und ungefiltert
weiterverarbeitet werden darf, damit zum Beispiel Angriffe
per SQL-Injection oder eval-Exploits nicht möglich sind.
Und dann gibt es natürlich Punkte, die von der jeweiligen
Sprache abhängen. Zum Beispiel die berüchtigten Buffer-
Overflows bei Programmen, die in C geschrieben sind (häu-
fig verursacht durch off-by-1-Fehler). Bei PHP sind es
zum Beispiel die bekannten Probleme, wenn man register-
globals eingeschaltet hat (was schonmal eine schlechte
Idee ist) und nachlässig mit der Initialisierung von Vari-
ablen ist.

Es gibt zahlreiche Websites, die sich mit Sicherheits-
aspekten von PHP beschäftigen. Offenbar besteht da ein
gewisser Bedarf. ;-) Die PHP-Doku selbst hat ein
eigenes Kapitel zum Thema Security, in dem wiederum ein
paar Links zu finden sind. Ich liste hier mal ein paar,
wahllos herausgepickt und ohne Anspruch auf Aktualität.

http://phpsec.org/
http://phpsec.org/projects/guide/
http://securephp.damonkohler.com/
http://shiflett.org/php-security.pdf
http://www.phpsecure.info/

> > PHP gehört eindeutig zu den schlimmsten Vertretern. Deut-
> > lich besser wäre z.B. perl im »taint mode« (Jörg Wunsch
> > wird mir jetzt sicherlich jubelnd zustimmen), obgleich
> > ich Perl sonst nicht mag.
>
> hm... sollte ich mal drüber nachdenken. Müsste aber meinen mitfinanzierer
> und PHP Verfechter dann auf perl bringen. Schwierige Aufgabe ;)

Wobei man natürlich immer noch wissen sollte, was man tut.
Perls »taint mode« (siehe die perlsec(1)-manpage) ist nur
ein Fingerzeig, der in einigen typischen Fällen verhindert,
daß man blind ins offene Messer rennt. In den Fuß schießen
kann man sich trotzdem noch.

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"UNIX was not designed to stop you from doing stupid things,
because that would also stop you from doing clever things."
        -- Doug Gwyn
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message