.LNX-WORLD

SSH absichern – ich sagte es schon in Teil 1 dieser Reihe – dies ist etwas, dass jeder der Linux Server betreibt (egal ob in einem Firmennetzwerk, direkt über das Web erreichbar, oder beides) mit als erstes in den Angriff nehmen sollte.

In diesem Teil 2 der Reihe “SSH absichern” gehe ich auf einen Punkt ein, welcher oftmals schlicht unterschätzt wird: Den SSH Port ändern! Wenn man im Mittelalter nicht wollte, dass jemand einen Schatz fand, bzw. einen geheimen Ort, dann wurde dieser versteckt. Genauso funktioniert das gute alte Kinderspiel des Versteckens.

Was damals funktionierte, tut auch heute noch seine Wirkung! Denn beim den simplen Portscans auf offene SSH Zugänge wird meist nur nach dem default Port von SSH gesucht, dem Port 22. Was nun wenn der Server bei Anfragen auf den SSH Port 22 ganz simpel nicht antwortet? Meist fliegt man aus der Liste der Server die per Script und Brute Force angegriffen werden sollen, zumindest ist dies mein Ergebniss aus den Erfahrungen der Vergangenheit. Continue reading ‘SSH absichern – Teil 2 – SSH Port ändern’ »

SSH absichern – dies ist etwas was jeder der Linux Server betreibt (egal ob in einem Firmennetzwerk, direkt über das Web erreichbar, oder beides) mit als erstes in den Angriff nehmen sollte. Linux hat einen Nachteil was Angriffe angeht: Der Benutzer auf den es alle zuerst abgesehen haben ist root und der heißt nunmal immer so.

Um root den direkten Login per SSH zu verbieten, muss nur eine Zeile in der /etc/ssh/sshd_config geändert werden:

PermitRootLogin yes
ändern zu
PermitRootLogin no

Diese Änderung in der SSH Konfiguration sorgt dafür das der direkte Login über SSH als Benutzer root untersagt wird, sprich unser SSH ist ein wenig mehr abgesichert. Continue reading ‘SSH absichern – Teil 1 – root darf mal etwas nicht…’ »

Manchmal bleiben auch bei VMware Systemen VM´s einfach hängen. Im ersten Schritt sollte man schauen, ob die entsprechende VMware VM nur im VMware vCenter noch als angeschaltet steht, sollte der VMware ESX selbst (via “esxtop” einfach per SSH nachsehen) die VMware VM bereits als offline sehen, hilft nur warten. Im Fall das die VMware VM auch hier noch als aktiv / online gelistet wird, kann man versuchen die VMware VM per SSH Konsole sanft zu beenden (nicht gleich den Kill einläuten! Das sollte immer der letzte Weg sein):

vmware-cmd /vmfs/volumes/[VMname].vmx stop

Sollte das nicht funktionieren sollte man einen “Hard Stop” versuchen (nicht gleich den Kill einläuten! Das sollte immer der letzte Weg sein):

vmware-cmd /vmfs/volumes/[VMname].vmx stop hard

Ich hatte nun einen Fall wo dies auch nicht mehr half. Die VMware VM wollte absolut nicht aus gehen und blockierte mir so mein System. (ACHTUNG – bei der nachfolgenden Methode kann es zu Datenverlust in der hängenden VM kommen) Da half nur noch ein direkter “kill” des Prozesses für die VMware VM – nur wie findet man die passende Prozess ID um auch den richtigen Prozess mit dem kill zu erwischen?  Die VMware ID welche man über “esxtop” erhält ist leider nicht gleich der Prozess ID für die VMware VM auf dem System. Mittels des SSH Kommandos

ps auxfww | grep [VMname]

erhält man die gewünschte Prozess ID der VMware VM im gewohnten ps Syntax. Danach einfach über das SSH Kommando “kill” den Prozess direkt abschießen:

kill -9 [PID]