Re: Apache vs PostgreSQL

Am Donnerstag 20 März 2008 23:34:35 schrieb Andreas 'ads' Scherbaum:
> On Thu, 20 Mar 2008 20:53:37 +0100 Olaf Radicke wrote:
> > Hier mal eine Hypothese als Diskussionsgrundlage:
>
> mir stellt sich die Frage, was genau du mit deiner Diskussion erreichen
> möchtest.

Mein Programm benutzt eine PostgreSQL-DB ohne Umwege (über einen Webserver).
Ich bin der Meinung eine PostgreSQL-DB ist erst mal nicht unsicherer als ein
Apache. Bisher habe ich zwar ungläubige Blicke geerntet dafür, aber keine
objektive überzeugende Einwende gehört. Liegt vielleicht daran, das es mehr
Leute gibt, die mit Apache rumgefummelt haben (und ohne scheu abenteuerliche
PHP Skripts auf den Rest der Menschheit losgelassen haben), als mit
PostgreSQL-Server.

> > Ich behaupte mal das ein richtig konfigurierte PostgreSQL-Datenbank
> > direkt im Internet verbunden nicht unsicherer ist als ein Apache
> > Webserver.
>
> Sicherheit bezieht sich nicht auf die Menge aller Schnittstellen nach
> aussen. Ein Fehler in der einen Schnittstelle reicht aus, um die gesamte
> proklamierte Sicherheit über den Haufen zu werfen.

Das ist richtig. Nur wenn du über eine sechsspurige Straße bei Rot rüber
bretterst, ist die Wahrscheinlichkeit lebend auf der andern Seite an zu
kommen geringer, als auf einer einspurigen Straße.

> > - Eine Apache-Konfiguration ist wesentlich komplexer als eine
> > PostgreSQL-Konfiguration, wenn man alle gängigen Module einschließt
> > (PHP,CGI,WebDAV,Python...)
>
> Es gibt unzählige Module in contrib und noch mehr, die man extra dazu
> laden kann. Ich sehe den Punkt nicht.

Gut. Gehen wir mal von einem 08/15 Szenario aus. Was ist den so alles bei. Was
wird vom WebAdmin einfach erwartet...? Bedeuten mehr, als von einem DBA oder?

> > - Es gibt keine strikten Trennungen der Domains in Apache. Hast du eine
> > gehackt - hast du alle gehackt.
>
> Konzepte wie suexec, getrennte Zugriffsrechte oder jails existieren und
> können auch für Apache angewandt werden. Natürlich ist das etwas
> Aufwand ...

...Und was aufwendig ist, wird nicht gemacht. Oder? SELinux benutzt doch auch
kaum einer, ob wohl du 99,5% der Angriffe lokal eingrenzen oder komplett
verhindern könntest.

> > - Es gibt gibt keine Rollen, Gruppen, oder User in Apache. Alles wird vom
> > selben Daemon ausgeführt. Rechtebeschränkung von Skripten ist deshalb
> > sehr schwierig.
>
> Schwierig ist nicht gleich unmöglich.
> Schwierig ist gleich Aufwand.

...Und wird deshalb vom Hobby-Admin nicht gemacht. Oder hast du was anderes
beobachtet?

> Wenn dir jemand über PostgreSQL direkt in den dahinterstehenden Unix
> User einbricht, hat der auch Kontrolle über die gesamten Daten. Dann
> sind all die ACLs, Nutzer, Gruppen und Zugriffsbeschränkungen aus
> pg_hba.conf nur Makulatur.

Okay. Mal abgesehen von richtigen Bugs in der DB. Wenn du einem Bösewicht
einen Zugriff auf EINE Datenbank gibst. Was könnte dann schlimmstenfalls
passiere. Sagen wir er ist Normaler User ohne Rechte Neue Rollen und DBs an
zu legen. Wir nehmen ihm noch die Rechte für CREATE, ALTER, DROP u.s.w und
lassen ihm nur noch SELECT, DELETE, INSERT und UPDATE. Dann kann er alle
Daten umgraben, aber das wars dann auch schon. Oder?

> > - Die Datenbanken innerhalb des Cluster sind sauber getrennt. Wenn eine
> > gehackt wurde, kommt man nicht so ohne weiteres in de nächste.
>
> Das gilt nur so lange, wie du innerhalb der Datenbank Software bleibst.
> Wenn es jemand schafft, daraus auszubrechen - hat er alles.

Sicher. Aber wie realistisch ist das?

> > - Die Konfiguration der Zugangsberechtigungen ist klar und zentral in
> > pg_hba.conf geregelt. pg_hba.conf ist das Nadelöhr an dem niemand vorbei
> > kann.
>
> Und wird gern umgangen, indem ganze IP-Bereiche auf "trust" geschaltet
> werden. Sicherheit ist etwas anderes und pg_hba.conf ist kompliziert
> und umständlich. BTST.

Finde ich nicht. Die Möglichkeiten sind sehr begrenzt.
# TYPE DATABASE USER CIDR-ADDRESS METHOD
Fünf Parameter. Das ist nichts im vergleich zu einer Apache-Konfiguration.

> > - Man kann erzwingen, das der Client sich nur mit ssl und md5 anmeldet
> > und jeder weitere Kommunikation abgeschirmt ist.
>
> Es gab in der Vergangenheit Schwachstellen in diversen SSL
> Implementierungen

Auch in der aktuellen 8.1 und 8.2 ?

> und MD5 ist schon seit einiger Zeit nichts, was man
> für Sicherheit einsetzen möchte.

So? Wenn das Passwort nicht gerade aus vier zahlen besteht, wüste ich nicht,
wie ich das so schnell ausheben soll. Wollen wir ein Test machen? Ich gebe
dir eine Phrase und die md5. Wenn du das Passwort nach 48h geknackt hast,
hast du gewonnen. Hier ist sie:
Frase: rübezahl
md5sum: 544489dee215eeb6ba1cda68de7ac8e9

Der Einfachhalber habe ich einfach nur die Phrase ohne Leerzeichen vor das
Passwort gesetzt und eine md5sum erstellt. Das Verfahren könnte man noch
etwas verfeinern, aber als Demo reicht das erst mal.

> > - Wenn man tigger und prozedurale Sprachen verbietet, ist es für den User
> > sehr schwer das System aus zu tricksen.
>
> Was haben Trigger damit zu tun? Und wie verbietest du Trigger?

Man könnte mit Trigger versuchen, etwas zu verschleiern. Aber mehr Rechte
bekommt man nicht. Das stimmt.

> > Zum Schluss noch eine provokante Polemik:
> >
> > Oft hört man, das nur der Apache direkt Datenbank Zugriffe dürfe, um ihn
> > vor dem Böse Internet zu schützen. Ich behaupte mal, ein Apache von dem
> > die Datenbank ausgeht, das von ihr keine Angriffe kommen, ist
> > gefährlicher, als das Internet selber.
>
> Also, deine Mail ist schön geschrieben, aber gängige
> Sicherheitskonzepte - so sie angewandt werden - sehen anders aus.

Die Aussage ist sehr allgemein.

Gruß

Olaf