-Versuchter Angriff?!"

  • Thread starter Thread starter Deleted member 14254
  • Start date Start date
D

Deleted member 14254

Guest
Hallo @ll,

Hab heute in meinem Messages-log (/var/log) etwas seltsames gesehen...

In der Nacht auf Sonntag, den 20.05.2012, also vorgestern, hat wohl (so wie ich das mit meinen noch-Laien-Augen) sehe, von einer bestimmten IP-Adresse versucht mit verschiedenen loginnamen (und wahrscheinlich auch Passwörtern-> Wörterbuch-Attacke???) versucht einen login zu bekommen...

Ich beginne gerade erst mit Root-Servern, d.h. hab ein Jahr Übung an meiner Lokalen Testumgebung hinter mir, wo ich aber soetwas wie in dem Log auf meinem "echten" dedizierten Server jetzt, nie zuGesicht bekam... Ich zeigs Euch einfach mal:

Code:
May 20 01:43:39 srv001 sshd[31093]: SSH: Server;Ltype: Version;Remote: 78.136.105.45-47257;Protocol: 2.0;Client: libssh-0.1
May 20 01:43:39 srv001 sshd[31093]: SSH: Server;Ltype: Kex;Remote: 78.136.105.45-47257;Enc: aes128-cbc;MAC: hmac-sha1;Comp: none [preauth]
May 20 01:43:39 srv001 sshd[31093]: SSH: Server;Ltype: Authname;Remote: 78.136.105.45-47257;Name: fruzsina [preauth]
May 20 01:43:39 srv001 sshd[31093]: Invalid user fruzsina from 78.136.105.45
May 20 01:43:39 srv001 sshd[31093]: input_userauth_request: invalid user fruzsina [preauth]
May 20 01:43:39 srv001 sshd[31093]: Received disconnect from 78.136.105.45: 11: Bye Bye [preauth]
May 20 01:43:39 srv001 sshd[31095]: SSH: Server;Ltype: Version;Remote: 78.136.105.45-47276;Protocol: 2.0;Client: libssh-0.1
May 20 01:43:39 srv001 sshd[31095]: SSH: Server;Ltype: Kex;Remote: 78.136.105.45-47276;Enc: aes128-cbc;MAC: hmac-sha1;Comp: none [preauth]
May 20 01:43:39 srv001 sshd[31095]: SSH: Server;Ltype: Authname;Remote: 78.136.105.45-47276;Name: yaroslav [preauth]
May 20 01:43:39 srv001 sshd[31095]: Invalid user yaroslav from 78.136.105.45
May 20 01:43:39 srv001 sshd[31095]: input_userauth_request: invalid user yaroslav [preauth]
May 20 01:43:39 srv001 sshd[31095]: Received disconnect from 78.136.105.45: 11: Bye Bye [preauth]
May 20 01:43:40 srv001 sshd[31097]: SSH: Server;Ltype: Version;Remote: 78.136.105.45-47301;Protocol: 2.0;Client: libssh-0.1
May 20 01:43:40 srv001 sshd[31097]: SSH: Server;Ltype: Kex;Remote: 78.136.105.45-47301;Enc: aes128-cbc;MAC: hmac-sha1;Comp: none [preauth]
May 20 01:43:40 srv001 sshd[31097]: SSH: Server;Ltype: Authname;Remote: 78.136.105.45-47301;Name: hongkongwin [preauth]
May 20 01:43:40 srv001 sshd[31097]: Invalid user hongkongwin from 78.136.105.45
May 20 01:43:40 srv001 sshd[31097]: input_userauth_request: invalid user hongkongwin [preauth]
May 20 01:43:40 srv001 sshd[31097]: Received disconnect from 78.136.105.45: 11: Bye Bye [preauth]
May 20 01:43:40 srv001 sshd[31099]: SSH: Server;Ltype: Version;Remote: 78.136.105.45-47316;Protocol: 2.0;Client: libssh-0.1
May 20 01:43:40 srv001 sshd[31099]: SSH: Server;Ltype: Kex;Remote: 78.136.105.45-47316;Enc: aes128-cbc;MAC: hmac-sha1;Comp: none [preauth]
May 20 01:43:40 srv001 sshd[31099]: SSH: Server;Ltype: Authname;Remote: 78.136.105.45-47316;Name: rhutd [preauth]
May 20 01:43:40 srv001 sshd[31099]: Invalid user rhutd from 78.136.105.45
May 20 01:43:40 srv001 sshd[31099]: input_userauth_request: invalid user rhutd [preauth]
May 20 01:43:40 srv001 sshd[31099]: Received disconnect from 78.136.105.45: 11: Bye Bye [preauth]
May 20 01:43:41 srv001 sshd[31101]: SSH: Server;Ltype: Version;Remote: 78.136.105.45-47338;Protocol: 2.0;Client: libssh-0.1
May 20 01:43:41 srv001 sshd[31101]: SSH: Server;Ltype: Kex;Remote: 78.136.105.45-47338;Enc: aes128-cbc;MAC: hmac-sha1;Comp: none [preauth]
May 20 01:43:41 srv001 sshd[31101]: SSH: Server;Ltype: Authname;Remote: 78.136.105.45-47338;Name: teddy31 [preauth]
May 20 01:43:41 srv001 sshd[31101]: Invalid user teddy31 from 78.136.105.45
May 20 01:43:41 srv001 sshd[31101]: input_userauth_request: invalid user teddy31 [preauth]
May 20 01:43:41 srv001 sshd[31101]: Received disconnect from 78.136.105.45: 11: Bye Bye [preauth]
May 20 01:43:41 srv001 sshd[31103]: SSH: Server;Ltype: Version;Remote: 78.136.105.45-47356;Protocol: 2.0;Client: libssh-0.1
May 20 01:43:41 srv001 sshd[31103]: SSH: Server;Ltype: Kex;Remote: 78.136.105.45-47356;Enc: aes128-cbc;MAC: hmac-sha1;Comp: none [preauth]
May 20 01:43:41 srv001 sshd[31103]: SSH: Server;Ltype: Authname;Remote: 78.136.105.45-47356;Name: mhepburn [preauth]

...das geht etwa mit verschiedenen "logins" 40 mal so... und hört dann auf. Die Adresse bleibt dieselbe, das Strickmuster auch. Wollte nur nicht so ein Riesenlog hierrein posten. Hoffe, ich habe es überhaupt in der richtigen Rubrik hier erstellt...

Mir fällt nur die Zeit so ins Auge... Innerhalb einer Sekunde soviele Usernames durchzuprobieren, wie soll das gehen ohne "Wörterbuch-Attacken" - Script?

Danke für Eure Hilfe :o
 
Last edited by a moderator:
Das ist bedauerlicherweise normal heutzutage. Und ja, natürlich sind das Wörterbuchattacken.

Ein Grund, den root Zugang zu sperren und lediglich Usern den SSH Login zu erlauben (per "su" gibts Rootrechte, wenn nötig).

Und ein Grund fail2ban zu installieren.:p
 
Also Root sperren nervt mich mehr als es mir nutzt.
Key-Auth und Root erlauben finde ich weniger bedenklich als egal welches CMS auf einem Server zu betreiben.
Selbst das viel umworbene umlegen des SSH Ports hab ich mittlerweile eingestellt.
Gruß Sven
 
Eher ein Grund den Port zu aendern.
Schuetzt zwar nicht das System nennenswert, aber das "Grundrauschen" in der Log wird effektiv unterdrueckt.
 
Guten Abend, Thunderbyte :)

Danke Dir für Deine schnelle Antwort und Bestätigung meiner Vermutung. Muss ich ja auch "lernen" soetwas zu erkennen. Einerseits betrübt mich sowas natürlich, nach nur paar Tagen 40-mal soetwas im log zu sehen, andererseits beruhigt es mich, das derjenige nicht reingekommen ist, und ich es richtig eingeschätzt habe.

Das war heute auch irgendwie Zufall, das ich "wie verbissen" in die Logs geguckt hatte. Ich hatte ja meinen Server letzte Woche auf gentoo umgestellt, hatte es aber versäumt, das RAID-1 einzurichten, weil ich damit bisher kaum Kontakt hatte. Das Original-Image von Hetzner (Debian) hat automatisch das RAID-1 und ich hab mich einige Tage dran versucht, dassselbe für gentoo einzurichten, was auch nicht "so ohne" war. Aber habs geschafft. Daher hab ich heute mal die Logs kontrolliert ob Kernel-Mode-Switch für KVM-Over-IP läuft und im unteren Teil fielen mir dann die Angriffsversuche auf...

Zu Deinen Vorschlägen:

fail2ban - Da habe ich mal von gelesen - Wie der Name schon vermuten lässt: Adressen, von denen Angriffe gefahren werden, kommen in eine Blacklist und der Server beachtet diese dann erst garnicht mehr, erfolgt nochmals ein Angriff von diesen... - korrekt?

Einen Username (fürs login) erstelle ich mir noch. Derzeit gibts nur root. Aber bevor Du jetzt schimpfst, ich habe Pub-Key-Auth aktiv. Es ist bei mir nicht möglich per Passwort einen login zu bekommen. Und der Pub-Key hat bei mir über 10kbit - Verschlüsselung.

Aber nichts desto Trotz, ich leg einen User auf dem Server an und werd für ihn ebenfalls Pub-Key-Auth aktivieren, danach root-login komplett abschalten. Und fail2ban installieren. Eine Frage hätte ich dazu noch: Angenommen, ich gebe selbst mal eine falsche Passphrase ein... Lande ich dann ebenfalls auf der gesperrten IP-Liste?
 
Guten Abend, d4f und sven,

Danke auch für Eure Hilfen :)

@d4f, den Port hab ich schon direkt geändert. Der ist nicht mehr 22.

@sven, hm... bin schon am überlegen, also mit dem Benutzernamen zusätzlich... Im Moment gibts nur root. Ich dachte mir "zuerst" - wenn ich auf den Server gehe, dann zum Administrieren, dann brauch ich root. Andererseits, per username und ssh draufzugehen, mit su root zu werden... ist natürlich auch nicht so verkehrt...

Fail2ban mach ich aber auf jeden Fall drauf.

Mit den CMS ist auch noch soein Ding... Ich hatte während meiner Übungszeit mal einige CMS im Test. Drupal, Joomla, Typo3 und gar ModX. Wobei ich mit dem letzten überhaupt nicht klarkam, da man mich nicht so unbedingt "Webdesigner" nennen möchte. Für mich kämen evtl. entweder Drupal oder Joomla in Frage... Joomla gefällt mir am besten, damit habe ich ammeisten ge"lernt", aber Joomla ist wahrscheinlich auch das anfälligste überhaupt. Weil am bekanntesten. Zudem darf man die Joomlacrew nicht mal mit Fragen behelligen. Das ist dort tödlich. Für die Fragen, die ich Euch hier seit letzter Woche gestellt habe, hätte ich dort schon den Stempel "Nicht Webseiten-tauglich, noch weniger root-Server-tauglich" aufgedrückt bekommen... Aber das soll keine Beschwerde werden hier.

Nagut, dann werd ich mich mal in fail2ban einlesen...

Danke Euch allen nochmals!!! Schön, das der Umgang hier angenehm ist! :rolleyes:
 
fail2ban - Da habe ich mal von gelesen - Wie der Name schon vermuten lässt: Adressen, von denen Angriffe gefahren werden, kommen in eine Blacklist und der Server beachtet diese dann erst garnicht mehr, erfolgt nochmals ein Angriff von diesen... - korrekt?

Größtenteils korrekt. Die negativ aufgefallenen IP Adressen werden automatisch in die Firewall Blockliste eingetragen.

Einen Username (fürs login) erstelle ich mir noch. Derzeit gibts nur root. Aber bevor Du jetzt schimpfst, ich habe Pub-Key-Auth aktiv. Es ist bei mir nicht möglich per Passwort einen login zu bekommen. Und der Pub-Key hat bei mir über 10kbit - Verschlüsselung.

Das ist SEHR SEHR löblich und m.E. absolut ausreichend. Wenn Du das gleich geschrieben hättest, dann hätte ich Dir sagen können, dass natürlich ein passwortbasierter Angriff NIE Erfolg haben kann, egal wie groß das Wörterbuch ist.

Aber nichts desto Trotz, ich leg einen User auf dem Server an und werd für ihn ebenfalls Pub-Key-Auth aktivieren, danach root-login komplett abschalten. Und fail2ban installieren. Eine Frage hätte ich dazu noch: Angenommen, ich gebe selbst mal eine falsche Passphrase ein... Lande ich dann ebenfalls auf der gesperrten IP-Liste?

Das kannst Du alles machen und bist damit sicherer als gefühlte 95% von Rootserverbetreibern ;) Wobei mit Key eine Rootabschaltung m.E. noch nicht mal unbedingt nötig wäre.

Wie auf der F2B Website geschrieben steht: in der Regel bannt F2B die IP(s) für eine einstellbare Zeit, um eben genau Wörterbuchattacken zu unterbinden (die ja, wie Du gesehen hast, in der Regel nur eine Zeit lang gehen) und nimmt dann die IPs wieder aus der Blacklist.
 
oomla ist wahrscheinlich auch das anfälligste überhaupt. Weil am bekanntesten.
Die Relation muss nicht zwingend stimmen da die meisten gefaehrlichen Sicherheitsloecher schon gefunden sind und neue Loecher schnell gefixt werden koennen.
Unbekanntere CMS hingegen haben zwar weniger bekannte (und reparierte) Loecher aber dafuer potentiell mehr Luecken und weniger Erfahrung in derem Umgang.

Siehe als gutes Beispiel wie Apple versucht hat der Trojaner-Plage unter OsX Herr zu werden; ihnen fehlte schlecht da Know-How zum erfolgreichen und schnellen Pushen...
 
Danke Euch :)

Thunderbyte said:
Das ist SEHR SEHR löblich und m.E. absolut ausreichend. Wenn Du das gleich geschrieben hättest, dann hätte ich Dir sagen können, dass natürlich ein passwortbasierter Angriff NIE Erfolg haben kann, egal wie groß das Wörterbuch ist.

Ich hab mit der ganzen Serversache mit Ubuntu damals (knapp 15 Monate in die Vergangenheit) angefangen. Die haben ein sehr sehr gutes How-To zu ssh. Da hab ich mir damals direkt mit Pub-Key angewöhnt. Das hab ich auch hier auf dem Testsystem so, obwohls da absolut "übertrieben" ist... ;) Ausserdem, die Verschlüsselungs-Bitstärke von nur 2048. Hab damals probiert, wie hoch das geht... Der damalige TV-Sender verwendete zum verschlüsseln der ECM-/EMM- 512/768. SSH RSA standardmäßig 2048. Ich beschloss, direkt eine -vielleicht paranoide- aber der- und der nächsten Zeit nicht brechbare Bitstärke von >10kb zu nehmen. Bin aber damals von Ubuntu abgekommen, weil mit dem Einzug von Unity meine damalige Grafikkarte nicht klarkam. Hatte nur noch Ruckeln. Zum Schluss bin ich dann auf gentoo gekommen und da verharrt. Daher wollte ich gentoo auch unbedingt auf dem Server. Ich hab "Schiß" wenn ich unsicher im Umgang mit dem System bin, was bei Debian nach langjähriger Abstinenz der Fall wäre.

Dann werd ich mir f2b mal installieren gleich. :)

@d4f,

das kommt noch mit dem $CMS. Wegen der Installiererei von gentoo mit SW-RAID-1 kam ich letzte Woche zu garnichts irgendwie. Muss noch die Domain reggen und die Einträge für RDNS usw. machen. Zuerst kommt der Mailserver, wenn die Domain steht und auf die IP verweist. Muss dazu noch sehen wie ich die geniale MS-Anleitung für Debian auf gentoo umgebogen bekomme. Die gentoo-Anleitung ist nicht sooo gut wie die von Debian :/
Gut vielleicht, doch vom Verständnis ist mir die leichter von Debian.
Danach werd ich dann die Webserver-Sache angehen. Besser langsam als überstürzt und mit 10 Fehlern oder mehr, mehr...
 
Lobt mich noch nicht zu früh :o:rolleyes: Die Bewährungsprobe kommt erst noch ;)
Versuche mich gerade an fail2ban... Soweit ist alles klar/installiert, doch mir macht der noch nicht konfigurierte Mail-Agent etwas Kopfschmerzen... Die Kopien der Dateien fail2ban.conf (->fail2ban.local) und jail.conf(->jail.local) sind erstellt. So wie ich die Anleitung verstanden habe, kommen in den $.local Dateien nur Abweichungen der beiden Configs zur Geltung... Also kann ich den Mail-Kram aus der .jail.local erstmal rauslassen, solange mta noch nicht konfiguriert ist... Ich bete jetzt mal, das das stimmt ;)
 
Scheint geklappt zu haben, fail2ban rennt. Hatte noch paar Ausnahmen für "ipignore" mitaufgenommen, unter anderem Hetzners DNS. Die Mailserver-Zeile habe ich mit # kommentiert, damits keine Fehler gibt, solange mta (zwar installiert aber noch nicht konfiguriert) nicht funktionsfähig ist...

So, dann nochmals vielen vielen Dank für Eure großartige Hilfe :) :thumbsup:

Und gute N8 :)
 
s24! said:
Warum sollten die Hetzner-Nameserver per ssh auf deinen Server verbinden wollen? :D

Frag ich mich grade auch :o:o:o:o Ich bin noch abergläubig, s24! :p Ich wollts irgendwie vermeiden, das fail2ban letztendlich Hetzner-"Service"-Servern "feindlich" gegenüber wird... Ich weiß, es ist totaler Stuss. Hab sowieso kaum nen Augen zu machen können seit paar Tagen. Hoffe, das legt sich bald. Darfst/Dürft mich also ruhig paranoid nennen, hab nix dagegen und nichts anderes ist die Wahrheit :o:rolleyes:
 
Cool bleiben! :D

fail2ban reagiert nur bei fehlgeschlagenen SSH Einlogversuchen. IPs (wie die DNS Server), die soetwas gar nicht versuchen, werden logischerweise auch nie in der Blockliste landen (können). Einfach logisch überlegen, dann kommt man da locker drauf.
 
Back
Top