Hi!

Hier mal eine Hypothese als Diskussionsgrundlage:

Ich behaupte mal das ein richtig konfigurierte PostgreSQL-Datenbank direkt =
im
Internet verbunden nicht unsicherer ist als ein Apache Webserver.

Die Begründung:

- Ein Apache ist schon deswegen unsicherer, weil es wesentlich mehr
Angriffsfläche bietet. Ein Apache unterstütze unzählige Schnittstelle=
n und
Protokolle.

- Eine Apache-Konfiguration ist wesentlich komplexer als eine
PostgreSQL-Konfiguration, wenn man alle gängigen Module einschließt
(PHP,CGI,WebDAV,Python...)

- Es gibt keine strikten Trennungen der Domains in Apache. Hast du eine
gehackt - hast du alle gehackt.

- Es gibt gibt keine Rollen, Gruppen, oder User in Apache. Alles wird vom=

selben Daemon ausgeführt. Rechtebeschränkung von Skripten ist deshalb s=
ehr
schwierig.

- Eine PostgreSQL hat ein klares ACL.

- Die Datenbanken innerhalb des Cluster sind sauber getrennt. Wenn eine
gehackt wurde, kommt man nicht so ohne weiteres in de nächste.

- 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.

- Man kann erzwingen, das der Client sich nur mit ssl und md5 anmeldet und=

jeder weitere Kommunikation abgeschirmt ist.

- Die möglichen Interaktionen des Benutzer mit der Datenbank sind übers=
chaubar
und fein granuliert ein zu stellen. Was sich bis zum einzelnen Befehl
herunterbrechen lässt.

- Wenn man tigger und prozedurale Sprachen verbietet, ist es für den User=
sehr
schwer das System aus zu tricksen.


Zum Schluss noch eine provokante Polemik:

Oft hört man, das nur der Apache direkt Datenbank Zugriffe dürfe, um ih=
n 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, a=
ls
das Internet selber.


Schönes Wochen Ende

Olaf Radicke


--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

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=C3=B6chtest.


> Ich behaupte mal das ein richtig konfigurierte PostgreSQL-Datenbank direk=
t 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 =C3=BCber den Haufen zu werfen.


> - Eine Apache-Konfiguration ist wesentlich komplexer als eine
> PostgreSQL-Konfiguration, wenn man alle g=C3=A4ngigen Module einschlie=C3=
=9Ft
> (PHP,CGI,WebDAV,Python...)

Es gibt unz=C3=A4hlige Module in contrib und noch mehr, die man extra dazu
laden kann. Ich sehe den Punkt nicht.


> - 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=C3=B6nnen auch f=C3=BCr Apache angewandt werden. Nat=C3=BCrlich ist das e=
twas
Aufwand ...


> - Es gibt gibt keine Rollen, Gruppen, oder User in Apache. Alles wird vom=

> selben Daemon ausgef=C3=BChrt. Rechtebeschr=C3=A4nkung von Skripten ist d=
eshalb sehr
> schwierig.

Schwierig ist nicht gleich unm=C3=B6glich.
Schwierig ist gleich Aufwand.

Wenn du Sicherheit haben m=C3=B6chtest, musst du etwas daf=C3=BCr tun. Wenn=
du
nach einem ersten Fehler (sprich: Einbruch) den Rest der Installation
sch=C3=BCtzen m=C3=B6chtest, sollten tunlichst nicht alle Domains unter den
gleichen Rechten laufen.

Wenn dir jemand =C3=BCber PostgreSQL direkt in den dahinterstehenden Unix
User einbricht, hat der auch Kontrolle =C3=BCber die gesamten Daten. Dann
sind all die ACLs, Nutzer, Gruppen und Zugriffsbeschr=C3=A4nkungen aus
pg_hba.conf nur Makulatur.


> - Die Datenbanken innerhalb des Cluster sind sauber getrennt. Wenn eine=

> gehackt wurde, kommt man nicht so ohne weiteres in de n=C3=A4chste.

Das gilt nur so lange, wie du innerhalb der Datenbank Software bleibst.
Wenn es jemand schafft, daraus auszubrechen - hat er alles.


> - Die Konfiguration der Zugangsberechtigungen ist klar und zentral in
> pg_hba.conf geregelt. pg_hba.conf ist das Nadel=C3=B6hr an dem niemand vo=
rbei
> 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=C3=A4ndlich. BTST.


> - Man kann erzwingen, das der Client sich nur mit ssl und md5 anmeldet un=
d
> jeder weitere Kommunikation abgeschirmt ist.

Es gab in der Vergangenheit Schwachstellen in diversen SSL
Implementierungen und MD5 ist schon seit einiger Zeit nichts, was man
f=C3=BCr Sicherheit einsetzen m=C3=B6chte.


> - Wenn man tigger und prozedurale Sprachen verbietet, ist es f=C3=BCr den=
User sehr
> schwer das System aus zu tricksen.

Was haben Trigger damit zu tun? Und wie verbietest du Trigger?


> Zum Schluss noch eine provokante Polemik:
>
> Oft h=C3=B6rt man, das nur der Apache direkt Datenbank Zugriffe d=C3=BCrf=
e, um ihn vor
> dem B=C3=B6se Internet zu sch=C3=BCtzen. Ich behaupte mal, ein Apache von=
dem die
> Datenbank ausgeht, das von ihr keine Angriffe kommen, ist gef=C3=A4hrlich=
er, als
> das Internet selber.

Also, deine Mail ist sch=C3=B6n geschrieben, aber g=C3=A4ngige
Sicherheitskonzepte - so sie angewandt werden - sehen anders aus.


Bis dann

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Am Donnerstag 20 M=C3=A4rz 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=C3=B6chtest.

Mein Programm benutzt eine PostgreSQL-DB ohne Umwege (=C3=BCber einen Webse=
rver).
Ich bin der Meinung eine PostgreSQL-DB ist erst mal nicht unsicherer als ei=
n
Apache. Bisher habe ich zwar ungl=C3=A4ubige Blicke geerntet daf=C3=BCr, ab=
er keine
objektive =C3=BCberzeugende Einwende geh=C3=B6rt. Liegt vielleicht daran, d=
as es mehr
Leute gibt, die mit Apache rumgefummelt haben (und ohne scheu abenteuerlich=
e
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 =C3=BCber den Haufen zu werfen.

Das ist richtig. Nur wenn du =C3=BCber eine sechsspurige Stra=C3=9Fe bei Ro=
t r=C3=BCber
bretterst, ist die Wahrscheinlichkeit lebend auf der andern Seite an zu
kommen geringer, als auf einer einspurigen Stra=C3=9Fe.

> > - Eine Apache-Konfiguration ist wesentlich komplexer als eine
> > PostgreSQL-Konfiguration, wenn man alle g=C3=A4ngigen Module einschlie=
=C3=9Ft
> > (PHP,CGI,WebDAV,Python...)
>
> Es gibt unz=C3=A4hlige 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 ode=
r?

> > - 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=C3=B6nnen auch f=C3=BCr Apache angewandt werden. Nat=C3=BCrlich ist das=
etwas
> Aufwand ...

....Und was aufwendig ist, wird nicht gemacht. Oder? SELinux benutzt doch au=
ch
kaum einer, ob wohl du 99,5% der Angriffe lokal eingrenzen oder komplett
verhindern k=C3=B6nntest.

> > - Es gibt gibt keine Rollen, Gruppen, oder User in Apache. Alles wird v=
om
> > selben Daemon ausgef=C3=BChrt. Rechtebeschr=C3=A4nkung von Skripten ist=
deshalb
> > sehr schwierig.
>
> Schwierig ist nicht gleich unm=C3=B6glich.
> Schwierig ist gleich Aufwand.

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

beobachtet?

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

Okay. Mal abgesehen von richtigen Bugs in der DB. Wenn du einem B=C3=B6sewi=
cht
einen Zugriff auf EINE Datenbank gibst. Was k=C3=B6nnte dann schlimmstenfal=
ls
passiere. Sagen wir er ist Normaler User ohne Rechte Neue Rollen und DBs an=

zu legen. Wir nehmen ihm noch die Rechte f=C3=BCr 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=C3=A4chste.
>
> 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=C3=B6hr 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=C3=A4ndlich. BTST.

Finde ich nicht. Die M=C3=B6glichkeiten sind sehr begrenzt.
# TYPE DATABASE USER CIDR-ADDRESS METHOD
F=C3=BCnf Parameter. Das ist nichts im vergleich zu einer Apache-Konfigurat=
ion.

> > - 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=C3=BCr Sicherheit einsetzen m=C3=B6chte.

So? Wenn das Passwort nicht gerade aus vier zahlen besteht, w=C3=BCste 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=C3=BCbezahl
md5sum: 544489dee215eeb6ba1cda68de7ac8e9

Der Einfachhalber habe ich einfach nur die Phrase ohne Leerzeichen vor das=

Passwort gesetzt und eine md5sum erstellt. Das Verfahren k=C3=B6nnte man no=
ch
etwas verfeinern, aber als Demo reicht das erst mal.

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

Man k=C3=B6nnte mit Trigger versuchen, etwas zu verschleiern. Aber mehr Rec=
hte
bekommt man nicht. Das stimmt.

> > Zum Schluss noch eine provokante Polemik:
> >
> > Oft h=C3=B6rt man, das nur der Apache direkt Datenbank Zugriffe d=C3=BC=
rfe, um ihn
> > vor dem B=C3=B6se Internet zu sch=C3=BCtzen. Ich behaupte mal, ein Apac=
he von dem
> > die Datenbank ausgeht, das von ihr keine Angriffe kommen, ist
> > gef=C3=A4hrlicher, als das Internet selber.
>
> Also, deine Mail ist sch=C3=B6n geschrieben, aber g=C3=A4ngige
> Sicherheitskonzepte - so sie angewandt werden - sehen anders aus.

Die Aussage ist sehr allgemein.

Gru=C3=9F

Olaf

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

On Fri, 21 Mar 2008 01:15:14 +0100 Olaf Radicke wrote:

> Am Donnerstag 20 M=C3=A4rz 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=C3=B6chtest.
>
> Mein Programm benutzt eine PostgreSQL-DB ohne Umwege (=C3=BCber einen Web=
server).
> Ich bin der Meinung eine PostgreSQL-DB ist erst mal nicht unsicherer als =
ein
> Apache. Bisher habe ich zwar ungl=C3=A4ubige Blicke geerntet daf=C3=BCr, =
aber keine
> objektive =C3=BCberzeugende Einwende geh=C3=B6rt. Liegt vielleicht daran,=
das es mehr
> Leute gibt, die mit Apache rumgefummelt haben (und ohne scheu abenteuerli=
che
> PHP Skripts auf den Rest der Menschheit losgelassen haben), als mit
> PostgreSQL-Server.

Deine Anwendung hat einen anderen Anwendungsfall als ein Webclient ihn
hat. Ich sehe hier immer noch keinen Punkt. Aber das ist wohl auch
nicht beabsichtigt.


> > > 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 =C3=BCber den Haufen zu werfen.
>
> Das ist richtig. Nur wenn du =C3=BCber eine sechsspurige Stra=C3=9Fe bei =
Rot r=C3=BCber
> bretterst, ist die Wahrscheinlichkeit lebend auf der andern Seite an zu=

> kommen geringer, als auf einer einspurigen Stra=C3=9Fe.

Und der Raser auf der einspurigen, geschwindigkeitsbeschr=C3=A4nkten Stra=
=C3=9Fe
muss bloss mit =C3=BCberh=C3=B6hter Geschwindigkeit geradeaus =C3=BCber den
Zebrasteifen fahren, um dich zu erwischen. Trotzdem bist du tot.
Komisch, das mehr Menschen beim =C3=9Cberqueren von Zebrastreifen
verunfallen als beim =C3=9Cberqueren von 6-spurigen Stra=C3=9Fen.


> > > - Es gibt gibt keine Rollen, Gruppen, oder User in Apache. Alles wird=
vom
> > > selben Daemon ausgef=C3=BChrt. Rechtebeschr=C3=A4nkung von Skripten i=
st deshalb
> > > sehr schwierig.
> >
> > Schwierig ist nicht gleich unm=C3=B6glich.
> > Schwierig ist gleich Aufwand.
>
> ...Und wird deshalb vom Hobby-Admin nicht gemacht. Oder hast du was ander=
es
> beobachtet?

Wenn wir hier Hobby-Admins und Sicherheit diskutieren, ist dieser
Thread f=C3=BCr mich beendet. Daf=C3=BCr brauche ich keine Fragen in den Ra=
um zu
werfen.


> > Wenn dir jemand =C3=BCber PostgreSQL direkt in den dahinterstehenden Un=
ix
> > User einbricht, hat der auch Kontrolle =C3=BCber die gesamten Daten. Da=
nn
> > sind all die ACLs, Nutzer, Gruppen und Zugriffsbeschr=C3=A4nkungen aus
> > pg_hba.conf nur Makulatur.
>
> Okay. Mal abgesehen von richtigen Bugs in der DB.

Nicht "mal abgesehen". Wenn ich irgendwo einbrechen will, suche ich mir
die Bugs dort, wo sie nicht erwartet werden, wo die Breitenwirkung aber
effektiver ist als bei einer simplen SQL-Injection.


> > 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?

Bis zum n=C3=A4chsten Bug. Und ja, es gibt auch Bugs, =C3=BCber die man dir=
ekt in
Datenbanken einbrechen kann, ohne vorher SQL nutzen zu m=C3=BCssen.

Es gibt auch Bugs, die Rechteeskalation erm=C3=B6glichen, da war Ende
letzten oder Anfang diesen Jahres erst etwas, was wohl bis zur=C3=BCck zu
7.3 gepatcht wurde - das finde ich schon sehr realistisch.
Durchsuch mal die CVE Datenbank, da d=C3=BCrftest du f=C3=BCndig werden.


> > > - Die Konfiguration der Zugangsberechtigungen ist klar und zentral in
> > > pg_hba.conf geregelt. pg_hba.conf ist das Nadel=C3=B6hr an dem nieman=
d 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=C3=A4ndlich. BTST.
>
> Finde ich nicht. Die M=C3=B6glichkeiten sind sehr begrenzt.
> # TYPE DATABASE USER CIDR-ADDRESS METHOD
> F=C3=BCnf Parameter. Das ist nichts im vergleich zu einer Apache-Konfigur=
ation.

Und warum gibt es dann so viele Fragen rund um diese 5 Parameter?
Warum kommen so viele User auf die Idee, da einfach mal mit "trust"
alle Probleme zu =C3=BCberwinden? In einer Default Apache Config =C3=A4nder=
e ich
ungef=C3=A4hr den Hostnamen und den Pfad f=C3=BCr document_root, das sind z=
wei
Parameter, nicht f=C3=BCnf.

Das f=C3=A4llt aber alles in die Kategorie "Hobby-Admin" und geh=C3=B6rt hi=
er
nicht hin.


> > > - 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 ?

Aktuell ist PostgreSQL 8.3, der Rest sind nur Versionen, die noch einige
Jahre Support genie=C3=9Fen.

Wie dir jedoch aufgefallen ist, ist SSL keine PostgreSQL
Entwicklung sondern daf=C3=BCr wird eine darunterliegende Bibliothek
genutzt. Die kann durchaus f=C3=BCr 8.1, 8.2 und 8.3 die gleiche
Versionsnummer - und ggf. die gleichen Fehler - beinhalten.

Es gab auch erst Ende 2007 einen Haufen Probleme mit einer Regexp
Library, die nicht nur von PG sondern von einer Menge Applikationen
mehr genutzt wird. Und Schwups hat man ein Sicherheitsproblem in der
H=C3=A4lfte der Services, ohne etwas daf=C3=BCr zu k=C3=B6nnen.


> > und MD5 ist schon seit einiger Zeit nichts, was man
> > f=C3=BCr Sicherheit einsetzen m=C3=B6chte.
>
> So? Wenn das Passwort nicht gerade aus vier zahlen besteht, w=C3=BCste ic=
h nicht,
> wie ich das so schnell ausheben soll. Wollen wir ein Test machen? Ich geb=
e
> dir eine Phrase und die md5. Wenn du das Passwort nach 48h geknackt hast,=

> hast du gewonnen. Hier ist sie:
> Frase: r=C3=BCbezahl
> md5sum: 544489dee215eeb6ba1cda68de7ac8e9

Schau, ich habe keine Lust, dir deine Sicherheitsbedenken zu best=C3=A4tigen
oder zu widerlegen. Das MD5 an sich mittlerweile nicht mehr als sicher
gilt, ist bekannt. Ansonsten darfst du dir das hier durchlesen:

http://eprint.iacr.org/2004/199.pdf
(speziell am Ende der ersten Seite)
http://www.mscs.dal.ca/~selinger/md5collision/

So, und jetzt lass uns das Thema beenden. Passw=C3=B6rter sind nur solange
sicher, wie sie niemand zu Gesicht bekommt. Bricht dir jemand in den
Unix Account ein, wird er auch Zugriff auf die md5 Passw=C3=B6rter erhalten.


> > Also, deine Mail ist sch=C3=B6n geschrieben, aber g=C3=A4ngige
> > Sicherheitskonzepte - so sie angewandt werden - sehen anders aus.
>
> Die Aussage ist sehr allgemein.

Deine Provokation ist - provokant. Aber an sich ohne wirkliche Inhalte.


Ich gehe jetzt schlafen.

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Olaf Radicke wrote:

[.. Ramblings snipped ..]

Worauf m=C3=B6chtest du hinaus?

Ja, Postgres kann man direkt am Internetz betreiben ohne dass einen
gleich die Chinesischen Wundermittelverk=C3=A4ufer als Keiler rekrutieren=
..

Nein, es ist keine gute Idee. Besonders nicht wenns von Applikationen
angesprochen werden soll die in nicht kontrollierten Umgebungen (read:
"Kunde") laufen.


Selbst wenn direkter Zugriff zur Datenbank keine Sicherheitsrisiken
bergen sollte (was auch bei Postgres schon mehrmals widerlegt wurde),
=C3=B6ffnet er doch T=C3=BCr und Tor f=C3=BCr Denial of Service-Attacken =
(Examples are
left as an exercise for the reader...) [1].


Ausserdem sollte bei jedem System das entwickelt wird, je nach
Sensibilit=C3=A4t, "Defense in Depth" beherzigt werden.

Das f=C3=A4ngt bei IP/Auth-Based ACLs f=C3=BCr API/XML-Schnittstellen an,=
geht
=C3=BCber halbwegs sichere Server-Setups f=C3=BCr selbige Dienste (selbst=
wenn
jemand den Daemon =C3=BCbernimmt m=C3=B6chte man ihm das Leben so schwer =
wie
m=C3=B6glich machen) [2] und wird durch sinnvolle Permissions in der
Datenbank komplementiert.

Nat=C3=BCrlich kann man bei allem Abstriche was Sicherheit und/oder
Flexibilit=C3=A4t anbelangt machen, obs einem das langfristig Wert war/is=
t
wird die Zeit zeigen. Und das Resultat aus dem ganzen nennt man dann
Erfahrung ;).

lg,
Michael

[1] Etwa OT, aber mein liebster (interdisziplin=C3=A4rer) PG-DoS ist noch=

immer http://linuxpunk.org/irc/showmore.php?id=3D1141 .

[2] How are you going to use this bindshell... when you can't connect to
the internet?

Oder als SELinux-Variante: ... when you can't bind()?

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Am Freitag 21 M=C3=A4rz 2008 02:11:03 schrieb Andreas 'ads' Scherbaum:
> On Fri, 21 Mar 2008 01:15:14 +0100 Olaf Radicke wrote:
> > Am Donnerstag 20 M=C3=A4rz 2008 23:34:35 schrieb Andreas 'ads' Scherbau=
m:
> > > On Thu, 20 Mar 2008 20:53:37 +0100 Olaf Radicke wrote:
[...]

Vielleich war der Betrefs verwirrent und h=C3=A4tte lauten sollen:

LAPP vs. PostgreSQL & Fat-Client

[...]

> > > Wenn dir jemand =C3=BCber PostgreSQL direkt in den dahinterstehenden =
Unix
> > > User einbricht, hat der auch Kontrolle =C3=BCber die gesamten Daten. =
Dann
> > > sind all die ACLs, Nutzer, Gruppen und Zugriffsbeschr=C3=A4nkungen aus
> > > pg_hba.conf nur Makulatur.
> >
> > Okay. Mal abgesehen von richtigen Bugs in der DB.
>
> Nicht "mal abgesehen". Wenn ich irgendwo einbrechen will, suche ich mir
> die Bugs dort, wo sie nicht erwartet werden, wo die Breitenwirkung aber
> effektiver ist als bei einer simplen SQL-Injection.

SQL-Injection sind ein Klassisches LAMP/LAPP Problem. Da die Datenbank Hint=
er
dem Apache und dem Skript quasie blind ist, muss sich die DB auf Apache und=

das Skript verlassen. Die DB /kann/ in diesen Fall garkeine
Plausibilit=C3=A4tspr=C3=BCfung machen. Eine SQL-Injection ist somit kein F=
ehler einer
DB.

> > > Das gilt nur so lange, wie du innerhalb der Datenbank Software bleibs=
t.
> > > Wenn es jemand schafft, daraus auszubrechen - hat er alles.
> >
> > Sicher. Aber wie realistisch ist das?
>
> Bis zum n=C3=A4chsten Bug. Und ja, es gibt auch Bugs, =C3=BCber die man d=
irekt in
> Datenbanken einbrechen kann, ohne vorher SQL nutzen zu m=C3=BCssen.

Wenn ich eine PostgreSQL als Server benutze, habe ich eine potenzielle
Angriffsfl=C3=A4che. Wenn ich ein LAMP/LAPP benutze habe ich drei.


> > Finde ich nicht. Die M=C3=B6glichkeiten sind sehr begrenzt.
> > # TYPE DATABASE USER CIDR-ADDRESS METHOD
> > F=C3=BCnf Parameter. Das ist nichts im vergleich zu einer
> > Apache-Konfiguration.
>
> Und warum gibt es dann so viele Fragen rund um diese 5 Parameter?
> Warum kommen so viele User auf die Idee, da einfach mal mit "trust"
> alle Probleme zu =C3=BCberwinden? In einer Default Apache Config =C3=A4nd=
ere ich
> ungef=C3=A4hr den Hostnamen und den Pfad f=C3=BCr document_root, das sind=
zwei
> Parameter, nicht f=C3=BCnf.

Fielleicht automatisiert das deine PHP-Applikation durch ein Wizart, so das=
du
nicht selber Hand anlegen musst. Wenn du z.B. ein CRM hast, brauchst du ein=
e
Zugangsverwaltung. Das kann man mit Apache ein bisschen hinbasteln, aber
meistens bringen die Skripte ihrer eigene Zugangsverwaltung mit. Viele
Programme haben dann auch noch unterschiedliche Vorstellungen dar=C3=BCber =
wie sie
das machen wollen. Einige benutzen z.B. LDAP.

War Breughel der das Bild malte mit der Reihe Blinder, die sich gegenseitig=

f=C3=BChrt? So kommt mir LAMP/LAPP ach vor:

Postgres vertraut Apache. Apache vertraut einem PHP-Skript, Das PHP-Skript=

vertraut sich selbst oder einem LDAP. Der LDAP...


> > > > - 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 ?
>
> Aktuell ist PostgreSQL 8.3, der Rest sind nur Versionen, die noch einige
> Jahre Support genie=C3=9Fen.
>
> Wie dir jedoch aufgefallen ist, ist SSL keine PostgreSQL
> Entwicklung sondern daf=C3=BCr wird eine darunterliegende Bibliothek
> genutzt. Die kann durchaus f=C3=BCr 8.1, 8.2 und 8.3 die gleiche
> Versionsnummer - und ggf. die gleichen Fehler - beinhalten.
>
> Es gab auch erst Ende 2007 einen Haufen Probleme mit einer Regexp
> Library, die nicht nur von PG sondern von einer Menge Applikationen
> mehr genutzt wird. Und Schwups hat man ein Sicherheitsproblem in der
> H=C3=A4lfte der Services, ohne etwas daf=C3=BCr zu k=C3=B6nnen.

Also h=C3=A4tte es dann auch einem LAMP/LAPP den Arsch weg gerissen?

> > > und MD5 ist schon seit einiger Zeit nichts, was man
> > > f=C3=BCr Sicherheit einsetzen m=C3=B6chte.
> >
> > So? Wenn das Passwort nicht gerade aus vier zahlen besteht, w=C3=BCste =
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=C3=BCbezahl
> > md5sum: 544489dee215eeb6ba1cda68de7ac8e9
>
> Schau, ich habe keine Lust, dir deine Sicherheitsbedenken zu best=C3=A4ti=
gen
> oder zu widerlegen. Das MD5 an sich mittlerweile nicht mehr als sicher
> gilt, ist bekannt. Ansonsten darfst du dir das hier durchlesen:
>
> http://eprint.iacr.org/2004/199.pdf
> (speziell am Ende der ersten Seite)
> http://www.mscs.dal.ca/~selinger/md5collision/

Wenn ich den Text richtig verstanden habe, war die Ausgangsfrage: "Kann ich=

ein Programm korrumpieren, ohne deren md5sum zu ver=C3=A4ndern?"

Die Beantwortung dieser Frage, ist aber bedeutungslos f=C3=BCr die Verwendu=
ng von
Authentifizierung mit md5sum. Im genannten Beispiel ist das Ergebnis bekann=
t.
Bei einer md5-Authentifizierung wei=C3=9F der Angreifer aber nicht was erwa=
rtet
wird. Da die Phrase st=C3=A4ndig wechselt, kann er auch nicht stur durchpro=
bieren.

> So, und jetzt lass uns das Thema beenden. Passw=C3=B6rter sind nur solange
> sicher, wie sie niemand zu Gesicht bekommt. Bricht dir jemand in den
> Unix Account ein, wird er auch Zugriff auf die md5 Passw=C3=B6rter erhalt=
en.

Das ist ein Zirkelschluss.

Mit Freundlichen Gr=C3=BC=C3=9Fen

Olaf

-
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Am Freitag 21 M=C3=A4rz 2008 01:44:07 schrieb Michael Renner:
> Olaf Radicke wrote:
>
> [.. Ramblings snipped ..]
>
> Worauf m=C3=B6chtest du hinaus?

Mal fragen, ob die Annahme, /eine Datenbank m=C3=BCsse immer hinter wen Web=
server
stehen/, nicht er auf "Esoterischen Grundlagen" beruht, statt auf Fakten, u=
m
es mal mit Tim Landscheidt Worten aus zu dr=C3=BCcken.

> Ja, Postgres kann man direkt am Internetz betreiben ohne dass einen
> gleich die Chinesischen Wundermittelverk=C3=A4ufer als Keiler rekrutieren.
>
> Nein, es ist keine gute Idee. Besonders nicht wenns von Applikationen
> angesprochen werden soll die in nicht kontrollierten Umgebungen (read:
> "Kunde") laufen.
>
>
> Selbst wenn direkter Zugriff zur Datenbank keine Sicherheitsrisiken
> bergen sollte (was auch bei Postgres schon mehrmals widerlegt wurde),
> =C3=B6ffnet er doch T=C3=BCr und Tor f=C3=BCr Denial of Service-Attacken =
(Examples are
> left as an exercise for the reader...) [1].

Wenn ich nicht irre, hat Apache keinerlei Funktionalit=C3=A4t um ein DOS-At=
tacken
zu begegnen. F=C3=BCr 1.x gab oder gibt es wohl ein mod.

MfG
Olaf

-
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

On Sun, 23 Mar 2008 21:36:48 +0100 Olaf Radicke wrote:

> Am Freitag 21 M=C3=A4rz 2008 02:11:03 schrieb Andreas 'ads' Scherbaum:
> > On Fri, 21 Mar 2008 01:15:14 +0100 Olaf Radicke wrote:
> > > Am Donnerstag 20 M=C3=A4rz 2008 23:34:35 schrieb Andreas 'ads' Scherb=
aum:
> > > > On Thu, 20 Mar 2008 20:53:37 +0100 Olaf Radicke wrote:
>
> > Nicht "mal abgesehen". Wenn ich irgendwo einbrechen will, suche ich mir
> > die Bugs dort, wo sie nicht erwartet werden, wo die Breitenwirkung aber
> > effektiver ist als bei einer simplen SQL-Injection.
>
> SQL-Injection sind ein Klassisches LAMP/LAPP Problem.

Lies meinen Satz noch mal durch, verstehe ihn, dann weisst du auch, das
ich etwas anderes als SQL-Injection gemeint habe. Dies stand da nur als
billiger Aufh=C3=A4nger, wie ein einfacher Fehler aussehen kann.


> > Bis zum n=C3=A4chsten Bug. Und ja, es gibt auch Bugs, =C3=BCber die man=
direkt in
> > Datenbanken einbrechen kann, ohne vorher SQL nutzen zu m=C3=BCssen.
>
> Wenn ich eine PostgreSQL als Server benutze, habe ich eine potenzielle
> Angriffsfl=C3=A4che. Wenn ich ein LAMP/LAPP benutze habe ich drei.

Und? Wo siehst du den Vorteil?
Wir sind weiterhin bei der Tatsache, das ein Bug in PG ausreicht, dein
Konzept =C3=BCber den Haufen zu werfen. Bei deinem Szenario m=C3=BCsste ich
zuerst in das LAMP/LAPP Setup einbrechen, ehe ich die Datenbank
angreifen kann. Das erfordert zwei Fehler in Reihe - bei deinem
Vorschlag reicht ein Fehler. Was ist nun besser?


> > Und warum gibt es dann so viele Fragen rund um diese 5 Parameter?
> > Warum kommen so viele User auf die Idee, da einfach mal mit "trust"
> > alle Probleme zu =C3=BCberwinden? In einer Default Apache Config =C3=A4=
ndere ich
> > ungef=C3=A4hr den Hostnamen und den Pfad f=C3=BCr document_root, das si=
nd zwei
> > Parameter, nicht f=C3=BCnf.
>
> Fielleicht automatisiert das deine PHP-Applikation durch ein Wizart, so d=
as du
> nicht selber Hand anlegen musst. Wenn du z.B. ein CRM hast, brauchst du e=
ine
> Zugangsverwaltung. Das kann man mit Apache ein bisschen hinbasteln, aber=

> meistens bringen die Skripte ihrer eigene Zugangsverwaltung mit. Viele
> Programme haben dann auch noch unterschiedliche Vorstellungen dar=C3=BCbe=
r wie sie
> das machen wollen. Einige benutzen z.B. LDAP.

Wir sprechen weiterhin =C3=BCber pg_hba.conf. Das ist eine Datei, die vom
zust=C3=A4ndigen Admin im Filesystem ge=C3=A4ndert werden muss. Das klappt =
nicht
=C3=BCber den Wizard in der Applikation. Und LDAP hier einzuwerfen lenkt nur
vom Thema ab.


> > Es gab auch erst Ende 2007 einen Haufen Probleme mit einer Regexp
> > Library, die nicht nur von PG sondern von einer Menge Applikationen
> > mehr genutzt wird. Und Schwups hat man ein Sicherheitsproblem in der
> > H=C3=A4lfte der Services, ohne etwas daf=C3=BCr zu k=C3=B6nnen.
>
> Also h=C3=A4tte es dann auch einem LAMP/LAPP den Arsch weg gerissen?

Nur, wenn diese auch die betroffenen Libraries verwenden. Aber auch
dieses Beispiel widerlegt deine Behauptung nicht sondern sorgt immer
noch daf=C3=BCr, das man die DB nicht offen am Netz haben m=C3=B6chte, wenn=
dies
nicht zwingend notwendig ist.


> > http://eprint.iacr.org/2004/199.pdf
> > (speziell am Ende der ersten Seite)
> > http://www.mscs.dal.ca/~selinger/md5collision/
>
> Wenn ich den Text richtig verstanden habe, war die Ausgangsfrage: "Kann i=
ch
> ein Programm korrumpieren, ohne deren md5sum zu ver=C3=A4ndern?"

Der Text zeigt (unter anderem), das md5 Passw=C3=B6rter nicht mehr state of
the art sind. Nimmt man die Menge bekannter Angriffe und
Einschr=C3=A4nkungen gegen md5, kann man nicht mehr von einem sicheren Hash
Verfahren ausgehen. Nimmt man die Menge bereits existierender Rainbow
Tabellen hinzu (deren Gr=C3=B6=C3=9Fe sich durch die bekannten Angriffe nur=
noch
weiter reduziert), d=C3=BCrften diverse Passw=C3=B6rter bereits in verschwi=
ndend
geringer Zeit knackbar sein. Bzw., man muss die Passw=C3=B6rter nicht
knacken, es gen=C3=BCgt, eine Eingabe zu finden, die die gleiche md5sum
erzeugt (Hash Kollision).

Um auf das Problem zur=C3=BCckzukommen: wir waren urspr=C3=BCnglich bei ein=
em
Einbruch in den Server selbst, vorbei an "SQL", ausgel=C3=B6st z.B. durch
Fehler im Programmcode. Durch diesen Einbruch erlangt jemand a) Zugriff
auf alle Daten, ohne Umwege und b) Zugriff auf die verschl=C3=BCsselten
Passw=C3=B6rter.


> > So, und jetzt lass uns das Thema beenden. Passw=C3=B6rter sind nur sola=
nge
> > sicher, wie sie niemand zu Gesicht bekommt. Bricht dir jemand in den
> > Unix Account ein, wird er auch Zugriff auf die md5 Passw=C3=B6rter erha=
lten.
>
> Das ist ein Zirkelschluss.

Warum? Die Datenbank muss die verschl=C3=BCsselten Passw=C3=B6rter lesen k=
=C3=B6nnen,
also kann dies auch jeder, der in den Unix Account der Datenbank
einbricht.


Mein Schluss:
Ich habe immer noch kein vern=C3=BCnftiges Argument von dir geh=C3=B6rt, wa=
rum
eine Datenbank am Netz etwas gutes sein sollte. Aber ein paar andere,
schwergewichtige Argumente dagegen haben sich angefunden.


Bis dann

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors

-
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

On Sun, 23 Mar 2008 22:25:30 +0100 Olaf Radicke wrote:

> Am Freitag 21 M=C3=A4rz 2008 01:44:07 schrieb Michael Renner:
> > Olaf Radicke wrote:
> >
> > [.. Ramblings snipped ..]
> >
> > Worauf m=C3=B6chtest du hinaus?
>
> Mal fragen, ob die Annahme, /eine Datenbank m=C3=BCsse immer hinter wen W=
ebserver
> stehen/, nicht er auf "Esoterischen Grundlagen" beruht, statt auf Fakten,=
um
> es mal mit Tim Landscheidt Worten aus zu dr=C3=BCcken.

Defense in depth - das sind sehr harte Fakten.
Aber das sagte dir Michael auch schon.


Bis dann

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors

-
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Am Sonntag 23 M=C3=A4rz 2008 23:13:23 schrieb Andreas 'ads' Scherbaum:
> On Sun, 23 Mar 2008 21:36:48 +0100 Olaf Radicke wrote:
> > Am Freitag 21 M=C3=A4rz 2008 02:11:03 schrieb Andreas 'ads' Scherbaum:
> > > On Fri, 21 Mar 2008 01:15:14 +0100 Olaf Radicke wrote:
> > > > Am Donnerstag 20 M=C3=A4rz 2008 23:34:35 schrieb Andreas 'ads' Sche=
rbaum:
> > > > > On Thu, 20 Mar 2008 20:53:37 +0100 Olaf Radicke wrote:
[...]
> > > Bis zum n=C3=A4chsten Bug. Und ja, es gibt auch Bugs, =C3=BCber die m=
an direkt in
> > > Datenbanken einbrechen kann, ohne vorher SQL nutzen zu m=C3=BCssen.
> >
> > Wenn ich eine PostgreSQL als Server benutze, habe ich eine potenzielle
> > Angriffsfl=C3=A4che. Wenn ich ein LAMP/LAPP benutze habe ich drei.
>
> Und?

Die DB k=C3=B6nnte ein oder mehrere Bugs haben...
Der Web-Server k=C3=B6nnte ein oder mehrere Bugs haben...
Der PHP-Interpreter k=C3=B6nnte ein oder mehrere Bugs haben...
Das PHP-Skript k=C3=B6nnte ein oder mehrere Bugs haben...
Das PHP-Lib k=C3=B6nnte ein oder mehrere Bugs haben...

....Das ist bedeutend mehr Fl=C3=A4che w=C3=BCrde ich sagen.

> Wo siehst du den Vorteil?

Ein ein einziges Programm was zur Not noch automatisch =C3=BCber z.B. apt-g=
et
updatebar ist, so das ich noch nicht mal ein ssh offen lassen m=C3=BCsste.

> Wir sind weiterhin bei der Tatsache, das ein Bug in PG ausreicht, dein
> Konzept =C3=BCber den Haufen zu werfen.

Sicher. Aber die Kette ist so stark wie das schw=C3=A4chst Glied. Mit LAMP =
hat die
Kette mehr Glieder und mehr potentielle schwache Glieder. Oder?

> Bei deinem Szenario m=C3=BCsste ich
> zuerst in das LAMP/LAPP Setup einbrechen, ehe ich die Datenbank
> angreifen kann. Das erfordert zwei Fehler in Reihe - bei deinem
> Vorschlag reicht ein Fehler. Was ist nun besser?

Sehe ich anders. Bei mir Probiert er es bei PostgreSQL und ist drinnen oder=

scheitert. Bei LAPP probiert er es zu erst mit diversen Apache Bugs, dann d=
ie
g=C3=A4ngigen PHP-Dinosaurier-Bugs, dann kommen die PHP-Skript wie phpBB
(*grusel*) selber dran, dann noch ein paar Apache Modole durchprobieren und=

gucken ob nicht noch was mit schlecht gewarteten PHP-Libs geht. Aber
vieleicht geht ja noch was mit Perl-CGI, Python, Ruby oder was man noch so=

alles sch=C3=B6nes findet auf ein Webserver...

> > > Und warum gibt es dann so viele Fragen rund um diese 5 Parameter?
> > > Warum kommen so viele User auf die Idee, da einfach mal mit "trust"
> > > alle Probleme zu =C3=BCberwinden? In einer Default Apache Config =C3=
=A4ndere ich
> > > ungef=C3=A4hr den Hostnamen und den Pfad f=C3=BCr document_root, das =
sind zwei
> > > Parameter, nicht f=C3=BCnf.
> >
> > Fielleicht automatisiert das deine PHP-Applikation durch ein Wizart, so
> > das du nicht selber Hand anlegen musst. Wenn du z.B. ein CRM hast,
> > brauchst du eine Zugangsverwaltung. Das kann man mit Apache ein bisschen
> > hinbasteln, aber meistens bringen die Skripte ihrer eigene
> > Zugangsverwaltung mit. Viele Programme haben dann auch noch
> > unterschiedliche Vorstellungen dar=C3=BCber wie sie das machen wollen. =
Einige
> > benutzen z.B. LDAP.
>
> Wir sprechen weiterhin =C3=BCber pg_hba.conf. Das ist eine Datei, die vom
> zust=C3=A4ndigen Admin im Filesystem ge=C3=A4ndert werden muss. Das klapp=
t nicht
> =C3=BCber den Wizard in der Applikation. Und LDAP hier einzuwerfen lenkt =
nur
> vom Thema ab.

Gut. Trotzdem regelst du ja (oder des PHP-Skript) irgendwie den Zugriff. We=
nn
du das mit Apache selbst machst, wirst du ein bisschen mehr Energie in dein=
e
Apache-Konfiguration stecken m=C3=BCssen als 5 Parameter. Tust du das nicht=
, macht
es eben das PHP-Skript. Und was und wie das PHP-Skript etwas mach, ist nich=
t
von Hause aus besser als PostgreSQL. Oder?

> > > Es gab auch erst Ende 2007 einen Haufen Probleme mit einer Regexp
> > > Library, die nicht nur von PG sondern von einer Menge Applikationen
> > > mehr genutzt wird. Und Schwups hat man ein Sicherheitsproblem in der
> > > H=C3=A4lfte der Services, ohne etwas daf=C3=BCr zu k=C3=B6nnen.
> >
> > Also h=C3=A4tte es dann auch einem LAMP/LAPP den Arsch weg gerissen?
>
> Nur, wenn diese auch die betroffenen Libraries verwenden. Aber auch
> dieses Beispiel widerlegt deine Behauptung nicht sondern sorgt immer
> noch daf=C3=BCr, das man die DB nicht offen am Netz haben m=C3=B6chte, we=
nn dies
> nicht zwingend notwendig ist.

Kann ich nicht nachvollziehen. PostgreSQL benutzt (zum Teil) das selbe, abe=
r
bei Apache ist es sicherer?

> > > http://eprint.iacr.org/2004/199.pdf
> > > (speziell am Ende der ersten Seite)
> > > http://www.mscs.dal.ca/~selinger/md5collision/
> >
> > Wenn ich den Text richtig verstanden habe, war die Ausgangsfrage: "Kann
> > ich ein Programm korrumpieren, ohne deren md5sum zu ver=C3=A4ndern?"
>
> Der Text zeigt (unter anderem), das md5 Passw=C3=B6rter nicht mehr state =
of
> the art sind.

Ich glaube das kann man nicht losgel=C3=B6st vom Anwendungsfall generell sa=
gen.

> Nimmt man die Menge bekannter Angriffe und
> Einschr=C3=A4nkungen gegen md5, kann man nicht mehr von einem sicheren Ha=
sh
> Verfahren ausgehen.

Muss man auch nicht, im Falle von einer MD5-Authentifizierung, weil der
Angreifer den vom Server gew=C3=BCnschten Hash sowieso nicht vor die Augen=

bekommt. Er m=C3=BCsste also etwas generieren, was er nicht kennt.

> Nimmt man die Menge bereits existierender Rainbow
> Tabellen hinzu (deren Gr=C3=B6=C3=9Fe sich durch die bekannten Angriffe n=
ur noch
> weiter reduziert), d=C3=BCrften diverse Passw=C3=B6rter bereits in versch=
windend
> geringer Zeit knackbar sein.

Beim MD5-Verfahren hast du nur _einen_ Versuch. Die Wahrscheinlichkeit von=

zwei Blitzen gleichzeitig getroffen zu werden, halte ich f=C3=BCr h=C3=B6he=
r.

> Bzw., man muss die Passw=C3=B6rter nicht
> knacken, es gen=C3=BCgt, eine Eingabe zu finden, die die gleiche md5sum
> erzeugt (Hash Kollision).

Das ist der Punkt: Als Angreifer weist du ja nicht, was du abzuliefern hast=
..
Um etwas zu f=C3=A4lschen, m=C3=BCsstet du wissen, wie das Original aussieh=
t. Das
Original verl=C3=A4sst aber nicht den Server und wird nur ein einziges mal=

erstellt, verwendet und dann verworfen.

> Um auf das Problem zur=C3=BCckzukommen: wir waren urspr=C3=BCnglich bei e=
inem
> Einbruch in den Server selbst, vorbei an "SQL", ausgel=C3=B6st z.B. durch
> Fehler im Programmcode. Durch diesen Einbruch erlangt jemand a) Zugriff
> auf alle Daten, ohne Umwege und b) Zugriff auf die verschl=C3=BCsselten
> Passw=C3=B6rter.

Wenn er drinnen ist interessieren ihn keine Passw=C3=B6rter mehr. Zum einen=
brauch
er sie jetzt sowieso nicht mehr und zum anderen lassen sie sich =C3=A4ndern=
.. Der
erste Schritt nach einem Einbruch ist unauff=C3=A4llig nach Hause zu telefo=
nieren,
Spuren zu verwischen, verwertbare Daten zu Machterweiterung zu finden. Der=

Apache kennt das Passwort von PostgreSQL-Server h=C3=B6chstwahrscheinlich..=
...

> > > So, und jetzt lass uns das Thema beenden. Passw=C3=B6rter sind nur so=
lange
> > > sicher, wie sie niemand zu Gesicht bekommt. Bricht dir jemand in den
> > > Unix Account ein, wird er auch Zugriff auf die md5 Passw=C3=B6rter er=
halten.
> >
> > Das ist ein Zirkelschluss.
>
> Warum? Die Datenbank muss die verschl=C3=BCsselten Passw=C3=B6rter lesen =
k=C3=B6nnen,
> also kann dies auch jeder, der in den Unix Account der Datenbank
> einbricht.

Wenn ich in einer Bank bin, kann ich ganz einfach von innen die T=C3=BCr au=
f machen
und kann dann ganz einfach in die Bank kommen, was beweist wie einfaches is=
t
in eine Bank zu kommen. Das nennen ich einen sauberen Zirkelschluss oder
auch "Henne-Ei-Problem" oder Tautologie. Man m=C3=BCsste schon in der Bank=
sein,
um in die Bank zu gelangen.

Mit freundlichen Gr=C3=BC=C3=9Fen

Olaf Radicke

-
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Olaf Radicke wrote:
> Am Freitag 21 M=C3=A4rz 2008 01:44:07 schrieb Michael Renner:
>> Olaf Radicke wrote:
>>
>> Worauf m=C3=B6chtest du hinaus?
>
> Mal fragen, ob die Annahme, /eine Datenbank m=C3=BCsse immer hinter wen=
Webserver
> stehen/, nicht er auf "Esoterischen Grundlagen" beruht, statt auf Fakte=
n, um
> es mal mit Tim Landscheidt Worten aus zu dr=C3=BCcken.

Eine Datenbank direkt ans Netz zu h=C3=A4ngen geht genausogut wie einen
Exchange direkt ans Netz zu h=C3=A4ngen oder eine AS400/E25K/sonst
irgendeinen Dinosaurier direkt ans Netz zu h=C3=A4ngen. Es wird
funktionieren, aber du verlierst einiges an Schutz und Flexibilit=C3=A4t.


>> Selbst wenn direkter Zugriff zur Datenbank keine Sicherheitsrisiken
>> bergen sollte (was auch bei Postgres schon mehrmals widerlegt wurde),
>> =C3=B6ffnet er doch T=C3=BCr und Tor f=C3=BCr Denial of Service-Attack=
en (Examples are
>> left as an exercise for the reader...) [1].
>
> Wenn ich nicht irre, hat Apache keinerlei Funktionalit=C3=A4t um ein DO=
S-Attacken
> zu begegnen. F=C3=BCr 1.x gab oder gibt es wohl ein mod.

Whoa, der is etwas sehr aus dem Abseits gekommen. Wenn du Webserver
halbwegs sicher bekommen m=C3=B6chtest verwendest du meistens etwas davor=

dass sich um die Connections k=C3=BCmmert (separaten Apache mit mod_proxy=
,
Squid, propriet=C3=A4re Dinger).

Falls dich die ganze Thematik interessiert kann ich dir "Scalable
Internet Architectures" vom Herrn Schlossnagle [1] empfehlen, das geht
jetzt weniger auf den DoS/Security/etc.-Aspekt ein, zeigt aber wie man
skalierbare Systeme entwirft. Und skalierbare Systeme bekommt man, ob
ihrer skalierbarkeit, meistens auch DoS-Resistent ;).

lg,
michael

[1] http://www.amazon.de/dp/067232699X/

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

* Olaf Radicke <olaf_rad [at] gmx.de> schrieb:

Hi,

> - Es gibt keine strikten Trennungen der Domains in Apache. Hast du eine=

> gehackt - hast du alle gehackt.
>
> - 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.

Nicht, wenn man metuxmpm benutzt ;-P
(okay, das wird schon seit Jahren nicht mehr weiterentwickelt)

Allerdings läuft der Postmaster auch auf einer UID.

> - Eine PostgreSQL hat ein klares ACL.

Hat der Apache auch ;-P

Allerdings kann das durch Scripte prima ausgehebelt werden.
Ausweg: jeden vhost unter seiner eigenen UID laufen lassen und das
drunterliegende OS die Zugriffssteuerung erledigen lassen.

Ich würde evtl. (wenn ich die Zeit dazu hätt ;-O) sogar noch weiter
gehen und die Script-Engines in einem eigenem VFS arbeiten lassen, das
via 9P (im Userland) gemounted wird - jeder einzelne Worker bekommt dann
sein Jail (*kein* Zugriff auf das Host-FS!). Allerdings müßte da
allerhand auf dieses VFS portiert werden :(

> - Die Datenbanken innerhalb des Cluster sind sauber getrennt. Wenn eine=

> gehackt wurde, kommt man nicht so ohne weiteres in de nächste.

Es sei denn, der Postmaster ist direkt kompromittiert (ist das schonmal
vorgekommen ?)

> - Man kann erzwingen, das der Client sich nur mit ssl und md5 anmeldet un=
d
> jeder weitere Kommunikation abgeschirmt ist.

Geht beim Apachen auch ;-P

> - Die möglichen Interaktionen des Benutzer mit der Datenbank sind übe=
rschaubar
> und fein granuliert ein zu stellen. Was sich bis zum einzelnen Befehl
> herunterbrechen lässt.

Geht beim Apachen auch, bis runter zu den atomaren Requests.
(okay, Content-Validierung wird da schwierig).

> - Wenn man tigger und prozedurale Sprachen verbietet, ist es für den Us=
er sehr
> schwer das System aus zu tricksen.

Ist eigentlich garnicht nötig. Vorrausgesetzt, die Sprache ist wirklich "=
trusted"
(nicht nur als solche deklariert ;-)), bekommt man damit auch nur auf genau=
die
Daten, die erlaubt sind. Okay, man könnte in speziellen Situationen viell=
eicht
einen unsauberen Trigger für DOS mißbrauchen, aber dazu braucht man eig=
entlich
keine Trigger.

> 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 d=
ie
> Datenbank ausgeht, das von ihr keine Angriffe kommen, ist gefährlicher,=
als
> das Internet selber.

Ja, wenn der Apache-Prozeß sich in der DB einloggen kann - damit kann man=
dann
natürlich mehr anstellen, als der pure Postmaster, für den man keinen Z=
ugang hat.

Der Punkt ist eigentlich ein ganz anderer: man sollte *generell* nur solche=

Zugänge öffnen, die wirklich benötigt werden. Wenn die Clients direkt=
SQL
sprechen wollen, ist das nötig - bei einer reinen Web-Anwendung nicht (da=
sprechen
die Clients nur HTTP).


cu
--
------------------------------------------------------------ ---------
Enrico Weigelt =3D=3D metux IT service - http://www.metux.de/
------------------------------------------------------------ ---------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
------------------------------------------------------------ ---------

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Am Donnerstag 03 April 2008 09:10:51 schrieb Enrico Weigelt:
> > - Man kann erzwingen, das der Client sich nur mit ssl und md5 anmeldet
> > und jeder weitere Kommunikation abgeschirmt ist.
>
> Geht beim Apachen auch ;-P

Ich wüste nicht. Wenn du ein übel zusamen gestricktes PHP-Skript hast, =
was
Passwörter in Klartext abfragt, kann das Apache kaum verhindern.

Olaf

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D[ INFO ]=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D
Sie können meine .odt Dateien nicht öffnen? Dann ist (höchswarscheinl=
ich) ihr
Office Paket veraltet. Das .odt Dateiformat ist eine international anerkann=
te
ISO-Norm. Patchen sie ihr Office-Paket bitte mit einem Plug-in von Sun
(http://www.sun.com/software/star/odf_plugin/) oder installieren sie ein
Zeitgemäßes Office-Paket (http://de.openoffice.org)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Am Freitag 04 April 2008 15:06:27 schrieb Robert M=C3=BCller:
> Am 03.04.08 schrieb Olaf Radicke <olaf_rad [at] gmx.de>:
> > Am Donnerstag 03 April 2008 09:10:51 schrieb Enrico Weigelt:
> > > > - Man kann erzwingen, das der Client sich nur mit ssl und md5
> > > > anmeldet
> > > >
> > > > und jeder weitere Kommunikation abgeschirmt ist.
> > >
> > > Geht beim Apachen auch ;-P
> >
> > Ich w=C3=BCste nicht. Wenn du ein =C3=BCbel zusamen gestricktes PHP-Skr=
ipt hast,
> > was Passw=C3=B6rter in Klartext abfragt, kann das Apache kaum verhinder=
n.
>
> Klar, indem der Apache die Daten eben nur per https sendet und empf=C3=A4=
ngt.

Hmmm... Kann ja sein das ich M=C3=BCll schreibe, aber ich glaube https kann=
nicht
verhindern, das PHP-Skripten sich ver=C3=A4ppeln lassen mit "b=C3=B6sen" UR=
Ls, die dann
die selbst gestrickten Limitierungen umgehen. Es ist lustig was f=C3=BCr Re=
sultate
man bekommt, wenn man auf blauen Dunst ein bar URLs durch probiert. Das d=
=C3=BCrft
auch ein https nicht verhindern k=C3=B6nnen. Eine ungesch=C3=BCtztes Verzei=
chnis mit
sensiblen Daten ist dann meist nur der Anfang vom Ende. Auf was das
PHP-Skript wie antwortet, da hat Apache kein Einfluss.


Gru=C3=9F

Olaf

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

QW0gMDMuMDQuMDggc2NocmllYiBPbGFmIFJhZGlja2UgPG9sYWZfcmFkQGdt
eC5kZT46Cj4gQW0gRG9ubmVyc3RhZyAwMyBBcHJpbCAyMDA4IDA5OjEwOjUx
IHNjaHJpZWIgRW5yaWNvIFdlaWdlbHQ6Cj4KPiA+ID4gLSBNYW4ga2FubiBl
cnp3aW5nZW4sIGRhcyBkZXIgQ2xpZW50IHNpY2ggbnVyIG1pdCBzc2wgdW5k
IG1kNSBhbm1lbGRldAo+ICA+ID4gdW5kIGplZGVyIHdlaXRlcmUgS29tbXVu
aWthdGlvbiBhYmdlc2NoaXJtdCBpc3QuCj4gID4KPiAgPiBHZWh0IGJlaW0g
QXBhY2hlbiBhdWNoIDstUAo+Cj4KPiBJY2ggd8O8c3RlIG5pY2h0LiBXZW5u
IGR1IGVpbiDDvGJlbCB6dXNhbWVuIGdlc3RyaWNrdGVzIFBIUC1Ta3JpcHQg
aGFzdCwgd2FzCj4gIFBhc3N3w7ZydGVyIGluIEtsYXJ0ZXh0IGFiZnJhZ3Qs
IGthbm4gZGFzIEFwYWNoZSBrYXVtIHZlcmhpbmRlcm4uCgpLbGFyLCBpbmRl
bSBkZXIgQXBhY2hlIGRpZSBEYXRlbiBlYmVuIG51ciBwZXIgaHR0cHMgc2Vu
ZGV0IHVuZCBlbXBmw6RuZ3QuCgo+Cj4gIE9sYWYKR3LDvMOfZQpSb2JlcnQK
Ci0tIApTZW50IHZpYSBwZ3NxbC1kZS1hbGxnZW1laW4gbWFpbGluZyBsaXN0
IChwZ3NxbC1kZS1hbGxnZW1laW5AcG9zdGdyZXNxbC5vcmcpClRvIG1ha2Ug
Y2hhbmdlcyB0byB5b3VyIHN1YnNjcmlwdGlvbjoKaHR0cDovL3d3dy5wb3N0
Z3Jlc3FsLm9yZy9tYWlscHJlZi9wZ3NxbC1kZS1hbGxnZW1laW4K