[linux-l] Re: administrieren vieler Rechner

[Steffen Dettmer]

* Thomas Knop wrote on Wed, Feb 06, 2002 at 13:57 +0000:
> * Martin Kleinschmidt <mk at theochem.uni-duesseldorf.de> [06.02.02]:
> >> > Ansonsten saehe mein Ansatz wie folgt aus:
> >> > jeder Rechner guckt per cronjob ab und an nach, ob in
> >> > einem ueber NFS gemounteten Verzeichnis ein neues script
> >> > aufgetaucht ist und fuehrt das dann aus.
> >> > Gibts da gravierende security-bedenken?
> >> Ja.
> >> Wenn es um Konfigurationen geht, werden meist root-Rechte benötigt.

Ja, wenn der Server kompromitiert wird, oder ein Client, der da
schreiben darf, hat sich Dein Netz erledigt.

> >> In einem per NFS gemountetem Verzeichnis muss man sehr vorsichtig mit
> >> ausführbaren Dateien sein (erlangt ein Einbrecher root-Rechte auf dem
> >> NFS-server, kann er sie auf allen Clients erlangen).

Man kann auch auf noexec gemounteten Verzeichnissen Programme und
natürlich Scripte ausführen. Das Problem sehe ich hier aber bei
den Schreibberechtigungen. Ist das Verzeichnis als ro exportiert?

> >Richtig.
> > 
> >> besser:
> >> + Benutzer "update" sieht per cronjob regelmäßig im NFS Verzeichniss nach
> >>   und kopiert Installationsdateien unter seiner uid:giu nach /install
> >> + Benutzer "install" führ in einem später laufendem cronjob die Skripte
> >>   mit sudo als root aus.
> >
> >Inwiefern ist das denn jetzt besser?
> a) Das NFS Verzeichniss kann mit "noexec,ro" gemountet werden.

Es muß mit ro exportiert werden, sonst reicht ja ein remount,rw.

> b) Trennung von Ausführung/Kopieren. Nur Benutzer "update" darf 
>    nach /install schreiben.

Was nützt das? Dann kann ich ihm immernoch Problemlos ein
manipuliertes Script unterjubeln, ob's nun vorher kopiert wird,
oder nicht...

> >Es kann doch immer noch ein kompromittiertes script sein,
> >das er dort gefunden hat.
> Dazu muss der Angreifer aber weit mehr "durschauen" als
> /etc/exports; während er bei einem "exec" gemountetem NFS nur einen
> einzigen beliebigen Benutzer auf jedem Client erraten muss um auch
> auf dem Client root zu werden.

Verstehe ich nicht. So bald er da irgentwie ein Script hinkriegt,
was irgentwann irgentwie als root gestartet werden wird, hast Du
verloren, so oder so.

> >>   ssh root@$client /root/tmp/install.sh 2>&1

So in etwa mache ich das auch meistens. Leider reagieren meistens
die Clients oft genug mit Fehlern, so daß man dann doch wieder
per Hand an einzelne muß. Aber solange man es wenigstens noch
merkt, ist ja alles in Butter!

> >Wenn ich das interaktiv mit password-authentication mache, 
> >spare ich nicht viel an Aufwand.
> Na ja, immerhin musst Du nur noch 10 x 2 passwörter eingeben.

ssh-agent. Keine Passwörter. Nur Keys. Einmal Passphrase
eingeben, und auch noch sicherer.

> >Und wenn ich es mit public-key mache, habe ich wieder
> >das problem, dass eine kompromittierte Maschine
> >reicht um alles lahm zu legen.

Der secret Key muß natürlich gut verschlüsselt sein, und
vorzugsweise auf einer Disk gespeichert sein, die man nur bei
Bedarf ins Laufwerk schiebt. Ein Hacker kann nicht so ohne
weiteres remote ne Disk einlegen. Aber leider kann er natürlich
warten. Aber dann braucht er viel Wissen. Lokal kann man den Key
aber sowieso kompromitieren, in dem man z.B. ssh-agent trojaned.
Also kein Nachteil.

> Richtig, dafür sollte man eine Admin-Maschine benutzen, die nur
> von der Console bedient werden kann, _keine_ Verbindungung
> zum Internet hat und _keine_ Verbindung vom Intranet zuläßt.

Wie adminisiriest Du dann? Oder hat keine Deiner Maschinen eine
Verbindung ins Internet?!

> Regelmäßiges ändern der SHH2 Schlüssel sollte ebenso durchgeführt
> werden.

Und vor allem: gute, lange, sehr zufällige Passphrases,
vorzugsweise mit Keygenerator und 12 Zeichen lang oder sowas.
Triviale Passphrases sind übner dictionary attacks schnell zu
knacken.

> >dies anders zu machen. Wenn es denn eine automatisierte 
> >Wartung sein soll, muss man wohl damit leben, dass 
> >von einem System aus alles offen liegt, oder?
> Ja.
> Ich bevorzuge überigens die SSH Methode.

Genau aus dem Grund würde ich es nicht komplett automatisieren.
Mit der SSH Methode muß der "Anstoß" manuell erfolgen, und man
kann da gucken und so, finde ich sicherer als voll automatisch.
Voll automatisch kann natürlich auch für voll automatische Hacks
benutzt werden...

oki,

Steffen

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