[linux-l] Scanner unterwegs

[Steffen Dettmer]

Hi,

sorry, war krank, daher die unglaublich späte Antwort :)

* Sven 'Rae the Git' Grounsell wrote on Sat, Sep 11, 2004 at 17:21 +0200:
> > * Sven 'Rae the Git' Grounsell wrote:
> > > Fatal ist es, daraus den Umkehrschluss zu ziehen und nach
> > > dem aktuellen Vorbild der T-Com zu sagen, dass der User per
> > > Vertrag verpflichtet ist, seinen Kram sicher zu halten, 
> > 
> > Na ja, aber dass muss man schon auch machen, zumindestens
> > formal.  Das kann bei der komischen Gerichtsbarkeit sonst
> > evtl. zu interessanten Schadensersatzforderungen kommen.
> > Diese "Expertenverantwortung" zwingt eine Firma IMHO dazu.
> 
> Aus dem Zusammenhang gerissen.
> Ich habe Beispiele mitgeliefert, die auch die T-Com ohne weiteres
> aendern kann, die ein Minimum an zweifelhaftem Komfort zunichte
> machen, jedoch ein erhebliches Mehr an Sicherheit bringen wuerden.

Ja, aber das ist dann eben ein anderes Business-Modell. Man kann
das jedenfalls so anbieten - muss ja keiner kaufen. Weil es aber
etwas billiger ist (wenn auch nicht unbedingt preiswerter),
lieben die Kunden das. Geiz ist ja geil.

> > > aber ich ihm meinerseits keine Methoden an die Hand gebe,
> > > die aufoktruierte Sicherheit auch konsequent nutzen zu
> > > koennen
> > 
> > Man kann ihn ja vertraglich verpflichten, dass er diese
> > Möglichkeiten selbst schaffen bzw. einkaufen muss.
> 
> Moment, Du behauptest ernsthaft, dass es folgendermassen aussehen
> soll?
> Ich kaufe eine Leistung eines Anbieters ein, schliesse damit
> einen rechtsgueltigen Vertrag ab, der mich verpflichtet,
> weitere Leistungen einzukaufen, damit ich den Vertrag nicht
> verletze?

Ja, so in der Art. Es gibt ein an Bedingunen gekoppeltes Angebot.
Das kannst Du annehmen (Vertrag) oder eben auch nicht. Ist ja
normal. Wenn Du ne Fluglinienlizenz erwirbst, musst Du
bespielsweise viele gesetzliche Auflagen erfüllen und dazu
vermutlich Leistungen einkaufen - Pilotenausbildungen vielleicht.
Wenn Du im Besitz einer Waffenbesitzkarte bist, und eine Waffe
kaufst, musst Du für geeignete, verschliessbare und nicht ganz
billige konforme Waffenschränke btw. Transportboxen sorgen - die
musst Du i.d.R. dann kaufen. In diesen Fällen muss der Verkäufer
das nichtmal vertraglich festlegen, das gesetzlich schon klar
ist. Oft hat aber der Anbieter seine Verträge (oder Ordungen oder
Gesetze) zu erfüllen, so dass er sich seinerseits eben
vertraglich absicheren muss. Du musst das Angebot ja nicht
wahrnehmen.

> > > Da bin ich als Admin in der Verantwortung und habe regelmaessig
> > > aktuelle Pakete und Patches einzuspielen.
> > 
> > Wenn Du das immer selbst machst, ok. Was viele wohl ungern
> > bezahlen. Egal, aber ich glaub, der Admin ist typischerweise das
> > grösste Sicherheitsrisiko, weil man eben schnell was falsch
> > macht.
> 
> Genau dazu nimmt man einen Admin her, wenn man es nicht kann - er wird
> dafuer _bezahlt_, zu wissen was er tut... und wenn er schnell was
> falsch macht, ist er schlichtweg im falschen Beruf; klingt hart, is
> aber so.

Ja, ich finde auch, dass viele Admins im falschen Beruf sind.
Trozdem weiss es Mensch nie /wirklich/ was er tut, beispielsweise
weli er ja nicht den Patch im Detail prüfen kann. Wie Du ja
selbst sagst, macht man ja eh nur Risk Management.

> Wenn ich mich allerdings umsehe, was sich so an
> "Freizeit-Providern" etc Admin schimpft, wundert mich auch
> nichts mehr... d.h. doch, es wundert mich, dass deren Geraffel
> immernoch funktioniert.

Ja, genau so seh ich das auch!!

> > Der Durchschnittsvirus ist blöd, einfach, schlecht
> > getarnt, lieblos entwickelt, schlampig programmiert und
> > ineffizient - und infiziert trozdem Millionen von Hosts :-)
> 
> Ja, weil immernoch 90% (oder was weiss ich wieviele, auf jeden Fall
> ist diese Groessenordnung realistisch) so argumentieren:
> "Ach, wer will denn schon an _meine_ Daten"
> "So wichtige Sachen hab ich auch nicht, dass sie niemand wissen darf"
> "Je mehr Aufwand ich betreibe um meinen Rechner zu schuetzen, um so
> interessanter ist er doch fuer Hacker (sic!)"

Ja, und ich möchte noch den IMHO häufigen Fall hinzufügen, dass
eben überhaupt nicht argumentiert oder nachgedacht wird. Anders
ist IMHO z.B. nicht erklärlich, warum es teils nichtmal
brauchbare Backups gibt etc.

> Und solange diese Meinung standard ist, werden Viren und sonstige
> Malware nicht "besser" programmiert werden... warum auch? Man kommt ja
> auch so ans Ziel.

Grünau.

> > Das ist natürlich Blödsinn, entschuldige mal. Zwischen `telnet'
> > und 1024 bit RSA liegen ja wohl Welten!
> 
> Da hast Du wahr, aber RSA ist immernoch ssh1 und die
> 1024bit-Schluessel hast du nicht explizit mit diesem Szenario in
> Zusammenhang gebracht... bzw. habe ich diesen Zusammenhang nicht
> hergestellt.

Sicher, aber ich wollte auf etwas anderes hinaus. Mit gegebenen
Mitteln (Geld, Zeit, ...) soll die Sicherheit maximiert werden.
Hier ist es IMHO sinnvoll, telnet zu verhindern und Patches
einzuspielen. Das bringt sagen wir mal "10" Sicherheit (was auch
immer 10 für ne Einheit hat). DSA anstatt RSA bringt dann IMHO
bloss 1 zusätzlich. Ist natürlich besser als 0 zusätzlich, aber
wenn man den Aufwand an anderen Stellen investiert, mag man damit
2 oder 5 erhalten. 

Sicherlich siehst Du das genauso, und es macht IMHO kaum noch
Sinn, dass wir diskutieren, wo wir doch einer Meinung sind :)

> Und ich bleibe dabei, dass es vom Aufwand her keinen grossen
> Unterschied macht, ob da jetzt ein telnetd lauscht oder ein
> sshd mit root- und Passwort-Login.

Wenn Du sniffen kannst, ist der Unterschied enorm. Da viele
Angriffe "von innen" kommen und es gut automatisierte
Sniffertools gibt, widerspreche ich Dir hier und behaupte, dass
sshd hier trozdem wirkungsvoll gegen einige Angriffe schützt
(10).  Natürlich schützt ein RSA Schlüssel noch besser (15), und
ein DSA Schlüssel (Proto2) noch besser (16). Bitte nicht um 16
oder 17 streiten ;) Du weisst ja, was ich meine.

> > Dann kann ein Angreifer das `su' ganz einfach manipulieren
> > und hat dann auch noch das root-Klartext-Passwort...
> 
> Na aber die Huerde ist ja, ueberhaupt erst auf das System _rauf_ zu
> kommen. Wenn ein Angreifer Zugang zum System bekommt, egal ob als User
> oder root, gilt das System fuer mich als kompromittiert.

Genau, seh ich auch so. Leider findet sich oft ein Weg für local
priviledge escalation. Daher kann man ja auch fast auf's `su'
verzichten, finde ich.

> Ausserdem aendern wir guten Admins unser root-Passwort ja auch in
> regelmaessigen Abstaenden *Augenlid runterzieh*

:) Natürlich :)

Gilt natürlich genauso für SSH Keys *Augenlid auch runterzieh*

> > Ja, und wie installierst Du dann Dein Script? Machste dann
> > stundenlang ssh hierhin, su, scp (vielleicht sogar zweifach, weil
> > direktes SSH nicht geht), starten, logout, logout und von vorn:
> > ssh dorthin.... Da geht man ja kaputt... 
> 
> "Security may not be bought, but that doesn't mean it's for free!"
> Du argumentierst hier letztlich M$ in die Arme - "Sicherheit ok, aber
> bloss nicht auf Komfort verzichten."

Nein, ich binde Sicherheit nur an den Schlüssel, was ja das ist,
wofür man Schlüssel hat. Ob da noch ein su kommt oder nicht, ist
IMHO schon fast ne "security through obscurity" Anwendung. Na
gut, das ist übertrieben, klar. Entweder traut man dem Schlüssel
und kann das machen, oder man traut ihm nicht und kann auch kein
user+su machen, finde ich.

> Genau deswegen geht der Standard-WinXP-Benutzer auch
> grundsaetzlich mit Administrator-Rechten ins Netz.

Nicht alles, was hinkt, ist ein Vergleich! :-)

> > Das Beispiel ist jedenfalls nicht schlecht: auf alle Server
> > ein Script kopieren und als root starten. Oder auf allen
> > Maschinen ein bestimmtes RPM deinstallieren (sowas brauchte
> > ich persönlich öftermal).
> 
> Du kannst in einem Script auch den Befehl ssh und scp
> verwenden, deswegen muss noch _lange_ nicht auch das Passwort
> im Script auftauchen (oder in einem seiner Includes).

Wenn ssh nicht root werden kann, kann es auch kein RPM
installieren. Wenn ich `su' brauche, braucht das Script ein
Passwort. Wenn man RPM Installation per sudo erlaubt, hat man
IMHO nix gewonnen, weil das ja eine Angreiferin auch wieder
ausnutzen kann.

> Script starten, bei Bedarf die Passwoerter angeben, und um den
> Rest brauchst Du Dir keine Gedanken machen.

Ja klar, dann geb ich 20 mal verschiedene root-Passwörter ein...
Prima, genau dafür sind Computer entwickelt worden. SCNR.

:)

Schönes Wochenende!

oki,

Steffen

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