Übersicht über Firewallregeln

Mit den Firewallregeln der Google Cloud Platform (GCP) können Sie den Traffic zu und von Ihren VM-Instanzen steuern und auf der Basis einer von Ihnen festgelegten Konfiguration zulassen oder ablehnen. Aktivierte GCP-Firewallregeln werden immer durchgesetzt. Sie schützen Ihre Instanzen unabhängig von ihrer Konfiguration und ihrem Betriebssystem, selbst wenn sie nicht gestartet wurden.

Jedes VPC-Netzwerk wirkt wie eine verteilte Firewall. Die Firewallregeln werden auf Netzwerkebene definiert, die Verbindungen aber pro Instanz zugelassen oder abgelehnt. Die GCP-Firewallregeln werden dabei nicht nur zwischen Ihren Instanzen und anderen Netzwerken angewendet, sondern auch zwischen einzelnen Instanzen innerhalb eines Netzwerks. Anleitungen zum Erstellen von Firewallregeln und zu deren Anwendung finden Sie unter Firewallregeln verwenden.

Firewallregeln auf der GCP

Beim Erstellen einer GCP-Firewallregel geben Sie ein VPC-Netzwerk sowie eine Gruppe von Komponenten an, mit denen die Aktionen der Regel definiert werden. Mit den Komponenten können Sie auf bestimmte Arten von Traffic verweisen, basierend auf dem Protokoll, den Ports, Quellen und Zielen des Traffics. Weitere Informationen finden Sie unter Komponenten von Firewallregeln.

Sie können GCP-Firewallregeln über die Google Cloud Platform Console, das gcloud-Befehlszeilentool und die REST API erstellen und ändern. Beim Erstellen oder Ändern einer Firewallregel geben Sie mit der Zielkomponente der Regel die Instanzen an, auf die sie angewendet werden soll.

Neben den von Ihnen erstellten Firewallregeln gibt es bei der GCP noch weitere Regeln, die den ein- und ausgehenden Traffic beeinflussen können:

  • Die GCP lässt bestimmte IP-Protokolle wie GRE in einem VPC-Netzwerk nicht zu. Weitere Informationen finden Sie unter Permanent blockierter Traffic.

  • Die GCP lässt die Kommunikation zwischen einer VM-Instanz und ihrem entsprechenden Metadatenserver unter 169.254.169.254 immer zu. Einzelheiten hierzu finden Sie unter Immer zugelassener Datenverkehr.

  • Für jedes Netzwerk gelten zwei implizierte Firewallregeln, die ausgehende Verbindungen zulassen und eingehende Verbindungen blockieren. Von Ihnen erstellte Firewallregeln können diese implizierten Regeln überschreiben.

  • Das default-Netzwerk ist bereits mit Firewallregeln gefüllt, die Sie löschen oder bearbeiten können.

Spezifikationen

GCP-Firewallregeln haben folgende Merkmale:

  • Firewallregeln unterstützen nur IPv4-Traffic. Wenn Sie eine Quelle für eine Eingangsregel oder ein Ziel für eine Ausgangsregel durch eine IP-Adresse angeben, müssen Sie dafür eine IPv4-Adresse oder einen IPv4-Block in CIDR-Notation verwenden.

  • Die Aktion jeder Firewallregel ist entweder allow oder deny. Die Regel gilt für den Traffic, so lange dieser erzwungen wird. Sie können eine Regel beispielsweise zu Fehlerbehebungszwecken deaktivieren.

  • Jede Firewallregel gilt entweder für eingehenden (ingress) oder für ausgehenden (egress) Traffic, jedoch nicht für beide Richtungen. Weitere Informationen finden Sie unter Traffic-Richtung.

  • Beim Erstellen einer Firewallregel müssen Sie ein VPC-Netzwerk auswählen. Während die Regel auf Instanzebene erzwungen wird, ist ihre Konfiguration einem VPC-Netzwerk zugeordnet. Das heißt, dass Sie keine Firewallregeln für VPC-Netzwerke gemeinsam verwenden können. Dies gilt auch für Netzwerke, die über VPC-Netzwerk-Peering verbunden sind oder für die Verwendung von Cloud VPN-Tunneln.

  • GCP-Firewallregeln sind zustandsorientiert. Wenn eine Verbindung zwischen einer Quelle und einem Ziel oder einem Ziel und einem anderen Ziel zugelassen wird, ist der gesamte Traffic in beide Richtungen zulässig, solange die Verbindung aktiv ist. Dies bedeutet, dass Firewallregeln eine bidirektionale Kommunikation erlauben, wenn eine Sitzung eingerichtet ist. Die Verbindung gilt als aktiv, wenn alle zehn Minuten mindestens ein Paket gesendet wird. Firewallregeln können den Traffic nicht auf eine Richtung beschränken, also nicht den Traffic in einer Richtung zulassen und den zugehörigen Rücktraffic ablehnen.

  • GCP-Firewallregeln fügen fragmentierte TCP-Pakete nicht wieder zusammen. Das bedeutet, dass eine Firewallregel für das TCP-Protokoll nur auf das erste Fragment angewendet wird, da dies den TCP-Header enthält. Für das TCP-Protokoll geltende Firewallregeln sind nicht auf nachfolgende TCP-Fragmente anwendbar.

  • Die maximale Anzahl nachverfolgter Verbindungen in der Firewallregeltabelle hängt von der Anzahl der zustandsorientierten Verbindungen ab, die vom Maschinentyp der Instanz unterstützt werden:

Maschinentyp der Instanz Maximale Anzahl an zustandsorientierten Verbindungen
Maschinentypen mit gemeinsam genutztem Kern 130.000
Instanzen mit einer bis acht vCPUs 130.000 Verbindungen pro vCPU
Instanzen mit mehr als acht vCPUs 1.040.000 (130.000 × 8) Verbindungen insgesamt

Implizierte Regeln

Jedes VPC-Netzwerk hat zwei implizierte Firewallregeln. Dies sind die folgenden Regeln (nicht in der Cloud Console angezeigt):

  • Die implizierte Regel zum Zulassen von ausgehendem Traffic: Eine egress-Regel mit der Aktion allow, dem Ziel 0.0.0.0/0 und der niedrigsten Priorität (65535) ermöglicht einer Instanz das Senden von Traffic zu jedem beliebigen Ziel. Davon ausgenommen ist Traffic, der von der GCP blockiert wird. Der ausgehende Zugriff kann durch eine Firewallregel mit höherer Priorität eingeschränkt werden. Der Internetzugriff ist zulässig, wenn keine anderen Firewallregeln den ausgehenden Traffic ablehnen und wenn die Instanz eine externe IP-Adresse hat oder eine NAT-Instanz verwendet. Weitere Informationen finden Sie unter Anforderungen für den Internetzugriff.

  • Die implizierte Regel zum Ablehnen von eingehendem Traffic: Eine ingress-Regel mit der Aktion deny, der Quelle 0.0.0.0/0 und der niedrigsten Priorität (65535) schützt alle Instanzen durch Blockierung des eingehenden Traffics. Der eingehende Zugriff kann von einer Regel mit höherer Priorität zugelassen werden. Das default-Netzwerk enthält einige zusätzliche Regeln, die diese Regel überschreiben und bestimmte Arten von eingehendem Traffic zulassen.

Die implizierten Regeln können nicht entfernt werden, haben aber die niedrigste Priorität. Sie können von Regeln überschrieben werden, die Sie selbst erstellen, solange Ihre Regeln eine höhere Priorität haben (Prioritätswerte kleiner als 65535).

Vorkonfigurierte Regeln im default-Netzwerk

Das default-Netzwerk enthält vorkonfigurierte Firewallregeln, die eingehenden Traffic an Instanzen zulassen. Diese Regeln können nach Bedarf gelöscht oder geändert werden:

  • default-allow-internal
    Lässt eingehende Verbindungen für alle Protokolle und Ports zwischen den Netzwerkinstanzen zu. Diese Regel hat die zweitniedrigste Priorität 65534 und erlaubt im Endeffekt eingehende Verbindungen zu VM-Instanzen von anderen VM-Instanzen im selben Netzwerk.
  • default-allow-ssh
    Lässt eingehende Verbindungen auf TCP-Port 22 von jeder Quelle zu jeder Instanz im Netzwerk zu. Diese Regel hat die Priorität 65534.
  • default-allow-rdp
    Lässt eingehende Verbindungen auf TCP-Port 3389 von jeder Quelle zu jeder Instanz im Netzwerk zu. Diese Regel hat die Priorität 65534 und ermöglicht Verbindungen zu Instanzen, auf denen das Remotedesktopprotokoll (RDP) von Microsoft ausgeführt wird.
  • default-allow-icmp
    Lässt eingehenden ICMP-Traffic von jeder Quelle zu jeder Instanz im Netzwerk zu. Diese Regel hat die Priorität 65534 und ermöglicht die Verwendung von Tools wie ping.

Permanent blockierter Traffic

Die Google Cloud Platform blockiert immer den im Folgenden aufgeführten Datenverkehr. Mit Firewallregeln können Sie die in der untenstehenden Tabelle aufgeführten Arten von Traffic nicht zulassen.

Permanent blockierter Traffic Gilt für
GRE-Traffic Alle Quellen, alle Ziele, auch zwischen Instanzen, die interne IP-Adressen verwenden
Andere Protokolle als TCP, UDP, ICMP und IPIP Traffic zwischen:
• Instanzen und dem Internet
• Instanzen, die mit externen IP-Adressen angesprochen werden
• Instanzen mit einem Load-Balancer mit einer externen IP-Adresse
Ausgehender Traffic auf TCP-Port 25 (SMTP) Traffic von:
• Instanzen in das Internet
• Instanzen zu anderen Instanzen, die von einer externen IP-Adresse angesprochen werden

Permanent zugelassener Traffic

Google betreibt neben jeder Instanz unter 169.254.169.254 einen lokalen Metadatenserver. Dieser Server ist für den Betrieb der Instanz unerlässlich. Daher kann die Instanz unabhängig von den konfigurierten Firewallregeln darauf zugreifen. Der Metadatenserver stellt die folgenden grundlegenden Dienste für die Instanz bereit:

Komponenten von Firewallregeln

Jede Firewallregel besteht aus den folgenden Konfigurationskomponenten:

  • Eine numerische Priorität, die dafür ausschlaggebend ist, ob die Regel angewendet wird. Es wird nur die Regel mit der höchsten Priorität (niedrigste Prioritätsnummer) angewendet, wenn der Traffic mit ihren anderen Komponenten übereinstimmt. In Konflikt stehende Regeln mit niedrigerer Priorität werden ignoriert.

  • Die Trafficrichtung: ingress-Regeln gelten für eingehende Verbindungen von angegebenen Quellen zu GCP-Zielen und egress-Regeln gelten für Traffic von Zielen zu angegebenen anderen Zielen.

  • Eine Aktion bei Übereinstimmung, entweder allow oder deny. Diese legt fest, ob die Regel Traffic zulässt oder blockiert.

  • Ein Ziel, das die Instanzen (einschließlich GKE-Cluster und Instanzen in der flexiblen App Engine-Umgebung) definiert, für die die Regel gilt.

  • Eine Quelle für ingress-Regeln oder ein Ziel für egress-Regeln

  • Das Protokoll (z. B. TCP, UDP oder ICMP) und der Port

  • Der Erzwingungsstatus der Firewallregel: Sie können Firewallregeln aktivieren und deaktivieren, ohne sie zu löschen.

Zusammenfassung der Komponenten

Eingangsregel (Ingress)
Priorität Aktion Erzwingung Parameter "target" (definiert das Ziel) Quelle Protokolle und Ports
Ganzzahl von 0 bis einschließlich 65535; Standard: 1000.
Entweder allow oder deny. Entweder enabled (Standard) oder disabled. Der Parameter "target" gibt das Ziel an. Mögliche Definitionen:
• Alle Instanzen im
   VPC-Netzwerk
• Instanzen nach
  Dienstkonto
• Instanzen nach Netzwerktag
Beispiele:
• Bereich von IPv4-Adressen;
  Standard: beliebig (0.0.0.0/0)
• Instanzen nach
  Dienstkonto
• Instanzen nach Netzwerktag
Legen Sie ein Protokoll oder ein Protokoll und einen Port fest.
Ist nichts festgelegt, gilt die Regel für alle Protokolle.
Ausgangsregel (Egress)
Priorität Aktion Erzwingung Parameter "target" (definiert die Quelle) Ziel Protokolle und Ports
Ganzzahl von 0 bis einschließlich 65535; Standard: 1000.
Entweder allow oder deny. Entweder enabled (Standard) oder disabled. Der Parameter "target" gibt die Quelle an. Mögliche Definitionen:
• Alle Instanzen im
   VPC-Netzwerk
• Instanzen nach
  Dienstkonto
• Instanzen nach Netzwerktag
Jedes Netzwerk oder ein bestimmter Bereich von IPv4-Adressen; Standard: beliebig (0.0.0.0/0). Legen Sie ein Protokoll oder ein Protokoll und einen Port fest.
Ist nichts festgelegt, gilt die Regel für alle Protokolle.

Priorität

Die Priorität einer Firewallregel wird als Ganzzahl von 0 bis einschließlich 65535 angegeben. Niedrigere Werte bedeuten eine höhere Priorität. Wenn Sie beim Erstellen einer Regel keine Priorität angeben, wird dieser die Priorität 1000 zugewiesen.

Die relative Priorität einer Firewallregel im Vergleich zu anderen Regeln ist ausschlaggebend dafür, ob sie angewendet wird. Die Anwendung erfolgt nach folgenden Richtlinien:

  • Die Regel mit der höchsten Priorität, die für ein Ziel eines bestimmten Traffictyps gilt, hat Vorrang. Die festgelegten Ziele spielen dabei keine Rolle. Beispielsweise überschreibt eine ingress-Regel höherer Priorität für bestimmte Ports und Protokolle, die für alle Ziele gelten soll, eine ähnlich definierte Regel für dieselben Ports und Protokolle, die nur für bestimmte Ziele festgelegt ist.

  • Die Regel mit der höchsten Priorität, die für eine bestimmte Protokoll- und Portdefinition gilt, hat auch dann Vorrang, wenn die Protokoll- und Portdefinition allgemeinerer Art ist. Beispielsweise überschreibt eine ingress-Regel höherer Priorität, die den Traffic für alle Protokolle und Ports für bestimmte Ziele zulässt, eine ingress-Regel niedrigerer Priorität, die den TCP-Port 22 für die gleichen Ziele ausschließt.

  • Eine Regel mit der Aktion deny überschreibt eine andere Regel mit der Aktion allow nur dann, wenn die beiden Regeln die gleiche Priorität haben. Durch Verwendung von relativen Prioritäten können Sie allow-Regeln erstellen, die deny-Regeln überschreiben, und umgekehrt.

  • Regeln mit derselben Priorität und derselben Aktion haben das gleiche Ergebnis. Die bei der Auswertung verwendete Regel ist jedoch unbestimmt. Normalerweise spielt es keine Rolle, welche Regel verwendet wird, es sei denn, Sie aktivieren das Firewallregel-Logging. Wenn in den Logs Firewallregeln in einer einheitlichen und klar definierten Reihenfolge aufgeführt werden sollen, weisen Sie ihnen eindeutige Prioritäten zu. Weitere Informationen zum Logging finden Sie unter Logging von Firewallregeln – Übersicht.

Betrachten Sie das folgende Beispiel, das aus zwei Firewallregeln besteht:

  • Einer ingress-Regel aus den Quellen 0.0.0.0/0 (beliebig) mit der Aktion deny und der Priorität 1000, die für alle Ziele, alle Protokolle und alle Ports gilt.

  • Einer ingress-Regel aus den Quellen 0.0.0.0/0 (beliebig) mit der Aktion allow, die für bestimmte Ziele mit dem Tag webserver und für Traffic auf TCP 80 gilt.

Die Priorität der zweiten Regel bestimmt, ob TCP-Traffic auf Port 80 für die webserver-Ziele zugelassen wird:

  • Wenn für die Priorität der zweiten Regel eine Zahl größer als 1000 festgelegt ist, hat sie eine niedrigere Priorität. Es gilt dann die erste Regel, die den gesamten Traffic ablehnt.

  • Wenn für die Priorität der zweiten Regel 1000 festgelegt ist, haben die beiden Regeln identische Prioritäten. Es gilt dann die erste Regel, die den gesamten Traffic ablehnt.

  • Wenn für die Priorität der zweiten Regel eine Zahl kleiner als 1000 festgelegt ist, hat die Regel eine höhere Priorität. Dadurch wird Traffic auf TCP 80 für die webserver-Ziele zugelassen. Ohne weitere Regeln lehnt die erste Regel weiterhin alle anderen Arten von Traffic zu den webserver-Zielen ab. Dies gilt auch für den gesamten Traffic (inklusive TCP 80) zu Instanzen ohne das Tag webserver.

Das vorherige Beispiel zeigt, wie Sie mithilfe von Prioritäten selektive allow-Regeln und globale deny-Regeln als bewährte Sicherheitsmaßnahme mit niedrigster Berechtigung implementieren können.

Trafficrichtung

Die Richtung einer Firewallregel kann entweder ingress oder egress sein. Sie wird immer aus Sicht des Ziels definiert.

  • Die ingress-Richtung beschreibt den von einer Quelle an ein Ziel gesendeten Traffic. Eingangsregeln gelten für Pakete für neue Sitzungen, bei denen das Ziel des Pakets das Ziel ist.

  • Die egress-Richtung beschreibt den von einem Ziel an ein anderes Ziel gesendeten Traffic. Ausgangsregeln gelten für Pakete für neue Sitzungen, bei denen die Quelle des Pakets das Ziel ist.

  • Wenn Sie keine Richtung angeben, verwendet die GCP ingress.

Nehmen Sie als Beispiel eine Verbindung zwischen zwei VMs im selben Netzwerk. In diesem Fall kann der Traffic von VM1 zu VM2 mit einer der folgenden Firewallregeln gesteuert werden:

  • Einer ingress-Regel mit dem Ziel "VM2" und der Quelle "VM1".

  • Einer egress-Regel mit dem Ziel "VM1" und einem anderen Ziel "VM2".

Aktion bei Übereinstimmung

Die Aktionskomponente einer Firewallregel bestimmt, ob Traffic zugelassen oder blockiert wird, vorbehaltlich der anderen Komponenten der Regel:

  • Die Aktion allow erlaubt Verbindungen, die mit den anderen angegebenen Komponenten übereinstimmen.

  • Die Aktion deny blockiert Verbindungen, die mit den anderen angegebenen Komponenten übereinstimmen.

Erzwingung

Sie können die Einstellung, ob eine Firewallregel erzwungen werden soll, ändern. Dazu legen Sie deren Zustand auf aktiviert oder deaktiviert fest. Die Deaktivierung einer Regel ist für die Fehlerbehebung oder die Erteilung des temporären Zugriffs auf Instanzen nützlich. Es ist viel einfacher, eine Regel zu deaktivieren, zu testen und dann wieder zu aktivieren, als die Regel zu löschen und neu zu erstellen.

Sofern nicht anders angegeben, sind alle Firewallregeln bei der Erstellung aktiviert. Sie können aber auch eine Regel erstellen, die sich in einem deaktivierten Zustand befindet.

Der Erzwingungszustand für Firewallregeln kann von aktiviert in deaktiviert und wieder in aktiviert geändert werden, indem die Regel aktualisiert wird.

Sie können eine Firewallregel beispielsweise auch für die folgenden Situationen deaktivieren:

  • Für die Fehlerbehebung: Wenn Sie sich nicht sicher sind, ob eine Firewallregel Traffic blockiert oder zulässt, deaktivieren Sie sie vorübergehend. So können Sie ermitteln, welcher Zustand zutrifft. Dies ist hilfreich, um Probleme im Zusammenhang mit den Auswirkungen einer Regel in Kombination mit anderen Regeln zu beheben.
  • Für die Wartung: Durch die Deaktivierung von Firewallregeln können regelmäßige Wartungen vereinfacht werden. Angenommen, eine vorhandene Firewallregel blockiert eingehende SSH-Verbindungen an Ziele (z. B. Instanzen nach Zieltag) und diese Regel ist normalerweise aktiviert. Wenn eine Wartung ansteht, können Sie die Regel deaktivieren. Nach Abschluss dieses Vorgangs kann sie wieder aktiviert werden.

Ziel

Bei einer Eingangsregel (Ingress) legt der Parameter "target" die Ziel-VMs fest, einschließlich GKE-Cluster und Instanzen in der flexiblen App Engine-Umgebung. Bei einer Ausgangsregel (Egress) legt der Parameter "target" die Quell-VMs, -Cluster und -Instanzen fest. Mit dem Parameter "target" werden also immer GCP-VMs definiert. Ob diese jedoch Ziel oder Quelle des Traffics sind, hängt von der Richtung der Regel ab.

Ein Ziel definieren Sie mit genau einer der folgenden Optionen:

  • Alle Instanzen im Netzwerk: Die Firewallregel gilt für alle VMs im Netzwerk.

  • Instanzen nach Zieltag: Die Firewallregel gilt nur für VMs mit einem übereinstimmenden Netzwerktag.

  • Instanzen nach Zieldienstkonto: Die Firewallregel gilt nur für VMs, die ein bestimmtes Dienstkonto verwenden.

Unabhängig davon, wie Sie ein Ziel angeben, gilt die Firewallregel sowohl für dessen primäre als auch für dessen sekundäre (Alias-) IP-Adressen. Ziele für Eingangsregeln umfassen Traffic, der an die primäre IP-Adresse oder die sekundären IP-Adressen der Instanzen gesendet wird. Ziele für Ausgangsregeln umfassen Traffic, der von der primären oder sekundären IP-Adressen der Instanzen gesendet wird. Weitere Informationen zu den Vorteilen und Einschränkungen beider Methoden finden Sie unter Nach Dienstkonto oder Netzwerktag filtern.

Quelle oder Ziel

In Abhängigkeit von der Richtung der von Ihnen erstellten Firewall geben Sie entweder eine Quelle oder ein Ziel an, aber nicht beides.

  • Bei Eingangsregeln (Ingress) gibt der Parameter "target" die Ziel-VMs für den Traffic an. Sie können den Parameter "destination" nicht verwenden. Die Quelle wird mit dem Parameter "source" angegeben.

  • Bei Ausgangsregeln (Egress) gibt der Parameter "target" die Quell-VMs für den Traffic an. Sie können den Parameter "source" nicht verwenden. Das Ziel wird mit dem Parameter "destination" angegeben.

Quellen

Der Parameter "source" gilt nur für Eingangsregeln. Er muss eine der folgenden Angaben haben:

  • Quell-IP-Bereiche: Sie können IP-Adressbereiche als Quellen für Pakete angeben. Die Bereiche können Adressen innerhalb und außerhalb Ihres VPC-Netzwerks umfassen. Mit Quell-IP-Bereichen lassen sich Quellen innerhalb und außerhalb der GCP definieren.

  • Quelltags: Sie können die Quelle für Pakete als primäre interne IP-Adresse der Netzwerkschnittstelle anderer VMs im selben VPC-Netzwerk definieren und diese Quell-VMs anhand eines übereinstimmenden Netzwerktags identifizieren. Quelltags gelten nur für andere GCP-VMs in Ihrem Netzwerk. Informationen zu der maximalen Anzahl von anwendbaren Quelltags finden Sie unter VPC-Kontingente und -Limits.

  • Quelldienstkonten: Sie können die Quelle für Pakete als primäre interne IP-Adresse der Netzwerkschnittstelle anderer VMs im selben VPC-Netzwerk definieren und diese Quell-VMs anhand des von ihnen verwendeten Dienstkontos identifizieren. Quelldienstkonten gelten nur für andere GCP-VMs in Ihrem Netzwerk.

  • Sie können eine Kombination aus Quell-IP-Bereichen und Quelltags verwenden.

  • Sie können eine Kombination aus Quell-IP-Bereichen und Quelldienstkonten verwenden.

  • Wenn keine Quell-IP-Bereiche, Quelltags oder Quelldienstkonten angegeben werden, definiert die GCP die Quelle als beliebige IP-Adresse (0.0.0.0/0).

Ziele

Der Parameter "destination" gilt nur für Ausgangsregeln. Er akzeptiert nur IP-Adressbereiche. Die Bereiche können Adressen innerhalb und außerhalb Ihres VPC-Netzwerks umfassen.

Wenn Sie keinen Zielbereich angeben, definiert die GCP das Ziel als alle IP-Adressen (0.0.0.0/0).

Protokolle und Ports

Durch Angabe von Protokollen oder Protokollen und Ports lässt sich der Umfang einer Firewallregel einschränken. Sie können ein Protokoll oder eine Kombination aus Protokollen und ihren Ports festlegen. Wenn Sie sowohl Protokolle als auch Ports weglassen, gilt die Firewallregel für den gesamten Traffic mit jedem Protokoll und auf jedem Port.

Damit Sie eine Firewallregel präzisieren können, müssen Sie zuerst ein Protokoll angeben. Wenn das Protokoll Ports unterstützt, können Sie optional eine Portnummer oder einen Portbereich festlegen. Allerdings unterstützen nicht alle Protokolle Ports. Beispielsweise gibt es Ports für TCP und UDP, nicht jedoch für ICMP. Das ICMP-Protokoll unterstützt verschiedene ICMP-Typen, wobei es sich jedoch nicht um Ports handelt.

Sie können ein Protokoll anhand seines Namens (tcp, udp, icmp, esp, ah, sctp, ipip) oder seiner dezimalen IP-Protokollnummer angeben.

GCP-Firewallregeln verwenden Portinformationen, um auf den Zielport eines Pakets zu verweisen, nicht auf seinen Quellport:

  • Bei Firewallregeln für eingehenden Traffic (Ingress) stellen Zielports die Ports auf Systemen dar, die durch den Parameter "target" der Regel identifiziert werden. Der Parameter "target" gibt für Eingangsregeln die Ziel-VMs für den Traffic an.

  • Bei Firewallregeln für ausgehenden Traffic (Egress) stellen Zielports die Ports auf Systemen dar, die durch den Parameter "destination" der Regel identifiziert werden.

In der folgenden Tabelle sind die gültigen Kombinationen aus Protokoll- und Portspezifikationen für GCP-Firewallregeln zusammengefasst:

Spezifikation Beispiel Erklärung
Weder Protokoll noch Port Wenn Sie kein Protokoll angeben, gilt die Firewallregel für alle Protokolle und die zugehörigen Ports.
Protokoll tcp Wenn Sie ein Protokoll ohne Portinformationen angeben, gilt die Firewallregel für dieses Protokoll und alle zugehörigen Ports.
Protokoll und einzelner Port tcp:80 Wenn Sie ein Protokoll und einen einzelnen Port angeben, gilt die Firewallregel nur für diesen Port des Protokolls.
Protokoll und Portbereich tcp:20-22 Wenn Sie ein Protokoll und einen Portbereich angeben, gilt die Firewallregel nur für den Portbereich des Protokolls.
Kombinationen icmp,tcp:80,tcp:443,udp:67-69 Wenn Sie eine durch Kommas getrennte Liste von Protokollen oder Protokollen und Ports angeben, gilt die Firewallregel für jedes angegebene Protokoll und jeden angegebenen Port. Weitere Informationen finden Sie unter Firewallregeln erstellen.

Quell- und Zielfilterung nach Dienstkonto

Mithilfe von Dienstkonten können Sie spezifischere Firewallregeln erstellen:

  • Bei Eingangs- und Ausgangsregeln lassen sich mit Dienstkonten Ziele angeben.

  • Bei Eingangsregeln können Sie die Quelle für eingehende Pakete als primäre interne IP-Adresse einer beliebigen VM in dem Netzwerk angeben, in dem die VM ein bestimmtes Dienstkonto verwendet.

Das Dienstkonto muss erstellt werden, bevor Sie eine Firewallregel erstellen, die darauf basiert.

Firewallregeln, die Instanzen anhand von Dienstkonten identifizieren, gelten für neue Instanzen, die mit dem Dienstkonto erstellt und diesem zugeordnet wurden, und für vorhandene Instanzen, deren Dienstkonten geändert wurden. Wenn Sie das einer Instanz zugeordnete Dienstkonto ändern, müssen Sie die Instanz beenden und neu starten. Sie können Dienstkonten einzelnen Instanzen und Instanzvorlagen zuordnen, die von verwalteten Instanzgruppen verwendet werden.

Nach Dienstkonto oder Netzwerktag filtern

Dieser Abschnitt beleuchtet wichtige Punkte, die Sie berücksichtigen sollten, wenn Sie sich beim Definieren von Zielen und Quellen für Eingangsregeln zwischen Dienstkonten und Netzwerktags entscheiden.

Wenn Sie strikte Kontrolle darüber benötigen, wie Firewallregeln auf VMs angewendet werden, verwenden Sie Zieldienstkonten und Quelldienstkonten anstelle von Zieltags und Quelltags:

  • Ein Netzwerktag ist ein beliebiges Attribut. Jedes IAM-Mitglied, das die Berechtigung zum Bearbeiten einer Instanz hat, kann dieser Instanz ein oder mehrere Netzwerktags zuordnen. IAM-Mitglieder mit der Rolle Compute Engine-Instanzadministrator für ein Projekt haben diese Berechtigung. Wenn IAM-Mitglieder eine Instanz bearbeiten dürfen, können sie deren Netzwerktags ändern. Dies führt unter Umständen dazu, dass sich auch die geltenden Firewallregeln für diese Instanz ändern.

  • Ein Dienstkonto steht für eine Identität, die einer Instanz zugeordnet ist. Einer Instanz kann nur ein einziges Dienstkonto zugeordnet werden. Sie steuern den Zugriff auf das Dienstkonto, indem Sie die Zuweisung der Rolle Dienstkontonutzer an andere IAM-Mitglieder kontrollieren. Damit ein IAM-Mitglied eine Instanz mit einem Dienstkonto starten kann, muss das Mitglied mindestens für dieses Dienstkonto die Rolle "Dienstkontonutzer" sowie entsprechende Berechtigungen zum Erstellen von Instanzen haben (z. B. die Rolle "Compute Engine-Instanzadministrator" für das Projekt).

Die Kombination von Dienstkonten und Netzwerktags in einer Firewallregel ist nicht möglich:

  • Sie können Zieldienstkonten und Zieltags nicht zusammen in einer Firewallregel für eingehenden oder ausgehenden Traffic verwenden.

  • Folgende Quellen sind für Firewallregeln für eingehenden Traffic nicht gültig, wenn Sie Ziele nach Zieltag oder Zieldienstkonto angeben:

Ziele Ungültige Quellen
Zieltags Quelldienstkonten
Kombination aus Quell-IP-Bereichen und Quelldienstkonten
Zieldienstkonto Quelltags
Kombination aus Quell-IP-Bereichen und Quelltags

Folgende operative Aspekte sollten Sie bei Dienstkonten und Netzwerktags berücksichtigen:

  • Wenn Sie ein Dienstkonto für eine Instanz ändern möchten, müssen Sie diese beenden und dann neu starten. Tags können bei laufender Instanz hinzugefügt oder entfernt werden.

  • Pro Firewallregel kann nur ein Zieldienstkonto angegeben werden. Allerdings können Sie in einer einzelnen Firewallregel mehrere Zieltags angeben.

  • Pro Firewallregel für eingehenden Traffic kann nur ein Quelldienstkonto angegeben werden. Allerdings können Sie in einer einzelnen Firewallregel mehrere Quelltags angeben.

  • Wenn Sie Instanzen anhand des Netzwerktags identifizieren, gilt die Firewallregel für die primäre interne IP-Adresse der Instanz.

Anwendungsfälle

Anhand der folgenden Anwendungsfälle wird die Funktionsweise von Firewallregeln veranschaulicht. In diesen Beispielen sind nicht alle Firewallregeln aktiviert.

Fälle für eingehenden Traffic

Firewallregeln für eingehenden Traffic steuern eingehende Verbindungen von einer Quelle zu Zielinstanzen in Ihrem VPC-Netzwerk. Für die Definition der Quelle einer Eingangsregel haben Sie folgende Möglichkeiten:

  • Ein Bereich von IPv4-Adressen; der Standardwert ist "Beliebig" (0.0.0.0/0)
  • Andere, durch ein Dienstkonto identifizierte Instanzen in Ihrem VPC-Netzwerk
  • Andere, durch Netzwerktags identifizierte Instanzen in Ihrem VPC-Netzwerk

Die Standardquelle ist eine beliebige IP-Adresse (0.0.0.0/0). Wenn Sie eingehende Verbindungen für Quellen außerhalb Ihres VPC-Netzwerks steuern möchten, einschließlich anderer Quellen im Internet, verwenden Sie einen IPv4-Adressbereich im CIDR-Format.

Eingangsregeln mit der Aktion allow erlauben eingehenden Traffic basierend auf den anderen Komponenten der Regel. Über die Angabe der Quelle und des Ziels für die Regel hinaus können Sie die Regel auf bestimmte Protokolle und Ports beschränken. In ähnlicher Weise können Sie Eingangsregeln mit einer deny-Aktion zum Schutz von Instanzen verwenden und damit eingehenden Traffic auf der Basis der Komponenten der Firewall blockieren.

Beispiele für eingehenden Traffic

Das folgende Diagramm zeigt einige Beispiele für eingehende Verbindungen, die durch Firewallregeln gesteuert werden können. In den Beispielen wird der Parameter target in Regelzuweisungen verwendet, um Regeln auf bestimmte Instanzen anzuwenden.

Beispiel für Firewallregeln für eingehenden Traffic (zum Vergrößern klicken)
Beispiel für Firewallregeln für eingehenden Traffic (zum Vergrößern klicken)
  • Für VM 1 gilt eine Eingangsregel mit der Priorität 1000. Diese Regel erlaubt eingehenden TCP-Traffic von einer beliebigen Quelle (0.0.0.0/0). TCP-Traffic von anderen Instanzen im VPC-Netzwerk ist zulässig, vorbehaltlich der geltenden Ausgangsregeln für diese Instanzen. VM 4 kann mit VM 1 über TCP kommunizieren, da für VM 4 keine Ausgangsregel festgelegt ist, die eine solche Kommunikation blockiert. Es gilt nur die implizierte Regel zum Zulassen von ausgehendem Traffic. Da VM 1 eine externe IP-Adresse hat, erlaubt diese Regel auch eingehenden TCP-Traffic von externen Hosts im Internet.

  • Für VM 2 ist keine Firewallregel für eingehenden Traffic festgelegt, sodass die implizierte Regel zum Ablehnen von eingehendem Traffic den gesamten eingehenden Traffic blockiert. Verbindungen von anderen Netzwerkinstanzen werden unabhängig von den Ausgangsregeln für diese Instanzen blockiert. Da VM 2 eine externe IP-Adresse hat, gibt es zu ihr einen Pfad von externen Hosts im Internet. Diese implizierte Ablehnungsregel blockiert aber auch externen eingehenden Traffic.

  • Für VM 3 gilt eine Eingangsregel mit der Priorität 1000. Diese Regel erlaubt TCP-Traffic von Netzwerkinstanzen mit dem Netzwerktag client, z. B. von VM 4. TCP-Traffic von VM 4 zu VM 3 ist zulässig, da VM 4 keine Ausgangsregel hat, die eine solche Kommunikation blockiert. Es gilt nur die implizierte Regel zum Zulassen von ausgehendem Traffic. Da VM 3 keine externe IP-Adresse hat, gibt es zu ihr keinen Pfad von externen Hosts im Internet.

Fälle für ausgehenden Traffic

Firewallregeln für ausgehenden Traffic steuern ausgehende Verbindungen von Zielinstanzen in Ihrem VPC-Netzwerk. Ausgangsregeln mit der Aktion allow erlauben Traffic von Instanzen auf Basis der anderen Komponenten der Regel. Beispielsweise können Sie ausgehenden Traffic zu bestimmten Zielen wie zu einem IPv4-Adressbereich für die von Ihnen angegebenen Protokolle und Ports zulassen. In gleicher Weise blockieren Ausgangsregeln mit einer deny-Aktion den Traffic auf der Basis der anderen Komponenten der Regel.

Jede egress-Regel benötigt ein Ziel. Standardmäßig kann das eine beliebige IP-Adresse sein (0.0.0.0/0). Sie können das Ziel aber durch einen Bereich von IPv4-Adressen im CIDR-Format eingrenzen. Mit der Festlegung eines Bereichs von IPv4-Adressen haben Sie die Möglichkeit, den Traffic zu Instanzen in Ihrem Netzwerk und zu Zielen außerhalb Ihres Netzwerks, einschließlich Zielen im Internet, zu steuern.

Beispiele für ausgehenden Traffic

Das folgende Diagramm zeigt einige Beispiele von ausgehenden Verbindungen, die durch Firewallregeln gesteuert werden können. In den Beispielen wird der Parameter target in Regelzuweisungen verwendet, um Regeln auf bestimmte Instanzen anzuwenden.

Beispiel für Firewallregeln für ausgehenden Traffic (zum Vergrößern klicken)
Beispiel für Firewallregeln für ausgehenden Traffic (zum Vergrößern klicken)
  • Für VM 1 ist keine Firewallregel für ausgehenden Traffic festgelegt, sodass die implizierte Regel zum Zulassen von ausgehendem Traffic den Traffic zu jedem Ziel erlaubt. Verbindungen zu anderen Instanzen im VPC-Netzwerk sind zulässig, vorbehaltlich der geltenden Eingangsregeln für diese Instanzen. VM 1 kann Traffic an VM 4 senden, da für VM 4 eine Eingangsregel gilt, die eingehenden Traffic von beliebigen IP-Adressbereichen zulässt. Da VM 1 eine externe IP-Adresse hat, kann sie auch Traffic an externe Hosts im Internet senden. Eingehende Antworten auf Traffic, der von VM 1 gesendet wird, sind zulässig, da Firewallregeln zustandsorientiert sind.

  • Für VM 2 gilt eine Ausgangsregel mit der Priorität 1000. Mit dieser Regel wird der gesamte ausgehende Traffic zu allen Zielen (0.0.0.0/0) abgelehnt. Ausgehender Traffic zu anderen Instanzen in der VPC wird unabhängig von den für diese Instanzen geltenden Eingangsregeln blockiert. Obwohl VM 2 eine externe IP-Adresse hat, blockiert diese Firewallregel auch den ausgehenden Traffic zu externen Hosts im Internet.

  • Für VM 3 gilt eine Ausgangsregel mit der Priorität 1000. Diese Regel blockiert den ausgehenden TCP-Traffic an ein beliebiges Ziel im IP-Bereich 192.168.1.0/24. Obwohl Eingangsregeln für VM 4 den gesamten eingehenden Traffic erlauben, kann VM 3 keinen TCP-Traffic an VM 4 senden. VM 3 kann jedoch UDP-Traffic an VM 4 senden, da die Ausgangsregel nur für das TCP-Protokoll gilt. Darüber hinaus kann VM 3 beliebigen Traffic an andere Instanzen im VPC-Netzwerk außerhalb des IP-Bereichs 192.168.1.0/24 senden, solange für diese Instanzen Eingangsregeln gelten, die einen solchen Traffic zulassen. Da sie keine externe IP-Adresse hat, gibt es keinen Pfad zum Senden von Traffic außerhalb des VPC-Netzwerks.

Nächste Schritte

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...