massenhaft versuche "einzubrechen" was kann ich machen
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 Oct 24 20:46:16 alice sshd[5250]: Did not receive identification string from 222.236.47.135 Oct 24 20:52:27 alice sshd[5285]: Invalid user globus from 222.236.47.135 Oct 24 20:52:30 alice sshd[5287]: Invalid user condor from 222.236.47.135 Oct 24 20:52:32 alice sshd[5289]: Invalid user marine from 222.236.47.135 Oct 24 20:52:32 alice sshd[5291]: Invalid user tomcat from 222.236.47.135 Oct 24 20:52:34 alice sshd[5293]: Invalid user cadi from 222.236.47.135 Oct 24 20:52:35 alice sshd[5296]: Invalid user global from 222.236.47.135 Oct 24 20:52:37 alice sshd[5294]: Invalid user marine from 222.236.47.135 Oct 24 20:52:38 alice sshd[5299]: Invalid user cady from 222.236.47.135 Oct 24 20:52:38 alice sshd[5300]: Invalid user upload from 222.236.47.135 und in /var/log/warn Apr 16 05:24:56 alice sshd[7031]: error: PAM: User not known to the underlying authentication module for illegal user avye from 218.241.164.34 Apr 16 05:25:35 alice sshd[7034]: error: PAM: User not known to the underlying authentication module for illegal user avye from 66.197.211.229 Apr 16 05:26:12 alice sshd[7037]: error: PAM: User not known to the underlying authentication module for illegal user avye from 102.155.95.219.klj01-home.tm.net.my Apr 16 05:27:18 alice sshd[7040]: error: PAM: User not known to the underlying authentication module for illegal user awen from 200.87.126.118 Apr 16 05:27:21 alice sshd[7043]: error: PAM: User not known to the underlying authentication module for illegal user awen from sprint-65-160-236-155.smf.ragingwire.net Apr 16 05:28:01 alice sshd[7046]: error: PAM: User not known to the underlying authentication module for illegal user awen from 216.241.173.122 Apr 16 05:28:37 alice sshd[7049]: error: PAM: User not known to the underlying authentication module for illegal user awen from 218.91.210.100 es scheint, dass jemand einzubrechen versucht. was kann ich machen um mich dagegen zu schützen? ich nutze suses firewall und aktualisiere die sicherheitspatches regelmässig. gruss robert -- 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
Guten Tag robert rottermann, am Mittwoch, 28. Oktober 2009 um 07:57 schrieben Sie:
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
Oct 24 20:46:16 alice sshd[5250]: Did not receive identification string from 222.236.47.135 Oct 24 20:52:27 alice sshd[5285]: Invalid user globus from 222.236.47.135 Oct 24 20:52:30 alice sshd[5287]: Invalid user condor from 222.236.47.135 Oct 24 20:52:32 alice sshd[5289]: Invalid user marine from 222.236.47.135 Oct 24 20:52:32 alice sshd[5291]: Invalid user tomcat from 222.236.47.135 Oct 24 20:52:34 alice sshd[5293]: Invalid user cadi from 222.236.47.135 Oct 24 20:52:35 alice sshd[5296]: Invalid user global from 222.236.47.135 Oct 24 20:52:37 alice sshd[5294]: Invalid user marine from 222.236.47.135 Oct 24 20:52:38 alice sshd[5299]: Invalid user cady from 222.236.47.135 Oct 24 20:52:38 alice sshd[5300]: Invalid user upload from 222.236.47.135
und in /var/log/warn Apr 16 05:24:56 alice sshd[7031]: error: PAM: User not known to the underlying authentication module for illegal user avye from 218.241.164.34 Apr 16 05:25:35 alice sshd[7034]: error: PAM: User not known to the underlying authentication module for illegal user avye from 66.197.211.229 Apr 16 05:26:12 alice sshd[7037]: error: PAM: User not known to the underlying authentication module for illegal user avye from 102.155.95.219.klj01-home.tm.net.my Apr 16 05:27:18 alice sshd[7040]: error: PAM: User not known to the underlying authentication module for illegal user awen from 200.87.126.118 Apr 16 05:27:21 alice sshd[7043]: error: PAM: User not known to the underlying authentication module for illegal user awen from sprint-65-160-236-155.smf.ragingwire.net Apr 16 05:28:01 alice sshd[7046]: error: PAM: User not known to the underlying authentication module for illegal user awen from 216.241.173.122 Apr 16 05:28:37 alice sshd[7049]: error: PAM: User not known to the underlying authentication module for illegal user awen from 218.91.210.100
es scheint, dass jemand einzubrechen versucht. was kann ich machen um mich dagegen zu schützen? ich nutze suses firewall und aktualisiere die sicherheitspatches regelmässig.
Entweder verlegst du den Port von SSH und/oder schaust dir mal fail2ban an. Der sperrt die IP von der das probiert wird. sebastian
gruss robert
-- Mit freundlichen Grüßen Sebastian Gödecke mailto:simpsonetti@googlemail.com -- 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
robert rottermann schrieb:
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
Oct 24 20:46:16 alice sshd[5250]: Did not receive identification string from 222.236.47.135 Oct 24 20:52:27 alice sshd[5285]: Invalid user globus from 222.236.47.135 Oct 24 20:52:30 alice sshd[5287]: Invalid user condor from 222.236.47.135 Oct 24 20:52:32 alice sshd[5289]: Invalid user marine from 222.236.47.135 Oct 24 20:52:32 alice sshd[5291]: Invalid user tomcat from 222.236.47.135 Oct 24 20:52:34 alice sshd[5293]: Invalid user cadi from 222.236.47.135 Oct 24 20:52:35 alice sshd[5296]: Invalid user global from 222.236.47.135 Oct 24 20:52:37 alice sshd[5294]: Invalid user marine from 222.236.47.135 Oct 24 20:52:38 alice sshd[5299]: Invalid user cady from 222.236.47.135 Oct 24 20:52:38 alice sshd[5300]: Invalid user upload from 222.236.47.135 ...
es scheint, dass jemand einzubrechen versucht. was kann ich machen um mich dagegen zu schützen? ich nutze suses firewall und aktualisiere die sicherheitspatches regelmässig.
Sicherlich hast Du Deinen sshd so konfiguriert, das er nur!! Public-Key Logins zulässt, dann sind diese Meldungen einfach nur lästige Logeinträge. Falls nicht, dann viel Glück. Außerdem ging das Thema bereits mehrfach durch die Mailingliste. z.B. Stichwort "fail2ban" -- Gruß Axel -- 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 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 -- 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
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
Moin moin, robert rottermann schrieb:
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
es scheint, dass jemand einzubrechen versucht. was kann ich machen um mich dagegen zu schützen? ich nutze suses firewall und aktualisiere die sicherheitspatches regelmässig.
gruss robert
Das ist das übliche Bild eines Servers im Netz ... leider gint halt viele Leute die zuviel Zeit haben ;) Nunja, hier ein kleiner Tipp 1.) Anmelden nur mit Public Key's erzwingen 2.) PAM Auth deaktivieren 3.) root login deaktiviern !! 4.) SSHD auf einen andern Port legen, das knockt schon die meisten dummies aus 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) !! Wenn Du dies sauber einrichtest sollten solche Logfiles sehr rar werden ;) good luck lg M.Heinze -- 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
robert rottermann schrieb:
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
es scheint, dass jemand einzubrechen versucht. was kann ich machen um mich dagegen zu schützen? ich nutze suses firewall und aktualisiere die sicherheitspatches regelmässig.
gruss robert
danke für die antworten, ich hab mal fail2ban installiert. Die andern vorschläge untersuche ich noch. gibt es eine möglichkeit festzustellen, ob wir "gehackt" wurden? danke robert -- 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
gibt es eine möglichkeit festzustellen, ob wir "gehackt" wurden?
Wenn Du glaubst, gehackt worden zu sein, kannst Du nat. der Ausgabe der installierten Programme nicht mehr trauen. Könnten ja kompromitiert sein. Es gab mal bei der IX eine CD, die ich immer nehme, wenn ich das Gefühl habe, da ist ein Fremdling. Auf dieser CD ist eine bash und diverse nützliche Kommandozeilentools, alle statisch gelinkt. Dadurch, daß diese Programme statisch gelinkt sind, und eine CD ja ein ro-Medium ist, sind diese Programme sauber. Dann gucke ich mit netstat auf seltsame Verbindungen oder neue geöffnete Ports, mit top auf unbekannte Ressourcenfresse, und mit df -h, ob irgendwo der Platz zugewachsen ist. Bernd-- 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 28.10.2009, robert rottermann wrote:
es scheint, dass jemand einzubrechen versucht. was kann ich machen um mich dagegen zu schützen?
Login via Passwort verbieten, nur via RSA-Schluessel. Problem geloest. -- 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 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
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. -- 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
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=20 auch DAUs per ssh zugreifen lassen muss. Wenn ich den allen=20 erkl=E4ren m=FCsste, wie sie per key ssh benutzen, m=FCsste ich die=20 Wartungskosten verdoppeln. ;)
2.) PAM Auth deaktivieren
Warum das? Auf jeden Fall pam_abl konfigurieren und benutzen.=20 Wies eigentlich immer fail2ban? Die pam-Module sind alle da. Man=20 muss sie nur installieren und nutzen. Das ist wirklich denkbar=20 einfach.
Hallo Erik, ich hatte lange nichts mehr von pam_abl gehört und darum vermutet, dass ich es als einziger einsetze.... 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? 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 Erik, Erik P. Roderwald schrieb:
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. ;)
Ich glaub das mit den Wartungskosten relativiert sich, wenn erstmal über einen der "schwachen" Zugänge Dein System kompromitiert worden ist. 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? -- Gruß Axel -- 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
Moin moin, Erik P. Roderwald schrieb:
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. ;)
Naja 'neue' Sachen empfinden die meisten User als unbequem und rebellieren, du bist Admin du musst dich durchsetzen gerade bei sicherheitsrelevanten Sachen, hier gehts um essentielle Sachen und nicht darum ob der User ein Hintergrundbild setzen darf oder nicht. Ja weiss dummer Vergleich, so wie die meisten Vergleiche aber ich denk Du verstehst was ich meine. Allerdings ist es manchmal einfach nicht möglich Key's einzusetzen, meist wenn verschiedene Systemgenerationen aufeinandertreffen, in diesem Fall ist 'pam_abl' dringend anzuraten
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.
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.
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. ;)
ACK
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.
Also ich hab die Erfahrung gemacht das dadurch mehr als 90% der Angriffe verschwinden, ist sicherlich immer an die 'Intelligenz' der Bot's gebunden. Ansonsten ist intern ein bebildertes Howto wie der Zugang einzurichten ist,da ausser dem Port auch Zeichensatzcodierung und Terminalstrings zu setzen sind. Es hat sich noch nie jemand darüber beschwert und wer es damit nicht honbekommt sollte auch keinen SSH Zugriff haben.
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.
ist eh erstmal default, dies verhindert das man vergisst es zu setzen, nur wer Zugriff braucht wird wirklich eine Shell bekommen und wenn man das vergisst bekommt man schnell entsprechendes Feedback, andersrum net ;)
hth
Liebe Grüße
Erik
Naja so hat jeder seine Ansichten, wobei denk ich beide den erwünschten Erfolg bringen dürften. lg max -- 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 Donnerstag 29 Oktober 2009, Heinz Diehl wrote:
Wenn eine Maschine "gehackt" wurde, dann ist sie unter fremder Kontrolle.
Das ist richtig.
Alle genannten Massnahmen sind vergeblich.
Das ist so nicht richtig.
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."
Nein, das Zitat passt nicht. Zum einen sprechen wir hier _nicht_ über den Hardwarezugriff (physical access), sondern über einen Zugriff via Netz. Hatte ein Angreifer wirklich Zugriff auf die Hardware, dann wird es sehr viel schwerer, einen Angriff zu entdecken. Zum anderen müssten wir alle Server sofort herunterfahren, wenn das tatsächlich so wäre. Natürlich kann ich mit verschiedenen Maßnahmen zumindest den Verdacht erhärten, dass ein Angriff stattgefunden hat bzw. dass etwas auf dem Server nicht stimmt. Wenn ich diesen _Verdacht_ habe, dann allerdings stimmt der Satz wieder. Es bleibt nur die Neuinstallation, da ich mir nie wirklich sicher sein kann, alles gefunden zu haben.
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. Ich kann zwar theoretisch alles manipulieren, manipuliere ich aber z. B. den TCP/IP-Stack zu sehr, dann funktioniert das Netz nicht mehr und mein gekaperter Server wird nutzlos. Manipuliere ich auf Ebene des Ethernets, dann funktioniert das Netz auch nicht mehr richtig. Wenn ich also direkt z. B. die Ethernetpakete mitlese, dann werde ich, sofern ich weiß, wonach ich suchen muss, auch zumindest den Verdacht erhärten können, dass etwas nicht stimmt. Wie gesagt: Der Verdacht reicht, um neu zu installieren. Im Übrigen sind die meisten Cracks relativ leicht mit den genannten Maßnahmen zu entdecken. Sie wollen ja was mit dem Server anstellen. Beispielsweise hat mal jemand erfolgreich versucht, mir eine Filmtauschbörse unterzuschieben. Den Spuk habe ich nach acht Stunden bei der täglichen Routineüberprüfung mit netstat und dem mc entdeckt. Ein Port zu viel offen und Gigabytes Filmdaten in einem Unterverzeichnis von /srv/www/htdocs. Also Server vom Netz nehmen und via serieller Konsole neu installieren. Glücklicherweise war das kein von mir installierter Server und somit kein Garantiefall. ;) Liebe Grüße Erik -- "Wenn Leute sich in einer Sache wie dem Zigarrenrauchen zu echten Kennern entwickeln, dann muß da ein bißchen mehr dran sein als ein bloßer Reiz für Gaumen und Augen. Man kann viel Freude an solchen Dingen haben, wenn man bereit ist, ein bißchen Zeit zu investieren, um sie richtig kennenzulernen, auch wenn es nicht gleich zur Hauptsache im Leben wird." Francis Ford Coppola 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, 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
Moin moin, Erik P. Roderwald schrieb:
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?
Ich kürz den Rest einfach mal weg, dann muss nich soviel gescrollt werden ;) 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 lg max -- 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
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
On Freitag 30 Oktober 2009, Heinz Diehl wrote:
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.
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.
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.
Das ist richtig. 100% aller Angreifer auf einen Webserver wollen diesen für ihre Zwecke missbrauchen. Dazu müssen sie entweder zusätzliche Ports öffnen oder über geöffenete Ports tunneln. Beides kann ich feststellen. Ich kann z. B. von außen einen Portscan machen oder feststellen, ob die richtige Anwendung auf z. B. Port 80 antwortet. Desweiteren muss dazu zusätzliche Software installiert werden. Auch die kann ich finden vorausgesetzt, ich weiß, was so auf meinem System sein darf. Übrigens ist der mögliche Zweck immer Ausgangspunkt beim Erstellen der Bedrohungsszenarien. Ich muss mir ja erst einmal darüber klar werden, was eigentlich eine Gefahr darstellt, bevor ich sie abwenden kann.
Jetzt denke umgekehrt: was, wenn jemand in dein System eindringt und es so veraendert, dass alle Spuren beseitigt sind? Genau: there is no way...
Das ist etwas anderes. Gefährlich ist ein solcher Angriff aber nur, wenn sensible Daten gestohlen werden sollen. Dann hinterlassen intelligente Angreifer keinerlei Spuren. Hinterher ist wieder alles so wie vorher und demzufolge der Angriff nicht mehr erkennbar. Deshalb sind solche Server auch ganz anders abzusichern als Webserver. Auf solche Server sollte niemand ohne VPN von außen direkten Zugriff haben. Auch sollte hier vor dem Server eine Firewall eingerichtet werden, die alle Zugriffe logt und beim geringsten Anzeichen das Teil vom Netz abklemmt. Wie schon gesagt: Jede Situation verlangt ihr eigenes Sicherheitskonzept. 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
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
Hallo zusammen, 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) das Teil neu aufzubauen. Dass Du die Seiten nicht mehr finden kannst, heißt nicht, dass sie niemals da waren. 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. Liebe Grüße Erik -- "Der Tabak ruft den Trieb zur Ehre und Tugend in allen Menschen wach, die sich seiner bedienen." Molière 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
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
Hi Erik! On Fr, 30 Okt 2009, Erik P. Roderwald wrote:
eingesetzt wird. Das Teil ist doch relativ leicht zu konfigurieren und kann nicht nur für ssh eingesetzt werden.
Das stimmt so auch für fail2ban. Mit freundlichen Grüßen Christian -- :wq -- 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
Hi Erik! On Do, 29 Okt 2009, Erik P. Roderwald wrote:
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. ;)
Das ist eine Frage der Policy. Ich hatte schon in Banken zu tun, bei denen nur ssh mit keys erlaubt war. Ich versteh auch nicht, was daran so schwer oder kompliziert sein soll, richtig eingerichtet mittels ssh-agent oder Putty Pageant unter Windows ist das doch richtig komfortabel. Mit freundlichen Grüßen Christian -- :wq -- 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
Hi Erik! On Fr, 30 Okt 2009, Erik P. Roderwald wrote:
Das ist etwas anderes. Gefährlich ist ein solcher Angriff aber nur, wenn sensible Daten gestohlen werden sollen. Dann hinterlassen intelligente Angreifer keinerlei Spuren. Hinterher ist wieder alles so wie vorher und demzufolge der Angriff nicht mehr erkennbar. Deshalb sind solche Server auch ganz anders
So? Du hälst also die Gefährdung anderer durch deine Hardware-Ressourcen für "ungefährlich"? Mit freundlichen Grüßen Christian -- :wq! -- 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, Al Bogner wrote:
Auch nicht in den Logs?
Nein, auch nicht in den Logs. Auch der User, unter dem die Seite zu sehen war, muss nicht mehr existieren. Also wenn ich sowas machen würde, dann so: Erstmal Server kapern. Habe ich einmal root-access, dann bin ich ja bekanntlich Gott und darf alles. ;) Also schalte ich erstmal alles, was mit logs zu tun hat, aus. Zumindest die logs, die mich verraten könnten. Das, was schon drin steht (also z. B. mein login als root), lösche ich. Etwas mehr Arbeit macht das geschicktere Vorgehen, nur das nicht mitzulogen, was mich verraten könnte. Ansonsten entstehen ja komische Löcher in den Logs. Nun will ich also eine Phishing-Seite unterbringen. Dazu lege ich ein neues Verzeichnis an. Dein Angreifer hat offenbar auch gleich einen neuen User angelegt. Da ja nicht mehr gelogt wird, erscheint davon auch nichts in den logs. Dann lege ich meine Seite ab und warte auf die Pins und Tans. Erfahrungsgemäß reagiert nach ein paar Stunden irgendjemand und diese Seite ist verbrannt. Also kann ich sie wieder löschen, den User auch wieder und zum Schluss schalte ich das Log wieder ein. Das war's. Spuren findest Du keine mehr, wenn ich sauber gearbeitet habe. Der Angreifer hat aber immer noch den root-Zugang. Liebe Grüße Erik -- "Tabak verwandelt Gedanken in Träume." Victor Hugo 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
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
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
Erik P. Roderwald schrieb:
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?
Naja, ob ich so einen Server noch haben möchte sei mal dahin gestellt. Wie oben schon mal genannt, besteht wahrscheinlich jederzeit die Gefahr eines erneuten Einbruchs! Nicht gut.. gar nicht gut. -- Gruß Axel -- 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, 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, oder er hat einen (unbekannten) Fehler in einem Server ausgenutzt, oder Du hast irgendetwas übersehen. Schicke mir doch mal die URL. Dann mache ich mal einen Portscan 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. Alles weitere wird dann auf einer alleine stehenden Maschine untersucht. 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.
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. :( Liebe Grüße Erik -- "Beim Tabak wie überall kommt man mit Ruhe und Erfahrung am weitesten." Jean Fernand Giono 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
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
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
Hallo zusammen, On Freitag 30 Oktober 2009, Al Bogner wrote:
Can the login via the webinterface be diasbled?
not on purpose.
Diese web interfaces. Ich hasse sie. Die fliegen immer als allererstes vom Server, wenn ein neuer angemietet wird. ;) So lange dieser Mist läuft, kannst Du auch auf keys verzichten. ;) Im Ernst, wovon reden wir? Vom Login beim Betreiber, um den Server z. B. neu zu starten oder zurückzusetzen? Oder von einem dieser "Administrationstools"? Auf jeden Fall auch dort das PW ändern. Liebe Grüße Erik P.S.: Alles weitere per pm. -- "Eine Cigarre genießen hat mit Lebenskultur, mit Savoir-vivre zu tun." Zino Davidoff 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 in /etc/security/pam_abl.conf? 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 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
participants (14)
-
Al Bogner -
Arno Lehmann -
Axel Birndt -
Christian Brabandt -
Erik P. Roderwald -
Fred Ockert -
hamann.w＠t-online.de -
Heinz Diehl -
Joerg Thuemmler -
Lentes, Bernd -
Markus Heinze -
Mathias Homann -
robert rottermann -
Sebastian Gödecke