[linux-l] FTP-Server konfigurieren (resent)

[Steffen Dettmer]

(sorry, meine Mailconfig ist leider dämlich)

 [...] 

* Peter Ross wrote on Tue, Nov 23, 2004 at 15:42 +1100:
> Steffen Dettmer wrote:
 [...] 
> >
> > Aber wenn Du mod_php hast, gibt's da praktisch eh nur einen
> > Account und Policies und Co. machen ja dann nur Sinn, wenn
> > man entweder allein ist oder viel Vertrauen hat - weil am
> > Ende ja nur ein "apache" User da ist. Natürlich
> > nett, das wenigstens in ein chroot zu packen, 
 [...] 
> 
> Du spendierst jedem user ein jail, d.h. jeder bekommt auch
> seinen Apachen.  

Die sich dann um Port 80 prügeln :) Ja, falls das die Aufgabe
ist, ist das schöner auf multi-user-spielservern. Allerdings
schnell recht aufwändig denke ich...

> Ein Hacker sieht nur das jail und nicht die Hostmaschine. Wenn
> dann z.B.  alle Binaries vom Hostsystem kommen, und in das jail
> read-only gemounted ist, ist da Schluss fuer den Hacker.
 [...] 
> Alles, was der Hacker vernichten kann, wenn es sinnvoll
> konfiguriert ist, sind die Nuterdaten. 

Ja, eben! Er kann Daten spionieren und sogar verfälschen. Gut, er
kann die Systemkonfiguration nicht ändern (wozu auch, geht ja
höchstens was kaputt, der Admin sorgt ja schon dafür, dass die
Kiste läuft). Na ja, vielleicht wird der Gebrauch als
Warez-Server verhindert (falls es quota oder sowas gibt, und das
jail hält), aber wie Du ja selbst sagst, sind solche Büchsen
relativ schutzlos...

> Neues jail zur Verfuegung stellen, Schwachstelle schliessen,
> Daten aus dem Backup holen - fertig.

Jo, zufällig merkst Du eines Tages, dass da ein Hacker drauf ist,
weil Du ein Script findest, dass Datenbankänderungen in einen IRC
channel postet. Kann seit zwei oder vier Wochen sein. Wenn die
Datenbank (mySQL mein ich jetzt) orignal-Daten hatte war's das
möglicherweise: vier Wochen altes Backup ist schon /sehr/ alt und
vielleicht ist auch das schon manipuliert... Auch wenn man
/bin/bash noch von CD holen kann :-)

Ich mein, der ganze Kram dient ja gerade dazu, die Daten zu
schützen. Das System muss ja nur geschützt werden, weil man sonst
die Daten nicht schützen kann. Wenn die Daten aber nicht sicher
sind, weil man z.B. mySQL Zugriffsprivilegien nicht restriktiv
genug definieren konnte oder es vergessen hat (denke mal, dass
mySQL inzwischen wenigstens rudimentäre Trigger und Rules hat,
die userabhängig Sachen verbieten können), kann der Angreifer ja
logischerweise diese manipulieren. Und dann ist's doch auch egal,
ob das System selbst nun sicher ist, oder nicht: Worst Case ist
ja bereits eingetreten...

> Klar ist es eine Frage, ob man den Aufwand haben will und fuer
> wen. Das zu designen, ist aber gar nicht so schwer. Man muss
> nur wissen, was man tut (und wenn Du nicht weisst, was Du tust,
> dann tue es mit Eleganz;-)

... und professionell natürlich :)

> Geteilte Webserver mit virtual hosts und geteilten
> Datenbank-Backends sind aber relativ schutzlos und ausserhalb
> der privaten Bastelstunde eigentlich eine Suende. 

:-) Genau, und bei Schutzmassnahmen muss man IMHO nicht nur
wissen, was man tut, sondern man muss vor allem wissen, warum man
es tut... Eine kompromitierte Datenbank zu schützen ist
jedenfalls weniger sinnvoll ;)

> Dass es trotzdem so etwas gibt und darauf gelegentlich sogar
> sensible Geschaeftsdaten liegen, naja..

Nix sensibles, bloss die Schwarzgeldbuchhaltung,
Schmiergeldkonten und die "Fonds für illegale Geschäfte" :-)

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.


----- End forwarded message -----
oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.