Xenserver 7: Sicherheit erhöhen – Rootserverbetrieb

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.

 

 

 

4 Kommentare

  • @Florian

    Mit Deiner Aussage hast Du klar gezeigt zu welcher „Art“ Du gehörst.

    Daniel schreibt hier einen ganz guten (lange nicht perfekt – aber gut) Artikel,
    wie man die Sicherheit erhöhen kann und Du hast nicht besseres zu tun als
    am Ende zu schreiben,..“Liebe Leute macht das nicht! Seid lieber alle ein Lazy-Admin so wie ich es scheinbar bin“.

    Ganz großes Kino. Also Bequemlichkeit auf Kosten der Sicherheit.
    Was ist wenn es wieder mal ein 0-day exploit für SSH gibt?
    Und irgendwelche Bots ganze Subnetze durchsuchen und automatisch alle IPs auf port 22 versuchen zu exploiten?!
    Gehen wir davon aus das Du Vogel noch nicht gepatched hast (liegt in der natur von 0-day).
    Was dann? Dann ist Deine Kiste ge’rooted on Teil eines Botnets was dann munter fröhlich DDOS attacken fährt oder sonst was für sachen macht. Das beste – dank deines tollen Kommentars gibt es bestimmt den ein oder anderen der denkt das Du Recht haben könntest. Also sprechen wir hier von n + 1 ge’rooteten kisten. Danke erstmal dafür!

    Und mal so nebenbei – welche Programme wird es den in Zukunft geben die unbedingt port 22 brauchen wo man den Ziel-port nicht anpassen kann?! WAS zum geier bitte sollte sonst port 22 brauchen? Vor allem auf einem xen-server wo eh nur einer über SSH connected – und das ist der admin mit seinem scheiss ssh-client. Also deine aussage hat echt null logische grundlage und ist nur zum nachteil. Aber das sind mir die richtigen – keine Ahnung, aber zu ALLEM eine Meinung.

    Kleiner Hinweis an alle.
    Einen anderen port zu nehmen ist eine gute idee, dann fliegen die ganzen automatischen angriffe gegen die „Wand“, weil keiner sich die mühe macht über jede IP ein port-scan laufen zu lassen, wenn es ein automatisierter angriff ist.

    Des weiteren empfehle ich den login per root über ssh zu verbieten.

    /etc/ssh/sshd_config:
    PermitRootLogin no
    (sshd re-starten)

    ACHTUNG:
    legt euch vorher einen anderen user mit einem namen an auf den man nicht schließen kann:
    sprich z.B. wackelpeter732 oder sonst was.
    logt euch dann mit wackelpeter732 über ssh ein und macht ein „su -“ zu root.

    Der vorteil hierbei ist, das keine brute-force-attacke funktioniert wenn man nicht den username hat.

    Wer spass dran hat, kann sich nicht fail2ban drauf packen und den geänderten ssh-port überwachen.
    Wenn es dann doch mal ein script-kind gibt was einen port-scan macht und dann sich am gefundenen ssh-port austoben will – packt ihr ihn einfach für 24h auf die iptables blockliste.

    Wenn Ihr es gescheit machen wollt, dann läuft das management interface nicht über eine öffentliche ip, sondern
    „private/lan/subnetze“ 192.168.1.*/24 / 10.0.0.*/24 usw.
    Das ist leider meistens nicht ganz so günstig wenn man nur einen server hat.

    Ansonsten X server und eine zusätzliche kiste in nem vlan. VPN (oder sonstige verbindung) zur zusätzlichen kiste, und von dieser Kiste dann im „privaten netzwerk“ die sachen aufrufen. Aber wie gesagt – kosten halt bisschen mehr.

    So schöne Tageszeit euch allen (welche das auch immer sein mag!)

    EOF

    • Hallo und vielen Dank für deinen Kommentar. (Auch wenn er recht offensiv formuliert ist) – aber so sind deutsche Hacker, die sich gerade in Russland befinden, halt 😉

  • 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.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

* Zustimmung zur Datenspeicherung lt. DSGVO

*

Ich bin damit einverstanden

This site uses Akismet to reduce spam. Learn how your comment data is processed.