Der Sicherheitsanbieter schreibt die “Linux.BackDoor.Xnote.1″ genannte Hintertür der Hackergruppe ChinaZ zu. Die Angreifer nutzen die SSH-Verbindung, um Malware auf Linux-Systemen einzuschleusen. Der Schädling soll unter anderem in der Lage sein, Befehle von Kommandoservern entgegenzunehmen und DDoS-Angriffe zu starten.

Weiterlesen

über eine SSH-Verbindung (Secure Shell) eingeschleust wird, nachdem Angreifer zuvor das Passwort eines entsprechenden Benutzerkontos geknackt haben

Also muss mal wieder an anderer Stelle geschlampt worden sein...
SSH nach draußen bringen ohne weitere Absicherung ist schon wirklich grobfahrlässig. Ich würde immer:

- permitRootLogin auf "no" setzen
- denyhosts oder fail2ban einsetzen um SSH abzusichern
- ggf. Passwort-Login verbieten, Login/Auth nur mit RSA-Key erlauben
- ggf. SSH nicht auf 22/tcp horchen lassen um den SSH-Dienst aus der Schusslinie zu nehmen

Wenn man in den Einstellungen die entfernte Anmeldung abschaltet dann funktioniert SSH auch nicht. Klar die Einstellungen in der Config sollte man auch einbeziehen bzw. dort ausdrücklich die Nutzer benennen (unter AllowUsers).
Problematisch wird es erst wenn SSH über Server läuft was natürlich das erste Angriffsziel darstellt.

mit

arp -a | grep :

Kann man sich alle verbundenen Rechner anzeigen lassen.

Zitat von Dante12

Problematisch wird es erst wenn SSH über Server läuft

Äh.....wie meinst du das, wenn SSH über Server läuft, meinst du wenn ich irgendwo bei einem Hoster einen Server miete auf dem ein SSH-Server läuft?

Zitat von Dante12

mit

Kann man sich alle verbundenen Rechner anzeigen lassen.

Moment, mit arp siehst du aber nur ne Zuordnung IP <=> MAC der anderen Rechner im selben Subnetz...da würde ich lieber mit netstat -an nachschauen und vllt auch mal die /var/log/auth.log nach ssh, fail und accept durchgreppen...

Zitat von cosinus

(- permitRootLogin auf "no" setzen, siehe Punkt RSA Key)
- denyhosts oder fail2ban einsetzen um SSH abzusichern
- ggf. Passwort-Login verbieten, Login/Auth nur mit RSA-Key erlauben
- ggf. SSH nicht auf 22/tcp horchen lassen um den SSH-Dienst aus der Schusslinie zu nehmen

Hab's mal etwas abgeändert. Nach diesen Regeln läuft derzeit mein SSH Server. Zusätzlich habe ich noch Logwatch installiert und die "Shell" etwas abgeändert das heißt: Wenn sich jemand per SSH einloggt -> E-Mail wird verschickt und Abends halt nochmal via Logwatch die Zusammenfassung, was am Tag passiert ist also: Updates, Upgrades, Logins etc...

Oh, Logwatch hatte ich bisher noch nicht so auf dem Schirm
Wer ich mir mal ansehen. Mir reichte es bisher, wenn mir denyhost ne Mail schickte wenn es mal wieder zu viele Fehlversuche ermittelt

Ich benutze Ubuntu 12.04 LTS zum surfen und nur in der Gastsitzung.

Falls ich mir die Schadsoftware wirklich einfangen würde, wäre es dann nicht so, dass beim nächsten Systemstart die Schadsoftware wieder entfernt wäre?

Na, das halt ich für etwas unpraktikabel. Ein "normale" Nutzung als normaler User von Linux ist da deutlich komfortabler und sicher genug. Die Gastsitzung ist quasi eine Art Kompromiss aus normal installiertem System und Live-System. Wenn du wirklich JEGLICHE Änderung wieder beim nächsten Start des Systems rückgängig haben willst, musst du von der DVD jedes Mal in den Ausprobiermodus booten....aber das hat wieder andere Nachteile wie zB dass auf der DVD enthaltene Programme logischerweise nicht aktualisiert werden können. Eben das was natürgemäß durch ein ro-Medium entsteht...