Firewallrichtlinien-Regeln

Beim Erstellen einer Firewallrichtlinienregel geben Sie eine Reihe von Komponenten an, die die Funktionsweise der Regel definieren. Diese Komponenten geben Merkmale für Trafficrichtung, Quelle, Ziel und Ebene 4 an, z. B. Protokoll und Zielport (wenn das Protokoll Ports verwendet).

Jede Firewall-Richtlinien-regel gilt entweder für eingehende (ingress) oder für ausgehende Verbindungen (egress), jedoch nicht für beide Verbindungen.

Regeln für eingehenden Traffic

Die eingehende Traffic-Richtung bezieht sich auf die eingehenden Verbindungen, die von bestimmten Quellen an Google Cloud-Ziele gesendet werden. Eingangsregeln gelten für eingehende Pakete, wo das Ziel der Pakete das Ziel ist.

Eine Regel für eingehenden Traffic mit einer deny-Aktion schützt alle Instanzen, indem eingehende Verbindungen an diese blockiert werden. Der eingehende Zugriff kann über eine Regel mit höherer Priorität zugelassen werden. Ein automatisch erstelltes Standardnetzwerk enthält einige vorausgefüllte VPC-Firewallregeln, die eingehenden Traffic für bestimmte Arten von Traffic zulassen.

Regeln für ausgehenden Traffic

Die Richtung "Ausgehender Traffic" bezieht sich auf den ausgehenden Traffic, der von einem Ziel an ein Ziel gesendet wird. Ausgangsregeln gelten für Pakete für neue Verbindungen, bei denen die Quelle des Pakets das Ziel ist.

Bei einer Regel für ausgehenden Traffic mit einer allow-Aktion kann eine Instanz Traffic an die in der Regel angegebenen Ziele senden. Ausgehender Traffic kann durch deny-Firewallregeln mit höherer Priorität abgelehnt werden. Außerdem blockiert oder begrenzt Google Cloud bestimmte Arten von Traffic.

Komponenten von Firewallrichtlinienregeln

Regeln in hierarchischen Firewallrichtlinien, globalen Netzwerk-Firewallrichtlinien und regionalen Netzwerk-Firewallrichtlinien verwenden die in diesem Abschnitt beschriebenen Komponenten. Der Begriff Firewallrichtlinie bezieht sich auf alle dieser drei Richtlinientypen. Weitere Informationen zu den Arten von Firewallrichtlinien finden Sie unter Firewallrichtlinien.

Firewallrichtlinienregeln funktionieren im Allgemeinen wie VPC-Firewallregeln. Es gibt jedoch einige Unterschiede, die in den folgenden Abschnitten beschrieben werden.

Priorität

Die Priorität einer Regel in einer Firewallrichtlinie ist eine Ganzzahl von 0 bis einschließlich 2.147.483.647. Niedrigere Werte bedeuten eine höhere Priorität. Die Priorität einer Regel in einer Firewallrichtlinie ähnelt der Priorität einer VPC-Firewall-Regel, mit den folgenden Unterschieden:

  • Jede Regel in einer Firewallrichtlinie muss eine eindeutige Priorität haben.
  • Die Priorität einer Regel in einer Firewallrichtlinie dient als eindeutige Kennung der Regel. Regeln in Firewallrichtlinien verwenden keine Namen zur Identifizierung.
  • Die Priorität einer Regel in einer Firewallrichtlinie definiert die Auswertungsreihenfolge innerhalb der Firewallrichtlinie selbst. VPC-Firewallregeln und -Regeln in hierarchischen Firewallrichtlinien, globalen Netzwerk-Firewallrichtlinien und regionalen Netzwerk-Firewallrichtlinien werden wie unter Richtlinien- und Regelauswertungsreihenfolge beschrieben ausgewertet.

Aktion bei Übereinstimmung

Eine Regel in einer Firewallrichtlinie kann eine der folgenden Aktionen haben:

  • allow lässt Traffic zu und beendet die weitere Regelauswertung.
  • deny lässt keinen Traffic zu und die weitere Regelauswertung wird beendet.
  • apply_security_profile_group fängt den Traffic transparent ab und sendet ihn für die Layer-7-Prüfung an den konfigurierten Firewallendpunkt.

Erzwingung

Sie können auswählen, ob eine Firewallrichtlinienregel für erzwungen werden soll. Dazu legen Sie deren Status auf "Aktiviert" oder "Deaktiviert" fest. Sie können den Erzwingungszustand festlegen, wenn Sie eine Regel erstellen oder eine Regel aktualisieren.

Wenn Sie beim Erstellen einer neuen Firewallregel keinen Erzwingungsstatus festlegen, wird die Firewallregel automatisch aktiviert.

Protokolle und Ports

Ähnlich wie bei Regeln von VPC-Firewallregeln müssen Sie beim Erstellen einer Regel eine oder mehrere Protokoll- und Porteinschränkungen angeben. Beim Angeben von TCP oder UDP in einer Regel können Sie das Protokoll, das Protokoll und einen Zielport oder das Protokoll und einen Zielportbereich angeben. Sie können nicht nur einen Port oder Portbereich angeben. Außerdem können Sie nur Zielports angeben. Regeln für Quellports werden nicht unterstützt.

Sie können die folgenden Protokollnamen in Firewallregeln verwenden: tcp, udp, icmp (für IPv4 ICMP), esp, ah, sctp und ipip. Verwenden Sie für alle anderen Protokolle die IANA-Protokollnummern.

Viele Protokolle verwenden bei IPv4 und IPv6 denselben Namen und dieselbe Nummer, einige Protokolle wie ICMP jedoch nicht. Verwenden Sie icmp oder die Protokollnummer 1, um IPv4 ICMP anzugeben. Verwenden Sie für IPv6 ICMP die Protokollnummer 58.

Firewallregeln unterstützen nicht die Angabe von ICMP-Typen und -Codes, sondern nur das Protokoll.

Das IPv6-Hop-by-Hop-Protokoll wird in Firewallregeln nicht unterstützt.

Wenn Sie keine Protokoll- und Portparameter angeben, gilt die Regel für alle Protokolle und Zielports.

Logging

Das Logging für Regeln von Firewallrichtlinien funktioniert genauso wie das Logging von Regeln in VPC-Firewalls, mit folgenden Ausnahmen:

  • Das Referenzfeld enthält die Firewallrichtlinien-ID und eine Zahl, die die Ebene der Ressource angibt, mit dem die Richtlinie verknüpft ist. 0 bedeutet beispielsweise, dass die Richtlinie auf eine Organisation angewendet wird, und 1, dass die Richtlinie auf einen Ordner auf oberster Ebene unter der Organisation angewendet wird.

  • Logs für Regeln Firewallrichtlinien enthalten ein target_resource-Feld, das die VPC-Netzwerke angibt, auf die die Regel angewendet wird.

  • Logging kann nur für allow-, deny- und apply_security_profile_group-Regeln aktiviert werden, nicht jedoch für goto_next-Regeln.

Ziel, Quelle, Bestimmungsort

Zielparameter identifizieren die Netzwerkschnittstellen von Instanzen, für die eine Firewallregel gilt.

Sie können sowohl Quellparameter als auch Zielparameter angeben, die für die Paketquellen oder Ziele für Firewallregeln für eingehenden und ausgehenden Traffic gelten. Die Richtung der Firewallregel bestimmt die möglichen Werte für die Quell- und Zielparameter.

Die Ziel- und Quellparameter arbeiten zusammen.

Ziele

Der Zielparameter identifiziert die Netzwerkschnittstellen der Compute Engine-Instanzen, einschließlich GKE-Knoten und Instanzen der flexiblen App Engine-Umgebung.

Sie können Ziele für Regeln für eingehenden oder ausgehenden Traffic definieren. Gültige Zieloptionen hängen vom Typ der Firewallrichtlinie ab.

Ziele für hierarchische Firewallrichtlinienregeln

Hierarchische Firewallrichtlinienregeln unterstützen die folgenden Ziele:

  • Breitestes Standardziel: Wenn Sie die Zielspezifikation in einer hierarchischen Firewallrichtlinienregel weglassen, gilt die Firewallregel für alle Instanzen in allen VPC-Netzwerken in allen Projekten unter dem Resource Manager-Knoten (Ordner oder Organisation), der mit der Firewallrichtlinie verknüpft ist. Dies ist der breiteste Satz von Zielen.

  • Bestimmte Netzwerke: Wenn Sie ein oder mehrere VPC-Netzwerke mit dem Parameter target-resources angeben, ist der breiteste Satz von Zielen auf VMs mit einer Netzwerkschnittstelle in mindestens einem der angegebenen VPC-Netzwerke beschränkt.

  • Nach Dienstkonto identifizierte Instanzen: Wenn Sie ein oder mehrere Dienstkonten mit dem Parameter target-service-accounts angeben, ist der breiteste Satz von Zielen auf VMs beschränkt, die eines der angegebenen Dienstkonten verwenden.

  • Bestimmte Netzwerke und Instanzen, die durch das Dienstkonto identifiziert werden: Wenn Sie sowohl den Parameter target-resources als auch den Parameter target-service-accounts angeben, wird der breiteste Satz von Zielen auf die VMs beschränkt, die die folgenden zwei Kriterien erfüllen:

    • Die VMs haben eine Netzwerkschnittstelle in einem der angegebenen VPC-Netzwerke.
    • Die VMs verwenden eines der angegebenen Dienstkonten.

Ziele für globale Netzwerk-Firewallrichtlinienregeln

Globale Netzwerk-Firewallrichtlinienregeln unterstützen die folgenden Ziele:

  • Standardziel – alle Instanzen im VPC-Netzwerk: Wenn Sie die Zielspezifikation in einer globalen Netzwerk-Firewallrichtlinienregel weglassen, gilt die Firewallregel für Instanzen, die eine Netzwerkschnittstelle im mit der Richtlinie verknüpften VPC-Netzwerk haben. Die Instanzen können sich in einer beliebigen Region befinden. Dies ist der breiteste Satz von Zielen.

  • Instanzen nach sicheren Ziel-Tags: Wenn Sie Ziel-Tags mit dem Parameter target-secure-tags angeben, ist der breiteste Satz von Zielen auf die an die Tags gebundenen VMs beschränkt.

  • Instanzen nach Zieldienstkonten: Wenn Sie Dienstkonten mit dem Parameter target-service-accounts angeben, ist der breiteste Satz von Zielen auf die VMs beschränkt, die eines der angegebenen Dienstkonten verwenden.

Ziele für regionale Netzwerk-Firewallrichtlinienregeln

Regionale Netzwerk-Firewallrichtlinienregeln unterstützen die folgenden Ziele:

  • Standardziel – alle Instanzen in der Region und im VPC-Netzwerk: Wenn Sie die Zielspezifikation in einer regionalen Netzwerk-Firewallrichtlinienregel weglassen, gilt die Firewallregel für Instanzen, die eine Netzwerkschnittstelle im mit der Richtlinie verknüpften VPC-Netzwerk haben. Die Instanzen müssen sich in derselben Region wie die Richtlinie befinden. Dies ist der breiteste Satz von Zielen.

  • Instanzen nach sicheren Ziel-Tags: Wenn Sie Ziel-Tags mit dem Parameter target-secure-tags angeben, ist der breiteste Satz von Zielen auf die an die Tags gebundenen VMs beschränkt.

  • Instanzen nach Zieldienstkonten: Wenn Sie Dienstkonten mit dem Parameter target-service-accounts angeben, ist der breiteste Satz von Zielen auf die VMs beschränkt, die eines der angegebenen Dienstkonten verwenden.

Ziele und IP-Adressen für Regeln für eingehenden Traffic

Die an die Netzwerkschnittstelle einer Ziel-VM weitergeleiteten Pakete werden gemäß den folgenden Bedingungen verarbeitet:

  • Wenn die Firewallregel für eingehenden Traffic einen Ziel-IP-Adressbereich enthält, muss das Ziel des Pakets in einen der explizit definierten Ziel-IP-Adressbereiche passen (Funktion in der Vorabversion).

  • Wenn die Firewallregel für eingehenden Traffic keinen Ziel-IP-Adressbereich enthält, muss das Ziel des Pakets mit einer der folgenden IP-Adressen übereinstimmen:

    • Die primäre interne IPv4-Adresse, die der NIC der Instanz zugewiesen ist.

    • Alle konfigurierten Alias-IP-Adressbereiche auf der NIC der Instanz.

    • Die externe IPv4-Adresse, die der NIC der Instanz zugeordnet ist.

    • Beliebige IPv6-Adresse, die der NIC zugewiesenen ist, wenn IPv6 im Subnetz konfiguriert ist.

    • Eine interne oder externe IP-Adresse, die mit einer Weiterleitungsregel verbunden ist, die für das Passthrough Load-Balancing verwendet wird, wobei die Instanz ein Backend für einen internen Passthrough Network Load Balancer oder einen externen Passthrough Network Load Balancer ist.

    • Eine interne oder externe IP-Adresse, die einer Weiterleitungsregel für die Protokollweiterleitung zugeordnet ist, wobei auf die Instanz von einer Zielinstanz verwiesen wird.

    • Eine IP-Adresse im Zielbereich einer benutzerdefinierten statischen Route, die die Instanz (next-hop-instance oder next-hop-address) als VM des nächsten Hops verwendet.

    • Eine IP-Adresse innerhalb des Zielbereichs einer benutzerdefinierten statischen Route, die einen internen Passthrough Network Load Balancer (next-hop-ilb) als nächsten Hop verwendet, wenn die VM ein Backend für diesen Load-Balancer ist.

Ziele und IP-Adressen für Regeln für ausgehenden Traffic

Die Verarbeitung von Paketen, die von der Netzwerkschnittstelle eines Ziels ausgegeben werden, hängt von der Konfiguration der IP-Weiterleitung auf der Ziel-VM ab. Die IP-Weiterleitung ist standardmäßig deaktiviert.

  • Wenn für die Ziel-VM die IP-Weiterleitung deaktiviert ist, kann die VM Pakete mit den folgenden Quellen ausgeben:

    • Die primäre interne IPv4-Adresse der NIC einer Instanz.

    • Jeder konfigurierte Alias-IP-Adressbereich auf der NIC einer Instanz.

    • Beliebige IPv6-Adresse, die der NIC zugewiesenen ist, wenn IPv6 im Subnetz konfiguriert ist.

    • Eine interne oder externe IP-Adresse, die mit einer Weiterleitungsregel verbunden ist, für Passthrough Load-Balancing oder Protokollweiterleitung. Dies gilt, wenn die Instanz ein Backend für einen internen Passthrough Network Load Balancer oder einen externen Passthrough Network Load Balancer ist oder von einer Zielinstanz referenziert wird.

    Wenn die Firewallregel für ausgehenden Traffic Quell-IP-Adressbereiche enthält, sind die Ziel-VMs weiterhin auf die zuvor erwähnten Quell-IP-Adressen beschränkt. Sie können diesen Satz jedoch mit dem Quellparameter verfeinern. Wenn Sie einen Quellparameter verwenden, ohne die IP-Weiterleitung zu aktivieren, wird der Satz möglicher Paketquelladressen nicht erweitert.

    Wenn die Firewallregel für ausgehenden Traffic keinen Quell-IP-Adressbereich enthält, sind alle zuvor genannten Quell-IP-Adressen zulässig.

  • Wenn für die Ziel-VM die IP-Weiterleitung aktiviert ist, kann die VM Pakete mit beliebigen Quelladressen ausgeben. Mit dem Quellparameter können Sie den Satz zulässiger Paketquellen genauer definieren.

Quellen

Die Werte der Quellparameter hängen von folgenden Faktoren ab:

  • Dem Typ der Firewallrichtlinie, die die Firewallregel enthält
  • Der Richtung der Firewallregel

Quellen für Regeln für eingehenden Traffic

In der folgenden Tabelle sind Quellparameter aufgeführt, die einzeln oder in Kombination in einer einzelnen Regel für die Firewallrichtlinie für eingehenden Traffic verwendet werden können. Für Cloud NGFW müssen Sie mindestens einen Quellparameter angeben.

Quellparameter für Eingangsregeln Unterstützung in hierarchischen Firewallrichtlinien Unterstützung in globalen und regionalen Netzwerk-Firewallrichtlinien
Bereiche von Quell-IP-Adressen

Eine einfache Liste mit IPv4-Adressen im CIDR-Format oder IPv6-Adressen im CIDR-Format. Die Liste wird in der Firewallrichtlinie selbst gespeichert.
Quelladressengruppen

Wiederverwendbare Sammlungen von IPv4-Adressen im CIDR-Format oder IPv6-Adressen im CIDR-Format. Die Firewallregel verweist auf die Sammlung. Weitere Informationen finden Sie unter Adressgruppen für Firewallrichtlinien.
Quelldomainnamen

Eine Liste mit einem oder mehreren Quelldomainnamen. Weitere Informationen, unter anderem dazu, wie Domainnamen in IP-Adressen umgewandelt werden, finden Sie unter FQDN-Objekte.
Sichere Quell-Tags

Eine Liste mit einer oder mehreren sicheren Quell-Tags. Weitere Informationen finden Sie unter Wie sichere Quell-Tags Paketquellen implizieren.
Geografische Standorte der Quelle

Eine Liste mit einem oder mehreren geografischen Standorten, die als Ländercodes mit zwei Buchstaben oder Regionscodes angegeben sind. Weitere Informationen finden Sie unter Standortobjekte.
Google Threat Intelligence-Listen als Quelle verwenden

Eine Liste mit einem oder mehreren vordefinierten Namen von Google Threat Intelligence-Listen. Weitere Informationen finden Sie unter Google Threat Intelligence für Firewallrichtlinien-Regeln.
Quellnetzwerkbereich

Eine Einschränkung, die eine Sicherheitsgrenze definiert. Weitere Informationen finden Sie unter Netzwerkbereiche.

In einer einzelnen Regel für eingehenden Traffic können Sie zwei oder mehr Quellparameter verwenden, um eine Quellkombination zu erstellen. Cloud NGFW erzwingt die folgenden Einschränkungen für Quellkombinationen jeder Ingress-Regel:

  • Quell-IP-Adressbereiche müssen entweder IPv4- oder IPv6-CIDRs enthalten, keine Kombination aus beiden.
  • Eine Quelladressgruppe, die IPv4-CIDRs enthält, kann nicht mit einer Quelladressgruppe verwendet werden, die IPv6-CIDRs enthält.
  • Ein Quell-IP-Adressbereich, der IPv4-CIDRs enthält, kann nicht mit einer Quelladressgruppe verwendet werden, die IPv6-CIDRs enthält.
  • Ein Quell-IP-Adressbereich, der IPv6-CIDRs enthält, kann nicht mit einer Quelladressgruppe verwendet werden, die IPv4-CIDRs enthält.
  • Der Internetnetzwerkbereich kann nicht mit sicheren Quell-Tags verwendet werden.
  • Der nicht internetweite, der VPC-Netzwerk- und der VPC-übergreifende Umfang können nicht mit Google Threat Intelligence-Listen oder -Standortinformationen verwendet werden.

Cloud NGFW wendet die folgende Logik an, um die Pakete einer Ingress-Regel mit einer Quellkombination zuzuordnen:

  • Wenn die Quellkombination keinen Quellnetzwerkbereich enthält, entsprechen Pakete der Ingress-Regel, wenn sie mit mindestens einem Quellparameter in der Quellkombination übereinstimmen.

  • Wenn die Quellkombination einen Quellnetzwerkbereich enthält, entsprechen Pakete der Ingress-Regel, wenn sie mit dem Quellnetzwerkbereich und mindestens einem der anderen Quellparameter in der Quellkombination übereinstimmen.

Wie sichere Quell-Tags Paketquellen implizieren

Regeln für eingehenden Traffic in globalen und regionalen Netzwerk-Firewallrichtlinien können Quellen mithilfe sicherer Tags angeben. Jedes sichere Tag ist mit einem einzelnen VPC-Netzwerk verknüpft. Ein sicheres Tag kann nur an eine VM gebunden werden, die eine Netzwerkschnittstelle im VPC-Netzwerk hat, dem das sichere Tag zugeordnet ist.

Pakete, die von einer Netzwerkschnittstelle einer VM gesendet werden, stimmen mit einer Ingress-Regel überein, die eine sichere Tagquelle verwendet, wenn die folgenden Bedingungen erfüllt sind:

  • Wenn sich die Ingress-Regel in einer regionalen Netzwerkrichtlinie befindet, muss sich die VM in einer Zone der Region der Netzwerk-Firewallrichtlinie befinden. Wenn sich die Ingress-Regel in einer globalen Netzwerk-Firewallrichtlinie befindet, kann sich die VM in einer beliebigen Zone befinden.

  • Die Netzwerkschnittstelle der VM, die die Pakete sendet, erfüllt eines der folgenden Kriterien:

    • Die Netzwerkschnittstelle der VM befindet sich im selben VPC-Netzwerk wie das VPC-Netzwerk, auf das die globale oder regionale Netzwerk-Firewallrichtlinie angewendet wird.
    • Die Netzwerkschnittstelle der VM befindet sich in einem VPC-Netzwerk, das über VPC-Netzwerk-Peering mit dem VPC-Netzwerk verbunden ist, auf das die globale oder regionale Netzwerk-Firewallrichtlinie angewendet wird.
    • Das VPC-Netzwerk, das von der Netzwerkschnittstelle der VM verwendet wird, und das VPC-Netzwerk, auf das die globale oder regionale Netzwerk-Firewallrichtlinie angewendet wird, sind beide VPC-Spokes am selben Network Connectivity Center-Hub.

  • Die Quell-IP-Adresse des Pakets ist eine der folgenden:

    • Die primäre interne IPv4-Adresse der Netzwerkschnittstelle.
    • Alle IPv6-Adressen (intern oder extern), die der Netzwerkschnittstelle zugewiesen sind.

Bei der Verwendung sicherer Quell-Tags werden keine anderen Quell-IP-Adressen des Pakets aufgelöst. Beispielsweise werden Alias-IP-Adressbereiche und externe IPv4-Adressen, die der Netzwerkschnittstelle zugeordnet sind, ausgeschlossen. Wenn Sie Firewallregeln für eingehenden Traffic erstellen müssen, deren Quellen Alias-IP-Adressbereiche oder externe IPv4-Adressen enthalten, verwenden Sie stattdessen einen Quelladressbereich oder eine Quelladressgruppe.

Quellen für Regeln für ausgehenden Traffic

Sie können die folgenden Quellen für Regeln für ausgehenden Traffic sowohl in hierarchischen Firewallrichtlinien als auch in Netzwerk-Firewallrichtlinien verwenden:

  • Standard – durch Ziel impliziert: Wenn Sie den Quellparameter in einer Regel für ausgehenden Traffic weglassen, werden die Paketquellen implizit wie in Ziele und IP-Adressen für Regeln für ausgehenden Traffic beschrieben definiert.

  • IPv4-Quelladressbereiche: Eine Liste von IPv4-Adressen im CIDR-Format.

  • IPv6-Quelladressbereiche: Eine Liste von IPv6-Adressen im CIDR-Format.

Befolgen Sie diese Richtlinien, um Quell-IP-Adressbereiche für Regeln für ausgehenden Traffic hinzuzufügen:

  • Wenn einer VM-Schnittstelle sowohl interne als auch externe IPv4-Adressen zugewiesen sind, wird nur die interne IPv4-Adresse während der Regelauswertung verwendet.

  • Wenn Sie in der Regel für ausgehenden Traffic einen Quell-IP-Adressbereich und Zielparameter haben, werden die Zielparameter in dieselbe IP-Version aufgelöst wie die Quell-IP-Version.

    Beispiel: In einer Regel für ausgehenden Traffic haben Sie im Quellparameter einen IPv4-Adressbereich und im Zielparameter ein FQDN-Objekt. Wenn der FQDN sowohl in IPv4- als auch in IPv6-Adressen aufgelöst wird, wird während der Regelerzwingung nur die aufgelöste IPv4-Adresse verwendet.

Reiseziele

Ziele können mithilfe von IP-Adressbereichen angegeben werden, die sowohl von Regeln für eingehenden als auch von Regeln für ausgehenden Traffic in hierarchischen und Netzwerk-Firewallrichtlinien unterstützt werden. Das Standardverhalten des Ziels hängt von der Richtung der Regel ab.

Ziele für Regeln für eingehenden Traffic

Sie können die folgenden Ziele für Firewallregeln für eingehenden Traffic sowohl in hierarchischen als auch in Netzwerk-Firewallrichtlinien verwenden:

  • Standard – durch Ziel impliziert: Wenn Sie den Zielparameter in einer Regel für eingehenden Traffic weglassen, werden die Paketziele implizit definiert, wie unter Ziele und IP-Adressen für Regeln für eingehenden Traffic beschrieben.

  • IPv4-Zieladressbereiche: Eine Liste von IPv4-Adressbereichen im CIDR-Format.

  • IPv6-Zieladressbereiche: Eine Liste von IPv6-Adressbereichen im CIDR-Format.

Befolgen Sie diese Richtlinien, um Ziel-IP-Adressbereiche für Regeln für eingehenden Traffic hinzuzufügen:

Ziele für Regeln für ausgehenden Traffic

In der folgenden Tabelle sind Zielparameter aufgeführt, die einzeln oder in Kombination in einer einzelnen Regel für ausgehende Firewallrichtlinien verwendet werden können. Für Cloud NGFW müssen Sie mindestens einen Zielparameter angeben.

Zielparameter für Ausgangsregeln Unterstützung in hierarchischen Firewallrichtlinien Unterstützung in globalen und regionalen Netzwerk-Firewallrichtlinien
Ziel-IP-Adressbereiche

Eine einfache Liste mit IPv4-Adressen im CIDR-Format oder IPv6-Adressen im CIDR-Format. Die Liste wird in der Firewallrichtlinie selbst gespeichert.
Zielgruppen

Wiederverwendbare Sammlungen von IPv4-Adressen im CIDR-Format oder IPv6-Adressen im CIDR-Format. Die Firewallrichtlinienregel verweist auf die Sammlung. Weitere Informationen finden Sie unter Adressgruppen für Firewallrichtlinien.
Zieldomainnamen

Eine Liste mit einem oder mehreren Quelldomainnamen. Weitere Informationen, unter anderem dazu, wie Domainnamen in IP-Adressen umgewandelt werden, finden Sie unter FQDN-Objekte.
Geografische Zielorte

Eine Liste mit einem oder mehreren geografischen Standorten, die als Ländercodes mit zwei Buchstaben oder Regionscodes angegeben sind. Weitere Informationen finden Sie unter Standortobjekte.
Zielordner für Google Threat Intelligence-Listen

Eine Liste mit einem oder mehreren vordefinierten Namen von Google Threat Intelligence-Listen. Weitere Informationen finden Sie unter Google Threat Intelligence für Firewallrichtlinien-Regeln.
Zielnetzwerkbereich

Eine Einschränkung, die eine Sicherheitsgrenze definiert. Weitere Informationen finden Sie unter Netzwerkbereiche.

In einer einzelnen Regel für ausgehenden Traffic können Sie zwei oder mehr Zielparameter verwenden, um eine Zielkombination zu erstellen. Cloud NGFW erzwingt die folgenden Einschränkungen für Zielkombinationen jeder Ausgangsregel:

  • Ziel-IP-Adressbereiche müssen entweder IPv4- oder IPv6-CIDRs enthalten, keine Kombination aus beiden.
  • Eine Zieladressgruppe, die IPv4-CIDRs enthält, kann nicht mit einer Zieladressgruppe verwendet werden, die IPv6-CIDRs enthält.
  • Ein Ziel-IP-Adressbereich, der IPv4-CIDRs enthält, kann nicht mit einer Zieladressgruppe verwendet werden, die IPv6-CIDRs enthält.
  • Ein Ziel-IP-Adressbereich, der IPv6-CIDRs enthält, kann nicht mit einer Zieladressgruppe verwendet werden, die IPv4-CIDRs enthält.
  • Google Threat Intelligence-Ziellisten oder Ziel-Standortinformationen können nicht für Ziele außerhalb des Internets verwendet werden.

Cloud NGFW wendet die folgende Logik an, um die Pakete einer ausgehenden Regel mit einer Zielkombination zuzuordnen:

  • Wenn die Zielkombination keinen Zielnetzwerkbereich enthält, entsprechen Pakete der Ausstiegsregel, wenn sie mit mindestens einem Zielparameter in der Zielkombination übereinstimmen.

  • Wenn die Zielkombination einen Zielnetzwerkbereich enthält, entsprechen Pakete der Ausstiegsregel, wenn sie mit dem Zielnetzwerkbereich und mindestens einem der anderen Zielparameter in der Zielkombination übereinstimmen.

Netzwerkbereiche

Netzwerkbereiche helfen Ihnen, Ihre Sicherheitsziele zu erreichen, indem Sie weniger Firewallrichtlinienregeln effizienter verwenden. Cloud NGFW unterstützt vier Arten von Netzwerkbereichen, mit denen eine Quell- oder Zielkombination in einer Regel einer hierarchischen Firewallrichtlinie, einer globalen Netzwerk-Firewallrichtlinie oder einer regionalen Netzwerk-Firewallrichtlinie erstellt werden kann.

Typen von Netzwerkbereichen

In der folgenden Tabelle sind die vier Netzwerkbereiche aufgeführt. Außerdem wird angegeben, ob ein Bereichstyp in einer Quellkombination einer Ingress-Regel, in einer Zielkombination einer Egress-Regel oder in beiden verwendet werden kann.

Typ des Netzwerkbereichs Quellen für Regeln für eingehenden Traffic Ziele für Regeln für ausgehenden Traffic
Internet (INTERNET)
Nicht internetbasiert (NON_INTERNET)
VPC-Netzwerke (VPC_NETWORKS)
VPC-intern (INTRA_VPC)

Die Internet- und Nicht-Internet-Bereiche schließen sich gegenseitig aus. Die VPC-Netzwerke und VPC-internen Bereiche sind Teilmengen des Nicht-Internet-Bereichs.

Internetbereich

Der Internetbereich (INTERNET) kann als Teil einer Quellkombination einer Ingress-Regel oder als Teil einer Zielkombination einer Ausgangsregel verwendet werden:

  • Geben Sie für eine Eingangsregel die Internetquelle und mindestens einen weiteren Quellparameter an, mit Ausnahme einer sicheren Tagquelle. Pakete stimmen mit der Ingress-Regel überein, wenn sie mit mindestens einem der anderen Quellparameter und mit dem Quellparameter auf Internetebene übereinstimmen.

  • Geben Sie für eine Ausgangsregel das Ziel auf Internetebene und mindestens einen anderen Zielparameter an. Pakete stimmen mit der Regel für ausgehenden Traffic überein, wenn sie mit mindestens einem der anderen Zielparameter und mit dem Zielparameter auf Internetebene übereinstimmen.

Im weiteren Verlauf dieses Abschnitts werden die Kriterien beschrieben, anhand derer die Cloud NGFW feststellt, ob ein Paket zum Internet gehört.

Internetbereich für eingehende Pakete

Eingehende Pakete, die von einem Maglev von Google an eine VM-Netzwerkschnittstelle weitergeleitet werden, werden im Internetbereich berücksichtigt. Pakete werden von einem Maglev an eine VM-Netzwerkschnittstelle weitergeleitet, wenn das Paketziel mit einem der folgenden Elemente übereinstimmt:

  • Eine regionale externe IPv4-Adresse einer VM-Netzwerkschnittstelle, eine Weiterleitungsregel eines externen Passthrough-Network Load Balancers oder eine Weiterleitungsregel für die externe Protokollweiterleitung.
  • Eine regionale externe IPv6-Adresse einer VM-Netzwerkschnittstelle, eine Weiterleitungsregel eines externen Passthrough-Network Load Balancers oder eine Weiterleitungsregel für die externe Protokollweiterleitung und das Paket wurde nicht über eine Subnetzroute weitergeleitet, die über VPC Network Peering importiert wurde oder von einem VPC-Speichen zu einem Network Connectivity Center-Hub.

Weitere Informationen zu Paketen, die von Maglev an Backend-VMs für einen externen Passthrough-Network Load Balancer oder eine externe Protokollweiterleitung weitergeleitet werden, finden Sie unter Pfade für externe Passthrough-Network Load Balancer und externe Protokollweiterleitung.

Internetbereich für ausgehende Pakete

Ausgehende Pakete, die von den Netzwerkschnittstellen der VM gesendet und mithilfe von statischen Routen weitergeleitet werden, die den nächsten Hop des Standard-Internetgateways verwenden, werden im Internetbereich berücksichtigt. Wenn die Ziel-IP-Adresse dieser ausgehenden Pakete jedoch für Google APIs und Dienste bestimmt ist, werden diese Pakete nicht dem Internet zugeordnet. Weitere Informationen zur Verbindung mit Google APIs und ‑Diensten finden Sie unter Nicht internetfähig.

Wenn die Pakete über eine statische Route mit dem nächsten Hop des Standard-Internetgateways weitergeleitet werden, werden alle Pakete, die von den Netzwerkschnittstellen der VM an die folgenden Ziele gesendet werden, im Internetbereich berücksichtigt:

  • Ein externes IP-Adressziel außerhalb des Google-Netzwerks.
  • Ein regionales externes IPv4-Ziel einer VM-Netzwerkschnittstelle, eine Weiterleitungsregel eines regionalen externen Load Balancers oder eine Weiterleitungsregel für die externe Protokollweiterleitung.
  • Ein regionales externes IPv6-Ziel einer VM-Netzwerkschnittstelle, eine Weiterleitungsregel eines regionalen externen Load Balancers oder eine Weiterleitungsregel für die externe Protokollweiterleitung.
  • Ein Ziel mit einer globalen externen IPv4- und IPv6-Adresse einer Weiterleitungsregel eines globalen externen Load Balancers.

Pakete, die von den VM-Netzwerkschnittstellen an Cloud VPN- und Cloud NAT-Gateways gesendet werden, werden im Internetbereich berücksichtigt:

  • Ausgehende Pakete, die von einer Netzwerkschnittstelle einer VM mit VPN-Software an die regionale externe IPv4-Adresse eines Cloud VPN-Gateways gesendet werden, werden im Internetbereich berücksichtigt.
  • Ausgehende Pakete, die von einem Cloud VPN-Gateway an ein anderes Cloud VPN-Gateway gesendet werden, werden nicht im Netzwerkbereich berücksichtigt, da Firewallregeln nur für VMs gelten.
  • Bei Public NAT werden Antwortpakete, die von einer VM-Netzwerkschnittstelle an die regionale externe IPv4-Adresse eines Cloud NAT-Gateways gesendet werden, im Internet berücksichtigt.

Wenn VPC-Netzwerke über VPC-Netzwerk-Peering verbunden sind oder VPC-Netzwerke als VPC-Spokes am selben Network Connectivity Center-Hub teilnehmen, können IPv6-Subnetz-Routen eine Verbindung zu regionalen externen IPv6-Adressenzielen von VM-Netzwerkschnittstellen, regionalen externen Load Balancer-Weiterleitungsregeln und externen Protokollweiterleitungsregeln herstellen. Wenn die Verbindung zu diesen regionalen externen IPv6-Zieladressen über eine Subnetzroute bereitgestellt wird, befinden sich die Ziele stattdessen außerhalb des Internets.

Nicht internetbezogen

Der nicht dem Internet zugewiesene Bereich (NON-INTERNET) kann als Teil einer Quellkombination einer Ingress-Regel oder als Teil einer Zielkombination einer Egress-Regel verwendet werden:

  • Geben Sie für eine Ingress-Regel die Quelle außerhalb des Internets und mindestens einen anderen Quellparameter an, mit Ausnahme einer Threat Intelligence-Liste oder einer geographischen Standortquelle. Pakete stimmen mit der Ingress-Regel überein, wenn sie mit mindestens einem der anderen Quellparameter und mit dem Quellparameter außerhalb des Internets übereinstimmen.

  • Geben Sie für eine Ausgangsregel das Ziel außerhalb des Internets und mindestens einen weiteren Zielparameter an. Pakete entsprechen der Regel für ausgehenden Traffic, wenn sie mit mindestens einem der anderen Zielparameter und mit dem Zielparameter außerhalb des Internets übereinstimmen.

Im weiteren Verlauf dieses Abschnitts werden die Kriterien beschrieben, anhand derer die Cloud NGFW feststellt, ob ein Paket nicht zum Internet gehört.

Nicht internetbezogener Umfang für eingehende Pakete

Eingehende Pakete, die über nächste Hops innerhalb eines VPC-Netzwerk oder von Google APIs und ‑Diensten an eine VM-Netzwerkschnittstelle weitergeleitet werden, werden nicht als Internetzugriff gezählt.

In den folgenden Fällen werden Pakete mithilfe von nächsten Hops innerhalb eines VPC-Netzwerk oder von Google APIs und ‑Diensten weitergeleitet:

  • Das Paketziel stimmt mit einer der folgenden Adressen überein:

    • Eine regionale interne IPv4- oder IPv6-Adresse einer VM-Netzwerkschnittstelle, eine Weiterleitungsregel eines internen Passthrough-Network Load Balancers oder eine Weiterleitungsregel für die interne Protokollweiterleitung.
    • Eine regionale externe IPv6-Adresse einer VM-Netzwerkschnittstelle, eine Weiterleitungsregel eines externen Passthrough-Network Load Balancers oder eine Weiterleitungsregel für die externe Protokollweiterleitung und das Paket wurde über eine lokale Subnetzroute, eine Peering-Subnetzroute oder eine Subnetzroute des Network Connectivity Center weitergeleitet.
    • Jede Adresse innerhalb des Zielbereichs einer statischen Route, bei der die empfangende VM entweder eine VM des nächsten Hops oder eine Backend-VM eines internen Passthrough Network Load Balancers des nächsten Hops ist.

  • Die Paketquelle entspricht einem der folgenden Elemente:

Nicht internetbezogener Umfang für ausgehende Pakete

Ausgehende Pakete, die entweder von den Netzwerkschnittstellen der VM gesendet und innerhalb eines VPC-Netzwerk weitergeleitet oder an Google APIs und ‑Dienste gesendet werden, werden im Bereich Nicht-Internet berücksichtigt.

Pakete werden in den folgenden Fällen mithilfe von nächsten Hops innerhalb eines VPC-Netzwerk oder an Google APIs und ‑Dienste weitergeleitet:

VPC-Netzwerke

Der Bereich VPC-Netzwerke (VPC_NETWORKS) kann nur als Teil einer Quellkombination einer Ingress-Regel verwendet werden. Sie können den Umfang „VPC-Netzwerke“ nicht als Teil einer Zielkombination einer Ausstiegsregel verwenden.

So verwenden Sie den Umfang „VPC-Netzwerke“ als Teil einer Quellkombination einer Ingress-Regel:

  1. Sie müssen eine Liste der Quell-VPC-Netzwerke angeben:

    • Die Liste der Quellnetzwerke muss mindestens ein VPC-Netzwerk enthalten. Sie können der Liste der Quellnetzwerke maximal 250 VPC-Netzwerke hinzufügen.
    • Ein VPC-Netzwerk muss vorhanden sein, bevor Sie es der Liste der Quellnetzwerke hinzufügen können.
    • Sie können das Netzwerk entweder mit der teilweisen oder vollständigen URL-ID hinzufügen.
    • VPC-Netzwerke, die Sie der Liste der Quellnetzwerke hinzufügen, müssen nicht miteinander verbunden sein. Jedes VPC-Netzwerk kann sich in einem beliebigen Projekt befinden.
    • Wenn ein VPC-Netzwerk gelöscht wird, nachdem es der Liste der Quellnetzwerke hinzugefügt wurde, bleibt der Verweis auf das gelöschte Netzwerk in der Liste. Gelöschte VPC-Netzwerke werden von Cloud NGFW ignoriert, wenn eine Ingress-Regel erzwungen wird. Wenn alle VPC-Netzwerke in der Liste der Quellnetzwerke gelöscht werden, sind die auf der Liste basierenden Ingress-Regeln ineffektiv, da sie mit keinem Paket übereinstimmen.

  2. Sie müssen mindestens einen anderen Quellparameter angeben, mit Ausnahme einer Threat Intelligence-Liste oder einer geographischen Quelle.

Ein Paket stimmt mit einer Ingress-Regel überein, die den Umfang der VPC-Netzwerke in der Quellkombination verwendet, wenn alle folgenden Bedingungen erfüllt sind:

  • Das Paket stimmt mit mindestens einem der anderen Quellparameter überein.

  • Das Paket wird von einer Ressource in einem der Quell-VPC-Netzwerke gesendet.

  • Das Quell-VPC-Netzwerk und das VPC-Netzwerk, auf das die Firewallrichtlinie mit der Ingress-Regel angewendet wird, sind dasselbe VPC-Netzwerk oder sind entweder über VPC-Netzwerk-Peering oder als VPC-Spokes an einem Network Connectivity Center-Hub verbunden.

Die folgenden Ressourcen befinden sich in einem VPC-Netzwerk:

  • VM-Netzwerkschnittstellen
  • Cloud VPN-Tunnel
  • Cloud Interconnect-VLAN-Anhänge
  • Router-Appliances
  • Envoy-Proxys in einem Nur-Proxy-Subnetz
  • Private Service Connect-Endpunkte
  • Connectors für serverlosen VPC-Zugriff

VPC-intern

Der Netzwerkbereich innerhalb des VPC (INTRA_VPC) kann nur als Teil einer Quellkombination einer Ingress-Regel verwendet werden. Sie können den VPC-internen Bereich nicht als Teil einer Zielkombination einer ausgehenden Regel verwenden.

Wenn Sie den VPC-internen Bereich als Teil einer Quellkombination einer Ingress-Regel verwenden möchten, müssen Sie mindestens einen anderen Quellparameter angeben, mit Ausnahme einer Threat Intelligence-Liste oder einer Standortquelle.

Ein Paket stimmt mit einer Ingress-Regel überein, die in der Quellkombination den VPC-internen Bereich verwendet, wenn alle folgenden Bedingungen erfüllt sind:

  • Das Paket stimmt mit mindestens einem der anderen Quellparameter überein.

  • Das Paket wird von einer Ressource im VPC-Netzwerk gesendet, auf das die Firewallrichtlinie mit der Eingangsregel angewendet wird.

Die folgenden Ressourcen befinden sich in einem VPC-Netzwerk:

  • VM-Netzwerkschnittstellen
  • Cloud VPN-Tunnel
  • Cloud Interconnect-VLAN-Anhänge
  • Router-Appliances
  • Envoy-Proxys in einem Nur-Proxy-Subnetz
  • Private Service Connect-Endpunkte
  • Connectors für serverlosen VPC-Zugriff

Standortobjekte

Verwenden Sie Standortobjekte in Firewallrichtlinien-Regeln, um externen IPv4- und externen IPv6-Traffic anhand bestimmter geografischer Standorte oder Regionen zu filtern.

Sie können Regeln mit Standortobjekten auf eingehenden und ausgehenden Traffic anwenden. Basierend auf der Richtung des Traffics werden die mit den Ländercodes verknüpften IP-Adressen mit der Quelle oder dem Ziel des Traffics abgeglichen.

  • Sie können Standortobjekte für hierarchische Firewallrichtlinien, globale Netzwerk-Firewallrichtlinien und regionale Netzwerk-Firewallrichtlinien konfigurieren.

  • Verwenden Sie zum Hinzufügen von Standorten zu den Firewallrichtlinien-Regeln Ländercodes mit zwei Buchstaben oder Regionscodes, wie in den ISO 3166-Alpha-2-Ländercodes definiert.

    Wenn Sie beispielsweise eingehenden Traffic nur aus den USA in das Netzwerk zulassen möchten, erstellen Sie eine Firewallregel für eingehenden Traffic und setzen Sie den Quellcode des Quelllandes auf US und die Aktion aufallow. Wenn Sie ausgehenden Traffic nur in die USA zulassen möchten, konfigurieren Sie eine Firewallrichtlinien-Regel und setzen Sie den Ziellländercode auf US und die Aktion auf allow.

  • Mit Cloud NGFW können Sie Firewallregeln für die folgenden Gebiete konfigurieren, die umfassenden US-Sanktionen unterliegen:

    Gebiete Zugewiesener Code
    Krim XC
    Sogenannte Volksrepublik Donezk und sogenannte Volksrepublik Luhansk XD

  • Wenn in einer einzelnen Firewallregel doppelte Ländercodes enthalten sind, wird nur ein Eintrag für diesen Ländercode beibehalten. Der doppelte Eintrag wird entfernt. In der Ländercodeliste ca,us,us wird beispielsweise nur ca,us beibehalten.

  • Google verwaltet eine Datenbank mit IP-Adressen und Ländercodezuordnungen. Google Cloud-Firewalls verwenden diese Datenbank, um die IP-Adressen des Quell- und Zieltraffics dem Ländercode zuzuordnen. Anschließend wird die übereinstimmende Firewallrichtlinien-Regel mit Standortobjekten angewendet.

  • Manchmal ändern sich IP-Adresszuweisungen und Ländercodes aufgrund der folgenden Bedingungen:

    Da es einige Zeit dauern kann, bis diese Änderungen in der Google-Datenbank widergespiegelt werden, kommt es unter Umständen zu Trafficunterbrechungen und Verhaltensänderungen bei bestimmtem Traffic, der blockiert oder zugelassen wird.

Standortobjekte mit anderen Filtern für Firewallrichtlinien-Regeln verwenden

Sie können Standortobjekte zusammen mit anderen Quell- oder Zielfiltern verwenden. Abhängig von der Regelrichtung wird die Firewallrichtlinien-Regel auf den eingehenden oder ausgehenden Traffic angewendet, der der Vereinigung aller angegebenen Filter entspricht.

Informationen zur Funktionsweise von Standortobjekten mit anderen Quellfiltern in den Regeln für eingehenden Traffic finden Sie unter Quellen für Regeln für eingehenden Traffic in hierarchischen Firewallrichtlinien und Quellen für Regeln für eingehenden Traffic in Netzwerk-Firewallrichtlinien.

Informationen zur Funktionsweise von Standortobjekten mit anderen Zielfiltern in den Regeln für ausgehenden Traffic finden Sie unter Ziele für Regeln für ausgehenden Traffic.

Google Threat Intelligence für Firewallrichtlinien-Regeln

Mit Firewallrichtlinien-Regeln können Sie Ihr Netzwerk sichern, indem Sie Traffic auf der Grundlage von Google Threat Intelligence-Daten zulassen oder blockieren. Google Threat Intelligence-Daten enthalten Listen von IP-Adressen basierend auf den folgenden Kategorien:

  • Tor-Ausgangsknoten: Tor ist eine Open-Source-Software, die anonyme Kommunikation ermöglicht. Wenn Sie Nutzer ausschließen möchten, die ihre Identität ausblenden, blockieren Sie die IP-Adressen der Tor-Ausgangsknoten (Endpunkte, an denen der Traffic das Tor-Netzwerk verlässt).
  • Bekannte schädliche IP-Adressen: IP-Adressen, von denen bekannterweise Angriffe auf Webanwendungen ausgingen. Blockieren Sie diese IP-Adressen, um den Sicherheitsstatus Ihrer Anwendung zu verbessern.
  • Suchmaschinen: IP-Adressen, für die Sie die Aktivierung der Websiteindexierung zulassen können.
  • IP-Adressbereiche der öffentlichen Cloud: Diese Kategorie kann entweder blockiert werden, um zu verhindern, dass schädliche automatisierte Tools in Webanwendungen suchen, oder sie kann zugelassen werden, wenn Ihr Dienst andere öffentliche Clouds verwendet. Diese Kategorie ist in die folgenden Unterkategorien unterteilt:
    • Von Amazon Web Services verwendete IP-Adressbereiche
    • Von Microsoft Azure verwendete IP-Adressbereiche
    • Von Google Cloud verwendete IP-Adressbereiche
    • Von Google-Diensten verwendete IP-Adressbereiche

Die Google Threat Intelligence-Datenlisten können IPv4-Adressen, IPv6-Adressen oder beides enthalten. Um Google Threat Intelligence in Ihren Firewallrichtlinien-Regeln zu konfigurieren, verwenden Sie die vordefinierten Google Threat Intelligence-Listennamen basierend auf der Kategorie, die Sie zulassen oder blockieren möchten. Diese Listen werden kontinuierlich aktualisiert, um Dienste ohne zusätzliche Konfigurationsschritte vor neuen Bedrohungen zu schützen. Folgende Listennamen sind gültig:

Name der Liste Beschreibung
iplist-tor-exit-nodes Entspricht IP-Adressen der TOR-Ausgangsknoten
iplist-known-malicious-ips Entspricht IP-Adressen, die bekanntermaßen Angriffe auf Webanwendungen ausführen
iplist-search-engines-crawlers Entspricht IP-Adressen von Suchmaschinen-Crawlern
iplist-vpn-providers Entspricht IP-Adressen, die zu VPN-Anbietern mit schlechter Reputation gehören
iplist-anon-proxies Entspricht IP-Adressen, die zu offenen anonymen Proxys gehören
iplist-crypto-miners Entspricht IP-Adressen, die zu Kryptomining-Websites gehören
iplist-public-clouds
  • iplist-public-clouds-aws
  • iplist-public-clouds-azure
  • iplist-public-clouds-gcp
  • iplist-public-clouds-google-services
 Entspricht IP-Adressen, die zu öffentlichen Clouds gehören
  • Führt zu Übereinstimmung mit den IP-Adressbereichen, die von Amazon Web Services verwendet werden
  • Entspricht den von Microsoft Azure verwendeten IP-Adressbereichen
  • Führt zu Übereinstimmung mit den von Google Cloud verwendeten IP-Adressbereichen
  • Führt zu Übereinstimmung mit den von Google-Diensten verwendeten IP-Adressbereichen

Google Threat Intelligence mit anderen Filtern für Firewallrichtlinien-Regeln verwenden

Befolgen Sie diese Richtlinien, um eine Firewallrichtlinien-Regel mit Google Threat Intelligence zu definieren:

  • Geben Sie für Regeln für ausgehenden Traffic das Ziel mithilfe einer oder mehrerer Google Threat Intelligence-Ziellisten an.

  • Geben Sie für Regeln für eingehenden Traffic die Quelle mit einer oder mehreren Google Threat Intelligence-Quelllisten an.

  • Sie können Google Threat Intelligence-Listen für hierarchische Firewallrichtlinien, globale Netzwerk-Firewallrichtlinien und regionale Netzwerk-Firewallrichtlinien konfigurieren.

  • Sie können diese Listen zusammen mit anderen Komponenten von Quell- oder Zielregelfiltern verwenden.

    Informationen dazu, wie Google Threat Intelligence-Listen mit anderen Quellfiltern in den Eingangsregeln funktionieren, finden Sie unter Quellen für Regeln für eingehenden Traffic in hierarchischen Firewallrichtlinien und Quellen für Regeln für eingehenden Traffic in Netzwerk-Firewallrichtlinien.

    Informationen zur Funktionsweise von Google Threat Intelligence-Listen mit anderen Zielfiltern in den Regeln für ausgehenden Traffic finden Sie unter Ziele für Regeln für ausgehenden Traffic.

  • Firewall-Logging erfolgt auf Regelebene. Fügen Sie nicht mehrere Google Threat Intelligence-Listen in eine einzelne Firewallregel ein, um die Fehlerbehebung und Analyse der Auswirkungen Ihrer Firewallregeln zu vereinfachen.

  • Sie können einer Firewallrichtlinienregel mehrere Google Threat Intelligence-Listen hinzufügen. Jeder in der Regel enthaltene Listenname wird als ein Attribut gezählt, unabhängig von der Anzahl der in dieser Liste enthaltenen IP-Adressen oder IP-Adressbereiche. Wenn Sie beispielsweise die Listennamen iplist-tor-exit-nodes, iplist-known-malicious-ips und iplist-search-engines-crawlers in die Firewallregel aufgenommen haben, erhöht sich die Anzahl der Regelattribute pro Firewallrichtlinie um: drei. Weitere Informationen zur Anzahl der Regelattribute finden Sie unter Kontingente und Limits.

Ausnahmen für Google Threat Intelligence-Listen erstellen

Wenn Sie Regeln für Google Threat Intelligence-Listen haben, können Sie mit den folgenden Methoden Ausnahmeregeln erstellen, die für bestimmte IP-Adressen innerhalb einer Google Threat Intelligence-Liste gelten:

  • Selektive Zulassungsliste: Angenommen, Sie haben eine Firewallregel für eingehenden oder ausgehenden Traffic, die Pakete von oder zu einer Google Threat Intelligence-Liste ablehnt. Wenn Sie Pakete von oder zu einer ausgewählten IP-Adresse innerhalb dieser Google Threat Intelligence-Liste zulassen möchten, erstellen Sie eine separate Zulassungs-Firewallregel für eingehenden oder ausgehenden Traffic mit höherer Priorität, die die Ausnahme-IP-Adresse als Quelle oder Ziel angibt.

  • Selektive Ablehnungsliste: Angenommen, Sie haben eine Firewallregel für eingehenden oder ausgehenden Traffic, die Pakete von oder zu einer Google Threat Intelligence-Liste zulässt. Wenn Sie Pakete von oder zu einer ausgewählten IP-Adresse innerhalb dieser Google Threat Intelligence-Liste ablehnen möchten, erstellen Sie eine Ablehnungs-Firewallregel für eingehenden oder ausgehenden Traffic mit höherer Priorität, die die Ausnahme-IP-Adresse als Quelle oder Ziel angibt.

Adressgruppen für Firewallrichtlinien

Adressbereiche sind eine logische Sammlung von IPv4-Adressbereichen oder IPv6-Adressbereichen im CIDR-Format. Mit Adressgruppen können Sie konsistente Quellen oder Ziele definieren, auf die viele Firewallregeln verweisen. Adressgruppen können ohne Änderung der Firewallregeln aktualisiert werden, von denen sie verwendet werden. Weitere Informationen zu Adressgruppen finden Sie unter Adressgruppen für Firewallrichtlinien.

Sie können Quell- und Zieladressgruppen für Firewallregeln für eingehenden und ausgehenden Traffic definieren.

Informationen zur Funktionsweise von Quelladressgruppen mit anderen Quellfiltern in den Regeln für eingehenden Traffic finden Sie unter Quellen für Regeln für eingehenden Traffic in hierarchischen Firewallrichtlinien und Quellen für Regeln für eingehenden Traffic in Netzwerk-Firewallrichtlinien.

Informationen zur Funktionsweise von Zieladressgruppen mit anderen Zielfiltern in den Regeln für ausgehenden Traffic finden Sie unter Ziele für Regeln für ausgehenden Traffic.

FQDN-Objekte

Verwenden Sie Objekte für voll qualifizierte Domainnamen (FQDN) in den Firewallrichtlinienregeln, um eingehenden oder ausgehenden Traffic von oder zu bestimmten Domains zu filtern.

Sie können Firewallregeln mit FQDN-Objekten sowohl auf eingehenden als auch auf ausgehenden Traffic anwenden. Abhängig von der Richtung des Traffics werden die mit den Domainnamen verknüpften IP-Adressen mit der Quelle oder dem Ziel des Traffics abgeglichen.

  • Sie können FQDN-Objekte in Firewallregeln für hierarchische Firewallrichtlinien, globale Netzwerk-Firewallrichtlinien und regionale Netzwerk-Firewallrichtlinien konfigurieren.

  • FQDN-Objekte müssen in der Standard-FQDN-Syntax angegeben werden.

    Weitere Informationen zu Domainnamenformaten finden Sie unter Domainnamenformat.

  • Cloud NGFW aktualisiert in regelmäßigen Abständen die Richtlinien für Firewallrichtlinien, die FQDN-Objekte mit den neuesten Ergebnissen der Domainnamenauflösung enthalten.

  • Die in den Firewallrichtlinien-Regeln angegebenen Domainnamen werden entsprechend der Reihenfolge der VPC-Namensauflösung von Cloud DNS in IP-Adressen aufgelöst. Cloud DNS benachrichtigt die Cloud NGFW, wenn sich die Ergebnisse der Auflösung von Domainnamen ändern. Diese werden auch als DNS-Einträge (Domain Name System) bezeichnet.

  • Wenn zwei Domainnamen in dieselbe IP-Adresse aufgelöst werden, gilt die Firewallregel für diese IP-Adresse, nicht nur für eine Domain. Die FQDN-Objekte sind also Layer-3-Entitäten.

  • Wenn das FQDN-Objekt in der Firewallregel für ausgehenden Traffic eine Domain enthält, die CNAMEs im DNS-Eintrag enthält, müssen Sie die Firewallregel für ausgehenden Traffic mit allen Domainnamen konfigurieren, die Ihre VMs abfragen können, einschließlich aller potenziellen Aliasse, um das zuverlässige Verhalten der Firewallregel zu gewährleisten. Wenn Ihre VMs CNAMEs abfragen, die nicht in der Firewallregel für ausgehenden Traffic konfiguriert sind, funktioniert die Richtlinie möglicherweise während der Änderung der DNS-Einträge nicht.

  • Sie können in Ihren Regeln für Netzwerk-Firewallrichtlinien auch interne Compute Engine-DNS-Namen verwenden. Achten Sie jedoch darauf, dass Ihr Netzwerk nicht für die Verwendung eines alternativen Nameservers in der Serverrichtlinie für ausgehenden Traffic konfiguriert ist.

  • Wenn Sie in den Firewallrichtlinien-Regeln für Ihr Netzwerk benutzerdefinierte Domainnamen hinzufügen möchten, können Sie verwaltete Cloud DNS-Zonen für die Auflösung von Domainnamen verwenden. Achten Sie jedoch darauf, dass Ihr Netzwerk nicht für die Verwendung eines alternativen Nameservers in der Serverrichtlinie für ausgehenden Traffic konfiguriert ist. Weitere Informationen zur Zonenverwaltung finden Sie unter Zonen erstellen, ändern und löschen.

Beschränkungen

Die folgenden Einschränkungen gelten sowohl für eingehende als auch für ausgehende Firewallregeln, die FQDN-Objekte verwenden:

  • FQDN-Objekte unterstützen weder Platzhalter (*) noch Stammdomainnamen der obersten Ebene. Beispielsweise werden *.example.com. und .org nicht unterstützt.

Sie können FQDN-Objekte in Firewallregeln für eingehenden Traffic verwenden. Beim Definieren von FQDN-Objekten für Regeln für eingehenden Traffic müssen Sie die folgenden Einschränkungen berücksichtigen:

  • Ein Domainname kann maximal 32 IPv4-Adressen und 32 IPv6-Adressen auflösen. DNS-Abfragen, die in mehr als 32 IPv4- und 32 IPv6-Adressen aufgelöst werden, werden gekürzt, um nur 32 IPv4- oder IPv6-Adressen dieser aufgelösten IP-Adressen aufzunehmen. Geben Sie daher keine Domainnamen an, die in mehr als 32 IPv4- und IPv6-Adressen in die Firewallregeln für eingehenden Traffic aufgelöst werden.

  • Einige Abfragen von Domainnamen haben je nach Standort des anfragenden Clients eindeutige Antworten. Der Standort, von dem aus die DNS-Auflösung der Firewallrichtlinien-Regel ausgeführt wird, ist die Google Cloud-Region mit der VM, für die die Firewallrichtlinien-Regel gilt.

  • Verwenden Sie keine Regeln für eingehenden Traffic mit FQDN-Objekten, wenn die Ergebnisse der Domainauflösung sehr variabel sind oder die Auflösung der Domainnamen eine Form des DNS-basierten Load-Balancings verwendet. Viele Google-Domainnamen verwenden beispielsweise ein DNS-basiertes Load-Balancing-Schema.

Sie können FQDN-Objekte in Firewallregeln für ausgehenden Traffic verwenden. Wir empfehlen jedoch, keine FQDN-Objekte mit DNS-A-Einträgen mit einer TTL (Time-to-Live) von weniger als 90 Sekunden zu verwenden.

FQDN-Objekte mit anderen Filtern für Firewallrichtlinien-Regeln verwenden

In einer Firewallrichtlinien-Regel können Sie FQDN-Objekte zusammen mit anderen Quell- oder Zielfiltern definieren.

Informationen zur Funktionsweise von FQDN-Objekten mit anderen Quellfiltern in den Regeln für eingehenden Traffic finden Sie unter Quellen für Regeln für eingehenden Traffic in hierarchischen Firewallrichtlinien und Quellen für Regeln für eingehenden Traffic in Netzwerk-Firewallrichtlinien.

Weitere Informationen zur Funktionsweise von FQDN-Objekten mit anderen Zielfiltern in den Regeln für ausgehenden Traffic finden Sie unter Ziele für Regeln für ausgehenden Traffic.

Domainnamenformat

VPC-Firewalls unterstützen das Domainnamenformat wie in RFC 1035, RFC 1123 und RFC 4343 definiert.

Beachten Sie diese Formatierungsrichtlinien, um Domainnamen zu Firewallrichtlinien-Regeln hinzuzufügen.

  • Der Domainname muss mindestens zwei Labels enthalten, die so beschrieben werden:

    • Jedes Label passt zu regulären Ausdrücken, die nur diese Zeichen enthalten: [a-z]([-a-z0-9][a-z0-9])?..
    • Jedes Label umfasst 1 bis 63 Zeichen.
    • Labels sind mit einem Punkt (.) verkettet.

  • Die maximale codierte Länge des Domainnamens darf 255 Byte (Oktett) nicht überschreiten.

  • Sie können den Firewallrichtlinien-Regeln auch einen internationalisierten Domainnamen (IDN) hinzufügen.

  • Domainnamen müssen im Unicode- oder Punycode-Format vorliegen.

  • Wenn Sie einen IDN im Unicode-Format angeben, wird dieser von der Google Cloud-Firewall vor der Verarbeitung in das Punycode-Format formatiert. Alternativ können Sie das IDN Converter Tool verwenden, um die Punycode-Darstellung von IDN abzurufen.

  • Die Google Cloud-Firewall unterstützt keine entsprechenden Domainnamen in derselben Firewallrichtlinien-Regel. Wenn die Domainnamen in das Punycode-Format konvertiert wurden und sich beide Domainnamen höchstens durch einen abschließenden Punkt unterscheiden, werden sie als äquivalent betrachtet.

FQDN-Ausnahmeszenarien

Wenn Sie FQDN-Objekte in den Firewallrichtlinien-Regeln verwenden, können bei der DNS-Namensauflösung die folgenden Ausnahmen auftreten:

  • Fehlerhafter Domainname: Wenn Sie beim Erstellen einer Firewallrichtlinien-Regel einen oder mehrere Domainnamen mit einem ungültigen Format angeben, erhalten Sie eine Fehlermeldung. Die Firewallrichtlinien-Regel kann nur erstellt werden, wenn alle Domainnamen richtig formatiert sind.

  • Domainname nicht vorhanden (NXDOMAIN): Wenn der Domainname nicht vorhanden ist, ignoriert Google Cloud das FQDN-Objekt von der Firewallrichtlinien-Regel.

  • Keine IP-Adressauflösung: Wenn der Domainname nicht in eine IP-Adresse aufgelöst wird, wird das FQDN-Objekt ignoriert.

  • Cloud DNS-Server nicht erreichbar: Wenn kein DNS-Server erreichbar ist, gelten die Firewallrichtlinien-Regeln, die FQDN-Objekte verwenden, nur dann, wenn die zuvor im Cache gespeicherten Ergebnisse der DNS-Auflösung verfügbar sind. Die FQDN-Objekte der Regel werden ignoriert, wenn keine im Cache gespeicherten DNS-Auflösungsergebnisse vorhanden oder die im Cache gespeicherten DNS-Ergebnisse nicht mehr gültig sind.

Nächste Schritte