Von Jörg W Mittag am Do, 4. Dezember 2003 um 11:53 #
Hi,
> Wie sollen die aufwachen wenn es erst seit 2 - 3 tagen einen patch gegen den non-puplic exploit gibt????
du machst dich gerade sehr verdächtig. Die Administratoren der gecrackten Server wissen noch nicht, wie der Einbruch vor sich ging. Damit gibt es nur eine Person, die wissen kann, was für ein Exploit verwendet wurde: der/die Angreifer/in(nnen) selbst. You lose!
> Man kann sich nicht schützen vor sachen die noch gar nicht aufgedeckt sind tztztz...
Aha. Vor ein paar Tagen, bei dem Debian-Exploit hieß es noch: "Kein Wunder, bei der ganzen veralteten Software, die Debian einsetzt, musste das ja mal passieren. Mit Gentoo wäre das nicht passiert!". Jetzt betrifft es einen Server des Gentoo-Projektes und dann heißt es: "Was kann man denn schon gegen einen Exploit ausrichten, gegen den es erst seit 2-3 Tagen einen Patch gibt?" (Was noch dazu falsch ist, denn den Patch gibt es bereits seit mehreren Monaten.)
> Jetzt kommen wieder die ober gescheiten antworten.
Hmmm, Ja und Nein Den Patch gibts schon seit längerem aber niemandem war klar das man dadurch root-Zugriff bekommt. Musst dir nur mal den Eintrag im Changelog anschauen: o Add TASK_SIZE check to do_brk()
Wahrscheinlich wusste bis zur Sache mit den Debian Servern nicht mal Tosatti selber, was er da eigentlich genau gefixt hat.
Von Jörg W Mittag am Do, 4. Dezember 2003 um 16:34 #
Mir ist schon klar, dass die Sicherheitslücke erst seit kurzem öffentlich ist. In dem Artikel, auf den ich geantwortet habe, wurde aber behauptet, dass der Patch erst seit kurzem öffentlich ist und das ist falsch.
Von Schrödinger am Do, 4. Dezember 2003 um 10:57 #
Es ist nicht DER rsync.gentoo.org server kompromitiert worden, sondern ein Server der rsync.*.gentoo.org Rotation. Und dieser eine Server ist etwa eine Stunde nach dem Angriff abgeschaltet worden. Mit den anderen Servern der Rotation kann der Datenbestand abgeglichen und verifiziert werden und es ist natürlich weiterhin möglich einen rsync durchzuführen (nur eben nicht mit diesem speziellen Rechner)
Spielt doch keine Rolle welcher Server das genau war, entscheidend ist der Sachverhalt an sich. Jeder der die Gentoo-Mailingsliste abonniert hat weiss natürlich das es kein primärer rsync-server war.
Wahrscheinlich kannten sich die Hacker nicht mit den Servern bei Gentoo so genau aus, oder sie wollten bewusst mehr auf etwas aufmerksam machen als grossen Schaden anrichten.
Es ist nicht geklärt warum wer das getan hat. Aber es war ein Server, der nicht nur für Gentoo da war sondern einer Firma gehört, die auch andere Dienste darauf laufen ließ.
Es ist nach bisherigen Erkenntnissen nichts verändert worden, ws zum Gentoo-RSync gehört. Der Angreifer hat es wohl auf den anderen Teil des Servers abgesehen, der der Firma gehört und diese Kompromittierung hat gentoo wohl nur "zufällig" betroffen.
Klar ist es trotzdem schiesse für das projekt, aber der Angriff ging (wie bisher bekannt) nicht gegen Gentoo.
Wir wissen nicht warum und wieso, darum können wir doch auch nicht sagen auf wen die Angreifer es abgesehen haben. Die Leute von Gentoo wollen auf Wunsch des Sponsors ja nicht mal verraten WELCHER Server es ist. Abe die letzten drei Angriffe (Debian, FSF, Gentoo) sind für mich doch eher ein Indiz das die Leute es auf diese Projekte abgesehen haben.
Jeder engagierte Hacker/Cracker dem das selbstherrliche und elitäre Geschwafel einiger Linux-Spezis auf den Wecker fällt, kann Spass an so einer Aktion haben. Und offensichtlich ist es mit der Sicherheit bei Linux nicht sehr weit her. Bevor ein Linux-Rechner kompromittiert wurde gibt es bei jedem Einbruch in einen Windows-Rechner schadenfrohes Geschrei. Betrifft es aber mal einen Linux-Rechner, so wird abgewiegelt. Linux nutzen aus Gründen des Komforts? Sicher nicht. Linux nutzen aus Gründen der Sicherheit? Wie lächerlich.
Eine Linuxdistribution ist ganz einfach auf die Platte zu bringen, auch wenn man dem GNU-Zeugs und den WMs/DEs eine Menge verschiedener Betriebssysteme unterjubeln kann. Aber was soll der Aufwand.....
Von Christian Hausknecht am Fr, 5. Dezember 2003 um 07:59 #
LOL
Sicherlich sind einige Linux-User ein wenig hochnäsig in Sachen Sicherheit - Deine primitive Haltung zum Thema ist jedoch einfach nur lächerlich! Im Linuxlager wird dieser Warnschuß ernst genommen und etwas dagegen getan, damit in Zukunft so etwas nicht wieder passiert. Das geht i.A. auch schneller als auf ein Service-Pack zu warten ...
Genau - zumindestens fühle ich mich mit mit Linux als User im Internet sicherer als mit Windows, speziell mit dem IE. Da brauche ich keine Angst vor Dialern zu haben etc.
es wird immer Bugs geben, die ausgenutzt werden können und auch werden. Die Frage ist, wie lange brauchen die Admins ihre Kisten auf Vordermann zu bringen. Wer heute Dienste im Internet anbietet, der braucht auch ein ausgeklügeltes Sicherheitskonzept. Da scheint noch viel Informationsbedarf zu bestehen.
SCO und Microsoft jedenfalls kaum, denn denen geht es ja einzig ums Geldverdienen und dabei stoert sie ja weder Debian noch die FSF oder Gentoo, sondern kommerzielle Distributionen wie Red Hat oder Novell/SuSE, also haetten sie eher die angreifen muessen.
Von Ronny Buchmann am Do, 4. Dezember 2003 um 11:17 #
Man sollte mal bemerken, dass die meisten angegriffenen Rechner (außer dem rsync-Server) eine sehr große Anzahl von Systemusern haben und somit sehr viel Angriffsfläche bieten.
Auf einen normalen Web- oder Mailserver können sich von außen nur eine begrenzte Anzahl Personen einloggen (oft auch gar keine). In der Regel stehen die Server auch in einer DMZ hinter einer Firewall, bei Projekten wie Debian oder Savannah ist das gar nicht möglich (bzw. würde nichts bringen, da man ja ssh durchlassen muss).
ich wollte mal anfragen, wie man feststellen kann, ob jemand in einen Rechner eingedrungen ist, bzw. ob so ein Root-Toolkit installiert wurde. Der Angreifer wird wahrscheinlich sämtliche relevanten Log-Dateien manipulieren, also fallen diese schon mal weg. Gibt es noch andere Möglichkeiten oder Tools ?
Google mal nach chkrootkit. Ist aber auch kein Allheilmittel, weil es maximal bereits bekannte (Versionen von) Rootkits erkennen könnte. Aber das ist noch besser als nix ;)
Das Entdecken eines Einbruchs geschieht auf mindestens zwei Arten: Einmal durch dafür vorgesehene Tools (chkrootkit, tripwire, remote-syslog usw.) und einmal (und das ist häufiger, als man denkt) durch Zufall. Rootkits greifen logischerweise sehr tief in den Kernel ein und wenn dieser mit "exotischen" (sprich: unerwarteten) Parametern konfiguriert ist, kommt er doch öfters mal zu Schwierigkeiten bzw. gar zu einer kernel panic. Ein Beispiel wären Capabilities, die bei vielen Produktivkerneln abgeschaltet sind, und dann auch root-Prozessen keinen Zugriff auf den Adressraum des Kernels erlauben. In einem solchen Fall kann der Eindringling zwar durch einen Exploit root-Rechte erlangen und das rootkit installieren, aber er bekommt es nicht zum Laufen, da er das bereits laufende init nicht loswird, dessen Speicherbereich bei deaktivierten Capabilities auch für root-Prozesse nur lesbar ist. Ihm bliebe also nur, einen Neustart auszulösen und damit fliegt alles sofort auf (Grundregel: Keine auffälligen Systemaktivitäten hervorrufen). In diesem Zusammenhang ist auch wichtig, dass das root- (und am besten auch das usr-)Dateisystem readonly ist, und zwar nicht nur logisch sondern physikalisch. Neben der Variante, es von CD zu nutzen, gibt es sowohl bei SCSI als auch bei IDE die Möglichkeit, über einen ganz primitiven Schalter die write-Kanäle in der Anschlussleitung zu unterbrechen, wodurch ein Schreiben unterbunden wird. Und durch die inaktiven Capabilities kommt man auch nicht an die Dateisystem-Treiber bzw. den Cache heran, um dort Änderungen vorzunehmen (auch mounts sind dann nicht mehr möglich, ein mount -o move /tmp/sbin /sbin funktioniert also nicht). Sehr interessant finde ich eine Idee, die letztens auf einer Debian-ML aufgetaucht ist. Dort wurde vorgeschlagen, die SetUID-Funktionen so zu verändern, dass nur noch auf UID>0 gewechselt werden kann. Zudem soll nur noch von 0 aus auf UID kleiner 1024 (sollten für Systemuser vorbehalten sein) gewechselt werden können. Damit verbunden wäre dann auch die Möglichkeit, einzelnen UIDs die Rechte an Ports <64 zu geben, so dass z.B. ein Apache von Anfang an gar keine root-Rechte mehr braucht, und damit einige Scheuentore zugemauert werden. Das ist natürlich kein Allheilmittel, denn der sshd oder zum Teil auf der ftpd (wenn es kein reiner Anon-FTP sein soll) müssen immer noch als root laufen.
Von Andreas Cordes am Do, 4. Dezember 2003 um 11:32 #
Hi,
interessant finde ich, dass der Einbruch auf dem Gentoo-Server bereits nach einer Stunde bemerkt wurde.
Was für Dienste/Dämons usw. laufen dort, um genau das heraus zu finden ?
Das interessiert mich im Moment etwas mehr.
BTW : Das ein Gentoo-Server gehackt wurde, heißt nicht unbedingt, dass auch Gentoo drauf läuft. Welches OS/Welche Distri da drauf würde ich auch gerne wissen.
Wie ja schon beschrieben in der News, laufen auch andere Dienste von anderen Projekten/Firmen auf dem Server, deswegen wird dessen Name ja auch nicht bekanntgegeben.
Der Einbruch in den Savannah-Server der Free Software Foundation erfolgte nach eigenem Bekunden der FSF:
"...irgenwann um den 02.November."
Also brauchten sie volle 4 Wochen um den Einbruch überhaupt zu entdecken, was wirklich kein gutes Licht auf die Verantwortlichen wirft.
Immerhin auffallend, das so ein wirklich wichtiges "Detail" in der Meldung komplett unter den Teppich gekehrt wird und man sich viel lieber dem Gentoo-Server widmet, wo man das Datum des Einbruchs (01.-02.12.) und die Entdeckung (02.12.), sowie die Zahlen der gefährdeten User (20) korrekt angiebt....
Wenn man das korrigieren kann, warum kann man dann nicht die Zeile korrigieren in der steht dass "rsync.gentoo.org" geknackt wurde?
Immerhin ist das nicht nur unsauber sondern falsch. Einfach nur falsch. rsync?.*.gentoo.org ist ein Ring mit sehr vielen Mirrors und einer davon wurde geknackt. Einer. Nicht der Haupt-Mirror und auch nicht der zuständige DNS-Server.
Aus der Gentoo Mitteilung: "the compromised system had both an IDS and a file integrity checker installed".
Entprechende Stelle in der GNU Mitteilung:
" ".
Dauer bis zur Erkennung des Einbruchs:
Gentoo (mit file integrity checker): 1 Tag GNU Savannah: (ohne File integrity checker): 1 Monat
Wer einen großen öffentlichen Server betreibt, der von Kunden anvertrauten Sourcecode verwaltet, tut gut daran, ein funktionierendes IDS zu benutzen.
Wer auf die nicht zu umgehenden "File Integrity Chercker" wie Tripwire oder AIDE verzeichtet, handelt grob fahrlässig, da einbrüche dann nur zufällig entdeckt werden.
Rootrechte auf einer Maschine, dessen Dateisystem regelmäßig von einer korrekten AIDE oder Tripwire Installation (auf CD) überwacht wird, bringen den Angreifer auch nicht weiter. (Deshalb bitte auf unqualifizierte Kommentare, die Signaturdatei oder das AIDE Binary könnte manipuliert werden, verzichten.)
hat eigentlich schon jemand hier Erfahrung mit AIDE? Ich hab gesehen, daß es erst im Beta Stadium ist. Allerdings hat's bei Debian ja scheinbar gut funktioniert.
Kleine Korrektur: Wir haben es nach weniger als einer Stunde gemerkt und der Server wurde sofort vom Netz getrennt und aus der DNS Rotation von rsync.gentoo.org herausgenommen.
Nicht unser Server, nicht unter unserer Verwaltung -- Aber ich denke mal Tripwire oder AIDE. Uns wurde der Speicherplatz und die Bandbreite nur gesponsort und es laufen noch andere Dienste für verschiedene Organisationen auf diesem Server.
Was wieder mal beweisst das Linux nicht von Grundauf sicherer ist als andere Systeme. Linux kann genauso einfach kompromittiert werden, wie ein Windowssystem - immer eine Frage des KnowHows. Wenn schon auf Servern der Distributionen es so einfach ist, wie einfach ist es dann erst beim normalen User der dank DSL-Flat 24h am Netzt hängt?
Es wird noch einiges auf uns zu kommen. Wenn Linux erstmal eine grössere Verbreitung haben sollte, wird es auch zunehmend interessant für Angriffe werden. Zumindest scheint es Sinn zu machen immer einigermassen Aktuell zu sein. Wer z.B. jetzt schon den 2.6 Test-Kernel drauf ist schon seit langem vor dem mmap-Bug sicher.
Wer von den einfachen DSL Usern betreibt einen rsync oder CVS Server, die einfachen User bieten immer weitsaus weniger Angriffspunkte, genauso wie es so gut wie unmöglih ist einen Winuser, der ne Personal Firewall hat und keine Dienste laufen hat zu hacken, erst laufende Dienste beieten einen Angriffspunkt. Das Problem ist sicherlich auch, dass die OpenSourcler oft die Rechner direkt angebunden haben und sich keine teuren Sicherheitslösungen hinstellen, z.B. login nicht direkt über ssh sondern hardware vpn.
Von sputnik1969 am Do, 4. Dezember 2003 um 14:53 #
Wenn schon auf Servern der Distributionen es so einfach ist, wie einfach ist es dann erst beim normalen User der dank DSL-Flat 24h am Netzt hängt? Deutlich schwerer, denn 1. Haben solche User in der Regel alle 24 h eine neue IP und ist 2. nur im Ausnahmefall über einen eigenen Domainnamen aus dem Internet heraus auffindbar und 3. Hat man fast nie irgendwelche Vorteile von der Übername eines solchen Rechners...Sowas machen also in der Regel nur Script-Kiddies die sich ausprobieren wollen, und wieviele Millionen Script-Kiddies existieren???
Was für ein Blödsinn! Es ist doch wohl ein Unterschied, ob ich mir mit einem unvorsichtigen Klick auf ein mail attachement meine HD löschen kann (wie in meiner WIN XP Umgebung) oder ob ein hochverfügbarer Server von Externen angegriffen wird. Bitte nicht Äpfel und Birnen vergleichen.
[...] und werden diesen erst wieder in Betrieb nehmen, wenn die Integrität vollständig überprüft wurde.
Zudem wird der Server natuerlich komplett neu installiert.
Was auch aus obiger Meldung nicht hervorkommt:
rsync.gentoo.org ist ein rotations Server der an verschiedene Mirror weiterleitet. Es wurde nicht der rsync.gentoo.org kompromittiert sondern einer der rsync server.
Ausserdem ist der kompromittierte Server nicht Bestandteil der Gentoo Infrastructure. Der Speicherplatz und die Bandbreite wurde uns von einem Sponsor zur Verfügung gestellt und auch die Verwaltung obligt nicht uns. Deshalb ist dieser Server auch nicht ausschliesslich fuer Gentoo verwendet wurden. Es ist also durchaus möglich das es sich in diesem Fall nur zufällig um einen unserer Server handelte.
Weitere Details werden (soweit ich informiert bin) in Kürze in Form von GLSA's folgen.
Immer dieses fundamentalistische Getue der FSF. Mir hängt dieses so zum Halse heraus. Wenn die doch wenigstens mit diesen Herumpöbeleien und Anfeindungen aufhören würden :-(
Und bezüglich "GNU/Linux": UNIX-Tools haben auch schon andere als Open Source Software nachprogrammiert. Da ist ein Kernel und ein X Window-System erheblich aufwändiger.
Schlimm ist, dass dieses getue von einigen wenigen FSF-Frontleuten stammt. Ich bin mir sicher, dass die Mehrheit der GNU-Contributer nicht so denkt.
hoffentlich wachen jetzt mal ein paar schlafmtzen auf und bringen ihren saustall in ordnung!
Man kann sich nicht schützen vor sachen die noch gar nicht aufgedeckt sind tztztz...
Jetzt kommen wieder die ober gescheiten antworten.
greets
Ferdinand
Willst Du wirklich jeden Bugfix sofort in deinen produktiven Kernel reinnehmen?
- michael
Das ist das was ich die ganze Zeit predige...IMMER UP TO DATE SEIN ist das a und o.
Das ist eib herber Schlag für alle die immer nur mit Uralt-Systemen rummachen.
Gerade in einem Kernel der produktiv genutzt wird muss sofort jeder Bugfic einfliessen !
Viel Spass mit Deiner Strategie. Ich will mir diesen Ärger nicht antun...
Gruss - michael
http://www.heise.de/newsticker/data/ju-04.12.03-001/
Bye
Thorsten
Bye
Thorsten
> Wie sollen die aufwachen wenn es erst seit 2 - 3 tagen einen patch gegen den non-puplic exploit gibt????
du machst dich gerade sehr verdächtig. Die Administratoren der gecrackten Server wissen noch nicht, wie der Einbruch vor sich ging. Damit gibt es nur eine Person, die wissen kann, was für ein Exploit verwendet wurde: der/die Angreifer/in(nnen) selbst. You lose!
> Man kann sich nicht schützen vor sachen die noch gar nicht aufgedeckt sind tztztz...
Aha. Vor ein paar Tagen, bei dem Debian-Exploit hieß es noch: "Kein Wunder, bei der ganzen veralteten Software, die Debian einsetzt, musste das ja mal passieren. Mit Gentoo wäre das nicht passiert!". Jetzt betrifft es einen Server des Gentoo-Projektes und dann heißt es: "Was kann man denn schon gegen einen Exploit ausrichten, gegen den es erst seit 2-3 Tagen einen Patch gibt?" (Was noch dazu falsch ist, denn den Patch gibt es bereits seit mehreren Monaten.)
> Jetzt kommen wieder die ober gescheiten antworten.
Ja, genau.
jwm
Den Patch gibts schon seit längerem aber niemandem war klar das man dadurch root-Zugriff bekommt. Musst dir nur mal den Eintrag im Changelog anschauen:
o Add TASK_SIZE check to do_brk()
Wahrscheinlich wusste bis zur Sache mit den Debian Servern nicht mal Tosatti selber, was er da eigentlich genau gefixt hat.
Gruss
jwm
Mit den anderen Servern der Rotation kann der Datenbestand abgeglichen und verifiziert werden und es ist natürlich weiterhin möglich einen rsync durchzuführen (nur eben nicht mit diesem speziellen Rechner)
Wahrscheinlich kannten sich die Hacker nicht mit den Servern bei Gentoo so genau aus, oder sie wollten bewusst mehr auf etwas aufmerksam machen als grossen Schaden anrichten.
Es ist nach bisherigen Erkenntnissen nichts verändert worden, ws zum Gentoo-RSync gehört.
Der Angreifer hat es wohl auf den anderen Teil des Servers abgesehen, der der Firma gehört und diese Kompromittierung hat gentoo wohl nur "zufällig" betroffen.
Klar ist es trotzdem schiesse für das projekt, aber der Angriff ging (wie bisher bekannt) nicht gegen Gentoo.
We will see.
die wollen zeigen, dass Windows halt doch sicherer ist...
cheers,
erich
Hurra wieder was für Verschwörungstheoretiker!
Full ACK.
MfG
Sicherlich sind einige Linux-User ein wenig hochnäsig in Sachen Sicherheit - Deine primitive Haltung zum Thema ist jedoch einfach nur lächerlich! Im Linuxlager wird dieser Warnschuß ernst genommen und etwas dagegen getan, damit in Zukunft so etwas nicht wieder passiert. Das geht i.A. auch schneller als auf ein Service-Pack zu warten ...
es wird immer Bugs geben, die ausgenutzt werden können und auch werden. Die Frage ist, wie lange brauchen die Admins ihre Kisten auf Vordermann zu bringen.
Wer heute Dienste im Internet anbietet, der braucht auch ein ausgeklügeltes Sicherheitskonzept. Da scheint noch viel Informationsbedarf zu bestehen.
PS Ich persönlich glaube auch nicht an eine M$ oder SCO Theorie.
cu Oliver
Auf einen normalen Web- oder Mailserver können sich von außen nur eine begrenzte Anzahl Personen einloggen (oft auch gar keine). In der Regel stehen die Server auch in einer DMZ hinter einer Firewall, bei Projekten wie Debian oder Savannah ist das gar nicht möglich (bzw. würde nichts bringen, da man ja ssh durchlassen muss).
ronny
ich wollte mal anfragen, wie man feststellen kann, ob jemand in einen Rechner eingedrungen ist, bzw. ob so ein Root-Toolkit installiert wurde. Der Angreifer wird wahrscheinlich sämtliche relevanten Log-Dateien manipulieren, also fallen diese schon mal weg. Gibt es noch andere Möglichkeiten oder Tools ?
Danke im Voraus,
Mike
screne
Hostbased Intrusion Detection => erkennt Änderungen an Dateien
(z.B.: aide, integrit, samhain, tripwire, lids, ...)
Logging auf einem Remoteserver (man syslog-ng)
Forensische Analyse mit z.B. sleuthkit
HTH
draughir
In diesem Zusammenhang ist auch wichtig, dass das root- (und am besten auch das usr-)Dateisystem readonly ist, und zwar nicht nur logisch sondern physikalisch. Neben der Variante, es von CD zu nutzen, gibt es sowohl bei SCSI als auch bei IDE die Möglichkeit, über einen ganz primitiven Schalter die write-Kanäle in der Anschlussleitung zu unterbrechen, wodurch ein Schreiben unterbunden wird. Und durch die inaktiven Capabilities kommt man auch nicht an die Dateisystem-Treiber bzw. den Cache heran, um dort Änderungen vorzunehmen (auch mounts sind dann nicht mehr möglich, ein mount -o move /tmp/sbin /sbin funktioniert also nicht).
Sehr interessant finde ich eine Idee, die letztens auf einer Debian-ML aufgetaucht ist. Dort wurde vorgeschlagen, die SetUID-Funktionen so zu verändern, dass nur noch auf UID>0 gewechselt werden kann. Zudem soll nur noch von 0 aus auf UID kleiner 1024 (sollten für Systemuser vorbehalten sein) gewechselt werden können. Damit verbunden wäre dann auch die Möglichkeit, einzelnen UIDs die Rechte an Ports <64 zu geben, so dass z.B. ein Apache von Anfang an gar keine root-Rechte mehr braucht, und damit einige Scheuentore zugemauert werden. Das ist natürlich kein Allheilmittel, denn der sshd oder zum Teil auf der ftpd (wenn es kein reiner Anon-FTP sein soll) müssen immer noch als root laufen.
interessant finde ich, dass der Einbruch auf dem Gentoo-Server bereits nach einer Stunde bemerkt wurde.
Was für Dienste/Dämons usw. laufen dort, um genau das heraus zu finden ?
Das interessiert mich im Moment etwas mehr.
BTW : Das ein Gentoo-Server gehackt wurde, heißt nicht unbedingt, dass auch Gentoo drauf läuft. Welches OS/Welche Distri da drauf würde ich auch gerne wissen.
Wie ja schon beschrieben in der News, laufen auch andere Dienste von anderen Projekten/Firmen auf dem Server, deswegen wird dessen Name ja auch nicht bekanntgegeben.
erfolgte nach eigenem Bekunden der FSF:
"...irgenwann um den 02.November."
Also brauchten sie volle 4 Wochen um den Einbruch überhaupt zu entdecken,
was wirklich kein gutes Licht auf die Verantwortlichen wirft.
Immerhin auffallend, das so ein wirklich wichtiges "Detail" in der Meldung
komplett unter den Teppich gekehrt wird und man sich viel lieber dem Gentoo-Server
widmet, wo man das Datum des Einbruchs (01.-02.12.) und die Entdeckung (02.12.),
sowie die Zahlen der gefährdeten User (20) korrekt angiebt....
Sebastian.
Gruss
demon
Sebastian.
Immerhin ist das nicht nur unsauber sondern falsch. Einfach nur falsch.
rsync?.*.gentoo.org ist ein Ring mit sehr vielen Mirrors und einer davon wurde geknackt. Einer. Nicht der Haupt-Mirror und auch nicht der zuständige DNS-Server.
cu, Bernd
Manche schreiben eben nur das was sie wissen. Und nicht das was sie zu wissen glauben
===============
Wieso zu wissen "glauben"?
Steht seit heute Nacht im Netz:
http://savannah.gnu.org/statement.html
Oder sind +/- 2-3 Tage, die das "etwa" ausmachen
für dich kein Grund überhaupt zu berichten?
Sebastian.
"the compromised system had both an IDS and a file integrity checker installed".
Entprechende Stelle in der GNU Mitteilung:
" ".
Dauer bis zur Erkennung des Einbruchs:
Gentoo (mit file integrity checker): 1 Tag
GNU Savannah: (ohne File integrity checker): 1 Monat
Wer einen großen öffentlichen Server betreibt, der von Kunden anvertrauten Sourcecode verwaltet, tut gut daran, ein funktionierendes IDS zu benutzen.
Wer auf die nicht zu umgehenden "File Integrity Chercker" wie Tripwire oder AIDE verzeichtet, handelt grob fahrlässig, da einbrüche dann nur zufällig entdeckt werden.
Rootrechte auf einer Maschine, dessen Dateisystem regelmäßig von einer korrekten AIDE oder Tripwire Installation (auf CD) überwacht wird, bringen den Angreifer auch nicht weiter. (Deshalb bitte auf unqualifizierte Kommentare, die Signaturdatei oder das AIDE Binary könnte manipuliert werden, verzichten.)
http://www.cs.tut.fi/~rammer/aide.html
http://sourceforge.net/projects/tripwire/
hat eigentlich schon jemand hier Erfahrung mit AIDE? Ich hab gesehen, daß es erst im Beta Stadium ist. Allerdings hat's bei Debian ja scheinbar gut funktioniert.
Gruß Inga
Steht auch so in dem GLSA.
Was für einen Filesystem Checker setzt ihr denn ein? Tripwire?
Uns wurde der Speicherplatz und die Bandbreite nur gesponsort und es laufen noch andere Dienste für verschiedene Organisationen auf diesem Server.
Es wird noch einiges auf uns zu kommen. Wenn Linux erstmal eine grössere Verbreitung haben sollte, wird es auch zunehmend interessant für Angriffe werden. Zumindest scheint es Sinn zu machen immer einigermassen Aktuell zu sein. Wer z.B. jetzt schon den 2.6 Test-Kernel drauf ist schon seit langem vor dem mmap-Bug sicher.
Deutlich schwerer, denn
1. Haben solche User in der Regel alle 24 h eine neue IP und ist
2. nur im Ausnahmefall über einen eigenen Domainnamen aus dem Internet heraus auffindbar und
3. Hat man fast nie irgendwelche Vorteile von der Übername eines solchen Rechners...Sowas machen also in der Regel nur Script-Kiddies die sich ausprobieren wollen, und wieviele Millionen Script-Kiddies existieren???
Es ist doch wohl ein Unterschied, ob ich mir mit einem unvorsichtigen Klick auf ein mail attachement meine HD löschen kann (wie in meiner WIN XP Umgebung) oder ob ein hochverfügbarer Server von Externen angegriffen wird.
Bitte nicht Äpfel und Birnen vergleichen.
Zudem wird der Server natuerlich komplett neu installiert.
Was auch aus obiger Meldung nicht hervorkommt:
rsync.gentoo.org ist ein rotations Server der an verschiedene Mirror weiterleitet. Es wurde nicht der rsync.gentoo.org kompromittiert sondern einer der rsync server.
Ausserdem ist der kompromittierte Server nicht Bestandteil der Gentoo Infrastructure. Der Speicherplatz und die Bandbreite wurde uns von einem Sponsor zur Verfügung gestellt und auch die Verwaltung obligt nicht uns. Deshalb ist dieser Server auch nicht ausschliesslich fuer Gentoo verwendet wurden.
Es ist also durchaus möglich das es sich in diesem Fall nur zufällig um einen unserer Server handelte.
Weitere Details werden (soweit ich informiert bin) in Kürze in Form von GLSA's folgen.
MfG,
bazik
Immer dieses fundamentalistische Getue
der FSF. Mir hängt dieses so zum Halse
heraus. Wenn die doch wenigstens mit diesen
Herumpöbeleien und Anfeindungen aufhören
würden :-(
Und bezüglich "GNU/Linux": UNIX-Tools
haben auch schon andere als Open Source
Software nachprogrammiert. Da ist ein
Kernel und ein X Window-System erheblich
aufwändiger.
Schlimm ist, dass dieses getue von
einigen wenigen FSF-Frontleuten stammt.
Ich bin mir sicher, dass die Mehrheit
der GNU-Contributer nicht so denkt.