[linux-l] Scanner unterwegs

[Sven 'Rae the Git' Grounsell]

Steffen Dettmer <steffen at dett.de> wrote:

> * Sven 'Rae the Git' Grounsell wrote on Sat, Sep 11, 2004 at 13:55
> +0200:
> > 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.

> > 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?
Sorry, das ist der groesste Humbug, den ich je gelesen habe ;o)

> > > > Das ist zugegebenermassen keine Hilfestellungen fuer ein
> > > > bereits geknacktes System, aber es verhindert dennoch recht
> > > > zuverlaessig
> > > 
> > > Zuverlässig? Na, reicht ja manchmal, wenn ein Patch fehlt...
> > 
> > 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.
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.

> ich glaub, solange man keinen "groben Unfug" macht, ist die RSA
> Schlüssellänge weniger ein Sicherheits-Problem.

Du hast nicht verstanden, worauf ich hinauswollte.
Ich habe nirgends behauptet, dass die Schluessellaenge ein konkretes
Sicherheitsproblem ist, sondern sie hilft, ein _Risiko_ zu minimieren.

Desweiteren minimiert DSA statt RSA das Risiko noch weiter... RSA =
ssh1, DSA = ssh2

> > > > Aehnliches fuer die Zukunft und schliesst ssh in weiten
> > > > Teilen als schwaechsten Punkt aus.
> > > 
> > > Ja, ich glaub, es reicht wenn man 10% sicherer ist, als der
> > > Durchschnitt, weil die anderen dann die Script-Kiddies
> > > beschäftigen... :)
> > 
> > s.o.
> > 100%ige Sicherheit ist per Definition unmoeglich -
> 

> 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!)"
etc
pp

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

> > > Also, um mal zu meiner eigentlichen Frage zu kommen: ihr macht
> > > dann Administration per `ssh <user>' und `su', ja?
> > 
> > Natuerlich, ich erlaube doch keinen ungesicherten Root-Zugriff
> > per Internet - dann kann ich auch Deiner Argumentation zufolge
> > gleich einen telnetd laufen lassen
> 
> 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.

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.

> Ausserdem bin ich nach wie vor der Meinung, dass das `su' da
> nicht so wahnsinnig viel bringt. Vielleicht hat dieser User gar
> `.' im Pfad, weil das meintwegen SuSE so defaultmässig macht oder
> weiss ich was. 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.
Ausserdem aendern wir guten Admins unser root-Passwort ja auch in
regelmaessigen Abstaenden *Augenlid runterzieh*

> > Was willst Du denn da automatisieren?
> > Was nicht per CronJob erledigt werden kann, kann man auch grad
> > noch von Hand machen... oder man schreibt ein Script, welches root
> > gehoert udn nur von diesem ausgefuehrt werden kann (Script
> > wiederrum heisst, dass es in der meisten Faellen auch per Cron
> > ausgefuehrt werden kann)
> 
> 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."
Genau deswegen geht der Standard-WinXP-Benutzer auch grundsaetzlich
mit Administrator-Rechten ins Netz.

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

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

Gruss,
Sven

-- 
http://www.tuxhilfe.de/
sven at tuxhilfe dot de