Ich habe mir kürzlich mal die auth.log auf dem Server angesehen, den ich
betreue. Die war in einem Jahr auf gut 60 MB angewachsen und voll von
Versuchen, mit allen möglichen Usernamen irgendwelche Paßworte
durchzuprobieren. Leider werden die Paßworte, die die Schurken testen,
nicht geloggt...
Eine spezielle Sparte sind Log-Einträge, die vom System als
Einbruchsversuch diagnostiziert werden:
1
Dec 9 11:16:22 h1xxxxxx sshd[3542]: reverse mapping checking getaddrinfo
2
for 116-14-251-64.serverpronto.com [64.251.14.116] failed - POSSIBLE BREAK-IN ATTEMPT!
Die Meldung bedeutet, daß von pam beim Reverse-DNS festgestellt wurde,
daß der angegebene DNS-Name nicht mit dem von Reverse-DNS übereinstimmt.
Wie kommt sowas zustande?
Die Login-Versuche per SSH laufen über Bots bzw. es ist ein Wurm, der
versucht sich einzuloggen und - falls er Erfolg hat - auf dem Zielsystem
zu installieren und andere Server auf die gleiche Art zu malträtieren.
Dass der SSH-Daemon die Passworte nicht loggt, ist eine vernünftige
Vorgehensweise, weil ansonsten auch die Passworte berechtigter Benutzer
nicht sicher wären.
Ich selbst nutze seit Jahren dieses Skript hier:
http://www.fail2ban.org/wiki/index.php/Main_Page
Es lässt nur eine einstellbare Anzahl Login-Versuche zu und blockiert
dann die IP für eine gewisse Zeit. Neben SSH kannst du auch weitere
Dienste damit schützen, wie FTP, SMTP etc.
Wobei man sich mit fail2ban auch selber ins Knie bohren kann:
http://www.ossec.net/main/attacking-log-analysis-tools
Ich war mit ossec immer sehr zufrieden, vor allem da es sich auch noch
um andere Dinge wie Checksummen kümmert. Und die Einrichtung ist auch
nicht allzu schwer.
Um die Logs sauber zu halten hilft es auch den sshd auf einen anderen
Port zu legen wenn möglich.
Das ein SSH Login nur per Zertifikat möglich und für root sowieso
verboten ist sollte selbstverständlich sein!
Das da ist (mittlerweile) eine der sinnlosesten Meldungen, die der
sshd so von sich geben kann. In meinem eigenen sshd hatte ich die
schon mal rausgepatcht, sie mir aber dann irgendwann unvorsichtiger-
weise wieder eingetreten. :-(
Diese Meldung bezieht sich auf die Übergangszeit von der rsh zur ssh,
als es noch üblich war, mit "hostbasierter Authentisierung" zu
arbeiten, also per .rhosts (oder .shosts) blind einer fremden
IP-Adresse und dem zugehörigen Hostnamen zu vertrauen. Sowas macht
schon mehr als 10 Jahre lang praktisch keiner mehr, aber dieses blöde
"possible breakin attempt" da drin hält sich wie Uhu, ähem, Aleskleber.
:-)
Nochmal meine Frage: Wie kommt sowas zustande? Sind das wirklich
Einbruchsversuche, oder kann sowas auch regulär zustande kommen?
Öhm schrieb:> Das ist normales Grundrauschen durch Scripte.
Das ist es sicherlich nicht, denn ich habe ganze Serien von solchen
Meldungen, die von derselben Quelle ausgelöst wurden.
Allerdings ist diese Art eine Minderheit. Die überwiegende Mehrheit sind
teilweise tagelange Versuche desselben Strato-Servers, der im
2-Sekundentakt versucht, ein Türchen zu finden - das ist kein
Grundrauschen, sondern deutet auf gekaperte Server bei Strato, wo auch
mein Server läuft.
Wer einen Strato-Server hat, sollte vielleicht mal einen Blick in
/var/log/auth.log werfen - ich glaube kaum, daß ich ein Ausnahmefall
bin.
Seit ich die Sache bei Strato gemeldet habe, ist übrigens Ruhe und ich
bekomme nur noch ganz vereinzelte Login-Versuche aus USA, oder China.
Oliver R. schrieb:> Dass der SSH-Daemon die Passworte nicht loggt, ist eine vernünftige> Vorgehensweise, weil ansonsten auch die Passworte berechtigter Benutzer> nicht sicher wären.
Wenn man nach dem 5. erfolglosen Versuch von derselben IP-Adresse in
sehr kurzem Zeitabstand das PW loggen würde, wäre diese Gefahr ziemlich
klein.
Zu den Skripten: ein kryptographisch abgesicherter ssh-Zugang und ein
wenigstens 15 Zeichen langes Zufallspaßwort ist wohl der beste Schutz -
geschafft hats jedenfalls damit keiner.
Solche Attacken sind Standard. Wenn man sicher ist dass der sshd code
wasserdicht ist, braucht man nur noch ein hinreichend langes Passwort.
Ich bin mir nicht sicher ob die Logincounter, die eine IP nach N
Versuchen fuer eine bestimmte Zeit sperren wasserdicht sind. Denn die
Sperrliste kann sehr lang werden. Koennt zu einem Memory Overflow
fuehren. Besser ist wenn man per firewall das ssh Protokoll nur vom
lokalen Netz zulaesst.
Mikro Oschi schrieb:> Besser ist wenn man per firewall das ssh Protokoll nur vom> lokalen Netz zulaesst.
Das geht wohl bei einem Strato-Server schlecht, wenn man sich nicht
ausschließen will.
> Solche Attacken sind Standard.
Na ja, Standard würde ichs nicht gerade nennen und wenn der Mist über
Stunden und Tage von Servern des eigenen Providers kommt, sollte man
schon mal was unternehmen...
Auf meinem Ubuntu-Server, auf den ich per dyn-DNS-Adresse und ssh
zugreife, gibt es auch immer diese fehlgeschlagenenen Loginversuche. Oft
wird es mit root versucht. Es tauchen aber auch andere usernamen auf.
Die Versuche kommen aus der ganzen Welt (ich mache immer whois). Mir
wurde gesagt, dass das alles völlig normal sei. Wichtig ist eben, ein
gutes Passwort zu haben.
Leg den ssh service auf einen port der nicht standard ist, irgendwas
>32567. Damit sind nach meinen Erfahrungen die ganzen script-attacken
alle weg. Den Port kann man zwar trotzdem leicht rausfinden wenn man
will, aber wozu die Mühe wenn man in der Zeit 10 andere Server mit
einfachen Passwörtern automatisch knacken kann.
Rolf schrieb:> Es tauchen aber auch andere usernamen auf.
Ja, bei mir wurden ganze Serien von leicht modifizierten
Standard-Loginnamen aller möglichen Pakete durchprobiert.
Dazu kommen dann noch Versuche, über http Zugänge zu den gängigen
Server-Administrationssystemen zu bekommen.
Ich stoppe jedenfalls prophylaktisch phpmyadmin per cron-Job, damit ein
vergessener kein Angriffsziel hergeben kann.
user schrieb:> ssh ermöglicht auch sich per Zertifikat einzuloggen, dann brauch man> kein Passwort mehr, und kann den login per Passwort komplett sperren
Ja, so mache ich das, als Fallback ist aber noch ein root-Zugang mit
sehr langem Zufallspaßwort vorhanden.
Rolf schrieb:> Hiermit bekommst Du schnell einen Überblick, wer wirklich reingekommen> ist:
Ich habe eigentlich wenig Sorgen, daß die Geier auf diesem Weg in meinen
Server kommen - aber jedem gehackten Server sollte das Handwerk gelegt
werden, wenn sich das leicht machen läßt.
Ganz klar, dass root nicht per SSH einlogen darf. Auf gar keinen Fall.
Wir machen jeweils einen dummy user, und dann von diesem user per SU
weitermachen, .. und beide mit einem richtig langen Passwort versehen.
Mikro Oschi schrieb:> Solche Attacken sind Standard.
Ja, seit Jahren, vollautomatisiert. Offenbar sind sie immer noch
erfolgreich, sonst würde sich niemand mehr die Mühe machen, solche
Scripts laufen zu lassen.
> Wenn man sicher ist dass der sshd code> wasserdicht ist, braucht man nur noch ein hinreichend langes Passwort.
Wer ist das schon, wenn man Kunden, Kollegen, Partner usw. auf der Kiste
hat?
...oder man wechselt auf Zertifikate/Keys und schaltet PW
Authentisierung komplett ab.
> Ich bin mir nicht sicher ob die Logincounter, die eine IP nach N> Versuchen fuer eine bestimmte Zeit sperren wasserdicht sind.
Ich habe sshguard dafür seit Jahren im Einsatz und schon verschiedene
Back-Ends verwendet (tcpwrappers, iptables, ipfw). Die Sperren sind
wasserdicht. Die Entsperrungen haben auch immer funzt.
> Denn die> Sperrliste kann sehr lang werden. Koennt zu einem Memory Overflow> fuehren.
Ein paar Tausend Hosts packt ein halbwegs modernes System locker. Ob
allerdings noch Bandbreite für regulären Traffic übrig ist?
> Besser ist wenn man per firewall das ssh Protokoll nur vom> lokalen Netz zulaesst.
...und die FW als Jumphost aufsetzen? Nee.
Rolf schrieb:> Hiermit bekommst Du schnell einen Überblick, wer wirklich reingekommen> ist:>> grep "Accepted password" auth.log
oder eben auf die älteren Dateien:
zgrep "Accepted password" auth.log.4.gz
Uhu Uhuhu schrieb:> Mikro Oschi schrieb:>> Ganz klar, dass root nicht per SSH einlogen darf.>> Auch nicht per Zertifikat?
Nein. Jeder User hat sein persönliches Benutzerkonto und kann, wenn
nötig und vorgesehen, mit su/sudo/runas/... administrative Tätigkeiten
ausführen.
Uhu Uhuhu schrieb:> Wenn man nach dem 5. erfolglosen Versuch von derselben IP-Adresse in> sehr kurzem Zeitabstand das PW loggen würde, wäre diese Gefahr ziemlich> klein.
Was willst du denn mit den geloggten Passwörtern dann tun? Willst du
hier BKA spielen und schon mal auf Vorrat welche sammeln? ;-) Das
sind doch alles irgendwelche Wörterbuch-Attacken.
Uhu Uhuhu schrieb:>> Solche Attacken sind Standard.>> Na ja, Standard würde ichs nicht gerade nennen
Leider sind sie es. Bevor ich bei mir den brutefoceblocker
installiert habe, hatte ich auch tagtäglich hunderte davon. Die
von dir genannte Fehlermeldung ist dabei allerdings der größte Mift,
denn dieses laute Herumschreien über etwas, was eigentlich gar kein
Thema (mehr) ist, müllt einem dann nur unsinnig das Log voll.
Mikro Oschi schrieb:> Ganz klar, dass root nicht per SSH einlogen darf. Auf gar keinen Fall.
Naja, gegen ein rein key-basiertes root-Login
("PermitRootLogin without-password") gibt es nicht unbedingt was
einzuwenden. Das ist nicht unsicherer als ein passwortbasiertes
Einloggen eines Nutzers mit anschließendem passwortbasiertem su-
Kommando.
Man kann ja beliebig viele keys dafür gestatten, sodass jeder seinen
eigenen benutzt, und vermutlich kann man auch noch loggen, mit welchem
key die Anmeldung erfolgt war.
Jörg Wunsch schrieb:>> Ganz klar, dass root nicht per SSH einlogen darf. Auf gar keinen Fall.>> Naja, gegen ein rein key-basiertes root-Login> ("PermitRootLogin without-password") gibt es nicht unbedingt was> einzuwenden. Das ist nicht unsicherer als ein passwortbasiertes> Einloggen eines Nutzers mit anschließendem passwortbasiertem su-> Kommando.
Was mich dabei stört ist die fehlende Nachvollziehbarkeit bei root
log-ons. Wer war da wirklich am Werk? Auch wenn root lokal alles
vertuschen kann, gelingt ihm das NICHT wenn die Authentisierungs-Logs
laufend weggeschrieben werden (log-server, syslog o.ä.)
Ohne root login ist das System "sicherer", weil du für einen
erfolgreichen Angriff u.U. 2 verschiedene PW benötigst und/oder einen
local exploit finden musst, um das System zu übernehmen.
Jörg Wunsch schrieb:>> Na ja, Standard würde ichs nicht gerade nennen> Leider sind sie es.
Mag ein, daß das eine gängige Methode ist, aber daß Strato nicht merkt,
daß die Angriffe seit Monaten von seinen eigenen Servern kommt, hätte
ich jedenfalls nicht erwartet. Die sollten doch wenigstens ein paar
Honeypots laufen haben, um zu sehen, was in ihrem Netz da so alles los
ist.
>... zufallsgeneriert ...
sicher ? Ausser der String fuer alle domains derselbe. Oder hat eine
berechnebare Eigenschaft. Denn falls dem nicht ist, ist entweder der
Server hackbar, oder der Admin hat geschlampt.
Es ist doch Kicki, ein Skript zu schreiben, das solche Schlüssel nach
Bedarf erzeugt und wenn ein Einbrecher die Historie des
Zufallsgenerators nicht kennt, dann kann er sich nur die Zähne daran
ausbeißen.
Nach meinen bisherigen Erfahrungen funktioniert das bei Strato völlig
reibungslos und ich kann mir kaum vorstellen, daß sie an derart
sensiblen Punkten so grob schlampen.
Das mit den offenbar nichtvorhandenen Honeypots gibt mir allerdings
etwas zu denken. Ich werde die Sache weiter beobachten.
Die vergangenen 34 Stunden kamen insgesamt 7 Einzelversuche, also keine
Serien mehr.
Uhu Uhuhu schrieb:> Bei mir war es eine zufallsgenerierte Buchstaben- und Ziffernwurst mit 8> Stellen - sollte eigentlich reichen.
Kommt drauf an... http://xkcd.com/936/ :)
(Ich benutz' nur noch Zertifikate falls möglich ist eh viel
komfortabler)
Uhu Uhuhu schrieb:> Zu den Skripten: ein kryptographisch abgesicherter ssh-Zugang und ein> wenigstens 15 Zeichen langes Zufallspaßwort ist wohl der beste Schutz -> geschafft hats jedenfalls damit keiner.
Nimm ssh keys, und schalte passwordauth beim sshd ab.
Uhu Uhuhu schrieb:> Bei mir war es eine zufallsgenerierte Buchstaben- und Ziffernwurst mit 8> Stellen - sollte eigentlich reichen.
Entspricht ca. 40 Bits, nicht besonders viel. Nimm ssh keys, hat auch
den angenehmen Nebeneffekt das man auch einen ssh agent benutzen kann
:-))
Uhu Uhuhu schrieb:> Es ist doch Kicki, ein Skript zu schreiben, das solche Schlüssel nach> Bedarf erzeugt und wenn ein Einbrecher die Historie des> Zufallsgenerators nicht kennt, dann kann er sich nur die Zähne daran> ausbeißen.
man urandom
Läubi .. schrieb:> (Ich benutz' nur noch Zertifikate falls möglich ist eh viel> komfortabler)
Mach ich auch so. Der gut vernagelte Paßwortzugang ist nur als Fallback
da, falls das Zertifikat untergeht.
Breaker schrieb:> Entspricht ca. 40 Bits, nicht besonders viel.
Dann rechne mal aus, wie lange da so ein Arsch orgeln muß, wenn er alle
2 Sekunden einen Versuch hat...
Tom M. schrieb:> Was mich dabei stört ist die fehlende Nachvollziehbarkeit bei root> log-ons. Wer war da wirklich am Werk?
Sollte man nicht den key loggen können, der zur Genehmigung des
Zugangs geführt hat?
> Ohne root login ist das System "sicherer", weil du für einen> erfolgreichen Angriff u.U. 2 verschiedene PW benötigst und/oder einen> local exploit finden musst, um das System zu übernehmen.
Letzteres dürfte allerdings die Methode sein, die am verbreitetsten
ist: man bekommt irgendwo her einen Login als normaler Nutzer
(geklautes Passwort oder dergleichen, das Leck ist meist nicht mehr
zu finden danach) und sieht dann zu, dass man einen local exploit
findet. Zwei von zwei Einbrüchen, die ich in meinem Leben gesehen
habe, sind nach diesem Schema gelaufen.
Schon wieder versucht sich ein bei Strato gehosteter Server mit seinen
"Testreihen" an meinem root-Zugang - seit Sonntag Abend. Ich habe ihn
gestern Nachmittag bei Abuse-Server@strato.de gemeldet - was aber nicht
verhinderte, daß der Bursche auch heute Nacht noch fröhlich
weitergebohrt hat.
Die Jungs dort haben sicherlich nur einen Sack Flöhe zu hüten, aber daß
sie solche Dinger nicht schneller in den Griff bekommen, wundert mich
doch schon etwas. Es müßte doch ausreichen, ein Dutzend Adressen auf
einen Honeypot zu leiten und den automatisch zu monitoren, um dann
kurzentschlossen zuzugreifen, wenn sich irgend so eine Ratte daran zu
schaffen macht.
Thread beobachten
Seitenaufteilung abschalten