hack

[captaincrunch]

Ich bin der Meinung, dass man auch ohne solche Dinge einen Rechner "sicher genug" konfigurieren kann - vorausgesetzt, man hat den dazu nötigen Clue.

Hehe, genau das haben sich die Debian-Jungs vor dem Einbruch auch gedacht. Sorry, ich hab heut meinen zynischen Morgen, ist einfach zu früh. ;)

Mal ernsthaft: anhand dieses doch sehr plastischen Beispiels wurde mir (für meinen Teil) deutlich, dass man als "Unbeteiligter", der nicht jede einzelne Zeile Code seines Systems auf Lücken selbst geprüft hat trotz einer sehr gut durchdachten Konfiguration trotzdem Opfer eines Angriffs werden kann. Sachen wie diese wird man jedenfalls nicht zum letzten Mal gehört haben, wobei ich kurz daran erinnern möchte, dass es auch die Gentoo-Jungs kurze Zeit später getroffen hat.
An beiden Stellen waren jedenfalls Admins am Werk, die ihr Handwerk normalerweise sehr gut verstehen. Genutzt hat es trotzdem nichts, ab und zu sind die "bösen" halt mal schneller.

Daher plädiere ich (spätestens seitdem) für proaktive Lösungen, die sich nicht darauf verlassen, dass Bugs schnell genug gefunden, und rechtzeitig gefixt werden, bevor irgendein pickliges, 12-jähriges Kiddie hunderte Rechner crackt, sondern einen Großteil der "Angriffe" von vornherein ins Leere laufen lassen.
Worin ich allerdings 100%ig mit deiner Meinung übereinstimme ist, dass man wenigestens ansatzweise verstehen sollte, worum es bei gewissen Patches geht, alleine PaX für sich alleine ist keine allzu leichte Kost. Die Gefahr, sich durch ein fälschliches Gefühl von "Sicherheit" selbst ins Knie zu schießen ist extrem groß. Wer denkt, GRSecurity macht ihn per default "sicher", hat das Konzept dahinter wohl nicht verstanden.

Mal ganz nebenbei bemerkt wird IMHO mittlerweile auch in Debian-Kreisen immer mehr über solch zusätzlichen Schutz nachgedacht. ;)

Auch von mir noch mal ein dickes Dankeschön für das hartnäckige, aber sehr gute Nachhaken.

[Joe User]

Daher plädiere ich (spätestens seitdem) für proaktive Lösungen, die sich nicht darauf verlassen, dass Bugs schnell genug gefunden, und rechtzeitig gefixt werden, bevor irgendein pickliges, 12-jähriges Kiddie hunderte Rechner crackt, sondern einen Großteil der "Angriffe" von vornherein ins Leere laufen lassen.

Genau hier setzen unter Anderem PIE und ProPolice an, siehe auch ftp://twocents.mooo.com/pub/hcc/propolice/propolice.txt.
Nachteil(?): Das komplette System muss mit PIE/ProPolice-Support kompiliert werden.

[dodolin]

Hehe, genau das haben sich die Debian-Jungs vor dem Einbruch auch gedacht.

Moment mal: ;)

Das Problem dort entstand _zuerst_ mal dadurch, dass irgendein User-Account gehackt wurde (vermutlich durch Passwort-Sniffen, IIRC). Erst dadurch konnten sie überhaupt ihren do_brk() Exploit anwenden. Wenn man fremde User mit vollwertigen Accounts hat, ist man _immer_ darauf angewiesen, dass dieser User "sorgfältig" mit diesem Account umgehen. Da trifft den Admin IMHO nur sekundäre Schuld.

[captaincrunch]

Mir ging es nicht darum, dem Admin die Schuld "in die Schuhe zu schieben". Kernaussage sollte eigentlich sein, dass es auch bei einem sauber gewarteten System immer noch ein nicht zu vernachlässigendes Sicherheitsrisiko gibt...jedenfalls so lange ich als Admin mir nicht (wie gesagt) jede kleinste Zeile Code durchgesehen, für gut befunden, und kritische Lücken gestopft habe.

Natürlich "reicht" ein vernünftig aufgesetztes, gut administratiertes System in 99% der Fälle aus, durch geeignete Maßnahmen (s.o.) lässt sich die Latte für potenzielle Angreifer noch erheblich höher legen.

[smur]

Dann geb ich auch mal kurz meinen Senf dazu: auch die do_brk() Lücke wurde von einem "white-hat" gefunden. Leider wurde diese Lücke falsch eingeschätzt und als unkritisch bewertet. Das führte dann leider zu dem hack.

[dodolin]

auch die do_brk() Lücke wurde von einem "white-hat" gefunden. Leider wurde diese Lücke falsch eingeschätzt und als unkritisch bewertet.

Ja, stimmt. Ich hatte mich etwas missverständlich ausgedrückt. Einigen wir uns vielleicht so: Die oder der Black Hat(s) haben zuerst das Missbrauchspotenzial hinter diesem Fehler gefunden. Einverstanden? ;)

[smur]

*g* is eigentlich eh egal. Aber einverstanden ;)

[rootmaster]

bzgl. do_brk()
imho konnte keiner der erwähnten kernelpatches den bug wirklich verhindern ;)
letzten endes kann es bei sicherheitsrelevanten daten nur über 100%ige zugriffskontrolle gehen; d.h. es dürfen nur die leute zugriff haben, die auch die vertrauensstellung für die daten haben (damit sind eigentlich alle öffentlichen server ausgeschlossen)
die patches helfen natürlich erhöhte sicherheitsrichtlinien (die in den meisten fällen von webapplikationen nicht gegeben sind ;)) auf systemebene umzusetzen (zb role-konzept bei rsbac) und erweitern den vanilla-kernel auch um viele weitere wichtige funktionen.
proaktiver schutz ist wichtig, doch das eigentliche sicherheitsbewusstsein setzt imho dort an, wo man von dem "worst-case" ausgeht; d.h. man geht davon aus, dass sein system gehackt werden kann ! dann ist es wichtig, dies früh zu erkennen und schnell zu reagieren. und wenn die daten wirklich "top secret" sind, dann verwendet man i.a. sicherheitskaskaden, die weniger als ein undurchdringbarer schutzwall als ein signalsystem zu betrachten sind, um rechtzeitig eingreifen zu können, bevor direkter zugriff auf die daten möglich ist resp. um den schaden zu minimieren helfen.
eine solche (etwas) simple alarmstufe wären zb. downloads über den webserver. man kann natürlich jedes file scannen lassen und darauf hoffen, die bad files zu entdecken oder man kann versuchen zugriffe auf entsprechende binaries wie wget & co zu unterbinden (was natürlich nicht wirklich hilft). all das wäre "proaktiver schutz" ;) jedoch besser wäre es eben, downloads über den webserver zu observieren, dann identifizieren und gegebenenfalls dann zu reagieren, freilich automatisiert in einem intrusion detection system 8)
das problem hierbei ist nur im allgemeinen, dass letzteres relativ aufwendig und zum teil (noch) nicht automatisierbar ist, was erhöhten aufwand an administration bedeutet.
fazit:
proaktiver schutz ist gut und richtig, soweit das kosten/nutzen-verhältnis ausgewogen ist; es verringert den umfang möglicher angriffspunkte enorm.
doch es gilt auch hier die alte weissheit:
"wer unbedingt reinkommen will, der kommt auch rein"
es ist nur eine frage des aufwandes...
für ein script-kiddie war/ist es relativ simple möglich, den do_brk()-exploit zu ziehen und dann über eine schwachstelle irgendeines php-scripts auf dem server zu installieren. doch keine spuren zu hinterlassen ist ihm kaum möglich ;)

"back to the roots"