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

[Steffen Dettmer]

* Peter Ross wrote on Wed, Nov 24, 2004 at 12:24 +1100:
> Steffen Dettmer wrote:
> > Die sich dann um Port 80 prügeln :)
 [...] 
> Du hast also einen Reverse Proxy davor, 
 [...] 

Ahh ja, das ist gut.

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

Ausgehende Verbindungen blocken ist ja auch nicht so einfach,
wenn wir schon mal bei dem Thema sind. Man kann natürlich nach
SYN filtern, aber man muss ja nicht unbedingt TCP verwenden. Man
kann ja z.B. TCP RST Pakete schicken oder so. Irgendwas wird
bestimmt ankommen. Aber ist ja auch wurst, wenn die Angreiferin
erstmal so weit gekommen ist...

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

Ja, was will er auch damit. Obwohl die ja Firewall.., nein!,
Paketfilterregeln ja auf einem anderen Host sind. Der
Reverse-Proxy-Firewall-Teil könnte ja auch auf einer anderen
Maschine laufen. Da kann man fix einen Haufen Server verbraten
:-)

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

Wie macht er das eigentlich?

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

Wenn der Angreifer ein Binary verändern /könnte/, kann er
sicherlich auch irgendwie ne Datenbankverbindung aufbauen, ohne
dass er die Binaries ändern müsste, oder? Also, warum sollte er
Binaries ändern? Gut, so kann er kein rootkit einspielen, aber
die Daten hat er eh (evtl. modifiziert)... Seh jetzt so den
grossen praktischen Vorteil nicht so. Ich mein, wenn sie gehakt
> > 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.

Ist doch egal, das jail muss doch die Datenbankverbinung
erlauben! Damit will doch ein Datenbankangreifer überhaupt nicht
aus dem Jail ausbrechen. Und mySQL gab IIRC kaum Mechnismen für
effektive Zugriffberechtigung her (keine StoredProcedures), ist
also ungeeignet für sowas. Also kann man nur Daten
reinschmeissen, wo's egal ist, wenn die jemand ändert oder
manipuliert. Vielleicht ein Gästebuch (was manche ja aus
irgendwelchen Gründen über eine DB lösen müssen ;)). Aber dann
ist ja die Datenbank nicht mehr schützenswert und wir haben ein
anderes Thema. Finde ich. Sprich, ich find sehr wichtig, dass man
erstmal weiss, wovor man eigentlich was schützen will. Ob dann nu
Firewall oder dies sieht man ja dann erst richtig.

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

Wenn da ein typischer PHP-Bug, ähh, PHP-Script mit drauf ist, was
malicious code injection ermöglicht, ist das dann aber egal. Ist
ja weniger schlimm, ein /sbin/ifconfig zu "verlieren" (solange es
noch geht), als die Datenbankdaten zu "verlieren" (wenn die
schützenswert sind). 

Jail und so sind ja alles nur Mittel zum Zweck, kein Selbstzweck. 

Man gewinnt teilweise (nicht hier!) den Eindruck, vieles an
Sicherheit wird nur gemacht, weil "man das so macht". Also
Paketfilter hier, chroot dort und nu ist's sicher und alles fein.

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

Jetzt hat schon jeder User eine eigene Datenbank :-) Aber ist ja
auch egal, als beispiel reicht ja ein User, ein Apache und eine
Datenbank (so hatte ich das Ursprungsposting verstanden).

Das wird langsam ein künstliches Beispiel, a la Strato oder so,
die sogenannte Datenbanken für Leute anbieten, die sie gar nicht
brauchen. Hier ist natürlich ein Jail sehr prima, weil man viele
Kunden auf eine Maschine packen kann. Aber so ein Gästebuch
braucht IMHO eingentlich keine DB, da kann man das Filesystem
nehmen. Na ja, egal.

In sinnvollen Anwendungen hat man vielleicht einen Webshop. Wer
die Datenbank manipulieren könnte, könnte sicherlich
"Bestellungen" einschummeln: erzeugt Arbeit, kostet Geld und kann
peinlich gegenüber dem Kunden werden. Wenn die Datenbank
orginal-Daten hat, Userdaten beispielsweise, wäre es zudem sehr
doof, wenn der Hacker z.B. 10% der Userdaten ändert, oder 1%
jeden Tag. So, dass man es erst später merkt und dann kein Backup
mehr einspielen muss, sondern per Hand ranmuss oder gleich
aufgeben kann :-)

Ob da nu ein /sbin/ifconfig trojaned ist... Macht ja nix. Wenn
man es merkt, kann man i.d.R. noch ein Backup der Daten ziehen
(bzw. die Festplatte aufheben, man weiss ja nie) und in aller
Ruhe einen neuen Server bauen. Der alte läuft dann eben noch
einen Tag, selbst das ist relativ egal.

Klingt immer so schlimm, aber was passiert denn, wenn ein hacker
/bin auf so einer Kiste schreiben kann? Er ist ja sicherlich
i.d.R. daran interesiert, den Server nicht ganz kaputtzumachen.
Dann kann man den Austauschen. Bei Webservern sollte man eh schon
ne "fertige" Reserveplatte im Schrank haben. Dann einfach updates
drauf, ggf. Datensicherung einspielen, Platte tauschen, booten
und bis zum nächsten Mal :)

> Das ist naehmlich der wunde Punkt vieler
> Webhosting-Implementationen, die alle zur gleichen DB-Instanz
> verbinden. 

Ja, das ist der eine Spezialfall, genau. War das unser Thema? Na
ja, auch egal, war IMHO nicht uninterssant. In so einer
Konfiguration hat man natürlich auch n User auf einem Server, ja.

Obwohl, ich glaub, wenn man n User auf einen Server samt
Datenbank fahren kann, braucht man keine Datenbank :-)

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

... Anforderungsanalyse, Dokumentation, ...

Na ja, könnten wir sicherlich noch ne Weile fortsetzen, die Liste
:-)

Ach so: und Kaffee gehört dazu. Nix ohne guten Kaffee :-)

oki,

Steffen

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