Wie Sie Ihr Google Cloud Platform-Projekt sicherer machen: GCE-Netzwerksicherheit

Dies ist der vierte Artikel in einer Reihe von Beiträgen über die Sicherheit von Google Cloud Platform.

Die ersten beiden Artikel (Artikel I., Artikel II.) der Serie konzentrierten sich auf die Härtungsmöglichkeiten auf Projektebene mit Google Cloud Platform. Der dritte Beitrag beleuchtete das Thema der integrierten GCE-Sicherheit. Im vierten Artikel der Serie werden wir verschiedene Schutztools auf Netzwerkebene vorstellen, die für Ihre Google Compute Engine-Instanzen verfügbar sind. Lesen Sie diesen Artikel, um mehr über die GCE-Netzwerksicherheit zu erfahren.

Verpassen Sie auch nicht den letzten Beitrag dieser Serie: Artikel V.: Wie Sie Ihr Google Cloud Platform-Projekt sicherer machen: GCE OS-Sicherheit

GCE-Netzwerksicherheit - Verwendung von Google Cloud Load Balancer für eingehenden HTTPS-Verkehr

Es ist immer eine gute Praxis, die Angriffsfläche zu reduzieren. Diese Methode ist ein Beispiel dafür, wie man genau das mit dem eingehenden HTTP- und HTTPS-Verkehr macht. Wenn Ihre Instanz Webanfragen bedient, sollten Sie den Google Cloud Load Balancer verwenden, um diese Anfragen an Ihre Instanz weiterzuleiten und die direkte Öffnung der HTTP- und HTTPS-Ports zum Internet zu vermeiden. Dies ist eine gute Idee, wenn Sie nur einen einzigen Computer verwenden. Dieser Ansatz hat zwei Vorteile. Der eine ist, dass Sie die einzelnen öffentlichen IP-Adressen Ihrer Webserver nicht preisgeben und sie so schwerer angreifbar machen. Der andere Vorteil ist, dass der Google Cloud Load Balancer einige Filter auf die eingehenden HTTP-Anfragen anwendet, so dass Sie wahrscheinlich gar nicht erst einen Haufen bösartiger Anfragen sehen, weil sie herausgefiltert werden, bevor sie Ihre Instanzen erreichen.

Außerdem haben Sie die Möglichkeit, Ihre Webserver zu skalieren oder zu ersetzen und dabei die volle Verfügbarkeit Ihrer Dienste aufrechtzuerhalten. Sie können die Backend-Server hinter dem Load Balancer jederzeit austauschen, und es können mehrere Webinstanzen gleichzeitig Ihre Websites bedienen.

GCE Netzwerksicherheit - Einschränkung der ausgehenden Firewall-Regeln

Selbst wenn Sie alle eingehenden Anfragen außer Webanfragen deaktivieren und sogar diese Anfragen durch den Google Cloud Load Balancer leiten, kann es sein, dass Sie immer noch einen Fehler in der Software haben, die Sie in Ihrem Web-Stack verwenden (z. B. Tomcat, NGINX) oder vielleicht sogar in Ihrem Anwendungscode. Wenn es einem Angreifer irgendwie gelingt, die Kontrolle über die Webprozesse zu erlangen und beliebigen Code auf Ihrem Webserver auszuführen, wird es sehr viel schwieriger sein, diesen Rechner langfristig zu kontrollieren, ohne mit ihm von einem Master-Knoten aus zu kommunizieren. Aus diesem Grund verwenden die meisten Angriffe eine Technik, um Ihre Firewall-Regeln auszutricksen und eine ausgehende Verbindung zu einem externen, vom Angreifer verwalteten Kontrollhost zu öffnen. Auf diese Weise ist die Verbindung nicht eingehend (wo die Firewall sie blockieren würde), sondern ausgehend (wo die Regeln normalerweise viel weniger restriktiv sind).

Sie können diese Art von Angriff erheblich erschweren, wenn Sie neue ausgehende Verbindungen zum Internet in Ihren Firewall-Regeln deaktivieren (entweder auf Betriebssystemebene auf den virtuellen Maschinen oder mit der von GCE bereitgestellten Firewall). Es gibt zwei Möglichkeiten, dies zu tun. Die eine besteht darin, nur neu aufgebaute ausgehende Verbindungen zu deaktivieren, so dass alle Antwortpakete für eingehende Verbindungen die Instanz verlassen können. Eine zweite, strengere Methode besteht darin, ausgehende Verbindungen nur zu den IPs zuzulassen, von denen aus Sie auf die Maschine zugreifen wollen. Auf diese Weise können nur diese Rechner mit der Instanz kommunizieren und es ist kein anderer Zugriff von außen möglich.

GCE Network Security - Einrichten eines HTTPS-Proxys für den ausgehenden Zugriff

Wenn Sie die Regeln aus dem vorigen Abschnitt anwenden, könnten Sie unbeabsichtigt einige legitime Funktionen Ihrer Anwendungen einschränken. Wenn Ihr Anwendungscode während des normalen Betriebs auf eine API eines Drittanbieters zugreift, müssen Sie den ausgehenden Verkehr in der Firewall für die IP-Adressen dieses Drittanbieterdienstes aktivieren. Andernfalls kann der Code nicht darauf zugreifen. Wenn Ihre Anwendungen nur HTTP oder HTTPS als ausgehende Verbindungen verwenden, ist es besser, einen HTTPS-(Web)Proxy für die Anfragen zu verwenden. Auf diese Weise müssen Sie nicht jede IP des API-Dienstes eines Drittanbieters in Ihren Firewall-Regeln auflisten. Installieren Sie einen Proxy-Server auf einer separaten Instanz.

Lassen Sie diese Instanz neue Verbindungen zum gesamten Internet an den HTTP- und HTTPS-Ports in der Firewall öffnen. Richten Sie dann die interne IP dieser Instanz als Proxy-Server ein, den Sie auf Ihren Webservern verwenden. Auf diese Weise haben Sie Zugang zu allen APIs über HTTP oder HTTPS, während ein Angreifer standardmäßig keine neuen ausgehenden Webverbindungen von Ihrem Rechner aus öffnen kann. Zumindest ohne Kenntnisse über Ihr Netzwerk-Layout.

GCE Network Security- Überprüfen Sie alle eingehenden Firewall-Regeln, die 0.0.0.0/0 als Quelle haben

Wenn Sie über Firewall-Regeln für eingehende Verbindungen verfügen, bei denen das gesamte Internet als zulässige Quelle angegeben ist, sollten Sie diese Regeln noch einmal überdenken. Wenn Sie den SSH-Zugang für das gesamte Internet erlauben, haben Sie eine sehr große Angriffsfläche und müssen sich darauf verlassen, dass jeder Benutzer seinen privaten SSH-Schlüssel nicht verliert. Und Ihr spezieller SSH-Server darf keine Sicherheitslücken aufweisen.

Es gibt mehrere Methoden, um die Anzahl der eingehenden Regeln mit breiten Quellen zu entfernen oder zumindest zu reduzieren. Wenn der spezifische Port nur von einer begrenzten Anzahl von Mitarbeitern/Partnern genutzt wird, ist es besser, die IP-Adressen der Büros anzugeben, von denen aus der Dienst genutzt wird. Wenn der Zugriff für Kunden erfolgt und der Dienst eine Webseite oder eine API ist, verwenden Sie Google Cloud Load Balancer vor Ihren Instanzen, wie zuvor beschrieben. Wenn Sie ein begrenztes Publikum haben, sind die Anfragen nicht webbezogen. Sie können den Quell-IP-Adressbereich des Publikums nicht im Voraus kennen. In diesem Fall sollten Sie die im nächsten Abschnitt beschriebenen Methoden ausprobieren.

GCE-Netzwerksicherheit - Verwenden Sie VPN oder einen Jump-Host für SSH oder spezielle Port-Zugänge

Wenn Sie über einen speziellen Port mit einem Dienst verfügen, der für eine begrenzte Zielgruppe bestimmt ist, sollten Sie diesen Dienst nicht für das gesamte Internet öffnen. Wenn die IP-Adresse des Publikums nicht im Voraus bekannt ist, können Sie zwei Lösungen ausprobieren. Erstellen Sie einen Jump-Host. Dies ist eine dedizierte Instanz, die eine Art von Fernzugriff (z. B. SSH, RDP) für das gesamte Internet ermöglicht. Von dieser Instanz aus ist der spezielle Dienst über das interne Netz zugänglich. Folglich verbindet sich Ihr Publikum zunächst mit dem Jump-Host und nutzt dann den Dienst von diesem Rechner aus. Dieser Ansatz hat einige Voraussetzungen, um sicher zu sein:

• Die IP-Adresse des Jump-Hosts ist nicht öffentlich bekannt.
• Dieser Jump-Host muss der aktuellste und am besten gesicherte Rechner in Ihrer gesamten Infrastruktur sein.
• Wenn Sie die Sicherheit dieses Ansatzes erhöhen wollen, können Sie einige zusätzliche Sicherheitsmaßnahmen anwenden.
• Verlegung des Fernzugriffs von dem bekannten Standard-Port auf einen zufälligen, nur Ihrem Publikum bekannten Port ODER
• Anwendung von fortgeschrittenen Techniken wie Port-Knocking.

Wenn diese Methode für Sie nicht geeignet ist, können Sie eine VPN-Einrichtung ausprobieren. In diesem Fall installieren Sie eine dedizierte VPN-Serverinstanz. Dort öffnen Sie nur die Ports des VPN-Servers für das gesamte Internet und verwenden eine schlüsselbasierte Authentifizierung. Auf diese Weise können Sie von Ihrem Rechner aus direkt über das interne Netz auf die Dienste im internen Netz zugreifen. Wenn die Pakete durch das Internet reisen, werden sie gekapselt und verschlüsselt, so dass auch dieser Ansatz sicher ist.

Filtern des Datenverkehrs zwischen Instanzen im selben Netzwerk

Isolierung ist eine sehr gute Strategie für den Fall, dass alles andere versagt. In diesem Fall gibt es immer noch eine letzte Verteidigungslinie in Ihrem System. Das bedeutet, dass nur einige Gruppen von Rechnern kompromittiert werden und nicht alle zur gleichen Zeit. Wenn ein Angreifer in den Besitz aller Ihrer privaten SSH-Schlüssel gelangt und die IP-Adressen einiger Rechner kennt, bei denen der SSH-Port offen ist, kann er nur auf diese Rechner zugreifen und nicht auf andere im privaten Netz. Dies ist darauf zurückzuführen, dass eine interne Netzwerkregel den Zugang zwischen den Rechnern blockiert. Es ist ratsam, Ihr internes Netzwerk in verschiedene Subnetze aufzuteilen, zwischen denen kein Zugriff möglich ist. Im Standardnetzwerk ist der gesamte interne Datenverkehr zwischen den Instanzen erlaubt. Sie können diese Einstellung jedoch entsprechend Ihren spezifischen Anforderungen ändern.

Entfernen Sie die öffentliche IP-Adresse einer Instanz, wenn sie nicht verwendet wird

Wenn eine Instanz keinen Dienst außerhalb des privaten Netzwerks anbietet (z. B. ein Verwaltungsknoten), ist es ratsam, ihre öffentliche IP-Adresse zu entfernen. Auf diese Weise ist es ihr unmöglich, Datenverkehr vom oder zum Internet zu empfangen oder zu senden. Dies ist eine sehr gute Möglichkeit, die Angriffsfläche dieser Instanzen stark zu reduzieren.