VPC-Firewallregeln

VPC-Firewallregeln (Virtual Private Cloud) gelten für ein bestimmtes Projekt und Netzwerk. Wenn Sie Firewallregeln auf mehrere VPC-Netzwerke in einer Organisation anwenden möchten, lesen Sie die Informationen unter Firewallrichtlinien und ‑regeln. Im weiteren Verlauf dieser Seite werden nur VPC-Firewallregeln behandelt.

Mit VPC Firewallregeln können Sie Verbindungen zu oder von VM-Instanzen in Ihrem VPC-Netzwerk zulassen oder ablehnen. Aktivierte VCP-Firewallregeln werden immer erzwungen. Sie schützen Ihre Instanzen unabhängig von ihrer Konfiguration und ihrem Betriebssystem, selbst wenn sie nicht gestartet wurden.

Jedes VPC-Netzwerk wirkt wie eine verteilte Firewall. Die Firewallregeln werden auf Netzwerkebene definiert, die Verbindungen aber pro Instanz zugelassen oder abgelehnt. Die VPC-Firewallregeln werden dabei nicht nur zwischen Ihren Instanzen und anderen Netzwerken angewendet, sondern auch zwischen einzelnen Instanzen innerhalb eines Netzwerks.

Weitere Informationen zu Firewalls finden Sie unter Firewall.

Best Practices für Firewallregeln

Beachten Sie beim Entwerfen und Bewerten Ihrer Firewallregeln die folgenden Best Practices:

  • Implementieren Sie die Prinzipien der geringsten Berechtigung. Blockieren Sie standardmäßig den gesamten Traffic und lassen Sie nur den erforderlichen Traffic zu. Dazu gehört auch, die Regel auf die benötigten Protokolle und Ports zu beschränken.
  • Verwenden Sie hierarchische Firewallrichtlinienregeln, um Traffic zu blockieren, der auf Organisations- oder Ordnerebene nie zugelassen werden sollte.
  • Beschränken Sie für "allow"-Regeln die Regeln auf bestimmte VMs, indem Sie das Dienstkonto der VMs angeben.
  • Wenn Sie Regeln auf der Grundlage von IP-Adressen erstellen müssen, versuchen Sie, die Anzahl der Regeln zu minimieren. Es ist einfacher, eine Regel zu verfolgen, die Traffic zu einem Bereich von 16 VMs zulässt, als 16 separate Regeln zu verfolgen.
  • Verwenden Sie Firewallrichtlinien, um Firewallregeln für eine vereinfachte Konfiguration und Bereitstellung zu gruppieren. Firewallrichtlinienregeln bieten mehrere Regelkomponenten, die eine detaillierte Traffic-Steuerung ermöglichen:
  • Aktivieren Sie das Logging von VPC-Firewallregeln und prüfen Sie mithilfe von Firewall Insights, ob Firewallregeln korrekt verwendet werden. Das Logging von VPC-Firewallregeln kann Kosten verursachen. Daher können Sie sie selektiv verwenden.

Firewallregeln in Google Cloud

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

VPC-Firewallregeln werden mithilfe derGoogle Cloud console, der Google Cloud CLI und der REST API erstellt oder geändert. Beim Erstellen oder Ändern einer Firewallregel geben Sie mit dem Zielparameter der Regel die Instanzen an, auf die sie angewendet werden soll. Beispiele für Firewallregeln finden Sie unter Weitere Konfigurationsbeispiele.

Neben den von Ihnen erstellten Firewallregeln bietet Google Cloud noch weitere Regeln,die eingehende (ingress) oder ausgehende (egress) Verbindungen beeinflussen können:

  • Google Cloud blockiert oder begrenzt einen bestimmten Traffic. Weitere Informationen finden Sie unter Blockierter und eingeschränkter Traffic.

  • Google Cloud lässt die Kommunikation zwischen einer VM-Instanz und ihrem entsprechenden Metadatenserver unter 169.254.169.254 immer zu. Weitere Informationen finden Sie unter immer erlaubter Traffic.

  • VPC-Firewallregeln werden zusammen mit Regeln in Firewallrichtlinien gemäß dem Auswertungsprozess für Firewallregeln ausgewertet. Als letzten Schritt erzwingt Cloud NGFW eine implizite Aktion, wenn keine explizite Aktion auf den Traffic angewendet wird.

  • Das Standardnetzwerk „default“ verfügt bereits über vorkonfigurierte Firewallregeln, die Sie löschen oder bearbeiten können.

Spezifikationen

VPC-Firewallregeln haben folgende Eigenschaften:

  • Jede Firewallregel gilt entweder für eingehende (ingress) oder für ausgehende Verbindungen (egress), jedoch nicht für beide Richtungen. Weitere Informationen finden Sie unter Verbindungsrichtung.

  • Firewallregeln unterstützen IPv4-Verbindungen. IPv6-Verbindungen werden auch in VPC-Netzwerken unterstützt, für die IPv6 aktiviert ist. Wenn Sie eine Quelle oder ein Ziel für eine Regel für eingehenden oder ausgehenden Traffic in Form einer Adresse angeben, können Sie IPv4- oder IPv6-Adressen oder -Blöcke in CIDR-Notation angeben.

  • Jede Firewallregel kann entweder IPv4- oder IPv6-Bereiche enthalten, jedoch nicht beides.

  • Die Aktion jeder Firewallregel ist allow oder deny. Die Regel gilt für Verbindungen, solange ihre Anwendung erzwungen wird. Sie können eine Regel beispielsweise zu Fehlerbehebungszwecken deaktivieren.

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

  • VPC-Firewallregeln sind zustandsorientiert:

    • Wenn eine Verbindung durch die Firewall in beide Richtungen zulässig ist, ist auch der mit dieser Verbindung übereinstimmende Traffic zulässig. Sie können eine Firewallregel nicht so konfigurieren, dass der zugehörige Antworttraffic abgelehnt wird.
    • Der zurückgegebene Traffic muss mit dem 5-Tupel (Quell-IP, Ziel-IP, Quellport, Zielport, Protokoll) des akzeptierten Anfragetraffics übereinstimmen, wobei die Quell- und Zieladressen sowie die Quell- und Zielports jedoch umgekehrt sind.
    • Google Cloud ordnet eingehende Pakete mithilfe einer Tabelle zum Tracking der Verbindung den entsprechenden ausgehenden Paketen zu. IPv4-Verbindungen unterstützen die Protokolle TCP, UDP, SCTP und ICMP. IPv6-Verbindungen unterstützen die Protokolle TCP, UDP, SCTP und ICMPv6.
    • Google Cloud implementiert Verbindungs-Tracking unabhängig davon, ob das Protokoll Verbindungen unterstützt. Wird eine Verbindung zwischen einer Quelle und einem Ziel (für eine Eingangsregel) oder zwischen einem Ziel und einem Bestimmungsort (für eine Ausgangsregel) zugelassen, ist der gesamte Antworttraffic zulässig, solange der Nachverfolgungsstatus der Firewall für die Verbindung aktiv ist. Der Nachverfolgungsstatus einer Firewallregel gilt als aktiv, wenn alle 10 Minuten mindestens ein Paket gesendet wird.
    • Wenn eine fragmentierte Verbindung durch die Firewall zugelassen wird, verwendetGoogle Cloud die Verbindungsverfolgung, um nur das erste Fragment des Rückgabeverkehrs zuzulassen. Um nachfolgende Rückgabefragmente zuzulassen, müssen Sie eine Firewallregel hinzufügen.
    • ICMP-Antworttraffic, wie z. B. „ICMP TYPE 3, DESTINATION UNREACHABLE“, der als Antwort auf eine zulässige TCP/UDP-Verbindung generiert wird, wird von der Firewall zugelassen. Dieses Verhalten entspricht RFC 792.

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

  • Die maximale Anzahl nachverfolgter Verbindungen in der Firewallregeltabelle hängt von der Anzahl der zustandsorientierten Verbindungen ab, die vom Maschinentyp der Instanz unterstützt werden: Wenn die maximale Anzahl nachverfolgter Verbindungen überschritten wird, wird das Tracking für die Verbindungen mit dem längsten Intervall der Inaktivität beendet, damit neue Verbindungen nachverfolgt werden können.

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

Implizierte Aktionen

Wenn keine VPC-Firewallregel auf ein Ziel angewendet wird, kann der Prozess zur Auswertung von Firewallregeln den letzten Schritt erreichen. In diesem Schritt verwendet Cloud NGFW eine implizite Aktion. Die implizierte Aktion hängt von der Richtung des Traffics und dem Zielressourcentyp ab.

Weitere Informationen finden Sie unter Prozess zur Auswertung von Firewallregeln.

Vorkonfigurierte Regeln im Standardnetzwerk "default"

Das Standardnetzwerk "default" enthält vorkonfigurierte Firewallregeln, die eingehende Verbindungen für Instanzen zulassen. Diese Regeln können nach Bedarf gelöscht oder geändert werden:

Regelname Richtung Priorität Quellbereiche Aktion Protokolle und Ports Beschreibung
default-allow-internal ingress 65534 10.128.0.0/9 allow tcp:0-65535
udp:0-65535
icmp 		Lässt eingehende Verbindungen von anderen Instanzen innerhalb desselben VPC-Netzwerks zu VM-Instanzen zu.
default-allow-ssh ingress 65534 0.0.0.0/0 allow tcp:22 Ermöglicht die Verbindung zu Instanzen mit Tools wie ssh, scp oder sftp.
default-allow-rdp ingress 65534 0.0.0.0/0 allow tcp:3389 Ermöglicht die Verbindung zu Instanzen mit dem Microsoft Remote Desktop Protocol (RDP).
default-allow-icmp ingress 65534 0.0.0.0/0 allow icmp Ermöglicht die Verwendung von Tools wie ping.

Sie können ähnliche Firewallregeln für andere Netzwerke als das Standardnetzwerk erstellen. Weitere Informationen finden Sie unter Firewallregeln für gängige Anwendungsfälle konfigurieren.

Gesperrter und eingeschränkter Traffic

Getrennt von VPC-Firewallregeln und hierarchischen Firewallrichtlinien blockiert oder begrenzt Google Cloud bestimmten Traffic,wie in der folgenden Tabelle beschrieben.

Traffictyp Details
Paketrate und Bandbreite

Gilt für:

  • Alle ausgehenden Pakete
  • Alle eingehenden Pakete
 Google Cloud berücksichtigt die Bandbreite pro VM-Instanz für jede Netzwerkschnittstelle (NIC) oder IP-Adresse. Der Maschinentyp einer VM definiert die maximal mögliche Rate für ausgehenden Traffic. Diese kann jedoch nur in bestimmten Situationen erreicht werden.

Weitere Informationen finden Sie in der Compute Engine-Dokumentation unter Netzwerkbandbreite.
DHCP-Angebote und -Bestätigungen

Gilt für:

  • Eingehende Pakete an UDP-Port 68 (DHCPv4)
  • Eingehende Pakete an UDP-Port 546 (DHCPv6)
 Google Cloud blockiert eingehende DHCP-Angebote und Bestätigungen aus allen Quellen mit Ausnahme von DHCP-Paketen vom Metadatenserver.
Von Google Cloud externen IP-Adressen unterstützte Protokolle

Gilt für:

  • Eingehende Pakete an externe IP-Adressen

Externe IPv4- und IPv6-Adressen akzeptieren nur TCP-, UDP-, ICMP-, IPIP-, AH-, ESP-, SCTP- und GRE-Pakete. Für Ressourcen, die externe IP-Adressen verwenden, gelten zusätzliche Protokolleinschränkungen:
SMTP-Traffic (Port 25)

Gilt für:

  • Ausgehende Pakete zu externen IP-Adressen an TCP-Port 25

Um Spam zu verhindern, blockiert Google Cloud standardmäßig ausgehende Pakete, die an den TCP-Zielport 25 einer externen IP-Adresse gesendet werden (einschließlich einer externen IP-Adresse einer anderen Google Cloud Ressource). Google Cloud entfernt diese Blockierung automatisch, sobald festgestellt wird, dass das Risiko, dass über ein Projekt große Mengen an E‑Mails über unverschlüsselte Verbindungen gesendet werden, gering ist. Google Cloud schließt SMTP-Traffic über TLS auf Port 465 oder 587 von dieser Blockierung aus. Wenn Sie herausfinden möchten, ob dieser Traffic in Ihrem Projekt zulässig ist, rufen Sie in der Google Cloud Console die Seite VPC-Netzwerke oder die Seite Firewallrichtlinien auf. Auf beiden Seiten wird in einem Banner angezeigt, ob dieser Traffic in Ihrem Projekt zulässig ist. Weitere Informationen erhalten Sie von einem Google Cloud -Vertriebsspezialisten.

Dieser Block gilt nicht für ausgehende Pakete, die an den TCP-Zielport 25 einer Internen IP-Adresse gesendet werden, einschließlich einer privat verwendeten öffentlichen IP-Adresse in einem VPC-Netzwerk oder einem lokalen Netzwerk.

Wenn externer SMTP-Ausgang auf Port 25 in Ihrem Projekt zulässig ist und Sie diese Art von Traffic senden möchten, müssen die folgenden zusätzlichen Bedingungen erfüllt sein:

  • Firewallregeln für ausgehenden Traffic im VPC-Netzwerk und hierarchische Firewallrichtlinien, die für das VPC-Netzwerk gelten, müssen ausgehenden Traffic zur externen IP-Adresse über TCP-Port 25 zulassen. Die implizierten Regeln zum Zulassen von ausgehendem Traffic erfüllen diese Anforderung, da sie den ausgehenden Traffic zu (und feststehende eingehende Antworten von) jeder IP-Adresse zulassen.
  • Die anwendbare Route für das Ziel muss den nächsten Hop des Standard-Internetgateways verwenden. Die vom System generierten Standardrouten erfüllen diese Anforderung.
  • Die Instanz, die Pakete an die externe IP-Adresse sendet, muss die Anforderungen für den Internetzugriff erfüllen.

Sie können ausgehenden SMTP-Ausgang verhindern. Erstellen Sie dazu VPC-Firewallregeln für ausgehenden Traffic oder hierarchische Firewallrichtlinien.

Permanent zugelassener Traffic

Für VM-Instanzen gelten VPC-Firewallregeln und hierarchische Firewallrichtlinien nicht für Folgendes:

  • Pakete, die an den Google Cloud -Metadatenserver gesendet und von diesem empfangen werden

  • Pakete, die an eine IP-Adresse gesendet werden, die einer der Netzwerkschnittstellen (NICs) der Instanz zugewiesen ist, bei denen Pakete innerhalb der VM selbst verbleiben. IP-Adressen, die der NIC einer Instanz zugewiesen sind, sind:

    • Die primäre interne IPv4-Adresse der Netzwerkkarte
    • Jede interne IPv4-Adresse aus einem Alias-IP-Bereich der NIC
    • Beliebige von den der NIC zugewiesenen IPv6-Adressen, wenn IPv6 im Subnetz konfiguriert ist
    • Eine interne oder externe IPv4-Adresse, die einer Weiterleitungsregel für das Load-Balancing oder die Protokollweiterleitung zugeordnet ist, wenn die Instanz ein Backend für den Load-Balancer oder eine Zielinstanz für die Protokollweiterleitung ist
    • Loopback-Adressen
    • Adressen, die als Teil der Netzwerk-Overlay-Software konfiguriert wurden, die Sie in der Instanz selbst ausführen

Google Cloud Metadatenserver

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

Produktinteraktionen

In den folgenden Abschnitten wird beschrieben, wie Firewallregeln und hierarchische Firewallrichtlinien mit anderen Google Cloud -Produkten interagieren.

Firewallregeln und Passthrough LoadBalancer

VPC-Firewallregeln und hierarchische Firewallrichtlinien steuern, welche Protokolle und Ports der Weiterleitungsregel auf die Back-Ends des Passthrough Load Balancers zugreifen dürfen. Weitere Informationen finden Sie unter:

Firewallregeln und Proxy-Load-Balancer

Für externe Application Load Balancer, interne Application Load Balancer, interne Proxy Network Load Balancer und externe Proxy Network Load Balancer steuern VPC-Firewallregeln und hierarchische Firewallrichtlinien nicht, welche Protokolle und Ports von der IP-Adresse der Weiterleitungsregel des Proxy Load Balancers akzeptiert werden. Die Weiterleitungsregel allein bestimmt, welche Protokolle und Ports vom Proxy-Load-Balancer akzeptiert werden.

VPC-Firewallregeln und hierarchische Firewallrichtlinien steuern die Kommunikation dieser Proxy-Load-Balancer mit ihren Back-Ends. Weitere Informationen finden Sie unter:

Firewallregeln und Cloud VPN

Firewallregeln und hierarchische Firewallrichtlinien bestimmen nicht, welche Protokolle und Ports vom Cloud VPN-Gateway akzeptiert werden.

Cloud VPN-Gateways akzeptieren nur Pakete für die in den Cloud VPN-Spezifikationen beschriebenen Protokolle und Ports.

Firewallregeln und GKE

Google Kubernetes Engine erstellt und verwaltet Firewallregeln automatisch, wenn Sie einen Cluster oder Ressourcen im Cluster erstellen (einschließlich Dienste und Ingress-Instanzen). Weitere Informationen finden Sie in der Google Kubernetes Engine-Dokumentation unter Automatisch erstellte Firewallregeln.

Firewallregeln und AI Hypercomputer

Sie können VPC-Firewallregeln erstellen, wenn Sie die VPC-Netzwerke erstellen, die zum Erstellen von VMs in AI Hypercomputer erforderlich sind. Mit den Firewallregeln können Sie die Protokolle und Ports angeben, die für Ihre VPC-Netzwerke zulässig sind. Weitere Informationen finden Sie in der Übersicht zum AI Hypercomputer.

Komponenten von Firewallregeln

Jede Firewallregel besteht aus den folgenden Konfigurationskomponenten:

  • Eine Richtung aus der Perspektive des Ziels. Die Richtung kann entweder eingehend oder ausgehend sein.

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

  • Eine Aktion bei Übereinstimmung, entweder allow oder deny, die ausschlaggebend dafür ist, ob die Regel Verbindungen zulässt oder blockiert.

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

  • Ein Ziel, mit dem die Instanzen definiert werden, auf die die Regel angewendet wird, einschließlich der GKE-Cluster und der Instanzen in der flexiblen App Engine-Umgebung.

  • Ein Quell- oder Zielfilter für Paketeigenschaften.

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

  • Eine boolesche Logoption, die Verbindungen, die der Regel entsprechen, in Cloud Logging protokolliert.

Zusammenfassung der Komponenten

Eingangsregel (Ingress)
Priorität Aktion Erzwingung Zielparameter Quell- und Zielfilter Protokolle und Ports
Ganzzahl von 0 bis einschließlich 65535; Standard: 1000 allow oder deny enabled (Standard) oder disabled Gibt die Instanzen an, die Pakete empfangen.

Quellen für Regeln für eingehenden Traffic

Ziele für Regeln für eingehenden Traffic

Geben Sie ein Protokoll oder ein Protokoll und einen Zielport an.

Wenn nichts festgelegt ist, gilt die Regel für alle Protokolle und Zielports. Weitere Informationen finden Sie unter Protokolle und Ports.
Ausgangsregel (Egress)
Priorität Aktion Erzwingung Zielparameter Quell- und Zielfilter Protokolle und Ports
Ganzzahl von 0 bis einschließlich 65535; Standard: 1000 allow oder deny enabled (Standard) oder disabled Gibt die Instanzen an, die Pakete senden.

Quellen für Regeln für ausgehenden Traffic

Ziele für Regeln für ausgehenden Traffic

Geben Sie ein Protokoll oder ein Protokoll und einen Zielport an.

Wenn nichts festgelegt ist, gilt die Regel für alle Protokolle und Zielports. Weitere Informationen finden Sie unter Protokolle und Ports.

Traffic-Richtung

Sie können Firewallregeln erstellen, die für eingehenden oder ausgehenden Traffic gelten. Eine einzelne Regel kann nicht sowohl für eingehenden als auch für ausgehenden Traffic gelten. Sie können jedoch mehrere Regeln erstellen, um den eingehenden und ausgehenden Traffic zu definieren, den Sie durch die Firewall zulassen oder ablehnen.

  • Eingehender Traffic beschreibt Pakete, die in eine Netzwerkschnittstelle eines Ziels eintreten.

  • Ausgehender Traffic beschreibt Pakete, die eine Netzwerkschnittstelle eines Ziels verlassen.

  • Wenn Sie keine Richtung angeben,verwendet Google Cloud „ingress“.

Priorität

Die Priorität einer VPC-Firewallregel ähnelt der Priorität einer Regel in einer Firewallrichtlinie, mit den folgenden Unterschieden:

Funktion Firewallrichtlinien-Regel VPC-Firewallregel
Bereich 0 bis 2.147.483.547 0 bis 65.535
Standardpriorität (Zahl) Keine 1.000 (Standard)
Eindeutigkeit Muss innerhalb der Richtlinie eindeutig sein Kann für mehrere Regeln verwendet werden

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

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

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

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

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

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

  • Eine Regel für eingehenden Traffic aus den Quellen 0.0.0.0/0 (beliebige IPv4-Adresse), die für alle Ziele, alle Protokolle und alle Zielports gilt und eine deny-Aktion sowie die Priorität 1000 hat.

  • Eine Regel für eingehenden Traffic an TCP 80 aus den Quellen 0.0.0.0/0 (beliebige IPv4-Adresse), die für bestimmte Ziele mit dem Netzwerk-Tag webserver gilt und eine allow-Aktion hat.

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

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

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

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

Das vorherige Beispiel zeigt, wie Sie mithilfe von Prioritäten selektive allow-Regeln und globale deny-Regeln als Best Practice im Sicherheitsbereich nach dem Prinzip der geringsten Berechtigung implementieren können.

Aktion bei Übereinstimmung

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

  • Die Aktion allow lässt Verbindungen zu, deren Komponenten den anderen angegebenen Komponenten entsprechen.

  • Die Aktion deny blockiert Verbindungen, deren Komponenten den anderen angegebenen Komponenten entsprechen.

Erzwingung

Sie können wählen, ob eine Firewallregel erzwungen werden soll. Legen Sie dazu deren Zustand auf enabled oder disabled 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, lautet die Firewallregel automatisch enabled.

Anwendungsfälle

Das Deaktivieren und Aktivieren ist für die Fehlerbehebung und Wartung hilfreich. Sie können die Erzwingung einer Firewallregel in den folgenden Situationen ändern:

  • Für die Fehlerbehebung: In Verbindung mit dem Logging von VPC-Firewallregeln können Sie eine Firewallregel vorübergehend deaktivieren, um festzustellen, ob die Regel für das Blockieren oder Zulassen von Traffic verantwortlich ist. Dies ist dann nützlich, wenn mehrere Firewallregeln für denselben Traffic gelten. Das Deaktivieren und Aktivieren von Regeln ist nützlicher als das Löschen und Neuerstellen von Regeln, da keine der anderen Komponenten der Regel verloren geht.

  • Für die Wartung: Durch die Deaktivierung von Firewallregeln können regelmäßige Wartungen vereinfacht werden. Sie können beispielsweise eine Firewallregel für eingehenden Traffic aktivieren, die den SSH-Zugriff nur dann zulässt, wenn Sie Wartungen mit SSH ausführen müssen. Wenn Sie keine Wartung ausführen, können Sie die Regel deaktivieren.

Auswirkungen auf vorhandenen Traffic

Wenn Sie den Erzwingungsstatus einer Firewallregel ändern, eine neue enforced-Regel erstellen oder Firewallregeln ändern, um zuvor zugelassenen Traffic abzulehnen, erzwingt Cloud NGFW diese Änderung nur für neue Verbindungen. Vorhandene Verbindungen bleiben bestehen und der zugehörige Traffic ist davon nicht betroffen.

Protokolle und Ports

Durch Angabe von Protokollen oder Protokollen und Zielports lässt sich der Umfang einer Firewallregel einschränken. Sie können ein Protokoll oder eine Kombination aus Protokollen und ihren Zielports festlegen. Wenn Sie weder Protokolle noch Ports angeben, gilt die Firewallregel für den gesamten Traffic mit jedem Protokoll und an allen Ports. Regeln für Quellports werden nicht unterstützt.

Nicht alle Protokolle unterstützen Ports. Beispielsweise gibt es Ports für TCP und UDP, nicht jedoch für ICMP. Das ICMP-Protokoll unterstützt verschiedene ICMP-Typen. Diese sind jedoch keine Ports und können nicht in einer Firewallregel angegeben werden.

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

Viele Protokolle verwenden bei IPv4 und IPv6 denselben Namen und dieselbe Nummer, einige Protokolle wie ICMP jedoch nicht.

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

In der folgenden Tabelle finden Sie eine Zusammenfassung der gültigen Kombinationen von Protokollen und Zielports für Google Cloud -Firewallregeln.

Spezifikation Beispiel Erklärung
Weder Protokoll noch Port – Wenn Sie kein Protokoll angeben, gilt die Firewallregel für alle Protokolle und die zugehörigen Zielports.
Protokoll tcp Wenn Sie ein Protokoll ohne Portinformationen angeben, gilt die Firewallregel für dieses Protokoll und alle seine zugehörigen Ports.
Protokoll und einzelner Port tcp:80 Wenn Sie ein Protokoll und einen einzelnen Zielport angeben, gilt die Firewallregel für diesen Zielport des Protokolls.
Protokoll und Portbereich