Mathias Homann schrieb:

Am Mittwoch 28 Oktober 2009 schrieb robert rottermann:

...

hoi zäme, ich hab mal die logs eines suse 11.1 (vor kurzem von 10.? upgedated) rechner angeschaut. da finde ich massenhaft meldungen in /var/log/messages von der art

(ssh brute force attack logs)

da kannst du gar nix machen ausser ssh von aussen zu zu machen... dann kannst du selber aber auch nicht mehr vom internetcafe aus "nach hause telefonieren".

Empfehlenswerte sicherheitsmassnamen:

ssh so konfigurieren dass nur bestimmte user von draussen rein dürfen, und das auch nur mit ssh key statt passwort.

bye, mh

Hi, auch eine zeitliche Beschränkung des Zugangs kann sinnvoll sein, falls sie für Dich paßt (geht aber wahrscheinlich nicht mit der Standard-Firewall). Kommt drauf an, was der Rechner tut. cu jth -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hallo zusammen, On Mittwoch 28 Oktober 2009, Markus Heinze wrote:

Nunja, hier ein kleiner Tipp

1.) Anmelden nur mit Public Key's erzwingen

Das ist nicht immer praktikabel. Ich betreue Server, auf die ich auch DAUs per ssh zugreifen lassen muss. Wenn ich den allen erklären müsste, wie sie per key ssh benutzen, müsste ich die Wartungskosten verdoppeln. ;)

2.) PAM Auth deaktivieren

Warum das? Auf jeden Fall pam_abl konfigurieren und benutzen. Wies eigentlich immer fail2ban? Die pam-Module sind alle da. Man muss sie nur installieren und nutzen. Das ist wirklich denkbar einfach.

3.) root login deaktiviern !!

Der ist afaik von vornherein deaktiviert. Alles andere ist Wahnsinn. Das gilt natürlich nicht für gemietete Server. Da kriegt man meist erstmal nur das root-Passwort. Dann ist das erste, was man tut, den Zugang für root zu sperren. Nein, das zweite. Erst muss ein anderer user eingerichtet werden. Und eine Konsole immer schön offen halten, falls was schief geht. ;)

4.) SSHD auf einen andern Port legen, das knockt schon die meisten dummies aus

Bringt nicht wirklich was außer Ärger mit den usern. Jedes Mal, wenn die einen neuen SSH-Client installiert haben, muss man denen erklären, dass sie einen anderen Port einstellen müssen. Der kann ruhig so bleiben, wie er ist.

5.) ggf. denyhosts einführen, dann wird der Angreifer nach x fehlversuchen gesperrt für Zeit x, aber vorsicht das kann einen auch selbst treffen (bei zu vielen fehlerhaften logins) !!

Auf jeden Fall IPs und auch user nach zu vielen Fehlversuchen für eine Stunde (oder bei noch mehr Versuchen) auch mal so für einen Tag aussperren. Das hilft ungemein. Vor dieser Maßnahme konnte ich meine Wände mit den Logeinträgen täglich neu tapezieren. Nach einer Weile spricht sich das rum und siehe da, heute hatte ich genau 0 Einträge, die auf einen Brute-Force-Angriff hinweisen würden. Endlich kann man /var/log/messages wieder lesen und findet die relevanten Dinge gleich. ;) Und noch ein letztes. Um das Risiko möglichst gering zu halten, kann man auch bei Usern, die sowieso nicht ssh nutzen sollen, in /etc/passwd die Standardshell auf /bin/false einstellen. hth Liebe Grüße Erik -- "Du atmest einfach aus und läßt den Rauch ziehen, und schon verbreitet sich eine friedliche Stille." Carlos Fuente jun. Erik P. Roderwald * Uhlenhoffweg 18 * 21129 Hamburg Telefon: +49 (0)40 8510 3150 * Fax: +49(0)40 8510 3148 http://www.zigarren-rollen.de http://www.roderwald.de http://blogs.roderwald.de http://forum.roderwald.de http://twitter.com/erikrode -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hallo zusammen, On Freitag 30 Oktober 2009, hamann.w@t-online.de wrote:

ich hatte lange nichts mehr von pam_abl gehört und darum vermutet, dass ich es als einziger einsetze....

*g* Das wundert mich auch immer wieder, dass es so selten eingesetzt wird. Das Teil ist doch relativ leicht zu konfigurieren und kann nicht nur für ssh eingesetzt werden.

Bei mir tritt das Problem auf, dass sshd nicht immer pam_abl aufruft - z.B. wenn in einer ssh Verbindung alle drei PW-Versuche ausgenutzt werden. Deshalb läuft noch ein Prozess nebenbei, der die Datenbank von pam_abl mit Einträgen aus dem Logfile befüllt. Die betreffenden Kisten laufen mit suse 10.1 oder älter. Hast du den Effekt auch beobachtet?

Nein, den Effekt hatte ich bisher nicht. Wenn die Passwortversuche aufgebraucht sind, dann setzt die Sperre ein und laut meinen Logs reagiert darauf auch pam_abl. Da steht immer schön drin, dass der Benutzer oder die IP gesperrt ist, ab wann und wie lange. Zugriff ist dann nicht mehr möglich. Ich richte übrigens immer einen zweiten Benutzer mit einem sehr langen und exotischen Benutzernamen und elend langem Passwort ein, damit ich, falls mal meine Benutzername gesperrt sein sollte, noch eine Hintertür habe. ;) Liebe Grüße Erik -- "Die meisten jagen so sehr dem Genuß nach, daß sie an ihm vorbeilaufen." Søren Kierkegaard Erik P. Roderwald * Uhlenhoffweg 18 * 21129 Hamburg Telefon: +49 (0)40 8510 3150 * Fax: +49(0)40 8510 3148 http://www.zigarren-rollen.de http://www.roderwald.de http://blogs.roderwald.de http://forum.roderwald.de http://twitter.com/erikrode -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

...

Hallo zusammen,

On Freitag 30 Oktober 2009, hamann.w@t-online.de wrote:

...

ich hatte lange nichts mehr von pam_abl geh=F6rt und darum vermutet, dass ich es als einziger einsetze....

*g* Das wundert mich auch immer wieder, dass es so selten=20 eingesetzt wird. Das Teil ist doch relativ leicht zu=20 konfigurieren und kann nicht nur f=FCr ssh eingesetzt werden.

...

Bei mir tritt das Problem auf, dass sshd nicht immer pam_abl aufruft - z.B. wenn in einer ssh Verbindung alle drei PW-Versuche ausgenutzt werden. Deshalb l=E4uft noch ein Prozess nebenbei, der die Datenbank von pam_abl mit Eintr=E4gen aus dem Logfile bef=FCllt. Die betreffenden Kisten laufen mit suse 10.1 oder =E4lter. Hast du den Effekt auch beobachtet?

Nein, den Effekt hatte ich bisher nicht. Wenn die=20 Passwortversuche aufgebraucht sind, dann setzt die Sperre ein=20 und laut meinen Logs reagiert darauf auch pam_abl. Da steht=20 immer sch=F6n drin, dass der Benutzer oder die IP gesperrt ist, ab=20 wann und wie lange. Zugriff ist dann nicht mehr m=F6glich.

Hallo Erik, ich habe es gerade noch mal ausprobiert - erst nach drei Versuchen wird der Zugriff eingetragen, d.h. ein Automat, der immer einen Versuch macht und dann neu verbindet, landet erst gar nicht im Log Meine pam config beginnt mit #%PAM-1.0 auth required pam_unix2.so debug # set_secrpc auth required pam_abl.so config=/etc/security/pam_abl.conf auth required pam_country.so allow=de,priv Wolfgang Hamann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

...

Hallo zusammen,

On Freitag 30 Oktober 2009, hamann.w@t-online.de wrote:

...

ich habe es gerade noch mal ausprobiert - erst nach drei Versuchen wird der Zugriff eingetragen, d.h. ein Automat, der immer einen Versuch macht und dann neu verbindet, landet erst gar nicht im Log

Hmmm, bei mir wird das sofort eingetragen. Was steht denn=20 in /etc/security/pam_abl.conf?

Hallo Erik, die pam_abl.conf legt ja nur fest, wann jemand ausgesperrt wird, also host_rule=*:2/10s,3/1m,5/1h,10/1d Wer zwei Versuche mit weniger als 10 s Abstand macht, löst aus usw. in sshd_config habe ich an relevanten EInträgen PasswordAuthentication no - es kann sein, dass es anders gar nicht ging UsePAM yes Wolfgang Hamann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hallo zusammen, On Freitag 30 Oktober 2009, Axel Birndt wrote:

Ich glaub das mit den Wartungskosten relativiert sich, wenn erstmal über einen der "schwachen" Zugänge Dein System kompromitiert worden ist.

Das sehen die Kunden immer anders. ;) Die Zugänge sind übrigens nicht schwach. Da gibt es noch die ein oder andere Maßnahme, die durchaus ausreichen, um sich die Plage vom Hals zu halten. Wir sprechen hier ja, denke ich, über normale Server wie z. B. einen Webserver. Sind wertvolle Daten zu schützen, sieht die Sache ganz anders aus. Eine weitere Maßnahme, die ich z. B. immer ergreife, ist das Einschränken des Rechts, sich zu root zu machen, auf meine Person und allenfalls noch ein Kollege meines Vertrauens. Normale user dürfen das gar nicht. Dann muss ein Angreifer schon meinen Benutzernamen und meine beiden Passwörter (Benutzerpasswort und root-Passwort) erraten, um erfolgreich zu sein. Natürlich benutze ich nur sehr starke Passwörter aus mindestens zehn Zeichen, die überhaupt keinen Sinn ergeben (zumindest nicht für andere).

Naja, ob ein Dau wirklich ssh-Zugriff braucht, sei auch mal dahin gestellt. Ich würde davon abraten. Wenn der "Dau" mit Public-Key nicht umgehen kann, kann er meiner Meinung nach auch nicht mit der Shell umgehen. Und wenn er mit der Shell nicht umgehen kann, braucht er auch keinen SSH-Zugang, oder?

Naja, mußt Du wissen wie Du es machst.

Ich vermute mal, Deine Dau's brauchen den Zugriff nur um Files auf das System zu kopieren?? =>> Dann lieber per ftp zugreifen lassen, oder?

Das erste Argument ist einfach ein ökonomisches: Wenn der Kunde es will, dann bekommt er einen shell-Zugang. Er zahlt ja schließlich. Klar hinterfrage ich den Wunsch. Aber letztlich bin ich der Dienstleister meiner Kunden und muss als solcher machen, was gewünscht wird. Will ich das nicht, muss ich den Kunden aufgeben. Auch das habe ich schon gemacht. Kunden, die root-Zugriff haben wollen, lehne ich in der Regel ab. In meinen Fällen brauchen sie den Zugriff tatsächlich, da sie Skripte starten müssen. Klar könnte man das auch auf andere Weise regeln. Aber da tritt wieder das erste Argument in Kraft. Der Kunde will es halt so schon allein deshalb, weil das Programmieren entsprechender Webinterfaces mit der dann wieder dazugehörenden Benutzer- und Rechteverwaltung zu teuer ist. Liebe Grüße Erik -- "Du atmest einfach aus und läßt den Rauch ziehen, und schon verbreitet sich eine friedliche Stille." Carlos Fuente jun. Erik P. Roderwald * Uhlenhoffweg 18 * 21129 Hamburg Telefon: +49 (0)40 8510 3150 * Fax: +49(0)40 8510 3148 http://www.zigarren-rollen.de http://www.roderwald.de http://blogs.roderwald.de http://forum.roderwald.de http://twitter.com/erikrode -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hallo zusammen, On Freitag 30 Oktober 2009, Markus Heinze wrote:

Allerdings ist es manchmal einfach nicht möglich Key's einzusetzen, meist wenn verschiedene Systemgenerationen aufeinandertreffen, in diesem Fall ist 'pam_abl' dringend anzuraten, wenn möglich würde ich mich trotzalledem für Key's entscheiden, dies mach ich jetzt seit knapp 6 Jahren und niemand hat damit ein Problem.

Sicher ist das Einrichten des Zugriffs nur mit keys der sicherste, sofern alle damit umgehen können. Er wird aber höchst unsicher, wenn man sich nicht auf die user und den sicheren Umgang mit den private keys verlassen kann. Das fängt schon mit der Übermittlung der keys an. Wie mache ich das, wenn mein neuer user (wie jetzt gerade wieder) in Mainz und ich in Hamburg sitze? Wie kriegt der seinen key so, dass er nicht unterwegs abgefangen werden kann? Da gibt es zwei Methoden: Ich schicke ihm eine Diskette/CD per Post. Weiß ich, wer die Post am anderen Ende öffnet? Weiß ich, was der user nach Einspielen des keys mit dem Datenträger macht? Die zweite Methode wäre die verschlüsselte Email. Einigermaßen sicher, aber ich muss dem user erst erklären, wie man denn eine verschlüsselte Email öffnet. Ich muss die Verschlüsselungssoftware installieren. Da ich aber nicht vor Ort bin, muss das der user selbst oder sein Admin tun. Ein Haufen Aufwand, der (leider, leider, leider) auch von vielen Firmenadmins nicht eingesehen wird. Dann kommt das nächste Problem. Der private Schlüssel muss ja irgendwo liegen. Weiß ich, ob er da auch sicher liegt? Oder hat der user den womöglich in einem Verzeichnis liegen, das auch von anderen in der Firma gelesen werden kann? Wenn ich auf all das Einfluss hätte, dann würde ich wahrscheinlich auch zu diesen Maßnahmen greifen. Aber in meiner Situation, in der sich die user auf verschiedene Behörden und Firmen verteilen und dann auch noch über das gesamte Bundesgebiet, ist das mit den keys nicht wirklich praktikabel. Liebe Grüße Erik -- "Du atmest einfach aus und läßt den Rauch ziehen, und schon verbreitet sich eine friedliche Stille." Unbekannter Autor Erik P. Roderwald * Uhlenhoffweg 18 * 21129 Hamburg Telefon: +49 (0)40 8510 3150 * Fax: +49(0)40 8510 3148 http://www.zigarren-rollen.de http://www.roderwald.de http://blogs.roderwald.de http://forum.roderwald.de http://twitter.com/erikrode -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hallo zusammen, On Freitag 30 Oktober 2009, Markus Heinze wrote:

Ich kürz den Rest einfach mal weg, dann muss nich soviel gescrollt werden ;)

Wohltuend. :)

Nunja es gibt genügend Fernwartungstools die dies sicher ans Ziel befördern und zwar genau auf den Rechner wo es hingehört und dies wiederum verschlüsselt. Dies hat zwei entscheidende  Vorteile

1. Ich weiss genau das die Daten dort landen wo ich sie hinhaben will 2. kann ich in weniger als 10min alles selbst einrichten, sodass der Kunde es sofort nutzen kann, keine Probleme mit irgendwelchen Missverständnissen, dies spart Zeit und Geld, sowohl meines als auch das des Kunden, das macht nicht nur einen guten Eindruck sondern vermittelt auch die eigene Kompetenz und bindet damit die Kundschaft

Einverstanden. Aber dazu muss ich wieder die Software irgendwie auf dem Zielrechner erstmal installieren. Darf ich das, dann ist das kein Problem. Aber ich habe es mit Behörden und behördenähnlichen Institutionen in fünf verschiedenen Bundesländern zu tun. Und Behördenadmins von etwas zu überzeugen, ist keine leichte Sache. Nur mal so als Beispiel: Letzt hatte ich eine Diskussion mit so einem und der kannte noch nicht einmal den Unterschied zwischen TTL und Time out. Was soll man dazu noch sagen? Im Übrigen würde ich auch keinem Fremden remote-Zugriff auf meine Rechner erlauben. Wo kommen wir denn da hin? ;) Letztlich kommt es mir darauf an, dass die Aussage: "Stell auf keys um und alles ist gut." so nicht richtig ist. Das kann immer nur eine Maßnahme unter vielen sein, um einen öffentlichen Server abzusichern. Und diese Maßnahme ist nicht immer praktikabel und erhöht nicht immer die Sicherheit, sondern setzt sie manchmal auch herab. So ist ein key unverschlüsselt auf einem Notebook sicherlich gefährdeter als das Passwort in meinem Kopf. Mein Notebook kann mir geklaut werden, mein Kopf nicht. Und wenn ich dann lese, dass manche meinen, den key könne man im Internet-Café ins Laufwerk stecken bzw. den Datenträger, auf dem er ist, dann kann ich dazu nur sagen, dass das genauso unsicher ist wie das Eintippen des Passwortes. Eher unsicherer. Dass ein key logger mitläuft, ist eher unwahrscheinlich. Dass sich der Schlüssel noch irgendwo im Cache befindet oder ich schlicht meine CD oder meinen Stick vergesse, passiert schon eher. Kurz gesagt: Es gibt bei dem Thema keine Patentrezepte, sondern immer nur ein umfassendes und der Situation angepasstes Konzept. Liebe Grüße Erik -- "Zuerst schuf der liebe Gott den Mann, dann schuf er die Frau. Danach tat ihm der Mann leid und er gab ihm Tabak." Mark Twain Erik P. Roderwald * Uhlenhoffweg 18 * 21129 Hamburg Telefon: +49 (0)40 8510 3150 * Fax: +49(0)40 8510 3148 http://www.zigarren-rollen.de http://www.roderwald.de http://blogs.roderwald.de http://forum.roderwald.de http://twitter.com/erikrode -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hallo zusammen, On Mittwoch 28 Oktober 2009, robert rottermann wrote:

gibt es eine möglichkeit festzustellen, ob wir "gehackt" wurden?

1. netstat -apnee Den Befehl führe ich täglich aus und zwar nicht automatisiert, sondern ich selbst. Bei dem Ergebnis interssiert einmal, ob wirklich die Ports nur offen sind, die auch offen sein müssen. Die stehen in den Zeilen, in denen "LISTEN" steht. (Wehe, Dein Server spricht Deutsch mit Dir. ;) ) Sind es auch die Prozesse, die diese Ports offen halten sollen? Aber auch die stehenden Verbindungen sind interessant. Auf Port 80 hat man hoffentlich gaaaaanz viele. ;) Aber was tut sich so auf den anderen Ports? Ist da vielleicht eine ssh-Verbindung, von der Du nichts weißt oder sind vielleicht Verbindungen von außen auf Ports, die gar nicht offen sein sollten? 2. ps aux Das mache ich auch täglich. Laufen nur Prozesse, die auch laufen dürfen? Du kennst sie nicht alle? Google ist Dein Freund. ;) Dann lernst Du nebenbei noch Dein System kennen. 3. Verzeichnisse durchsuchen Alle von außen erreichbaren Verzeichnisse (also z. B. per http) nach Dateien durchsuchen, die da nicht hingehören. Außerdem auch Verzeichnisse, in denen ausführbare Dateien liegen (also z. B. /usr/bin oder /bin) durchwühlen. Alles noch in Ordnung? Das ist eine langwierige Angelegenheit. 4. Sniffer einsetzen Wenn Du ganz genau wissen willst, was so über Deinen Draht ins große weite Netz hinausgeht, dann kannst Du mittels eines Sniffers mal eine Weile direkt auf der Netzwerkkarte mitloggen. Leider lässt sich das nicht von vornherein vernünftig filtern, da man schon den ganzen Netzverkehr mitschreiben muss, wenn man wissen will, was los ist. In http z. B. kann man eine Menge verstecken. Was Du aber auf keinen Fall mitloggen darfst sind Email-Pakete und andere schützenswerte Daten, die unverschlüsselt übermittelt werden. Das muss schon beim Schreiben gefiltert werden. Entdeckt man was bei den Untersuchungen, dann Neuinstallation. Die Frage ist, wie wahrscheinlich ist es, dass Ihr gehackt wurdet? Wie sehen die Passwörter aus? Dürfen einfache verwendet werden oder zwingst Du die user zu harten Passwörtern? Wie oft werden sie gewechselt? Wie sehen die Benutzernamen aus? Viele gängige Vornamen wie z. B. Hans oder Peter? Oder eher Abkürzungen der Namen oder der Funktion? Sprich wie wahrscheinlich ist es, dass eine solche Wörterbuchattacke Erfolg hatte? Mir hat bisher immer 1. und 2. genügt, um ruhig schlafen zu können. Wie genau Du es brauchst, musst Du abschätzen. ;) Liebe Grüße Erik -- "Kreiere mir eine Zigarre, die so ist wie unser Land, die nach Kuba duftet und den ganzen Saft unseres fruchtbaren Bodens in sich trägt. Sie soll das verkörpern, dass für dieses wunderbare Fleckchen Erde spricht." Fidel Castro als er die Cohiba in Auftrag gab Erik P. Roderwald * Uhlenhoffweg 18 * 21129 Hamburg Telefon: +49 (0)40 8510 3150 * Fax: +49(0)40 8510 3148 http://www.zigarren-rollen.de http://www.roderwald.de http://blogs.roderwald.de http://forum.roderwald.de http://twitter.com/erikrode -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hallo, 29.10.2009 22:35, Heinz Diehl wrote:

On 29.10.2009, Erik P. Roderwald wrote:

...

...

gibt es eine möglichkeit festzustellen, ob wir "gehackt" wurden?

...

1. netstat -apnee 2. ps aux 3. Verzeichnisse durchsuchen 4. Sniffer einsetzen [....]

Wenn eine Maschine "gehackt" wurde, dann ist sie unter fremder Kontrolle. Alle genannten Massnahmen sind vergeblich.

Ich zitiere hier Werner Koch, wenngleich er das Zitierte aus einem ganz anderen Grund und Sachverhalt geschrieben hat, uebertragen passt es doch:

"Please repeat with me: There is no way to avoid or detect backdoors if physical access to the machine has ever been granted."

Wenn die Maschine "gehackt" wurde, und der Eindringling Zugriff hat/hatte, dann soltest du dir im Klaren sein, dass er alles manipulieren kann. Du wirst keine Chance haben, das zu entdecken.

In diesem Falle gibt es doch eine kleine Chance: du hast eine Checksummen Datenbank auf einem externen Medium (CD-R), das von (d)einem nachweislich unkompromittierten System vor dem Event gemacht wurde.

Stichwort: aide.

Andere Stichworte: Bacula und Verify-Jobs. Damit /etc /sbin /usr/sbin /bin /usr/bin (und ggf. alles andere was sich nicht ändern soll) überwachen. Wenn dann noch die Datenbank auf einem anderen Server liegt - bestens :-) Arno -- Arno Lehmann IT-Service Lehmann Sandstr. 6, 49080 Osnabrück www.its-lehmann.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

On 30.10.2009, Erik P. Roderwald wrote:

Nein, das Zitat passt nicht. Zum einen sprechen wir hier _nicht_ über den Hardwarezugriff (physical access), sondern über einen Zugriff via Netz.

Ja, deswegen hatte ich auch geschrieben, dass es nicht ganz passt. Vergiss das olle Zitat einfach :-) Der Sachverhalt bleibt dennoch der gleiche.

...

Wenn die Maschine "gehackt" wurde, und der Eindringling Zugriff hat/hatte, dann soltest du dir im Klaren sein, dass er alles manipulieren kann. Du wirst keine Chance haben, das zu entdecken.

Cracker kochen auch nur mit Wasser und müssen sich auch an die Vorgaben des Systems und die Netzwerkspezifikationen halten. [....]

Im Übrigen sind die meisten Cracks relativ leicht mit den genannten Maßnahmen zu entdecken. Sie wollen ja was mit dem Server anstellen. [....]

Wenn der Eindringling root-Rechte erlangt hat, dann ist deine Maschine kompromittiert, und alle Detektivarbeit auf dem Rechner selbst ist vergeblich, da du vom schlimmsten Fall ausgehen musst, dass der Eindringling ueber die besten Faehigkeiten ueberhaupt verfuegt. Wenn die Maschine also erstmal kompromittiert ist, dann gibt es keine Sicherheit mehr, da jeglicher Hinweis auf eine Kompromittierung vom Eindringling manipulierbar ist. Deswegen der Tip mit aide, und deswegen das (entfremdete) Zitat: "There is no way....". Es gibt keinen Weg, dir Sicherheit zu verschaffen mit Mitteln, die gleichzeitig dem Zugriff des Eindringlings ausgesetzt sind, und keine Sicherheit der Daten, die vom Eindringling manipuliert sein koennen. Du rechnest hier damit, dass 99.9% der Eindringlinge mehr oder weniger unsauber vorgehen, und denkst an einen evtl. Zweck, den der Eindringling evtl. damit vorhaben koennte. Jetzt denke umgekehrt: was, wenn jemand in dein System eindringt und es so veraendert, dass alle Spuren beseitigt sind? Genau: there is no way... Nebenbei: ich persoenlich meine es ist unheimlich schwierig, Checksummen-Datenbanken wie die von aide (oder find/sha512 oder was auch immer) nach bereits wenigen Tagen korrekt zu interpretieren, wenn man nicht ueber sehr tiefgreifendes Verstaendnis aller Prozesse und Datenstrukturen auf einem modernen Linux-System verfuegt. Zu vieles wird im Hintergrund geoeffnet und dynamisch manipuliert... -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Am Freitag 30 Oktober 2009 12:12:17 schrieb Erik P. Roderwald:

Einverstanden. Es muss beim geringsten Verdacht neu installiert werden. Wird ein erfolgreicher Angriff entdeckt, gibt es keine andere sichere Möglichkeit, evtl. installierte Schadsoftware wieder los zu werden. Vollkommen einverstanden. Es ging aber erst einmal darum, die Tatsache, ob ein Angriff stattgefunden hat, festzustellen, und nicht um die Beseitigung der Folgen. Bei der Beseitigung der Folgen gebe ich Dir vollkommen recht. No way.

Genau damit schlage ich mich gerade rum. War da wirklich wer im System oder ist es das Ergebnis externer "Spielereien". Ich erhielt zu mehreren Domains ein ähnliches Mail. Rufe ich die angebliche Phishing-Seite auf, so existiert sie nicht. Zugriff per ssh ist nur über Keys möglich. Müsste ich nicht irgendwo im System Namen des angeblichen Phishing-Links finden? Die einfachste Erklärung wäre, dass irgendwer einen Link gesetzt hat und Google den dann aufgrund der Begriffe gesperrt hat. _______________ Return-Path: <3dc7oSgcKCncijmZkgtbjjbgZ.XjhkjnohVnoZmWjbiZm.kmdq.Vo@phishing.bounces.google.com> X-Original-To: $localuser@localhost.local.localdomain.tld Delivered-To: $localuser@localhost.local.localdomain.tld Received: from localhost (localhost [127.0.0.1]) by sv.local.localdomain.tld (Postfix) with ESMTP id BCCE942D9F4 for <$localuser@localhost.local.localdomain.tld>; Thu, 29 Oct 2009 00:15:18 +0100 (CET) X-Virus-Scanned: amavisd-new at local.localdomain.tld Authentication-Results: sv.local.localdomain.tld (amavisd-new); dkim=pass header.i=@google.com Authentication-Results: sv.local.localdomain.tld (amavisd-new); domainkeys=pass header.from=noreply@google.com Received: from sv.local.localdomain.tld ([127.0.0.1]) by localhost (sv.local.localdomain.tld [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rm4CVSAbWaIF for <$localuser@localhost.local.localdomain.tld>; Thu, 29 Oct 2009 00:15:12 +0100 (CET) Received: from sv.local.localdomain.tld (localhost [127.0.0.1]) by sv.local.localdomain.tld (Postfix) with ESMTP id C824D2BDC09 for <$localuser@localhost>; Thu, 29 Oct 2009 00:15:12 +0100 (CET) Delivery-date: Thu, 29 Oct 2009 00:06:32 +0100 Received: from mail.utanet.$ [213.90.36.103] by sv.local.localdomain.tld with POP3 (fetchmail-6.3.9-rc2 polling mail.utanet.$ account $username) for <$localuser@localhost> (single-drop); Thu, 29 Oct 2009 00:15:12 +0100 (CET) Received: from solitaire.xoc.tele2net.at ([213.90.36.15]) by mary.xoc.tele2net.at with esmtp (Exim 4.69) (envelope-from <3dc7oSgcKCncijmZkgtbjjbgZ.XjhkjnohVnoZmWjbiZm.kmdq.Vo@phishing.bounces.google.com>) id 1N3Hb6-0006Zu-KV for $localpart@utanet.$; Thu, 29 Oct 2009 00:06:32 +0100 Received: from m1.dnsix.com ([66.11.225.176]) by solitaire.xoc.tele2net.at with esmtp (Exim 4.69) (envelope-from <3dc7oSgcKCncijmZkgtbjjbgZ.XjhkjnohVnoZmWjbiZm.kmdq.Vo@phishing.bounces.google.com>) id 1N3Hb5-0003U2-KF for $localpart@utanet.$; Thu, 29 Oct 2009 00:06:32 +0100 Received: from [209.85.222.227] (helo=mail-pz0-f227.google.com) by m1.dnsix.com with esmtp (Exim 4.63) (envelope-from <3dc7oSgcKCncijmZkgtbjjbgZ.XjhkjnohVnoZmWjbiZm.kmdq.Vo@phishing.bounces.google.com>) id 1N3Hb4-0002CR-R9 for postmaster@angebliche.phishing.domain; Wed, 28 Oct 2009 16:06:30 -0700 Received: by pzk24 with SMTP id 24so371179pzk.11 for <postmaster@angebliche.phishing.domain>; Wed, 28 Oct 2009 16:06:29 -0700 (PDT) Received-SPF: neutral (solitaire.xoc.tele2net.at: domain of 3dc7oSgcKCncijmZkgtbjjbgZ.XjhkjnohVnoZmWjbiZm.kmdq.Vo@phishing.bounces.google.com is neutral about designating 66.11.225.176 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:auto-submitted:received:message- id :date:subject:from:to:content-type; bh=4c5t09T4RP/cuZbb7N0jWmErmFmdbKncIEznpX/1HAA=; b=hl7pZH/+M61gOw+JN6KJfR8kqG4OXt8OtmDIannysmu/LLYprX3JUzmJ9w7Ch6gjxD edfFA4Cxus/eDtcAARjA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:auto-submitted:message-id:date:subject:from:to :content-type; b=uhkkRsNvNi6hPVbMFeRqlU1e/qRO1Pm3cVW/oOx2oUSUNZERomyYqKS7GK6OXzBh7k B8ZLi7eLNzEp3HT4yl6w== MIME-Version: 1.0 Auto-Submitted: auto-generated Received: by 10.142.74.4 with SMTP id w4mr2363299wfa.5.1256771189788; Wed, 28 Oct 2009 16:06:29 -0700 (PDT) Message-ID: <001636e1fbb054d317047706d8d5@google.com> Date: Wed, 28 Oct 2009 23:06:29 +0000 Subject: Phishing notification regarding angebliche.phishing.domain From: noreply@google.com To: abuse@angebliche.phishing.domain, admin@angebliche.phishing.domain, administrator@angebliche.phishing.domain, contact@angebliche.phishing.domain, info@angebliche.phishing.domain, postmaster@angebliche.phishing.domain, support@angebliche.phishing.domain, webmaster@angebliche.phishing.domain Content-Type: multipart/alternative; boundary=001636e1fbb054d307047706d8d2 X-DCC-UTA-Metrics: solitaire.xoc.tele2net.at 32731; Body=1 Fuz1=1 Fuz2=1 X-TELE2-DKIM-Check: header.i=@google.com result:good X-Virus-Scanned: Yes, on solitaire.xoc.tele2net.at X-Spam-Score-Int: 30 X-Spam-Checker: Spamassassin 3.2.5 on solitaire.xoc.tele2net.at X-TELE2-Spam-Relay-Countries: US US X-UIDL: J\B!!(/d"!1mM"!Q;o"! Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: X-KMail-MDN-Sent: Dear site owner or webmaster of angebliche.phishing.domain, We recently discovered that some pages on your site look like a probable phishing attack, in which users are encouraged to give up sensitive information such as login credentials or banking information. We have begun showing a warning page to users who visit this site in certain browsers that receive anti-phishing data from Google, as well as users redirected to this site from various Google properties. Below are one or more example URLs on your site which appear to be part of a phishing attack: http://www.angebliche.phishing.domain/~dbean/components/com_letterman/images... cards;jsessionid=0000pDFvvK08lyoIpQOFOAhC_Ct11j74l29q/ Here is a link to a sample warning page: http://www.google.com/interstitial?url=http%3A//www.angebliche.phishing.doma... cards%3Bjsessionid%3D0000pDFvvK08lyoIpQOFOAhC_Ct11j74l29q/ We strongly encourage you to investigate this immediately to protect users who are being directed to a suspected phishing attack being hosted on your web site. Although some sites intentionally host such attacks, in many cases the webmaster is unaware because: 1) the site was compromised 2) the site doesn't monitor for malicious user-contributed content If your site was compromised, it's important to not only remove the content involved in the phishing attack, but to also identify and fix the vulnerability that enabled such content to be placed on your site. We suggest contacting your hosting provider if you are unsure of how to proceed. Once you've secured your site, and removed the content involved in the suspected phishing attack, or if you believe we have made an error and this is not actually a phishing attack, you can request that the warning be removed by visiting http://sb.google.com/safebrowsing/report_error/ and reporting an "incorrect forgery alert." We will review this request and take the appropriate actions. Sincerely, Google Search Quality Team _______________ Al -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Am Freitag 30 Oktober 2009 12:52:55 schrieb Erik P. Roderwald: Hallo Erik,

On Freitag 30 Oktober 2009, Al Bogner wrote:

...

Ich erhielt zu mehreren Domains ein ähnliches Mail. Rufe ich die angebliche Phishing-Seite auf, so existiert sie nicht. Zugriff per ssh ist nur über Keys möglich.

Hmmmm, bei solchen Mails sollten sämtliche Alarmglocken klingeln. Das wäre für mich ein hinreichender Verdacht, um nach einem Backup (um danach auf einer anderen Maschine ohne Internetzugang schauen zu können, wo denn die Lücke war)

Genau darum geht es, ich habe nicht die geringste Idee, wo ich da Spuren finden könnte. Es bringt mir nichts, neu zu installieren, wenn dann wieder die gleiche Lücke offen wäre. In den Logs fand ich zB nichts.

das Teil neu aufzubauen. Dass Du die Seiten nicht mehr finden kannst, heißt nicht, dass sie niemals da waren.

Auch nicht in den Logs?

Phishing-Sites werden heutzutage sehr schnell entdeckt. Entsprechend schnell wandern sie von einem gecrackten Server auf den anderen.

...

Müsste ich nicht irgendwo im System Namen des angeblichen Phishing-Links finden? Die einfachste Erklärung wäre, dass irgendwer einen Link gesetzt hat und Google den dann aufgrund der Begriffe gesperrt hat.

Das verstehe ich nicht.

Ich beziehe mich auf http://www.angebliche.phishing.domain/~dbean/components/com_letterman/images... cards;jsessionid=0000pDFvvK08lyoIpQOFOAhC_Ct11j74l29q/ Wenn ich das Sytem zB nach dbean durchsuche und zwar mit find, grep und zgrep, sollte ich da nicht etwas finden? Wenn du willst, nenne ich dir per PM die Domain. Al -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Am Freitag 30 Oktober 2009 13:40:13 schrieb Erik P. Roderwald:

war's. Spuren findest Du keine mehr, wenn ich sauber gearbeitet habe. Der Angreifer hat aber immer noch den root-Zugang.

Somit muss ich mich fragen, wie er den root-Zugang erhalten hat. Ich schließe aus, dass er den private-Key erraten konnte. Login per user / pw ist nicht möglich. Also wäre Cross-Site-Scripting denkbar, oder er hat es über das Login beim VPS-Hoster geschafft. Das PW dort ist gut. Alle Pakete sind aktuell. Ich bin etwas ratlos, wie ich mich besser absichern soll. Al -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Am Freitag 30 Oktober 2009 14:41:19 schrieb Erik P. Roderwald: Hallo Erik,

On Freitag 30 Oktober 2009, Al Bogner wrote:

...

...

war's. Spuren findest Du keine mehr, wenn ich sauber gearbeitet habe. Der Angreifer hat aber immer noch den root-Zugang.

Somit muss ich mich fragen, wie er den root-Zugang erhalten hat. Ich schließe aus, dass er den private-Key erraten konnte. Login per user / pw ist nicht möglich. Also wäre Cross-Site-Scripting denkbar, oder er hat es über das Login beim VPS-Hoster geschafft. Das PW dort ist gut. Alle Pakete sind aktuell.

Oder er hatte Hardwarezugriff,

Ok, aber da bin ich mit einem VPS machtlos.

oder er hat einen (unbekannten) Fehler in einem Server ausgenutzt, oder Du hast irgendetwas übersehen.

Also bei den normalen Zugriffsmöglichkeiten, stehe ich etwas an. Vor allem wie der _erneut_ Zugriff bekommen kann. Login per PW geht nicht. Per ssh-key muss er irgendwo seinen Key hinterlassen, oder er hat meinen private-Key von meiner lokalen Maschine. Da könnte man überlegen wo man eine public-key zur Authentifizierung verstecken könnte.

Schicke mir doch mal die URL.

Mache ich gleich. Danke!

Dann mache ich mal einen Portscan

Da sollten nur 80 und 22 offen sein, wenn ich mit nmap nachschaue. nmap -d -sA -n -P0 -p 1-20000 a.b.c.d Starting Nmap 5.00 ( http://nmap.org ) at 2009-10-30 15:44 CET --------------- Timing report --------------- hostgroups: min 1, max 100000 rtt-timeouts: init 1000, min 100, max 10000 max-scan-delay: TCP 1000, UDP 1000, SCTP 1000 parallelism: min 0, max 0 max-retries: 10, host-timeout: 0 min-rate: 0, max-rate: 0 --------------------------------------------- NSE: Loaded 0 scripts for scanning. Initiating ACK Scan at 15:44 Scanning a.b.c.d [20000 ports] Packet capture filter (device eth1): dst host 192.168.178.100 and (icmp or ((tcp or udp or sctp) and (src host a.b.c.d))) ACK Scan Timing: About 15.02% done; ETC: 15:47 (0:02:55 remaining) ACK Scan Timing: About 33.20% done; ETC: 15:47 (0:02:03 remaining) ACK Scan Timing: About 54.27% done; ETC: 15:47 (0:01:17 remaining) ACK Scan Timing: About 78.41% done; ETC: 15:46 (0:00:33 remaining) Completed ACK Scan at 15:46, 155.43s elapsed (20000 total ports) Overall sending rates: 258.01 packets / s, 10320.38 bytes / s. Host a.b.c.d is up, received user-set (0.19s latency). Scanned at 2009-10-30 15:44:22 CET for 156s Interesting ports on a.b.c.d: Not shown: 19998 filtered ports Reason: 19998 no-responses PORT STATE SERVICE REASON 22/tcp unfiltered ssh reset 80/tcp unfiltered http reset Final times for host: srtt: 191058 rttvar: 16288 to: 256210 Read from /usr/share/nmap: nmap-services. Nmap done: 1 IP address (1 host up) scanned in 155.63 seconds Raw packets sent: 40101 (1.604MB) | Rcvd: 159 (8088B)

und schaue, wo man da überall rein kommt. Oder, oder, oder ... Wie das gemacht wurde, wirst Du vielleicht nie erfahren. Aber nach der Mail von google, dass eine Seite in einem public_html-Verzeichnis eines users, der gar nicht da ist, gefunden wurde, würde ich an Deiner Stelle von einem erfolgreichen Angriff einfach mal ausgehen und sofort entsprechende Maßnahmen einleiten.

Die Frage ist was "entsprechende Maßnahmen" sind, wenn nicht im entferntesten erkennbar ist, was ich da tun kann, dass es nicht mehr passiert. Ich kann nur trachten, dass alle Pakete aktuell sind. Als 1. Massnahme, habe ich die Eingabemöglichkieten auf den Homepages reduziert, d.h. Kommentare sind keine mehr möglich, hat sowieso keiner was geschrieben.

Alles weitere wird dann auf einer alleine stehenden Maschine untersucht.

Meine Sicherungen sind keine Vollbackups, enthalten aber eine Liste aller Dateien. Im Zweifelsfall ziehe ich eine Neuinstallation mit Restore der notwendigen Daten vor.

Soll das gerichtsverwertbar werden, dann sind viele Dinge zu beachten. Vor allem muss der Zustand des Servers auf einem nicht mehr veränderbaren Datenträger gesichert werden.

Das kann man vergessen.

...

Ich bin etwas ratlos, wie ich mich besser absichern soll.

Sicher ist nur eines: der Tod. Das ist leider auch in der IT nicht anders. :(

Ich setze den Rechner sofort neu auf, wenn klar ist, wo da wer reingekommen sein kann, Das ist die Antwort vom Hoster:

I am really unsure, if someone gained root-access.

It is highly unlikely. What is more likely is either: 1) somebody exploited a bug/feature in Drupal. 2) nothing is wrong - a false positive. #2 is most likely - many phishing reports turn our to be false positives. Since you were able to confirm the URL google thought was a phishing page doesn't exist, it is a false positive. ----

How often can be tried to login with a wrong username / password at the webinterface?

we can't disclose that information.

Can the login via the webinterface be diasbled?

not on purpose. Al -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Al Bogner schrieb:

Am Freitag 30 Oktober 2009 13:40:13 schrieb Erik P. Roderwald:

...

war's. Spuren findest Du keine mehr, wenn ich sauber gearbeitet habe. Der Angreifer hat aber immer noch den root-Zugang.

Somit muss ich mich fragen, wie er den root-Zugang erhalten hat. Ich schließe aus, dass er den private-Key erraten konnte. Login per user / pw ist nicht möglich. Also wäre Cross-Site-Scripting denkbar, oder er hat es über das Login beim VPS-Hoster geschafft. Das PW dort ist gut. Alle Pakete sind aktuell.

Pakete aktuell ist kein Grund ;-) , verringert nur Angriffschancen. Wie er reinkommt ? Im einfachsten Fall über Anwendungspakete.. wenn du PHP laufen hast, wenn du Scripte hast (Python, Perl ) wenn du Java hast (Tomcat), wenn du eine Datenbank im Hintergrund hast (SQL-Injection).... Alles "theoretisch offene Löcher".

Ich bin etwas ratlos, wie ich mich besser absichern soll.

im einfachsten Fall, indem du deinen Server sauber handelst ... Beispiele ( mal klug dahergeredet...) Eingaben prüfen, alles Zulässige Prüfen, Rest verwerfen (keine "hilfreichen" Fehlermeldungen rausgeben). Pakete permanent aktualisieren, kritische Funktionen ausschalten. Login nur über Key hast du ja schon, hoffen wir also, dass auch das richtige OpenSSH-Paket dazugehört und keines mit vorhersagbaren Hashs. Und natürlich - wenn du eines hattest - hast dun alle Keys neu generiert... Es gab ja vor kurzem ein ssh-Paket, bei dem Keys recht gut erratbar waren, dazu noch ein Brute-Force-Angriff...meinetwegen auch verteilt ..und du warst relativ schnell durch (Tage statt Jahre). Ist nur ein Beispiel... Cross-Site-Scripting wirkt wohl eher auf den Nutzer einer Internetseite. Wenn du natürlich "links" Opfer eines erfolgreichen Angriffs wirst und "rechts" auf deinem (Web)Server eingeloggt bist.... ... gut für Herrn Zahnstein.. :)) Gruesse Fred

Al

-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hallo zusammen, On Freitag 30 Oktober 2009, Christian Brabandt wrote:

So? Du hälst also die Gefährdung anderer durch deine Hardware-Ressourcen für "ungefährlich"?

Nein, natürlich nicht. Aber ein Server, der nach einem erfolgreichen Angriff wieder in den ursprünglichen Zustand versetzt wurde, um alle Spuren zu verwischen, ist in diesem Zustan nicht mehr für andere gefährlich. Oder? Liebe Grüße Erik -- "Als ich die erste Havanna ansteckte, war das mein wahrer Geburtstag." Lord Grade of Elstree Erik P. Roderwald * Uhlenhoffweg 18 * 21129 Hamburg Telefon: +49 (0)40 8510 3150 * Fax: +49(0)40 8510 3148 http://www.zigarren-rollen.de http://www.roderwald.de http://blogs.roderwald.de http://forum.roderwald.de http://twitter.com/erikrode -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org