Abuse Mail vom Provider erhalten.

stoffmann

New Member
Hallo,

ich habe heute folgende Abuse mail von meinem Provider bekommen. Ich verstehe das log so, daß jemand von meinem Server aus versucht sich per ssh auf einem fremden Server anzumelden.

> Dear Sir/Madam,
>
> We have detected abuse from the IP address 80.241.214.159, which according to a whois lookup is on your network. We would appreciate if you would investigate and take action as appropriate.
>
> Log lines are given below, but please ask if you require any further information.
>
> (If you are not the correct person to contact about this please accept our apologies - your e-mail address was extracted from the whois record by an automated process. This mail was generated by Fail2Ban.)
>
> Note: Local timezone is +0200 (CEST)
> Sep 11 08:50:01 secgw sshd[31689]: Failed password for root from 80.241.214.159 port 53271 ssh2
> Sep 11 08:50:01 secgw sshd[31689]: Received disconnect from 80.241.214.159: 11: Bye Bye [preauth]
> Sep 11 08:50:05 secgw sshd[31691]: Failed password for root from 80.241.214.159 port 53439 ssh2
> Sep 11 08:50:05 secgw sshd[31691]: Received disconnect from 80.241.214.159: 11: Bye Bye [preauth]
> Sep 11 08:50:06 secgw sshd[31693]: Invalid user berton from 80.241.214.159
> Sep 11 08:50:07 secgw sshd[31693]: Failed password for invalid user berton from 80.241.214.159 port 53687 ssh2

Wie kann man feststellen was/wer dahinter steckt?

Gruß

Stefan
 

stoffmann

New Member
Danke für den Tip. Ich verwende den Server als Seafile Server. Evtl. wir die seafile Website ja misbraucht. Mal sehen was die Tools ergeben.
 

etron770

Member
Ist zwar schon lange her, aber genau dazu habe ich zwei Fragen:

Wenn ich das richtig sehe versucht bei den Logfiles jemand vom Server 80.241.214.159 auf den Server zuzugreifen, auf dem die Logfiles erzeugt werden.
Ohne Fail2ban hätte ich haufenweise solcher Zugriffe auf einem meiner Server.
Ich kann die Fehlermeldung dann so erzeugen: ssh klaus@123.123.123.123 -p1234
Warum steht dann aber im Logfile:

Code:
Apr  1 12:19:03 server sshd[3713]: Invalid user klaus from 321.321.321.321 port 48710
Apr  1 12:19:03 server sshd[3713]: Connection closed by invalid user klaus 321.321.321.321 port 48710 [preauth]
also port 48710 und [preauth]?

Und weitere Frage, wenn man die User also nicht mit fail2ban aussperrt, kann es dann sein, dass dann irgendwann bei massenweisen Zugriffen der Server hängt. Das hatte ich mal auf einer alten VM Testserver, bei dem fail2ban nicht gestartet war. (der war beim Neustart vom host aus versehen noch im Autostart und lief ohne dass ich es wollte )

Das einloggen per pubkey ging nur bis zur Passwortabfrage, editieren von Dateien war nicht mehr möglich z.b crontab -e.
Nach Zugriff über den Host und stoppen von Diensten wie apache oder mysql, die viele Dateien offen haben hat dann den Zugriff per ssh wieder ermöglicht.

wie ist da der Zusammenahng?
 

matz

Member
Bei mir sind gerade jetzt 1067 IPs von F2B geblockt, die den sshd umsonst bemüht haben. Im log sieht es so aus (Auszug):
Code:
Apr  1 23:44:00 mein_server sshd[30342]: Invalid user mcserver from 187.11.113.231 port 50999
Apr  1 23:44:00 mein_server sshd[30342]: Received disconnect from 187.11.113.231 port 50999:11: Bye Bye [preauth]
Es ist der Alltag. F2B blockt wie verrückt und es geht immer weiter. Es kann niemand dran kommen weil ich nur PubKey erlaube und für den Private müsste man schon in mein Haus rein. Ohne Passphrase würde dieser allerdings auch nicht viel nützen. Ich weiß, dass es nicht immer möglich ist, aber nur PubKey ist m.E. das Beste.

Mein sshd wird anscheinend auch stark belastet, denn manchmal dauert der Verbindungsaufbau etwas länger und es gibt kleine Verzögerungen beim Tippen. top zeigt allerdings keine besondere Last an. Das Aussperren mit F2B hat keinen Einfluss auf die Anzahl der Angriffe. Du sperrst 1000 Neugierige aus und 1000 neue starten durch. Beim sshd blocke ich 1 Monat lang und habe trotzdem fette logs. Wenn in China der Strom ausfällt dann gibt es 60% weniger Versuche ;)

Wenn du den Web- und Datenbankserver stoppst, muss das nicht mit sshd zusammenhängen. Zu viele offene Verbindungen, zu viele offene Files (Standard ist 1024), sonstige Last. Ich fahre ab und und zu Lasttests mit Jmeter. Da geht ssh schon spürbar langsamer. Die Last geht dann an php-fpm, nginx und mysqld, für andere bleibt nicht so viel übrig.
 
Zuletzt bearbeitet:

etron770

Member
Als Lösung dass sie immer weiter versuchen habe ich alle IPs die [preauth] in der Zeile haben nach einem Versuch für eine Woche geblockt. Nachdem nur Pubkey erlaubt ist sind alle bei denen [preauth] auftaucht Spammer. Da wird es schon extrem weniger.
 

Werbung

Top
Unsere Website wird durch die Anzeige von Online-Werbung für unsere Besucher ermöglicht.
Bitte ziehe es in Betracht, uns zu unterstützen, indem du deinen Werbeblocker deaktivierst.