Ich kann sowas wie process accounting mitlaufen lassen. Aber das hilft bei der Aufklärung eines Hacks doch auch mehr oder weniger zufällig? Und wenn der Böse dann vielleicht auch noch Logs löscht?
> Ich kann sowas wie process accounting mitlaufen > lassen. Aber das hilft bei der Aufklärung eines Hacks > doch auch mehr oder weniger zufällig? Und wenn der > Böse dann vielleicht auch noch Logs löscht?
Und wie willer das am zentralen Logserver der alles mitschreibt machen wenn er den noch nicht gehackt hat?
Genau, Server in der DMZ loggen remote auf einen anderen Host der nicht in der DMZ steht, und somit relativ wahrscheinlich nicht "gehackt" wird.
Dazu kommt auch, dass "gehackt" nicht automatisch root-Zugriff heißt. Hier wurde der webcvs-Dienst erwähnt, vielleicht wars ja "nur" ein Hack auf diesen Dienst so dass sie z.B. beliebige Befehle als der unpriveligierte Webserver-User ausführen konnten. Das hieße in dem Fall noch lange nicht, dass sie die Logdateien des Webservers ändern können.
Vielleicht wars auch kein Zugriff auf die Shell, sondern nur Zugriff auf alle (normalerweise geschützten) Bereiche des webcvs.
Aber selbst wenn ich weiß, über welchen Service jemand einbrechen konnte (z.B. weil verdächtige Accounting-Logs auftauchen), weiß ich doch noch lange nicht, wie das passieren konnte?
Siehe diesbezüglich z.B. die aktuelle Diskussion um NSA-Hintertüren bei OpenBSDs IPSec-Stack...
Wie genau weiß SF sicher auch noch nicht, aber welche Komponente angegriffen wurde, bekommen sie so raus. Und da die Jungs ja sicher relativ professionell sind, wird der webcvs-dienst auf seperaten Hosts laufen, somit kann man die vom Netz nehmen und analysieren was dort passiert ist.
Ich würd eine Webkomponente auf einer/mehreren dedizierten Hosts/VMs installieren und nur den unbedingt nötigen Zugriff auf andere Hosts (z.B. mysql) erlauben. SSH oder ähnliche potentielle Risikofaktoren müssen da auch nicht aktiv/installiert sein, ich komme ja bei VMs über die virtuelle Konsole auf das System, ansonsten per seriell oder halt per Turnschuh. Somit kann ich relativ sicher sein, dass ein erfolgreicher Angriff auf diesen Dienst keine Auswirkungen auf andere Dienste hatte und kann den erstmal deaktivieren und in Ruhe analysieren. Bei VMs beispielsweise könnte ein stündlicher Snapshot gezogen werden, somit kann man relativ einfach und sicher nachvollziehen was am System geändert wurde seitdem der Angriff erfolgreich war. Den webcvs-Dienst würd ich in dem Umfeld auch als optional also nicht produktionsrelevant sehen, somit muss da nicht zwingend sofortiger Ersatz geschaffen werden.
So die Theorie, in der Praxis gibts da unendlich viele Falltüren. Einer Datenbank die von einem kompromittierten System aus erreichbar war würd ich allerdings auch nicht mehr vertrauen, außer es war ein readonly-Clone der Produktion (was in dem Fall hier ja gereicht hätte, oder kann man in diesem webcvs auch komitten?).
Du nicht, jemand der weiss was er tut wird es aber letztlich rausbekommen
Das ist eben der Unterschied zwischen einem Homeuser und jemandem der wirklich Systeme administrieren kann, dazu gehört nämlich auch sich im Ernstfall was zu überlegen was nicht auf einem fertigen Ablaufplan steht
Aber auch jemand "der wirklich Systeme administrieren kann", kann nur mit Wasser kochen und sich nicht im Nachhinein etwas aus den Fingern saugen.
Für die *Erkennung* eines Einbruches fallen mir viele Möglichkeiten ein und es gibt mit den IDS ja auch eine Menge an Programmen, die sowas leisten. Aber das dient ja nur der Feststellung, dass jemand eingebrochen ist und hilft nicht bei der Frage, wie man den gleichen Einbuch zukünftig vermeiden kann. Und ps-acct mit einem Loghost ist die einzige Möglichkeit, im Nachhinein so etwas zu leisten? Das glaube ich nicht. Gibt es vielleicht professioneller Tools als das PS-Accounting, das ja eigentlich für Großrechner-Abrechnung gedacht war?
Ich verstehe dein Problem nicht so recht. Natürlich kann man zu erkentnissen kommen wie man einen weiteren Einbruch vermeidet, wenn man weiss wie es beim ersten mal passiert ist.
Viele Einbrüche basieren auf Softwarefehlern und Konfigurationsfehlern, beides kann man mit Wissen um die Einbruchsmethode angehen.
> Aber auch jemand "der wirklich Systeme administrieren > kann", kann nur mit Wasser kochen und sich nicht im > Nachhinein etwas aus den Fingern saugen
Kind wo ist dein Problem ausser dass du von der Materie keine Ahnung hast und deswegen einfach nicht verstehst wie jemand agiert der weiss wie ein System wirklich funktioniert und wie Softwarekomponenten und Konfigurationen zusammenspielen
Wie soll man das einem DAu erkläern? Geht nicht!
Genausoweiig wie du verstehst wie man Software debuggt und im Nachhinein Fehler die beim user aufgetreten sind nachvollzieht wenn man sie selbst nicht nachstellen kann - Auch das geht und ist keine Magie, für jemanden der keinen Dunst davon hat wirkt das wie unmöglich, logisch, liegt in der Natur der Sache
Das ist aber nicht nur in der IT so
Ich habe auch keine Ahnung wie man einen Krankheitserreger im Labor untersucht und Gegenmittel entwickelt. Trotzdem stelle ich mich nicht hin und sage "Wie soll denn das gehen?"
> Kind wo ist dein Problem ausser dass du von der Materie keine > Ahnung hast und deswegen einfach nicht verstehst wie jemand > agiert der weiss wie ein System wirklich funktioniert und wie > Softwarekomponenten und Konfigurationen zusammenspielen > > Wie soll man das einem DAu erkläern? > Geht nicht!
*g*
Dann lass uns Unwissende doch bitte an Deiner Weisheit teilhaben?
Und damit Du uns mit Deiner Brillianz beeindrucken kannst, versetz ich Dich doch bitte ins folgende Szenario: auf einem Deiner Mailserver (sendmail, dovecot, ssh, mysql) von Dir läuft auf einmal ein IRC-Server und es gibt einen Benutzer anon mit UID 0. In /dev/.../log siehst Du eine Aufzeichnung aller UserPasswörter.
/var/log/* ist leer (gelöscht) und der Rechner ist auf einem aktuellen Patchlevel.
Und jetzt bist Du dran, Du Schlaumeier: wie gehst Du vor, um herauszufinden, wie der offensichtliche Einbruch erfolgen konnte?
> /var/log/* ist leer (gelöscht) und der Rechner ist auf einem aktuellen Patchlevel.
Das mit dem zentralen Log-Server hast du offenbar überlesen. Aber auch sonst kann man z.B. viel aus einem Dateisystem rausholen, auch wenn dort viel rumgefuhrwerkt wurde.
> Dann lass uns Unwissende doch bitte an Deiner > Weisheit teilhaben?
Warum soll ich meine Zeit mit sowas wie dir verschwenden wenn man doch im nächsten Absatz sieht dass du merkbefreit bist oder eine massive Leseschwäche hast?
> Und damit Du uns mit Deiner Brillianz beeindrucken kannst
Kind ich habe es schon lange nicht mehr nötig jemand zu beeindrucken
> versetz ich Dich doch bitte ins folgende Szenario
ja und?
> auf einem Deiner Mailserver (sendmail, dovecot, ssh, > mysql) von Dir läuft auf einmal ein IRC-Server und es > gibt einen Benutzer anon mit UID 0. In /dev/.../log siehst > Du eine Aufzeichnung aller UserPasswörter
Und weiter?
> /var/log/* ist leer (gelöscht) und der Rechner ist auf > einem aktuellen Patchlevel.
Was interessiert mich verdammt nochmal /var/log Genau DAS meine ich mit merkbefreit Soll ich dir einen zentralen Logserver auf ein Blatt Papier malen oder wo ist dein problem zu kapieren dass der Kerl mindestens ZWEI Server hacken müsste um alle Spuren zu verwischen - Sehr unwahrscheinlich in kurzer Zeit
> Und jetzt bist Du dran, Du Schlaumeier: wie gehst Du vor, > um herauszufinden, wie der offensichtliche Einbruch > erfolgen konnte?
Ich schaue in meine Logs die wich ich dir schon ganz weit oben erklärt habe mit ziemlicher Sicherheit noch da sind
/var/log interessiert im Falle eines erfolgreichen Einbruchs sowieso keine Sau weil die Protokolle der betroffenen Maschine nocht vertrauenswürdig sind!
Du kennst nur /var/log/ - Ja das ist dein verdammtes Problem aber dann tu nicht so als wenn du mitreden könntest
Auf Deinem zentralen Logserver siehst Du gegen 17:00 Uhr ein erfolgreiches Einloggen von user anon. Zwischen 16:00 und 16:45 taucht in auth.log mehrere erfolglose Einloggversuche von mail, guest, system, admin, superuser, usw. per SSH auf.
Ab 17.00 siehst Du gar nichts mehr, denn der syslog wurde auf dem gehackten Server gestoppt.
Was du nur immer und immer wieder ignorierst: Nicht bei jedem Hack hat der Einbrechende diese Möglichkeiten.
Zudem reichen die vorhandenen Logs aus, um die durchgeführten Handlungen bis dahin zurück zu verfolgen, und diese Sicherheitslücke zu schliesen. Das betroffene System wird sowieso neu aufgesetzt, sodass Folgehandlungen des Hackers auf dem System nicht mehr von belang sind. Müssen Datenbestände von dem System geholt werden, vergleicht man diese mit Backups und führt auf den Änderungen Plausibilitätsprüfungen durch. Das ist Arbeit, aber notwendig.
Dein SSH Szenario erscheint mir auch eher abwegig. SSH ist nicht das Hauptangriffsziel heutzutage, da dies leicht abzusichern ist (Anzahl Trys pro Minute, Firewall Regeln die nur nach senden von Paketen an bestimmte Ports SSH überhaupt für eine IP Freigeben, Pre-shared Keys, lange Passwörter, ungewöhnliche Usernamen usw.).
Wichtiger sind Webservices, Mailserver und co. Doch auch hier lassen sich Angriffe gut zurückverfolgen, zudem laufen diese Dienste nicht mit den nötigen Rechten, außer es gelingt ein Hochstufen der Rechte. Aber das muss auch erstmal erfolgen.
> Nicht bei jedem Hack hat der Einbrechende diese Möglichkeiten.
Klar, ein shell-Account reicht dafür sicherlich nicht aus. Aber das weiß ich ja vorher nicht.
> Zudem reichen die vorhandenen Logs aus, um die durchgeführten Handlungen bis > dahin zurück zu verfolgen, und diese Sicherheitslücke zu schliesen.
Und das ist schlichtweg falsch! Nehmen wir z.B. einen aktuell genutzten expolit für debian Exim 4.63. In den Logs taucht da lediglich ein normaler Maillog-Eintrag auf (Mail an root oder postmaster oder irgendwas!). Von einem solchen Eintrag auf eine Sicherheitslücke in exim zu schließen ist de facto nicht möglich. In einem solchen Fall findet man die Sicherheitslücke wahrscheinlich über den Patchlevel, der hier offensichtlich nicht aktuell ist (da Debian ja Updates für den Bug zur Verfügung stellt).
Daher zurück zur Frage: wie findet man heraus, über welchen Service ein Einbrecher eindringen konnte, wenn es keine aussagekräftigen Logs gibt? Die Möglichkeit über PS-Acct und Loghost darauf zu kommen lasse ich ja gelten. Aber es muss doch wissenschaftlichere Wege für sowas geben?
Aber vermutlich ist das Prolinux-Forum nicht (mehr!?!) der richtige Platz um sowas zu diskutieren. Ich erinnere mich da gerne an die gute alte Zeit (TM) zurück, in der man z.B. mit GNU Wolfgang hier hervorragend diskutieren und fachsimpeln konnte, ohne dass jemand beleidigend wurde. Und das trotz kontroverser Meinungen!
> und führt auf den Änderungen Plausibilitätsprüfungen durch.
DAS ist dann auch die Stelle, wo es richtig hart wird! In den Repositories von squirrelmail gab es nach deren Hack folgende Änderung:
diff -r g/squirrelmail-1.4.12/functions/global.php b/squirrelmail-1.4.12/functions/global.php 76a77,81 /** set the value of the base path */ if (isset($_SERVER['HTTP_BASE_PATH'])) { define('SM_PATH',$_SERVER['HTTP_BASE_PATH']); }
Und sowas finde ich ja beeindruckend ausgefuchst! Auf den ersten Blick würde doch niemand vermuten, dass das was schadhaftes passiert, oder? Aber durch die Möglichkeit, dem Webserver individuelle Header-Einträge mitzugeben, wird der BASE_PATH geändert und damit hat der Angreifer die Möglichkeit, den Ort zu bestimmen, woher Squirrelmail seine Dateien nachlädt! DOH -- das ist mal ausgefuchst, oder?
Tja, aber anscheinend ist der Hack wohl aufgeflogen. Ich gebe dir recht, dass soetwas nicht jedem auffällt. Aber ich bin zuversichtlich, dass es dem Entwickler auffällt, der für den jeweiligen Code verantwortlich war. Klar, jetzt kannst du ein weiteres Beispiel bringen, in dem das ganze noch ausgefuchster war, aber ich finde, die Latte ist jetzt schon ziemlich hoch gesetzt.
> Aber ich bin zuversichtlich, dass es dem Entwickler auffällt, der für den jeweiligen Code > verantwortlich war.
Nope!
Zitat: "Nach einer genaueren Untersuchung stuften die Entwickler des plattformübergreifenden Web-Mail-Systems SquirrelMail die kürzlich bekannt gewordenen Manipulationen an Version 1.4.12 als weitaus gefährlicher ein als zunächst angenommen. Angreifer könnten Code auf den PC einschleusen und ausführen. Nach der ersten Analyse hatte man die Schäden für ungefährlich gehalten."
Und jetzt möge bitte jeder mal nachdenken: wenn selbst die Entwickler von Suirrelmail nach einem CodeReview nicht durchsteigen, dass da jemand etwas extrem böses reingeschmuggelt hat. Wie groß ist da erst die Wahrscheinlichkeit, dass ich das bei einem gehackten Rechner herausfinde, wo ich nicht mal weiß, woher und wie der Eindringling reinkam?
Es ist also mitnichten so trivial, wie "Verdammt" einen das glauben lassen mag!
Ok, aber das war nicht mein Punkt. Was ich meinte war: Auch wenn der Entwickler jetzt nicht gleich die Konsequenzen der Manipulation einschätzen konnte, so wusste er immerhin, dass er diese 3 Zeilen nicht selbst geschrieben hatte.
> wenn selbst die Entwickler von Suirrelmail nach einem CodeReview nicht durchsteigen, dass da jemand etwas extrem böses reingeschmuggelt hat.
Anhand der Heise-Meldung interpretiere ich das aber anders: Nachdem bekannt wurde, dass sich die zum Download freigegebenen Dateien verändert haben (also die fertig gepackten releases!), hat man diese wieder zurückgesetzt. Ok, die haben beim CodeReview am Anfang versagt, aber das spielte für die Sicherheit keine Rolle, weil die Änderungen ja prinzipiell zurückgespult werden.
Zuürckgesetzt? Na klar! Aber was ist mit den Downloads zwischen Code-Änderung und Zurücksetzung?
In diesem Zusammenhang sehr lesenswert: http://www.heise.de/security/news/foren/S-Achtung-hab-grad-ein-gecracktes-Paket-von-SourceForge-bekommen-mirrors-unsync/forum-128972/msg-14071699/read/
So, dritter Post Ich nehme an, dass das auch nicht dein ursprünglicher Punkt war, sondern der, dass du als Admin hilflos dastehst, weil du im nachhinein nicht weißt, wie der Exploit oder was auch immer aufgebaut war. Mir fällt dazu eigentlich auch nur ein: a) der Exploit muss verdammt gut gemacht sein, dass er im System keine Spuren hinterlässt. So einen Exploit zu konstruieren kann schon sehr aufwändig sein und vielleicht i.d.R. nicht der Mühe wert. b) Selbst wenn der Exploit nichts über sich und die Stelle der Software verrät, die ausgenutzt wurde, so weiß der Admin doch grob die Komponente über die der Angreifer in das System gelang (wegen Sauberer Trennung der Systeme usw.). Dadurch kann er in Zukunft für diese Komponente verstärktes Monitoring anschalten, in der "Hoffung", dass es doch noch mal jemand versucht.
Ich als admin weiß nicht, wie ein Exploit aufgebaut ist und vielleicht noch nicht einmal, welcher Service exploitable war. Das kann durch einen 0-day kommen (bei einem kleinem Webserver zugegebenermaßen eher unwahrscheinlich), durch eigene Dienste, fahrlässige Konfiguration, schlechte Passwörter oder was weiß ich. Und das im Nachhinein herauszufinden ist teilweise schlicht und einfach nicht möglich, oder?
Und falls ein exploit Spuren hinterlässt (tmp-files, Einträge in /proc, u.ä.) kann ein Einbrecher die ja auch (fast) immer nach dem Einbruch löschen.
Und Deine angesprochene Möglichkeit b ist auch nciht ganz einfach. Denn das "verstärkte Monitoring" müsste ja so detailliert sein, dass man im Nachhinein die fehlerhafte Komponente finden kann? Lass mal bei einem mittelmäßig besuchten Webserver ein strace mitlaufen und Du weißt, was ich meine...
Fakt sit dass du KEINE AHNUNG von der Materie hast, erst naiv genug bist zu glauben jemand könnte dir in einem Forum einfach so Vratändnis einimpfen und einfach nur dumm herum trollst
Kauf dir ein paar Bücher, schaue, lerne, probiere oder halt einfach den Broteinschub
Du nervst seit du den Mund aufgemacht hast weil du glaubst hier erklären dir Leute Arbeit die sie über Jahre mühsam gelernt haben einfach nebenbei DAU-Gerecht
Warum bricht man bei so einem Anbieter für Open Source Sachen ein? Leider wissen wir nicht genau, worauf es die Angreifer abgesehen hatten, aber ich finde es irgendwie arm.
Ich würde sagen, dass das deine subjektive Einschätzung ist, die absolut nicht stimmen muss. Es gibt noch viele sehr bekannte OSS Projekte, die auf sourceforge.net laufen. Selbst wenn der Trend für neue Projekte zu GitHub/Bitbucket/etc. geht, ist sf.net dadurch noch lange nicht tot.
der fummel-elite ist facebook zu regulär also gehen sie zu github und forken statt poken..
Für Andere sieht das trotzdem immer noch aus wie eine Packung Gummibärchen.. und irgendwie geht code bei so viel social leicht unter. Avatare, PMs, farbige Fork-trees.. nur um in ein paar Jahren festzustellen, dass man mit einer gewöhnlich Mailingliste und einem gewöhnlichen Repo eigentlich auch produktiv sein kann (wenn nicht produktiver).
Wenn von einem Servereinbruch bei savannah.gnu.org gesprochen wird, kommen sofort Kommentare wie "ist das peinlich" oder "da merkt man mal dieses freie-software-getue total scheiße ist!" (http://www.pro-linux.de/news/1/16455/comm/1/show-all-comments.html). nun gibt es einen servereinbruch bei sourceforge und es wird nichts von wegen "ist das peinlich!!" gesagt. wie verblendet sind doch die menschen!
Peinlich ist nicht der Einbruch als solches sondern viel mehr, wie damit anschliessend umgegangen wird. Und in dieser Disziplin hat SF gepunktet.
Die Vorgehensweise von SF ist vorbildlich, neben einem evtl. aufgetretenem Schaden wird vorsorglich weiterer Schaden vermieden - die Mail zur Aufforderung zum PW Wechsel kam heute pünktlich und es wurde nichts beschönigt oder bagatellisiert.
...am Freitag. Die armen Admin ^^
// Edit: Ging ja schon am Mittwoch los...
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 28. Jan 2011 um 16:54.> Die SourceForge-Administratoren haben in der Zwischenzeit ermittelt,
> wie der Einbruch geschah
Ich frag mich immer: wie macht man sowas?
Man kann doch nicht anhand von Logdateien herausfinden, wie ein Server gehackt wurde??
"Man kann doch nicht anhand von Logdateien herausfinden, wie ein Server gehackt wurde??"
Warum nicht? wenn alles gut mitgeloggt wird lässt sich einiges rausfinden. Muss nur alles gut eingestellt sein.
Und was heißt "gut eingestellt"?
Ich kann sowas wie process accounting mitlaufen lassen. Aber das hilft bei der Aufklärung eines Hacks doch auch mehr oder weniger zufällig? Und wenn der Böse dann vielleicht auch noch Logs löscht?
> Ich kann sowas wie process accounting mitlaufen
> lassen. Aber das hilft bei der Aufklärung eines Hacks
> doch auch mehr oder weniger zufällig? Und wenn der
> Böse dann vielleicht auch noch Logs löscht?
Und wie willer das am zentralen Logserver der alles mitschreibt machen wenn er den noch nicht gehackt hat?
Genau, Server in der DMZ loggen remote auf einen anderen Host der nicht in der DMZ steht, und somit relativ wahrscheinlich nicht "gehackt" wird.
Dazu kommt auch, dass "gehackt" nicht automatisch root-Zugriff heißt. Hier wurde der webcvs-Dienst erwähnt, vielleicht wars ja "nur" ein Hack auf diesen Dienst so dass sie z.B. beliebige Befehle als der unpriveligierte Webserver-User ausführen konnten. Das hieße in dem Fall noch lange nicht, dass sie die Logdateien des Webservers ändern können.
Vielleicht wars auch kein Zugriff auf die Shell, sondern nur Zugriff auf alle (normalerweise geschützten) Bereiche des webcvs.
Usw...
Aber selbst wenn ich weiß, über welchen Service jemand einbrechen konnte (z.B. weil verdächtige Accounting-Logs auftauchen), weiß ich doch noch lange nicht, wie das passieren konnte?
Siehe diesbezüglich z.B. die aktuelle Diskussion um NSA-Hintertüren bei OpenBSDs IPSec-Stack...
Wie genau weiß SF sicher auch noch nicht, aber welche Komponente angegriffen wurde, bekommen sie so raus. Und da die Jungs ja sicher relativ professionell sind, wird der webcvs-dienst auf seperaten Hosts laufen, somit kann man die vom Netz nehmen und analysieren was dort passiert ist.
Ich würd eine Webkomponente auf einer/mehreren dedizierten Hosts/VMs installieren und nur den unbedingt nötigen Zugriff auf andere Hosts (z.B. mysql) erlauben. SSH oder ähnliche potentielle Risikofaktoren müssen da auch nicht aktiv/installiert sein, ich komme ja bei VMs über die virtuelle Konsole auf das System, ansonsten per seriell oder halt per Turnschuh. Somit kann ich relativ sicher sein, dass ein erfolgreicher Angriff auf diesen Dienst keine Auswirkungen auf andere Dienste hatte und kann den erstmal deaktivieren und in Ruhe analysieren. Bei VMs beispielsweise könnte ein stündlicher Snapshot gezogen werden, somit kann man relativ einfach und sicher nachvollziehen was am System geändert wurde seitdem der Angriff erfolgreich war. Den webcvs-Dienst würd ich in dem Umfeld auch als optional also nicht produktionsrelevant sehen, somit muss da nicht zwingend sofortiger Ersatz geschaffen werden.
So die Theorie, in der Praxis gibts da unendlich viele Falltüren. Einer Datenbank die von einem kompromittierten System aus erreichbar war würd ich allerdings auch nicht mehr vertrauen, außer es war ein readonly-Clone der Produktion (was in dem Fall hier ja gereicht hätte, oder kann man in diesem webcvs auch komitten?).
Du nicht, jemand der weiss was er tut wird es
aber letztlich rausbekommen
Das ist eben der Unterschied zwischen einem Homeuser und jemandem der wirklich Systeme administrieren kann, dazu gehört nämlich auch sich im Ernstfall was zu überlegen was nicht auf einem fertigen Ablaufplan steht
Aber auch jemand "der wirklich Systeme administrieren kann", kann nur mit Wasser kochen und sich nicht im Nachhinein etwas aus den Fingern saugen.
Für die *Erkennung* eines Einbruches fallen mir viele Möglichkeiten ein und es gibt mit den IDS ja auch eine Menge an Programmen, die sowas leisten. Aber das dient ja nur der Feststellung, dass jemand eingebrochen ist und hilft nicht bei der Frage, wie man den gleichen Einbuch zukünftig vermeiden kann.
Und ps-acct mit einem Loghost ist die einzige Möglichkeit, im Nachhinein so etwas zu leisten? Das glaube ich nicht.
Gibt es vielleicht professioneller Tools als das PS-Accounting, das ja eigentlich für Großrechner-Abrechnung gedacht war?
Ich verstehe dein Problem nicht so recht. Natürlich kann man zu erkentnissen kommen wie man einen weiteren Einbruch vermeidet, wenn man weiss wie es beim ersten mal passiert ist.
Viele Einbrüche basieren auf Softwarefehlern und Konfigurationsfehlern, beides kann man mit Wissen um die Einbruchsmethode angehen.
> Aber auch jemand "der wirklich Systeme administrieren
> kann", kann nur mit Wasser kochen und sich nicht im
> Nachhinein etwas aus den Fingern saugen
Kind wo ist dein Problem ausser dass du von der Materie keine Ahnung hast und deswegen einfach nicht verstehst wie jemand agiert der weiss wie ein System wirklich funktioniert und wie Softwarekomponenten und Konfigurationen zusammenspielen
Wie soll man das einem DAu erkläern?
Geht nicht!
Genausoweiig wie du verstehst wie man Software debuggt und im Nachhinein Fehler die beim user aufgetreten sind nachvollzieht wenn man sie selbst nicht nachstellen kann - Auch das geht und ist keine Magie, für jemanden der keinen Dunst davon hat wirkt das wie unmöglich, logisch, liegt in der Natur der Sache
Das ist aber nicht nur in der IT so
Ich habe auch keine Ahnung wie man einen Krankheitserreger im Labor untersucht und Gegenmittel entwickelt. Trotzdem stelle ich mich nicht hin und sage "Wie soll denn das gehen?"
> Kind wo ist dein Problem ausser dass du von der Materie keine
> Ahnung hast und deswegen einfach nicht verstehst wie jemand
> agiert der weiss wie ein System wirklich funktioniert und wie
> Softwarekomponenten und Konfigurationen zusammenspielen
>
> Wie soll man das einem DAu erkläern?
> Geht nicht!
*g*
Dann lass uns Unwissende doch bitte an Deiner Weisheit teilhaben?
Und damit Du uns mit Deiner Brillianz beeindrucken kannst, versetz ich Dich doch bitte ins folgende Szenario: auf einem Deiner Mailserver (sendmail, dovecot, ssh, mysql) von Dir läuft auf einmal ein IRC-Server und es gibt einen Benutzer anon mit UID 0. In /dev/.../log siehst Du eine Aufzeichnung aller UserPasswörter.
/var/log/* ist leer (gelöscht) und der Rechner ist auf einem aktuellen Patchlevel.
Und jetzt bist Du dran, Du Schlaumeier: wie gehst Du vor, um herauszufinden, wie der offensichtliche Einbruch erfolgen konnte?
> /var/log/* ist leer (gelöscht) und der Rechner ist auf einem aktuellen Patchlevel.
Das mit dem zentralen Log-Server hast du offenbar überlesen. Aber auch sonst kann man z.B. viel aus einem Dateisystem rausholen, auch wenn dort viel rumgefuhrwerkt wurde.
> Dann lass uns Unwissende doch bitte an Deiner
> Weisheit teilhaben?
Warum soll ich meine Zeit mit sowas wie dir verschwenden wenn man doch im nächsten Absatz sieht dass du merkbefreit bist oder eine massive Leseschwäche hast?
> Und damit Du uns mit Deiner Brillianz beeindrucken kannst
Kind ich habe es schon lange nicht mehr nötig
jemand zu beeindrucken
> versetz ich Dich doch bitte ins folgende Szenario
ja und?
> auf einem Deiner Mailserver (sendmail, dovecot, ssh,
> mysql) von Dir läuft auf einmal ein IRC-Server und es
> gibt einen Benutzer anon mit UID 0. In /dev/.../log siehst
> Du eine Aufzeichnung aller UserPasswörter
Und weiter?
> /var/log/* ist leer (gelöscht) und der Rechner ist auf
> einem aktuellen Patchlevel.
Was interessiert mich verdammt nochmal /var/log
Genau DAS meine ich mit merkbefreit
Soll ich dir einen zentralen Logserver auf ein Blatt Papier malen oder wo ist dein problem zu kapieren dass der Kerl mindestens ZWEI Server hacken müsste um alle Spuren zu verwischen - Sehr unwahrscheinlich in kurzer Zeit
> Und jetzt bist Du dran, Du Schlaumeier: wie gehst Du vor,
> um herauszufinden, wie der offensichtliche Einbruch
> erfolgen konnte?
Ich schaue in meine Logs die wich ich dir schon ganz weit oben erklärt habe mit ziemlicher Sicherheit noch da sind
/var/log interessiert im Falle eines erfolgreichen Einbruchs sowieso keine Sau weil die Protokolle der betroffenen Maschine nocht vertrauenswürdig sind!
Du kennst nur /var/log/ - Ja das ist dein verdammtes Problem aber dann tu nicht so als wenn du mitreden könntest
So, Schlauermeier....
Auf Deinem zentralen Logserver siehst Du gegen 17:00 Uhr ein erfolgreiches Einloggen von user anon. Zwischen 16:00 und 16:45 taucht in auth.log mehrere erfolglose Einloggversuche von mail, guest, system, admin, superuser, usw. per SSH auf.
Ab 17.00 siehst Du gar nichts mehr, denn der syslog wurde auf dem gehackten Server gestoppt.
Du bist dran, Schlaumeier,,,
Was du nur immer und immer wieder ignorierst: Nicht bei jedem Hack hat der Einbrechende diese Möglichkeiten.
Zudem reichen die vorhandenen Logs aus, um die durchgeführten Handlungen bis dahin zurück zu verfolgen, und diese Sicherheitslücke zu schliesen. Das betroffene System wird sowieso neu aufgesetzt, sodass Folgehandlungen des Hackers auf dem System nicht mehr von belang sind.
Müssen Datenbestände von dem System geholt werden, vergleicht man diese mit Backups und führt auf den Änderungen Plausibilitätsprüfungen durch.
Das ist Arbeit, aber notwendig.
Dein SSH Szenario erscheint mir auch eher abwegig. SSH ist nicht das Hauptangriffsziel heutzutage, da dies leicht abzusichern ist (Anzahl Trys pro Minute, Firewall Regeln die nur nach senden von Paketen an bestimmte Ports SSH überhaupt für eine IP Freigeben, Pre-shared Keys, lange Passwörter, ungewöhnliche Usernamen usw.).
Wichtiger sind Webservices, Mailserver und co.
Doch auch hier lassen sich Angriffe gut zurückverfolgen, zudem laufen diese Dienste nicht mit den nötigen Rechten, außer es gelingt ein Hochstufen der Rechte. Aber das muss auch erstmal erfolgen.
> Nicht bei jedem Hack hat der Einbrechende diese Möglichkeiten.
Klar, ein shell-Account reicht dafür sicherlich nicht aus. Aber das weiß ich ja vorher nicht.
> Zudem reichen die vorhandenen Logs aus, um die durchgeführten Handlungen bis
> dahin zurück zu verfolgen, und diese Sicherheitslücke zu schliesen.
Und das ist schlichtweg falsch! Nehmen wir z.B. einen aktuell genutzten expolit für debian Exim 4.63. In den Logs taucht da lediglich ein normaler Maillog-Eintrag auf (Mail an root oder postmaster oder irgendwas!). Von einem solchen Eintrag auf eine Sicherheitslücke in exim zu schließen ist de facto nicht möglich. In einem solchen Fall findet man die Sicherheitslücke wahrscheinlich über den Patchlevel, der hier offensichtlich nicht aktuell ist (da Debian ja Updates für den Bug zur Verfügung stellt).
Daher zurück zur Frage: wie findet man heraus, über welchen Service ein Einbrecher eindringen konnte, wenn es keine aussagekräftigen Logs gibt? Die Möglichkeit über PS-Acct und Loghost darauf zu kommen lasse ich ja gelten. Aber es muss doch wissenschaftlichere Wege für sowas geben?
Aber vermutlich ist das Prolinux-Forum nicht (mehr!?!) der richtige Platz um sowas zu diskutieren. Ich erinnere mich da gerne an die gute alte Zeit (TM) zurück, in der man z.B. mit GNU Wolfgang hier hervorragend diskutieren und fachsimpeln konnte, ohne dass jemand beleidigend wurde. Und das trotz kontroverser Meinungen!
> und führt auf den Änderungen Plausibilitätsprüfungen durch.
DAS ist dann auch die Stelle, wo es richtig hart wird! In den Repositories von squirrelmail gab es nach deren Hack folgende Änderung:
diff -r g/squirrelmail-1.4.12/functions/global.php b/squirrelmail-1.4.12/functions/global.php
76a77,81
/** set the value of the base path */
if (isset($_SERVER['HTTP_BASE_PATH'])) {
define('SM_PATH',$_SERVER['HTTP_BASE_PATH']);
}
Und sowas finde ich ja beeindruckend ausgefuchst! Auf den ersten Blick würde doch niemand vermuten, dass das was schadhaftes passiert, oder? Aber durch die Möglichkeit, dem Webserver individuelle Header-Einträge mitzugeben, wird der BASE_PATH geändert und damit hat der Angreifer die Möglichkeit, den Ort zu bestimmen, woher Squirrelmail seine Dateien nachlädt! DOH -- das ist mal ausgefuchst, oder?
Edit: Ich nehme an, der User "Verdammt" hätte das wegen seines umfangreichen Wissens natürlich sofort alles durchschaut! Kein Problem für ihn!
Tja, aber anscheinend ist der Hack wohl aufgeflogen. Ich gebe dir recht, dass soetwas nicht jedem auffällt. Aber ich bin zuversichtlich, dass es dem Entwickler auffällt, der für den jeweiligen Code verantwortlich war. Klar, jetzt kannst du ein weiteres Beispiel bringen, in dem das ganze noch ausgefuchster war, aber ich finde, die Latte ist jetzt schon ziemlich hoch gesetzt.
> Aber ich bin zuversichtlich, dass es dem Entwickler auffällt, der für den jeweiligen Code
> verantwortlich war.
Nope!
Zitat:
"Nach einer genaueren Untersuchung stuften die Entwickler des plattformübergreifenden Web-Mail-Systems SquirrelMail die kürzlich bekannt gewordenen Manipulationen an Version 1.4.12 als weitaus gefährlicher ein als zunächst angenommen. Angreifer könnten Code auf den PC einschleusen und ausführen. Nach der ersten Analyse hatte man die Schäden für ungefährlich gehalten."
http://www.heise.de/security/meldung/SquirrelMail-1-4-13-schliesst-Sicherheitsluecke-170857.html
Und jetzt möge bitte jeder mal nachdenken:
wenn selbst die Entwickler von Suirrelmail nach einem CodeReview nicht durchsteigen, dass da jemand etwas extrem böses reingeschmuggelt hat. Wie groß ist da erst die Wahrscheinlichkeit, dass ich das bei einem gehackten Rechner herausfinde, wo ich nicht mal weiß, woher und wie der Eindringling reinkam?
Es ist also mitnichten so trivial, wie "Verdammt" einen das glauben lassen mag!
Ok, aber das war nicht mein Punkt. Was ich meinte war: Auch wenn der Entwickler jetzt nicht gleich die Konsequenzen der Manipulation einschätzen konnte, so wusste er immerhin, dass er diese 3 Zeilen nicht selbst geschrieben hatte.
> wenn selbst die Entwickler von Suirrelmail nach einem CodeReview nicht durchsteigen, dass da jemand etwas extrem böses reingeschmuggelt hat.
Anhand der Heise-Meldung interpretiere ich das aber anders: Nachdem bekannt wurde, dass sich die zum Download freigegebenen Dateien verändert haben (also die fertig gepackten releases!), hat man diese wieder zurückgesetzt. Ok, die haben beim CodeReview am Anfang versagt, aber das spielte für die Sicherheit keine Rolle, weil die Änderungen ja prinzipiell zurückgespult werden.
Zuürckgesetzt? Na klar! Aber was ist mit den Downloads zwischen Code-Änderung und Zurücksetzung?
In diesem Zusammenhang sehr lesenswert:
http://www.heise.de/security/news/foren/S-Achtung-hab-grad-ein-gecracktes-Paket-von-SourceForge-bekommen-mirrors-unsync/forum-128972/msg-14071699/read/
So, dritter Post
Ich nehme an, dass das auch nicht dein ursprünglicher Punkt war, sondern der, dass du als Admin hilflos dastehst, weil du im nachhinein nicht weißt, wie der Exploit oder was auch immer aufgebaut war. Mir fällt dazu eigentlich auch nur ein:
a) der Exploit muss verdammt gut gemacht sein, dass er im System keine Spuren hinterlässt. So einen Exploit zu konstruieren kann schon sehr aufwändig sein und vielleicht i.d.R. nicht der Mühe wert.
b) Selbst wenn der Exploit nichts über sich und die Stelle der Software verrät, die ausgenutzt wurde, so weiß der Admin doch grob die Komponente über die der Angreifer in das System gelang (wegen Sauberer Trennung der Systeme usw.). Dadurch kann er in Zukunft für diese Komponente verstärktes Monitoring anschalten, in der "Hoffung", dass es doch noch mal jemand versucht.
Ich als admin weiß nicht, wie ein Exploit aufgebaut ist und vielleicht noch nicht einmal, welcher Service exploitable war. Das kann durch einen 0-day kommen (bei einem kleinem Webserver zugegebenermaßen eher unwahrscheinlich), durch eigene Dienste, fahrlässige Konfiguration, schlechte Passwörter oder was weiß ich. Und das im Nachhinein herauszufinden ist teilweise schlicht und einfach nicht möglich, oder?
Und falls ein exploit Spuren hinterlässt (tmp-files, Einträge in /proc, u.ä.) kann ein Einbrecher die ja auch (fast) immer nach dem Einbruch löschen.
Und Deine angesprochene Möglichkeit b ist auch nciht ganz einfach. Denn das "verstärkte Monitoring" müsste ja so detailliert sein, dass man im Nachhinein die fehlerhafte Komponente finden kann? Lass mal bei einem mittelmäßig besuchten Webserver ein strace mitlaufen und Du weißt, was ich meine...
now thats a crazy indentation level!
Fakt sit dass du KEINE AHNUNG von der Materie hast, erst naiv genug bist zu glauben jemand könnte dir in einem Forum einfach so Vratändnis einimpfen und einfach nur dumm herum trollst
Kauf dir ein paar Bücher, schaue, lerne, probiere oder halt einfach den Broteinschub
Du fängst an zu nerven. Bleib bei der Sache oder mach was sinnvolles.
Ich hoffe, hjb löscht solche und ähnliche Kommentare...
Du nervst seit du den Mund aufgemacht hast weil du glaubst hier erklären dir Leute Arbeit die sie über Jahre mühsam gelernt haben einfach nebenbei DAU-Gerecht
Schön dass du endlich die Klappe hältst!
Warum bricht man bei so einem Anbieter für Open Source Sachen ein? Leider wissen wir nicht genau, worauf es die Angreifer abgesehen hatten, aber ich finde es irgendwie arm.
Publicity? Die Webseite der DVU Ortsgruppe Hinterwaldsdorf zu hacken macht ja keinen Spaß weils keiner merkt..
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 28. Jan 2011 um 23:24.Stell dir mal vor du würdest unbemerkt einen schadcode in die beliebtesten projekte von sf bekommen....
Klingt als würde in Zeiten von github die Konsequenz überschaubar sein
Wahrscheinlich war auf den Servern Ubuntu installiert.
http://www.microsoft.com/germany/windowsserver2003/default.mspx
Geld zu haben ist schön. Es gibt aber ein Problem. Ein Dieb kann es stehlen. Die Lösung ist, das Geld dem Dieb zu geben. Da ist es sicher ...
.. aber wenn es einen zweiten Dieb gibt?
Man könnte also meinen das Problem ist nur "verlagert".
Bleibt nur, "das Geld rauszuhauen".
Ich weiss,
Thema verfehlt, Note sechs, setzen.
Schönes WE
Sourceforge? Benutzt das noch jemand? Heutzutage ist man doch bei Github,
> Sourceforge? Benutzt das noch jemand?
Für so ein Getrolle gibt es nur eine angemessene Antwort:
Idiot!
Wieso getrolle, die Frage ist doch berechtigt. Heute findet man fast überall nur Github. Sourceforge ist doch fast tod.
Ich würde sagen, dass das deine subjektive Einschätzung ist, die absolut nicht stimmen muss. Es gibt noch viele sehr bekannte OSS Projekte, die auf sourceforge.net laufen. Selbst wenn der Trend für neue Projekte zu GitHub/Bitbucket/etc. geht, ist sf.net dadurch noch lange nicht tot.
der fummel-elite ist facebook zu regulär also gehen sie zu github und forken statt poken..
Für Andere sieht das trotzdem immer noch aus wie eine Packung Gummibärchen.. und irgendwie geht code bei so viel social leicht unter. Avatare, PMs, farbige Fork-trees.. nur um in ein paar Jahren festzustellen, dass man mit einer gewöhnlich Mailingliste und einem gewöhnlichen Repo eigentlich auch produktiv sein kann (wenn nicht produktiver).
Wenn von einem Servereinbruch bei savannah.gnu.org gesprochen wird, kommen sofort Kommentare wie "ist das peinlich" oder "da merkt man mal dieses freie-software-getue total scheiße ist!" (http://www.pro-linux.de/news/1/16455/comm/1/show-all-comments.html).
nun gibt es einen servereinbruch bei sourceforge und es wird nichts von wegen "ist das peinlich!!" gesagt. wie verblendet sind doch die menschen!
Niemand interessiert sich eben mehr wirklich für Sourceforge.
Peinlich ist nicht der Einbruch als solches sondern viel mehr, wie damit anschliessend umgegangen wird. Und in dieser Disziplin hat SF gepunktet.
Die Vorgehensweise von SF ist vorbildlich, neben einem evtl. aufgetretenem Schaden wird vorsorglich weiterer Schaden vermieden - die Mail zur Aufforderung zum PW Wechsel kam heute pünktlich und es wurde nichts beschönigt oder bagatellisiert.
Für mich ist SF immer noch die Nummer 1.
Naja, gnu.org repräsentiert wenn man so will die gesamte Open Source-Bewegung.
Stell dir das umgekehrte vor: Es wird bei microsoft.com eingebrochen oder bei apple.com. Dieser Fehler wird sofort auf die Produkte projiziert.
Die würden das ganze wohl auch unter den Teppich kehren