Anfängerfrage zu sicherer Serveradministration

[kai-behncke]

Hallo liebes Forum,

ich nutze einen dezidierten Server bei Strato - und zahle da jetzt leider richtig Lehrgeld, da jemand offensichtlich von außen root-Zugriff erlangt hat

Nun habe ich den Server plattgemacht und will das ganze von vorne -aber diesmal richtig - angehen.
Was würdet Ihr mir empfehlen? Wie administriert Ihr Eure Server?

Ich habe das zuvor über ssh als root gemacht (was wohl nicht so gut war). Welche Alternativen gibt es?
Nutze Debian 4.0
Vielen Dank, Kai

[silent85]

Ich habe das zuvor über ssh als root gemacht (was wohl nicht so gut war).

Keine

Sichere deinen ssh zugang und die Software die auf deinem Root läuft.
Erst wenn du weist wie einer denn Deckel geöffnet hat kannst du ihn wieder schliessen.

Hast du deine Logs vorher gesichert? Was genau ist passiert?

[kai-behncke]

Danke zunächst einmal für die Antwort. :)

Hast du deine Logs vorher gesichert? Was genau ist passiert?

Leider nicht. Ich habe eine Mail von Strato erhalten, in welcher mir gesagt wurde, dass von meinem Server massenhaft Einbruchversuche auf andere Rechner ausgehen, hab dann da angerufen und mir das bestätigen lassen.
Anshließend hab ich den Server plattgemacht, war nicht so schlimm, weil da eh noch nicht so viel drauf war, doch nun muss ichs richtig angehen.

Wie kann ich denn ssh sicher machen?
Die bei Strato haben mir auch empfohlen, dass sich root nicht über ssh anmelden kann, nur wie kann ich dann administrieren?
Kann ich vielleicht einen User anlegen, der root-Rechte hat aber anders heißt?

[silent85]

Ich habe bei mir den ssh Port geändert, configs findest du in /etc/ssh.
Restarten kannst du ssh mit /etc/init.d/ssh restart

Lass wärend des restarten eine Putty Instanz offen falls du was falsch machst und du zb beide Ports dichgemacht hast. So haste noch einen funktionierende Session.

Dann kannst du die anzahl der Logins Begrenzen zb 3 fehlversuche in 10 min. Das verlangsamt angriffe auf ssh schonmal ungemein.

Das ist dann aber nur ein Problem weniger von hunderten..

Gerade über Plesk und Confixx gibt es viele Möglichkeiten


Denn login des roots kannste sperren dann musst du dich mit einem anderen benutzer einloggen und mit su zu root werden.

[kai-behncke]

Alles klar, danke!!

[oxygen]

Mach dir keine Gedanken über ssh. Sobald man nur key Authentifizierung benutzt, ist der Dienst sicher.
Der Hauptangriffsvektor ist heutzutage PHP bzw. PHP-Anwendungen, wie Foren, Blogs, CMSe.

[kai-behncke]

Kann ich eigentlich alternativ jeden x-beliebigen Port für ssh nehmen/festlegen?

[Joe User]

Nein, nur Ports, welche nicht von anderen Diensten benötigt werdeen, siehe auch /etc/services

[Joe User]

Da es in der aktuellsten Liste http://www.iana.org/assignments/port-numbers auch noch veraltet aufgeführt ist, sollte man Andy Burgess freundlich darum bitten, die Einträge bei der IANA zu aktualisieren/erweitern. Solange die jeweiligen Hersteller und/oder Contributoren nicht regelmässig ihre Einträge warten, kann man sich auf diese Liste natürlich nicht verlassen. Zumal diese Liste eh nur als Anhaltspunkt zu verstehen ist und nicht als gültige Referenz. Aus diesem Grund schrieb ich ja "siehe auch" ;)

[daemotron]

Portverlegung hin oder her - wichtiger ist, dass die Authentifizierung auf Public Key umgestellt wird. Eine Beispielkonfiguration für den sshd findest Du im Wiki. Wahrscheinlich musst Du aber auf die Angabe der AddressFamily verzichten, weil Debian selbst bei 4.0 eine recht antike Version von OpenSSH beipackt.

Und wie bereits gesagt - SSH ist das unwahrscheinlichste aller Einfallstore, es sei denn, man hat als Passwort "root" oder "geheim" o. ä. gesetzt :twisted: Viel wahrscheinlicher ist ein Einbruch über eine schlecht programmierte Webanwendung, über die eine Webshell o. ä. untergeschoben wird, mit der dann der Zugang aufgebohrt werden kann.

Zu guter letzt - man kann einen Einbruch nicht immer verhindern, und selbst dem erfahrensten Admin kann mal eine Webanwendung geknackt werden. Die Frage ist nur, wie weit der Angreifer danach kommt. Bei einem gehärteten und strikt konfigurierten System ist spätestens dann Schluss, wenn der Angreifer versucht, weitergehende Rechte zu erlangen.