Wenn der Xenserver auf einem Rootserver im Internet installiert wird, ist dieser über die ihm zugeordnete offizielle IP Adresse erreichbar. Dies bedeutet, dass das Managementnetzwerk / Managementinterface grundsätzlich von jedem aufrufbar ist.
Um dieser Problematik etwas entgegenzuwirken, kann man die iptablesfirewall umkonfigurieren bzw. den SSH-Port verschieben.
Mir ist bewusst, dass das nur ein Tropfen auf den heißen Stein ist, jedoch jedenfalls besser wie nichts.
SSH Port verlegen
Per XenCenter Serverkonsole sind folgende Anpassungen durchzuführen.
Im Verzeichnis /etc/ssh/sshd_config wird der Port verlegt. Standardmäßig läuft SSH auf Port 22. Dies verlegt man z.B. auf Port 2232.
Iptables anpassen
Nun muss natürlich die Firewall angepasst werden, damit Verbindungen auf Port 2232 erlaubt werden.
Das anzupassende File namens iptables findet sich im Ordner /etc/sysconfig. Es beinhaltet bereits einige Regeln. Unter anderem findet sich auch die Regel für den Standardport (22) in dieser Datei. Diese wird entsprechend angepasst, sodass sie dem „neuen“ SSH-Port entspricht.
Schließlich ist die Datei noch zu speichern und iptables und sshd neu zu starten.
service iptables restart && service sshd restart
hosts.deny und hosts allow einsetzen
Genaugenommen eigentlich ein MUSS in einer solchen Netzwerkkonstellation.
Sofern der PC, mit dem man auf den Xenserver einsteigt, mit einer statischen offiziellen IP-Adesse ins Internet geht, gibt es eine elegante Methode, den Zugriff auf den Xenserver einzuschränken.
In der Datei /etc/hosts.allow wird definiert, welche IPs auf den Server zugreifen dürfen. Die anzuführenden IPs sind neben der localhost IP (127.0.0), auch noch die statische IP, von der aus man den Xenserver managed.
Der Eintrag kann z.B. so aussehen:
ALL: 127.0.0 89.163.225.17
D.h. diese IPs dürfen sämtliche Services auf dem Xenserver nutzen.
Nun muss in /etc/hosts.deny noch für alle anderen ALLES verboten werden. Dieser Eintrag ist recht simpel gehalten und sieht folgendermaßen aus:
ALL: ALL
Durch diese Einstellungen wird jedem Client der Zugriff verweigert, solange nicht die Ausnahmeregelung in den hosts.allow greift.
Nachteil
Natürlich bedingt dies, dass man immer mit den angeführten IP Adressen auf den Xenserver zugreift. Blöd nur, wenn man gerade „irgendwo“ ist und man nicht von seiner gewohnten IP-Adresse aus aufs Internet zugreift.
Workaround
Sollte neben dem Dedicated Root(Xen)Server noch ein weiterer Server mit statischer offizieller IP im (Inter)net aktiv sein, kann man diese IP ebenso in die hosts.allow eintragen. Schließlich könnte dann der Umweg über den zusätzlichen Server genommen werden.
Sprich also:
Client mit dynamischer IP -> ssh zu zusätzlichem Rootserver (IP steht am Xen in den hosts.allow) -> ssh zu Xenserver.
Hallo Florian,
da hast du sicher nicht unrecht. Es kann zu Problemen kommen, klar.
Dennoch habe ich beispielsweise schon mehrfach erlebt, dass bei einigen Hostern / Dedicated Server Anbietern der Port 22 derart zugemüllt wird, dass per SSH kaum noch etwas geht.
Wenn man den SSH-Port verschiebt, dann nimmt man ihn wenigstens aus der Schusslinie der automatisierten Angriffe, die auf Port 22 abzielen.
Es ist also eigentlich gar keine Sicherheitsmaßnahme, denn wenn jemand den SSH-Port finden will, findet er ihn auch, wenn er verschoben worden ist. Ich denke, dass der Einsatz von hosts.allow und hosts.deny eine ganz gute Sache ist.
Optimal wäre es natürlich, wenn man die virtuelle Umgebung so konfiguriert, dass man ausschließlich per VPN auf den Host / eine VM connecten kann.
Beispielsweise in der Form, dass man eine VM verwendet zu der man sich per VPN hinverbindet und das Management dann über diese VM erledigt.
LG
*Kommentar wiederhergestellt*
Bitte, bitte, bitte, hört auf SSH-Ports zu verbiegen. Das sorgt nur irgendwann für Ärger (Programme mit nicht-anpassbarem Ziel-Port, nervige Firewalls, die keine Verbindungen zu Ports außer 22,80,443 zulassen, …)
Ein starkes Passwort (oder noch besser: SSH-Keys) und gut.
Und wenn die vielen Log-Einträge nerven, fail2ban.