# [Heim-Server] Brute SSH Attacke

## Finswimmer

Hi,

mein Rechner, der von außen per DynDNS erreichbar ist, hat sich heute komisch verhalten.

Es ging fast alles norml, nur htop, ps aux haben nicht mehr richtig funktioniert.

In den Logs sah ich unzählige vergebliche SSH-Login Versuche. (Ich lasse nur die publickey Methode zu).

Kann es sein, dass dadurch der PC "schlapp" gemacht hat?

Ich habe jetzt fail2ban mit iptables installiert.

Nur würde ich gerne wissen, was mit dem PC los war...

free -m, df -h haben normale Werte angezeigt.

Ob ein Prozess 100% CPU hat, konnte ich nicht feststellen, da ja htop, ps nicht gingen.

Danke

Tobi

----------

## cryptosteve

Moin,

was heisst denn "haben nicht mehr richtig funktioniert"?

Normalerweise sollte sowas nicht beeinträchtigt sein, allenfalls die Netzverbindung kann in die Knie gehen, aber auch das ist im normalen Rauschen des Netzes bei aktuellen Verbindungen eher unwahrscheinlich.

----------

## Yamakuzure

Also die SSH-Versuche sind "normal". (Script-Kiddies.) fail2ban ist eine sehr gut Idee. Wenn [h]top nicht mehr starten möchte, liegt das meistens an einer verstopften Netzleitung, zumindest war das bei unseren Servern hier immer so. Andernfalls könntest du, falls du die Uhrzeit noch weißt, in /var/log/messages schauen, ob zu dem Zeitpunkt etwas Anderes komisch war. Ich hatte mal den Fall, dass SSH zu einem Debian-Server (LAN, wohlgemerkt) sehr langsam war, htop und top kaum starten wollten, und ps ewig und drei Tage gebraucht hat. Der Grund: Ein vergeblicher Versuch eines überflüssigen Daemons sich mit einem (nicht erreichbaren) NTP-Server zu synchronisieren. Die CPU-Last (16 CPUs) lag derweil bei <0.01.

----------

## Finswimmer

OK. Sehr schlechte Fehlermeldung von mir.

Bei dem Aufruf aller drei Programme blieb die Shell hängen und es hat sich gefühlt nichts mehr getan.

Auch nach 5min noch nicht. Länger hatte ich keine Geduld und habe den Rechner normal per init 6 neustarten können.

Die Netzwerk-Verbindung per SSH war allerdings normal schnell.

----------

## Yamakuzure

Eine andere Idee, an die ich Vorgestern nicht dachte:

Ich hatte mal das Problem, dass selbst "ls" einfach genau nichts tat. Es ließ sich auch weder mit strg+c, noch von einer anderen Konsole mit kill -9 abwürgen.

Lösung: Jemand hat ein rm -rf auf einen per iSCSI angeschlossenen NAS losgelassen, in einem Verzeichnis mit ca. 150 Mio Dateien (2TB), und das System war permanent am "fsync"en. 'ls' hat schlicht auf das Ende des fsync gewartet, und befand sich dadurch (natürlich) im Modus 'D' (uninterruptible sleep).

Okay, okay, ein fsync-Problem ist bei dir sicherlich weit hergeholt. Aber kannst du dich lokal anmelden? Und wenn "top" per ssh hängt, funktioniert das dann lokal? Dann könnte es ein MTU Problem sein. (http://www.znep.com/~marcs/mtu/)

----------

