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

[Peter Ross]

Steffen Dettmer wrote:
>> Du spendierst jedem user ein jail, d.h. jeder bekommt auch
>> seinen Apachen.
>
> Die sich dann um Port 80 prügeln :)

Ein jail apache hat keinen direkten Zugriff auf externe Ports (jedes Jail
bekommt eine eigene interne IP).

Du hast also einen Reverse Proxy davor, z.B. pound. Der kann, muss aber
nicht im jail laufen (in dem fall sorgt eine forward-klausel im Firewall
des Hostsystems dafuer, dass er die ankommenden Pakete bekommt.)

>  Ja, falls das die Aufgabe
> ist, ist das schöner auf multi-user-spielservern. Allerdings
> schnell recht aufwändig denke ich...

Eigentlich nicht. einmal geskripted, ist so ein jail schnell aufgesetzt.
Es ist beim ersten Mal praktisch eine basissystem-Installation mit
minimalen Satz von Binaries, die statt in / in /usr/jail anfaengt.

Die echten jails mounten von da read-only und bekommen ihr eigenes /etc
und /var spendiert.

>> 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 :-)

Nicht wirklich. Ein WWW-Server erlaubt nur eingehende Port
80-Verbindungen, ausgehende Verbindungen sollte jeder vernuenftig
aufgesetzte Firewall blocken.

Die Firewallrules laufen auf dem host und nicht im jail und sind so dem
Hacker selbst nach dem Einbruch nicht zugaenglich.

Also ist der einzige "Eingang" der Apache, vor dem der pound laeuft, der
u.a. auch "malicious" SQL-Statements aussortiert.

Die Binaries des Hosts, die der erfolgreiche Hacker sieht, sind nicht die
des Jails. anyway, beide sind read-only gemountet und ausserdem mit
chflags(1) versehen. Da der Securelevel 3 ist, gibt es keine Chance das zu
aendern - die Binaries sind auch fuer root nicht schreibbar! (Das geht nur
durch reboot im Single-User-Mode, dann ist der Rechner nur noch ueber die
Konsole erreichbar).

> 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...
>
> Eine kompromitierte Datenbank zu schützen ist
> jedenfalls weniger sinnvoll ;)

Die Datenbank liegt nicht auf dem Rechner, ist lediglich ueber die
host(pound)->jail(apache)->DB(irgendwo anders) zugaenglich.

Gut, dafuer, was die CGI-Skripte dann tun, muss der Verwickler
geradestehen. Aber ich gebe ihm mit meinen Admin_massnahmen schon eine
gewisse Sicherheit.

U.a. auch, dass ein Nutzer keine Daten eines anderen sieht, da er auf
dessen DB-Server keinen Zugriff hat.

Das ist naehmlich der wunde Punkt vieler Webhosting-Implementationen, die
alle zur gleichen DB-Instanz verbinden. Mit den von Dir angesprochenen
Grants-Schludrigkeiten (wie haeufig habe ich ein Grants 'all for all'
gesehen, weil der Entwickler irgendwie Zugriffsprobleme hatte) ist das
dann schnell ein Problem.

Sicherheit ist nichts, was genial mit einem Tool erledigt wird. da gehoert
viel zusammen, Sandboxen, dedicated Server, Reverse-Proxy, Firewall-rules,
Filesystem-Restriktionen etc.

Gruss
Peter