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 Richtung „Eingehender Traffic“ 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. Google Cloud 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:

Aktionsparameter Beschreibung
allow

Ermöglicht Pakete für eine neue Verbindung. Die Auswertung von Regeln in der Firewallrichtlinie, die die übereinstimmende Regel enthält, wird beendet. Es werden keine anderen Firewallregeln ausgewertet.

Unabhängig von der Richtung der Regel wird bei einer Zulassungsregel, wenn das Paketprotokoll und der Firewallrichtlinientyp die Verbindungsverfolgung unterstützen, ein Eintrag in der Firewall-Verbindungsverfolgungstabelle erstellt, der sowohl eingehende als auch ausgehende Pakete zulässt.
deny

Verhindert Pakete für eine neue Verbindung. Die Auswertung von Regeln in der Firewallrichtlinie, die die übereinstimmende Regel enthält, wird beendet. Es werden keine anderen Firewallregeln ausgewertet.

Cloud NGFW prüft immer, ob ein Eintrag in der Tabelle zur Verbindungsverfolgung der Firewall vorhanden ist, bevor Firewallregeln ausgewertet werden. Wenn also durch eine „Zulassen“-Regel ein Eintrag in der Tabelle zur Verbindungsverfolgung erstellt wurde, hat dieser Eintrag Vorrang.
apply_security_profile_group

Fängt Pakete für eine neue Verbindung ab und sendet sie an einen Firewallendpunkt oder eine Abfangendpunktgruppe. Die Auswertung von Regeln in der Firewallrichtlinie, die die übereinstimmende Regel enthält, wird beendet. Es werden keine anderen Firewallregeln ausgewertet.

Unabhängig von der Richtung der Regel wird bei einer Regel mit der Aktion apply_security_profile_group ein Eintrag in der Firewall-Verbindungs-Tracking-Tabelle erstellt, wenn das Paketprotokoll und der Firewallrichtlinientyp das Verbindungs-Tracking unterstützen. So werden sowohl eingehende als auch ausgehende Pakete vom Firewall-Endpunkt oder der Abfangendpunktgruppe abgefangen.

Sie können keine Regeln mit der Aktion apply_security_profile_group in regionalen Netzwerk-Firewallrichtlinien erstellen.
goto_next

Die Auswertung anderer Regeln in der Firewallrichtlinie wird beendet und die Regeln im nächsten Schritt der Reihenfolge der Firewallrichtlinien- und Regelauswertung werden ausgewertet.

Im nächsten Schritt der Firewallrichtlinien- und Regelauswertungsreihenfolge werden möglicherweise Regeln in einer anderen Firewallrichtlinie oder die impliziten Firewallregeln ausgewertet.

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 die Protokollnummer 58, um IPv6 ICMP anzugeben.

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

Alle Firewallregeln für eingehenden und ausgehenden Traffic haben ein Ziel. Das Ziel identifiziert die Netzwerkschnittstellen der Compute Engine-Instanzen, einschließlich Google Kubernetes Engine-Knoten und Instanzen der flexiblen App Engine-Umgebung, für die die Firewallregel gilt.

Jede Firewallregel hat ein breitestes Ziel, das Sie eingrenzen können, indem Sie einen Zielparameter oder eine Zielparameterkombination angeben. Wenn Sie weder einen Zielparameter noch eine Zielparameterkombination angeben, gilt die Firewallregel für das breiteste Ziel.

  • Breitestes Ziel für Regeln in hierarchischen Firewallrichtlinien: alle VM-Netzwerkschnittstellen in einem Subnetz in einer beliebigen Region eines beliebigen VPC-Netzwerks, das sich in einem Projekt unter dem Resource Manager-Knoten (Ordner oder Organisation) befindet, der mit der hierarchischen Firewallrichtlinie verknüpft ist.

  • Breitestes Ziel für Regeln in globalen Netzwerk-Firewallrichtlinien: alle VM-Netzwerkschnittstellen in einem Subnetzwerk in einer beliebigen Region des VPC-Netzwerks, das mit der globalen Netzwerk-Firewallrichtlinie verknüpft ist.

  • Breiteste Zielgruppe für Regeln in regionalen Netzwerk-Firewallrichtlinien: alle VM-Netzwerkschnittstellen in einem Subnetzwerk innerhalb der Region und des VPC-Netzwerks, das der regionalen Netzwerk-Firewallrichtlinie zugeordnet ist.

In der folgenden Tabelle sind gültige Zielparameter und Kombinationen aufgeführt, mit denen Sie das Ziel einer Firewallregel eingrenzen können:

Zielparameter Unterstützung in hierarchischen Firewallrichtlinien Unterstützung in globalen und regionalen Netzwerk-Firewallrichtlinien
VPC-VPC-Netzwerk als Ziel festlegen

Eine Liste mit einem oder mehreren VPC-Netzwerken, die mit dem Parameter target-resources angegeben werden. Diese Liste schränkt das breiteste Ziel der Firewallregel auf die VM-Netzwerkschnittstellen ein, die sich in mindestens einem der angegebenen VPC-Netzwerke befinden.
Zieldienstkonten

Eine Liste mit einem oder mehreren Dienstkonten, die mit dem Parameter target-service-accounts angegeben werden. Diese Liste schränkt das breiteste Ziel der Firewallregel auf die VM-Netzwerkschnittstellen ein, die zu VM-Instanzen gehören, die mindestens einem der angegebenen Dienstkonten zugeordnet sind.
Kombination aus Ziel-Dienstkonten und Ziel-VPC-Netzwerkressourcen

Eine Kombination, bei der sowohl der Parameter target-service-accounts als auch der Parameter target-resources in derselben Regel verwendet werden. Durch diese Kombination wird das breiteste Ziel der Firewallregel auf die VM-Netzwerkschnittstellen beschränkt, die beide der folgenden Kriterien erfüllen:

  • Schnittstellen, die sich in mindestens einem der angegebenen VPC-Netzwerke befinden
  • Schnittstellen, die zu VM-Instanzen gehören, die mindestens einem der angegebenen Dienstkonten zugeordnet sind
Sichere Tag-Werte aus einem Tag-Schlüssel mit Daten zum Netzwerkzweck ausrichten

Eine Liste mit mindestens einem Tag-Wert aus einem Tag-Schlüssel, dessen Zweckdaten ein einzelnes VPC-Netzwerk angeben. Diese Liste schränkt das breiteste Ziel der Firewallregel auf die VM-Netzwerkschnittstellen ein, die sich im VPC-Netzwerk befinden, das in den Zweckdaten angegeben ist. Weitere Informationen finden Sie unter Sichere Tags für Firewalls.
Sichere Tag-Werte aus einem Tag-Schlüssel mit Daten zum Organisationszweck ausrichten

Eine Liste mit mindestens einem Tag-Wert aus einem Tag-Schlüssel, dessen Zweckdaten organization=auto sind. Dadurch wird das breiteste Ziel der Firewallregel auf die VM-Netzwerkschnittstellen in einem beliebigen VPC-Netzwerk der Organisation eingegrenzt. Weitere Informationen finden Sie unter Sichere Tags für Firewalls.

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 die Quellparameter aufgeführt, die einzeln oder in Kombination miteinander 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 Regeln für eingehenden Traffic Unterstützung in hierarchischen Firewallrichtlinien Unterstützung in globalen und regionalen Netzwerk-Firewallrichtlinien
Quell-IP-Adressbereiche

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

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, einschließlich der Konvertierung von Domainnamen in IP-Adressen, finden Sie unter FQDN-Objekte.
Sichere Tag-Werte aus einem Tag-Schlüssel mit Daten zum Netzwerkzweck abrufen

Eine Liste mit mindestens einem Tag-Wert aus einem Tag-Schlüssel, dessen Zweckdaten ein einzelnes VPC-Netzwerk angeben. Weitere Informationen finden Sie unter Sichere Tags für Firewalls und Wie sichere Quell-Tags Paketquellen implizieren.
Sichere Tag-Werte aus einem Tag-Schlüssel mit Daten zum Organisationszweck abrufen

Eine Liste mit mindestens einem Tag-Wert aus einem Tag-Schlüssel, dessen Zweckdaten organization=auto sind. Weitere Informationen finden Sie unter Sichere Tags für Firewalls und Wie sichere Quell-Tags Paketquellen implizieren.
Quellstandorte

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-Quelllisten

Eine Liste mit einem oder mehreren vordefinierten Google Threat Intelligence-Listennamen. Weitere Informationen finden Sie unter Google Threat Intelligence für Firewallrichtlinien-Regeln.
Quellnetzwerktyp

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

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, aber nicht beides.
  • 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 Internet-Netzwerktyp kann nicht mit den sicheren Quell-Tags verwendet werden.
  • Die Typen „Ohne Internet“, „VPC-Netzwerke“ und „VPC-übergreifend“ können nicht mit Google Threat Intelligence-Listen als Quelle oder mit Geolocation als Quelle verwendet werden.

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

  • Wenn die Quellkombination keinen Quellnetzwerktyp enthält, entsprechen Pakete der Regel für eingehenden Traffic, wenn sie mindestens einem Quellparameter in der Quellkombination entsprechen.

  • Wenn die Quellkombination einen Quellnetzwerktyp enthält, stimmen Pakete mit der Regel für eingehenden Traffic überein, wenn sie mit dem Quellnetzwerktyp und mindestens einem der anderen Quellparameter in der Quellkombination übereinstimmen.

Wie sichere Quell-Tags Paketquellen implizieren

Regeln für eingehenden Traffic in Firewallrichtlinien können Quellen mithilfe von sicheren Quell-Tags (Tag-Werten) angeben. Sichere Tag-Werte identifizieren Netzwerkschnittstellen, nicht Paketmerkmale wie IP-Adressen.

Pakete, die von einer Netzwerkschnittstelle einer VM-Instanz gesendet werden, entsprechen einer Regel für eingehenden Traffic, die einen sicheren Quell-Tag-Wert verwendet, gemäß den folgenden Regeln:

  • Wenn sich die Regel für eingehenden Traffic in einer regionalen Netzwerkrichtlinie befindet, muss sich die VM-Instanz in einer Zone derselben Region wie die regionale Netzwerk-Firewallrichtlinie befinden. Andernfalls kann sich die VM-Instanz in einer beliebigen Zone befinden.

  • Die VM-Instanz muss demselben sicheren Tag-Wert zugeordnet sein, der als sicheres Quell-Tag in einer Firewallregel für eingehenden Traffic verwendet wird.

  • Der sichere Tag-Wert, der der VM-Instanz zugeordnet und von der Firewallregel für eingehenden Traffic verwendet wird, muss von einem Tag-Schlüssel stammen, dessen Attribut purpose-data mindestens ein VPC-Netzwerk identifiziert, das eine Netzwerkschnittstelle der VM-Instanz enthält:

    • Wenn die Zweckdaten des Tag-Schlüssels ein einzelnes VPC-Netzwerk angeben, gelten Firewallregeln für eingehenden Traffic, die den sicheren Quell-Tag-Wert verwenden, für die Netzwerkschnittstellen der VM-Instanz, die sich in diesem VPC-Netzwerk befinden.

    • Wenn die Zweckdaten des Tag-Schlüssels die Organisation angeben, gelten Firewallregeln für eingehenden Traffic, die den sicheren Quell-Tag-Wert verwenden, für die Netzwerkschnittstellen der VM-Instanz, die sich in einem beliebigen VPC-Netzwerk der Organisation befinden.

  • Die identifizierte VM-Netzwerkschnittstelle muss eines der folgenden Kriterien erfüllen:

    • Die VM-Netzwerkschnittstelle befindet sich im selben VPC-Netzwerk wie das VPC-Netzwerk, für das die Firewallrichtlinie gilt.
    • Die VM-Netzwerkschnittstelle befindet sich in einem VPC-Netzwerk, das über VPC-Netzwerk-Peering mit dem VPC-Netzwerk verbunden ist, für das die Firewallrichtlinie gilt.

Weitere Informationen zu sicheren Tags für Firewalls finden Sie unter Spezifikationen.

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-Adressen 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 die Zielparameter aufgeführt, die einzeln oder in Kombination miteinander in einer einzelnen Regel für ausgehenden Traffic in einer Firewallrichtlinie verwendet werden können. Für Cloud NGFW müssen Sie mindestens einen Zielparameter angeben.

Zielparameter für Regeln für ausgehenden Traffic 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 Firewallrichtlinienregel selbst gespeichert.
Zieladressgruppen

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

Eine Liste mit einem oder mehreren Quelldomainnamen. Weitere Informationen, einschließlich der Konvertierung von Domainnamen in IP-Adressen, 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.
Ziel-Threat Intelligence-Listen von Google

Eine Liste mit einem oder mehreren vordefinierten Google Threat Intelligence-Listennamen. Weitere Informationen finden Sie unter Google Threat Intelligence für Firewallrichtlinien-Regeln.
Zielnetzwerktyp

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

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, aber nicht beides.
  • 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.
  • Ziel- Google Threat Intelligence-Listen oder Ziel- Geolokationen können nicht mit dem Zielnetzwerktyp „Nicht-Internet“ verwendet werden.

Cloud NGFW wendet die folgende Logik an, um die Pakete einer Egress-Regel zuzuordnen, die eine Zielkombination verwendet:

  • Wenn die Zielkombination keinen Zielnetzwerktyp enthält, stimmen Pakete mit der Regel für ausgehenden Traffic überein, wenn sie mindestens einem Zielparameter in der Zielkombination entsprechen.

  • Wenn die Zielkombination einen Zielnetzwerktyp enthält, entsprechen Pakete der Regel für ausgehenden Traffic, wenn sie dem Zielnetzwerktyp und mindestens einem der anderen Zielparameter in der Zielkombination entsprechen.

Netzwerktypen

Mit Netzwerktypen können Sie Ihre Sicherheitsziele mit weniger Firewallrichtlinienregeln effizienter erreichen. Cloud NGFW unterstützt vier Netzwerktypen, die zum Erstellen einer Quellkombination oder Zielkombination in einer Regel einer hierarchischen Firewallrichtlinie, einer globalen Netzwerk-Firewallrichtlinie oder einer regionalen Netzwerk-Firewallrichtlinie verwendet werden können.

In der folgenden Tabelle sind die vier Netzwerktypen aufgeführt und es wird angegeben, ob ein Netzwerktyp in einer Quellkombination einer Ingress-Regel, in einer Zielkombination einer Egress-Regel oder in beiden verwendet werden kann.

Netzwerktyp 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 Netzwerktypen „Internet“ und „Ohne Internet“ schließen sich gegenseitig aus. Die VPC-Netzwerke und Intra-VPC-Netzwerktypen sind Teilmengen des Netzwerktyps „Ohne Internet“.

Typ des Internetnetzwerks

Der Netzwerktyp internet (INTERNET) kann als Teil einer Quellkombination einer Ingress-Regel oder als Teil einer Zielkombination einer Egress-Regel verwendet werden:

  • Geben Sie für eine Regel für eingehenden Traffic die Quelle des Internetyps und mindestens einen anderen Quellparameter an, mit Ausnahme einer Quelle mit sicherem Tag. Pakete entsprechen der Regel für eingehenden Traffic, wenn sie mindestens einem der anderen Quellparameter und dem Quellparameter für den Internettyp entsprechen.

  • Geben Sie für eine Ausgangsregel das Ziel vom Typ „Internet“ und mindestens einen weiteren Zielparameter an. Pakete entsprechen der Regel für ausgehenden Traffic, wenn sie mindestens einem der anderen Zielparameter und dem Zielparameter für den Internettyp entsprechen.

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

Typ des Internetnetzwerks für eingehende Pakete

Eingehende Pakete, die von einem Google Maglev an eine VM-Netzwerkschnittstelle weitergeleitet werden, gehören zum Netzwerktyp „Internet“. 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, einer Weiterleitungsregel eines externen Passthrough-Network Load Balancers oder einer Weiterleitungsregel für die externe Protokollweiterleitung.
  • Eine regionale externe IPv6-Adresse einer VM-Netzwerkschnittstelle, einer Weiterleitungsregel eines externen Passthrough-Network Load Balancers oder einer Weiterleitungsregel für die externe Protokollweiterleitung und das Paket nicht über eine Subnetzroute weitergeleitet wurde, die durch VPC Network Peering oder von einem VPC-Spoke in einem Network Connectivity Center-Hub importiert wurde.

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

Typ des Internetnetzwerks für ausgehende Pakete

Ausgehende Pakete, die von den Netzwerkschnittstellen der VM gesendet und über statische Routen mit dem nächsten Hop des Standard-Internetgateways weitergeleitet werden, gehören zum Netzwerktyp „Internet“. Wenn die Ziel-IP-Adresse dieser Egress-Pakete jedoch für Google APIs und Dienste bestimmt ist, werden diese Pakete dem Netzwerktyp „Nicht-Internet“ zugeordnet. Weitere Informationen zur Verbindung mit Google APIs und ‑Diensten finden Sie unter Nicht internetbasierter Netzwerktyp.

Wenn die Pakete über eine statische Route weitergeleitet werden, die das Standard-Internetgateway als nächsten Hop verwendet, gehören alle Pakete, die von den VM-Netzwerkschnittstellen an die folgenden Ziele gesendet werden, zum Internettyp:

  • Ein externes IP-Adressziel außerhalb des Google-Netzwerks.
  • Eine regionale externe IPv4-Zieladresse einer VM-Netzwerkschnittstelle, einer Weiterleitungsregel eines regionalen externen Load Balancers oder einer Weiterleitungsregel für die externe Protokollweiterleitung.
  • Eine regionale externe IPv6-Zieladresse einer VM-Netzwerkschnittstelle, einer Weiterleitungsregel eines regionalen externen Load Balancers oder einer Weiterleitungsregel für die externe Protokollweiterleitung.
  • Ein globales externes IPv4- und IPv6-Adressziel einer Weiterleitungsregel eines globalen externen Load-Balancers.

Pakete, die von den VM-Netzwerkschnittstellen an Cloud VPN- und Cloud NAT-Gateways gesendet werden, gehören zum Typ „Internet“:

  • Ausgehende Pakete, die von einer Netzwerkschnittstelle einer VM mit VPN-Software an die regionale externe IPv4-Adresse eines Cloud VPN-Gateways gesendet werden, gehören zum Internettraffic.
  • Ausgehende Pakete, die von einem Cloud VPN-Gateway an ein anderes Cloud VPN-Gateway gesendet werden, gehören zu keinem Netzwerktyp, 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, als zum Internettraffic gehörend betrachtet.

Wenn VPC-Netzwerke über VPC Network Peering verbunden sind oder VPC-Netzwerke als VPC-Spokes am selben Network Connectivity Center-Hub teilnehmen, können IPv6-Subnetzrouten die Verbindung zu regionalen externen IPv6-Adressenzielen von VM-Netzwerkschnittstellen, regionalen externen Load-Balancer-Weiterleitungsregeln und externen Protokollweiterleitungsregeln ermöglichen. Wenn die Verbindung zu diesen regionalen externen IPv6-Zieladressen über eine Subnetzroute erfolgt, gehören die Ziele stattdessen zum Netzwerktyp „Nicht-Internet“.

Nicht internetbasierter Netzwerktyp

Der Netzwerktyp non-internet (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 Regel für eingehenden Traffic die Quelle vom Typ „Nicht-Internet“ und mindestens einen weiteren Quellparameter an, mit Ausnahme einer Threat Intelligence-Listenquelle oder einer Geolocation-Quelle. Pakete entsprechen der Regel für eingehenden Traffic, wenn sie mindestens einem der anderen Quellparameter entsprechen und dem Quellparameter vom Typ „Nicht-Internet“.

  • Geben Sie für eine Ausgangsregel das Ziel vom Typ „Nicht-Internet“ und mindestens einen weiteren Zielparameter an. Pakete entsprechen der Regel für ausgehenden Traffic, wenn sie mindestens einem der anderen Zielparameter entsprechen und dem Zielparameter vom Typ „Nicht-Internet“.

Im weiteren Verlauf dieses Abschnitts werden die Kriterien beschrieben, anhand derer Cloud NGFW ermittelt, ob ein Paket zum Netzwerktyp „Nicht-Internet“ gehört.

Nicht internetbasierter Netzwerktyp für eingehende Pakete

Pakete für eingehenden Traffic, die über nächste Hops innerhalb eines VPC-Netzwerk oder von Google APIs und ‑Diensten an eine VM-Netzwerkschnittstelle weitergeleitet werden, gehören zum Netzwerktyp „Nicht-Internet“.

Pakete werden in den folgenden Szenarien über nächste Hops innerhalb eines VPC-Netzwerk oder von Google APIs und Google-Diensten weitergeleitet:

  • Das Paketziel entspricht einem der folgenden Werte:

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

  • Die Paketquelle entspricht einer der folgenden:

Nicht-Internet-Netzwerktyp für ausgehende Pakete

Ausgehende Pakete, die entweder von den VM-Netzwerkschnittstellen gesendet und in einem VPC-Netzwerk weitergeleitet werden oder an Google APIs und Google-Dienste gesendet werden, gehören zum Netzwerktyp „Nicht-Internet“.

Pakete werden in den folgenden Szenarien über nächste Hops innerhalb eines VPC-Netzwerk oder an Google APIs und Google-Dienste weitergeleitet:

VPC-Netzwerktyp

Der Typ VPC-Netzwerke (VPC_NETWORKS) kann nur als Teil einer Quellkombination einer Ingress-Regel verwendet werden. Sie können den VPC-Netzwerktyp nicht als Teil einer Zielkombination einer Egress-Regel verwenden.

Wenn Sie den Typ „VPC-Netzwerke“ als Teil einer Quellkombination einer Ingress-Regel verwenden möchten, gehen Sie so vor:

  1. Sie müssen eine Liste mit Quell-VPC-Netzwerken angeben:

    • Die Liste der Quellnetzwerke muss mindestens ein VPC-Netzwerk enthalten. Sie können der Quellnetzwerkliste 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 der vollständigen URL-Kennung hinzufügen.
    • VPC-Netzwerke, die Sie der Quellnetzwerkliste 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 Quellnetzwerkliste hinzugefügt wurde, bleibt der Verweis auf das gelöschte Netzwerk in der Liste. Cloud NGFW ignoriert gelöschte VPC-Netzwerke, wenn eine Ingress-Regel erzwungen wird. Wenn alle VPC-Netzwerke in der Quellnetzwerkliste gelöscht werden, sind Regeln für eingehenden Traffic, die auf der Liste basieren, wirkungslos, da sie mit keinen Paketen übereinstimmen.

  2. Sie müssen mindestens einen weiteren Quellparameter angeben, mit Ausnahme einer Quelle für Threat Intelligence-Listen oder einer Quelle für geografische Daten.

Ein Paket entspricht einer Regel für eingehenden Traffic, die den VPC-Netzwerktyp in ihrer Quellkombination verwendet, wenn alle der folgenden Bedingungen erfüllt sind:

  • Das Paket entspricht mindestens einem der anderen Quellparameter.

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

  • Das Quell-VPC-Netzwerk und das VPC-Netzwerk, für das die Firewallrichtlinie mit der Ingress-Regel gilt, sind dasselbe VPC-Netzwerk oder sind entweder über VPC-Netzwerk-Peering oder als VPC-Spokes in 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

Intra-VPC-Netzwerktyp

Der Netzwerktyp intra-VPC (INTRA_VPC) kann nur als Teil einer Quellkombination einer Regel für eingehenden Traffic verwendet werden. Sie können den VPC-internen Netzwerktyp nicht als Teil einer Zielkombination einer Egress-Regel verwenden.

Wenn Sie den Typ „Intra-VPC“ als Teil einer Quellkombination einer Regel für eingehenden Traffic verwenden möchten, müssen Sie mindestens einen anderen Quellparameter angeben, mit Ausnahme einer Threat Intelligence-Listenquelle oder einer geografischen Quelle.

Ein Paket entspricht einer Regel für eingehenden Traffic, die den Typ „intra-VPC“ in ihrer Quellkombination verwendet, wenn alle folgenden Bedingungen erfüllt sind:

  • Das Paket entspricht mindestens einem der anderen Quellparameter.

  • Das Paket wird von einer Ressource im VPC-Netzwerk gesendet, auf das die Firewallrichtlinie mit der Regel für eingehenden Traffic 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 Cloudverwendete 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 geringer 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 Cloudverwendeten 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 Zulassungs-Firewallregel: 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 Ablehnungs-Firewallregel: 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

Objekte mit vollqualifizierten Domainnamen (FQDN) enthalten Domainnamen, die Sie im Domainnamenformat angeben. Sie können FQDN-Objekte als Quellen für Regeln für eingehenden Traffic oder als Ziele für Regeln für ausgehenden Traffic in einer hierarchischen Firewallrichtlinie, einer globalen Netzwerk-Firewallrichtlinie oder einer regionalen Netzwerk-Firewallrichtlinie verwenden.

Sie können FQDNs mit anderen Parametern kombinieren. Weitere Informationen zu Kombinationen von Quellparametern in Regeln für eingehenden Traffic finden Sie unter Quellen für Regeln für eingehenden Traffic. Weitere Informationen zu Kombinationen von Zielparametern in Regeln für ausgehenden Traffic finden Sie unter Ziele für Regeln für ausgehenden Traffic.

FQDN-Objekte unterstützen Cloud DNS-Antwortrichtlinien, verwaltete private Zonen mit VPC-Netzwerkbereich, interne Compute Engine-DNS-Namen und öffentliche DNS-Zonen. Diese Unterstützung gilt, solange das VPC-Netzwerk keine Serverrichtlinie für ausgehenden Traffic hat, die einen alternativen Nameserver angibt. Weitere Informationen finden Sie unter Reihenfolge der VPC-Netzwerkauflösung.

FQDN-Objekte IP-Adressen zuordnen

Cloud NGFW löst FQDN-Objekte regelmäßig in IP-Adressen auf. Cloud NGFW folgt der Reihenfolge der VPC-Namensauflösung von Cloud DNS im VPC-Netzwerk, das die Ziele der Firewallregel enthält.

Cloud NGFW verwendet das folgende Verhalten für die Auflösung von IP-Adressen:

  • CNAME-Chasing unterstützen: Cloud NGFW verwendet CNAME-Chasing von Cloud DNS, wenn die Antwort auf eine FQDN-Objektanfrage ein CNAME-Eintrag ist.

  • IP-Adressen für das Programm Cloud NGFW verwendet die aufgelösten IP-Adressen, wenn die Firewallregeln programmiert werden, in denen FQDN-Objekte verwendet werden. Jedes FQDN-Objekt kann maximal 32 IPv4-Adressen und 32 IPv6-Adressen zugeordnet werden.

    Wenn die DNS-Antwort für eine FQDN-Objektanfrage in mehr als 32 IPv4-Adressen oder mehr als 32 IPv6-Adressen aufgelöst wird, beschränkt Cloud NGFW die programmierten IP-Adressen in den Firewallregeln auf die ersten 32 IPv4-Adressen und die ersten 32 IPv6-Adressen.

  • FQDN-Objekte ignorieren: Wenn Cloud NGFW ein FQDN-Objekt nicht in eine IP-Adresse auflösen kann, wird das FQDN-Objekt ignoriert. In den folgenden Situationen ignoriert Cloud NGFW ein FQDN-Objekt:

    • Wenn NXDOMAIN Antworten eingehen. NXDOMAIN-Antworten sind explizite Antworten von einem Nameserver, die angeben, dass kein DNS-Eintrag für die FQDN-Objektanfrage vorhanden ist.

    • Wenn in einer Antwort keine IP-Adresse vorhanden ist. In diesem Fall führt eine FQDN-Objektanfrage nicht zu einer Antwort mit einer IP-Adresse, die Cloud NGFW zum Programmieren einer Firewallregel verwenden kann.

    • Wenn der Cloud DNS-Server nicht erreichbar ist. Cloud NGFW ignoriert FQDN-Objekte, wenn ein DNS-Server, der die Antwort liefert, nicht erreichbar ist.

    Wenn ein FQDN-Objekt ignoriert wird, programmiert Cloud NGFW die verbleibenden Teile einer Firewallregel, sofern möglich.

Hinweise zu FQDN-Objekten

Beachten Sie Folgendes für FQDN-Objekte:

  1. Da FQDN-Objekte IP-Adressen zugeordnet und als solche programmiert werden, verwendet Cloud NGFW das folgende Verhalten, wenn zwei oder mehr FQDN-Objekte derselben IP-Adresse zugeordnet sind. Angenommen, Sie haben die folgenden zwei Firewallregeln, die für dasselbe Ziel gelten:

    • Regel 1: Priorität 100, eingehender Traffic von Quell-FQDN example1.com zulassen
    • Regel 2: Priorität 200, eingehender Traffic von Quell-FQDN example2.com zulassen

    Wenn sowohl example1.com als auch example2.com in dieselbe IP-Adresse aufgelöst werden, stimmen eingehende Pakete von example1.com und example2.com mit der ersten Firewall-Regel überein, da diese Regel eine höhere Priorität hat.

  2. Bei der Verwendung von FQDN-Objekten sind unter anderem folgende Aspekte zu berücksichtigen:

    • Eine DNS-Abfrage kann je nach Standort des anfragenden Clients eindeutige Antworten haben.

    • DNS-Antworten können sehr unterschiedlich ausfallen, wenn ein DNS-basiertes Load-Balancing-System beteiligt ist.

    • Eine DNS-Antwort kann mehr als 32 IPv4-Adressen enthalten.

    • Eine DNS-Antwort kann mehr als 32 IPv6-Adressen enthalten.

    Da Cloud NGFW in den oben genannten Situationen DNS-Abfragen in jeder Region ausführt, die die VM-Netzwerkschnittstelle enthält, für die die Firewallregel gilt, enthalten die programmierten IP-Adressen in Firewallregeln nicht alle möglichen IP-Adressen, die dem FQDN zugeordnet sind.

    Die meisten Google-Domainnamen, z. B. googleapis.com, unterliegen einer oder mehreren dieser Situationen. Verwenden Sie stattdessen IP-Adressen oder Adressgruppen.

  3. Verwenden Sie keine FQDN-Objekte mit Cloud DNS DNS64. Cloud NGFW programmiert keine Well-Known Prefix (WKP)-IPv6-Adressen, die von DNS64 verwendet werden.

    DNS64 und NAT64 sind für die gemeinsame Verwendung vorgesehen, um Verbindungen zu reinen IPv4-Servern von reinen IPv6-VM-Clients aus zu ermöglichen. Um diese Konnektivität bereitzustellen, synthetisiert ein DNS64-Anbieter eine AAAA-Antwort auf eine DNS-Abfrage, für die kein AAAA-Eintrag vorhanden ist. Die synthetische AAAA-Antwort codiert die IPv4-Adresse des Servers in den letzten vier Byte einer bekannten IPv6-Adresse (64:ff9b::/96). Wenn der reine IPv6-Client Pakete an die bekannte IPv6-Adresse sendet, extrahiert ein NAT64-Anbieter die IPv4-Serveradresse aus der bekannten IPv6-Adresse und öffnet eine IPv4-Verbindung zum reinen IPv4-Server.

    Wenn DNS64 verwendet wird, empfehlen wir, in Firewallregeln IP-Adressen oder Adressgruppen zu verwenden. Achten Sie darauf, dass Sie sowohl die IPv4-Adresse des Servers als auch die WKP-IPv6-Darstellung angeben.

  4. Vermeiden Sie die Verwendung von FQDN-Objekten mit DNS-A-Einträgen mit einer TTL (Time-to-Live) von weniger als 90 Sekunden.

Domainnamen formatieren

FQDN-Objekte müssen dem Standard-FQDN-Format entsprechen.Dieses Format ist in RFC 1035, RFC 1123 und RFC 4343 definiert. Cloud NGFW lehnt FQDN-Objekte ab, die einen Domainnamen enthalten, der nicht allen folgenden Formatierungsregeln entspricht:

  • Jedes FQDN-Objekt muss ein Domainname mit mindestens zwei Labels sein:

    • Jedes Label muss einem regulären Ausdruck entsprechen, der nur diese Zeichen enthält: [a-z]([-a-z0-9][a-z0-9])?..
    • Jedes Label muss zwischen 1 und 63 Zeichen lang sein.
    • Labels müssen mit einem Punkt (.) verkettet werden.

    Daher unterstützen FQDN-Objekte keine Platzhalterzeichen (*) oder Stammdomainnamen der obersten Ebene wie *.example.com. und .org, da diese nur ein Label enthalten.

  • FQDN-Objekte unterstützen internationalisierte Domainnamen (IDNs). Sie können einen IDN entweder im Unicode- oder im Punycode-Format angeben. Berücksichtige Folgendes:

    • Wenn Sie einen IDN im Unicode-Format angeben, wird dieser von Cloud NGFW vor der Verarbeitung in das Punycode-Format formatiert.

    • Mit dem IDN-Konverter können Sie die Punycode-Darstellung einer IDN erstellen.

    • Die Zeichenbeschränkung von 1 bis 63 pro Label gilt für IDNs nach der Konvertierung in das Punycode-Format.

  • Die codierte Länge eines vollqualifizierten Domainnamens (FQDN) darf 255 Byte (Oktett) nicht überschreiten.

Cloud NGFW unterstützt keine entsprechenden Domainnamen in derselben Firewallregel. Wenn sich die beiden Domainnamen (oder Punycode-Darstellungen von IDNs) beispielsweise höchstens durch einen abschließenden Punkt (.) unterscheiden, werden sie von Cloud NGFW als gleichwertig betrachtet.

Nächste Schritte