Online Magazine

Azure VMSS – Verhindern von Sicherheitslücken in isolierter Infrastruktur

In diesem Hack zum Thema „Azure Virtual Machine Scale Set (VMSS)“ zeige ich auf, wo sich eine Sicherheitslücke in einer isolierten Infrastruktur verbergen kann – wie man sie findet und schliesslich auch schliesst.

von Peter Stadler

Mit Verwendung des Microsoft Azure Services „Azure Virtual Machine Scale Set (VMSS)“ kann eine Gruppe von virtuellen Maschinen (VMs) mit Lastenausgleich und automatischer Skalierung erstellt bzw. verwaltet werden. Nun, was heisst das genau und worauf will ich hinaus?

Gehen wir vom Beispiel aus, in einem Unternehmen wird eine IT-Anwendung zur Ressourcenplanung bereitgestellt. Aufgrund der Herstellergarantie darf diese Anwendung aber nur auf virtuellen Maschinen installiert werden. Da dem Unternehmen wichtig ist, dass diese Anwendung 365 Tage im Jahr ohne Unterbrechung reibungslos erreichbar ist, muss für diese Anwendung die notwendige IT-Infrastruktur bereitgestellt werden. Azure Virtual Machine Scale Set erfüllt genau diesen Zweck. Der Service stellt eine IT-Infrastruktur bereit, die nicht nur für Ausfallsicherheit sorgt, sondern auch automatisch je nach Auslastung und Zugriff die passende Leistung bereitstellt. Der Service dient meist eher für Anwendungen für Big-Data-, Batch-, Container-Workloads, etc. Für unser Beispiel tut es eine Anwendung zur Ressourcenplanung ebenfalls. Wir gehen davon aus, dass die Anwendung nur intern (innerhalb des eigenen Unternehmens) erreichbar und aufrufbar sein soll. Sprich die Anwendung ist abgeschnitten vom Internet und somit wird eine isolierte Infrastruktur realisiert. Genau das ist aber nicht automatisch garantiert.

Die Sicherheitslücke

Beim Aufbau vom Azure VMSS hat man die Möglichkeit, zu wählen, ob diese eine öffentliche Anbindung bekommt oder eben nicht. Um den Lastenausgleich zu garantieren, wird im Front-End für den Zugriff ein Loadbalancer realisiert und dieser, wenn gewünscht, mit einer öffentlichen Anbindung ausgestattet:

Will man nun den Zugriff isoliert behandeln, vermeidet man am besten die öffentliche Anbindung. In unserem Hack erstellen wir sogar nicht mal ein Front-End für den Zugriff und wählen den Loadbalancer ab:

Nach der Erstellung haben wir somit einen isolierten Azure VMSS Service. Als Beispiel werden wir nun eine VM (bezeichnet als Node) genauer betrachten und die Sicherheitslücke aufdecken:

Wie zu sehen, hat dieser Node nur eine private und isolierte Anbindung mit der IP Adresse 10.100.2.4. Das Netz hierzu ist bereits mit einem Default-Regelwerk als Schutz (bezeichnet als Network Security Group) ausgestattet, zu dem wir später noch im Detail kommen werden:

Die ersten Tests auf dem Node sind vielversprechend und zeigen klar, dass es sich hier um einen isolierten Aufbau handelt, da scheinbar keine Kommunikation ins Internet funktioniert:

Wenn wir jedoch die Tests etwas höher im OSI-Model ansetzen, dann stellen wir spätestens bei einem HTTPS-Request fest, dass eine Internetverbindung zustande kommt:

Dem Node ist dadurch natürlich auch eine öffentliche IP zugeordnet, was laut unserem isolierten Aufbau gar nicht sein darf:

Da ist sie nun, unsere Sicherheitslücke.

Hack

Nun sehen wir uns mal das Standard-Regelwerk in der Network Security Group in Azure an. Was kann zusätzlich der Sicherheitsvorkehrungen und der isolierten Umgebung ohne öffentliche Anbindung unternommen werden, um diese Lücke zu schliessen?

Bei genauerer Betrachtung der Standard-Regeln können wir folgendes festhalten:

Eingehender Netzwerk-Verkehr ist nur vom privaten Netzwerk und vom Service Azure Loadbalancer erlaubt, alles weitere wird unterbunden. Dieses Regelwerk ist soweit in Ordnung und deckt unseren Sicherheitsbedarf in diesem Hack.
Ausgehender Netzwerk-Verkehr ist hingegen ins private Netzwerk, aber auch Richtung Internet und somit ins öffentliche Netzwerk erlaubt, was wir in unserem Hack verhindern wollen, um die Sicherheitslücke zu schliessen.

Somit müssen wir als Schlussfolgerung nur die ausgehenden Regeln individualisieren und anpassen: