GSP474

Übersicht

Traffic-Mirroring ist eine wichtige Funktion in Google Cloud-Netzwerken für die Sicherheit und Netzwerkanalyse. Die Funktionsweise ähnelt der eines Netzwerk-Taps oder einer Span-Sitzung in herkömmlichen Netzwerken. Kurz gesagt: Bei der Paketspiegelung wird der Netzwerk-Traffic (ein- und ausgehend) von ausgewählten „gespiegelten Quellen“ erfasst, kopiert und an „Collectors“ weitergeleitet.

Zu bedenken ist allerdings, dass bei der Paketspiegelung die gesamte Nutzlast jedes Pakets erfasst und daher zusätzliche Bandbreite verbraucht wird. Da die Paketspiegelung nicht auf einem Stichprobenzeitraum basiert, kann sie für eine bessere Fehlerbehebung, hilfreichere Sicherheitslösungen und Analysen auf höherer Anwendungsebene verwendet werden.

Die Grundlage bildet eine „Paketspiegelungsrichtlinie“, die die folgenden Attribute enthält:

• Region
• VPC-Netzwerk(e)
• Gespiegelte Quelle(n)
• Collector (Ziel)
• Gespiegelter Traffic (Filter)

Diese wichtigen Punkte müssen ebenfalls berücksichtigt werden:

• Es kann nur TCP-, UDP- und ICMP-Traffic gespiegelt werden. Damit sollten jedoch die meisten Anwendungsfälle abgedeckt sein.
• „Gespiegelte Quellen“ und „Collectors“ müssen sich in DERSELBEN Region befinden, können aber in verschiedenen Zonen und sogar in verschiedenen VPCs sein, solange diese VPCs richtig verbunden sind.
• Es fallen zusätzliche Bandbreitengebühren an, insbesondere zwischen Zonen. Mit Filtern lässt sich der gespiegelte Traffic einschränken.

Ein Hauptanwendungsfall für die Paketspiegelung ist die Verwendung in einer IDS-Lösung (Intrusion Detection System). Für einige cloudbasierte IDS-Lösungen ist ein spezieller Dienst erforderlich, der auf jeder Quell-VM ausgeführt wird, oder eine virtuelle IDS-Appliance, die zwischen Netzwerkquelle und ‑ziel geschaltet wird. Beides hat erhebliche Auswirkungen. Die dienstbasierte Lösung ist zwar vollständig verteilt, aber das Gastbetriebssystem muss die Software unterstützen. Die Inline-Lösung kann zu einem Netzwerkengpass führen, da der gesamte Traffic über die IDS-Appliance geleitet werden muss. Mit der Inline-Lösung kann auch kein Ost-West-Traffic zwischen VMs in derselben VPC erfasst werden.

Für die Google Cloud-Paketspiegelung ist keine zusätzliche Software auf den VMs erforderlich. Sie ist vollständig auf allen gespiegelten virtuellen Maschinen verteilt. Das „Collector“-IDS wird mithilfe eines internen Network Load Balancers (ILB) außerhalb des Pfads platziert und empfängt sowohl Nord-Süd- als auch Ost-West-Traffic.

Beschreibung des Labs zur Paketspiegelung

An diesem Beispiel mit dem Open-Source-IDS Suricata wird demonstriert, wie die Paketspiegelung mit einem IDS eingesetzt werden kann.

• Eine einzelne VPC mit zwei Subnetzen (eines für gespiegelte Quellen und eines für den Collector)
• Zwei Webserver mit einer öffentlichen IP-Adresse
• Ein Collector-Server (IDS) OHNE öffentliche IP-Adresse (aus Sicherheitsgründen)
• Cloud NAT nach Bedarf für den Internetzugriff aktiviert
• Alle VMs aus Gründen der Einfachheit und Kostenersparnis in derselben Region und Zone erstellt

In diesem Lab erstellen Sie eine Google Cloud-Umgebung, konfigurieren den als „Collector“ fungierenden internen Load Balancer und die Paketspiegelungsrichtlinie und installieren und konfigurieren [Suricata] (https://suricata-ids.org/) auf einer virtuellen Instanz als IDS. Anschließend werden Netzwerktests durchgeführt, um die Konfiguration und Verwendung der Paketspiegelung mit dem Open-Source-IDS zu prüfen. Zur Vereinfachung der Demonstration werden ein deutlich abgespeckter Regelsatz und eine schlichte Suricata-Konfiguration verwendet.

Lernziele:

• Im Diagramm oben dargestellte Google Cloud-Netzwerkumgebung erstellen
• Mit gcloud-Befehlen zwei virtuelle Maschinen, die als WEBSERVER fungieren, erstellen
• Mit gcloud-Befehlen eine einzelne virtuelle Maschine als IDS erstellen
• Internen Load Balancer (ILB) erstellen, der als „Collector“ für die Paketspiegelung fungiert
• Open-Source-IDS (Suricata) auf der IDS-VM installieren und konfigurieren
• Einige grundlegende Regeln für IDS-Benachrichtigungen kennenlernen
• Paketspiegelungsrichtlinie erstellen
• Paketspiegelung testen, indem Netzwerkverkehr zum „gespiegelten“ Subnetz generiert wird
• IDS Suricata testen, indem Netzwerk-Traffic generiert wird, um ein IDS-Ereignis zu simulieren und das IDS-Logging zu prüfen

Einrichtung und Anforderungen

Vor dem Klick auf „Start Lab“ (Lab starten)

Lesen Sie diese Anleitung. Labs sind zeitlich begrenzt und können nicht pausiert werden. Der Timer beginnt zu laufen, wenn Sie auf Lab starten klicken, und zeigt Ihnen, wie lange Google Cloud-Ressourcen für das Lab verfügbar sind.

In diesem praxisorientierten Lab können Sie die Lab-Aktivitäten in einer echten Cloud-Umgebung durchführen – nicht in einer Simulations- oder Demo-Umgebung. Dazu erhalten Sie neue, temporäre Anmeldedaten, mit denen Sie für die Dauer des Labs auf Google Cloud zugreifen können.

Für dieses Lab benötigen Sie Folgendes:

• Einen Standardbrowser (empfohlen wird Chrome)

Hinweis: Nutzen Sie den privaten oder Inkognitomodus (empfohlen), um dieses Lab durchzuführen. So wird verhindert, dass es zu Konflikten zwischen Ihrem persönlichen Konto und dem Teilnehmerkonto kommt und zusätzliche Gebühren für Ihr persönliches Konto erhoben werden.

• Zeit für die Durchführung des Labs – denken Sie daran, dass Sie ein begonnenes Lab nicht unterbrechen können.

Hinweis: Verwenden Sie für dieses Lab nur das Teilnehmerkonto. Wenn Sie ein anderes Google Cloud-Konto verwenden, fallen dafür möglicherweise Kosten an.

Lab starten und bei der Google Cloud Console anmelden

1. Klicken Sie auf Lab starten. Wenn Sie für das Lab bezahlen müssen, wird ein Dialogfeld geöffnet, in dem Sie Ihre Zahlungsmethode auswählen können. Auf der linken Seite befindet sich der Bereich „Details zum Lab“ mit diesen Informationen:

   • Schaltfläche „Google Cloud Console öffnen“
   • Restzeit
   • Temporäre Anmeldedaten für das Lab
   • Ggf. weitere Informationen für dieses Lab

2. Klicken Sie auf Google Cloud Console öffnen (oder klicken Sie mit der rechten Maustaste und wählen Sie Link in Inkognitofenster öffnen aus, wenn Sie Chrome verwenden).

   Im Lab werden Ressourcen aktiviert. Anschließend wird ein weiterer Tab mit der Seite „Anmelden“ geöffnet.

   Tipp: Ordnen Sie die Tabs nebeneinander in separaten Fenstern an.

   Hinweis: Wird das Dialogfeld Konto auswählen angezeigt, klicken Sie auf Anderes Konto verwenden.

3. Kopieren Sie bei Bedarf den folgenden Nutzernamen und fügen Sie ihn in das Dialogfeld Anmelden ein.

   {{{user_0.username | "Username"}}}

   Sie finden den Nutzernamen auch im Bereich „Details zum Lab“.

4. Klicken Sie auf Weiter.

5. Kopieren Sie das folgende Passwort und fügen Sie es in das Dialogfeld Willkommen ein.

   {{{user_0.password | "Password"}}}

   Sie finden das Passwort auch im Bereich „Details zum Lab“.

6. Klicken Sie auf Weiter.

   Wichtig: Sie müssen die für das Lab bereitgestellten Anmeldedaten verwenden. Nutzen Sie nicht die Anmeldedaten Ihres Google Cloud-Kontos. Hinweis: Wenn Sie Ihr eigenes Google Cloud-Konto für dieses Lab nutzen, können zusätzliche Kosten anfallen.

7. Klicken Sie sich durch die nachfolgenden Seiten:

   • Akzeptieren Sie die Nutzungsbedingungen.
   • Fügen Sie keine Wiederherstellungsoptionen oder Zwei-Faktor-Authentifizierung hinzu (da dies nur ein temporäres Konto ist).
   • Melden Sie sich nicht für kostenlose Testversionen an.

Nach wenigen Augenblicken wird die Google Cloud Console in diesem Tab geöffnet.

Hinweis: Wenn Sie auf Google Cloud-Produkte und ‑Dienste zugreifen möchten, klicken Sie auf das Navigationsmenü oder geben Sie den Namen des Produkts oder Dienstes in das Feld Suchen ein.

Cloud Shell aktivieren

Cloud Shell ist eine virtuelle Maschine, auf der Entwicklertools installiert sind. Sie bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und läuft auf Google Cloud. Mit Cloud Shell erhalten Sie Befehlszeilenzugriff auf Ihre Google Cloud-Ressourcen.

1. Klicken Sie oben in der Google Cloud Console auf Cloud Shell aktivieren .

2. Klicken Sie sich durch die folgenden Fenster:

   • Fahren Sie mit dem Informationsfenster zu Cloud Shell fort.
   • Autorisieren Sie Cloud Shell, Ihre Anmeldedaten für Google Cloud API-Aufrufe zu verwenden.

Wenn eine Verbindung besteht, sind Sie bereits authentifiziert und das Projekt ist auf Project_ID, eingestellt. Die Ausgabe enthält eine Zeile, in der die Project_ID für diese Sitzung angegeben ist:

Ihr Cloud-Projekt in dieser Sitzung ist festgelegt als {{{project_0.project_id | "PROJECT_ID"}}}

gcloud ist das Befehlszeilentool für Google Cloud. Das Tool ist in Cloud Shell vorinstalliert und unterstützt die Tab-Vervollständigung.

3. (Optional) Sie können den aktiven Kontonamen mit diesem Befehl auflisten:

gcloud auth list

4. Klicken Sie auf Autorisieren.

Ausgabe:

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} Um das aktive Konto festzulegen, führen Sie diesen Befehl aus: $ gcloud config set account `ACCOUNT`

5. (Optional) Sie können die Projekt-ID mit diesem Befehl auflisten:

gcloud config list project

Ausgabe:

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} Hinweis: Die vollständige Dokumentation für gcloud finden Sie in Google Cloud in der Übersicht zur gcloud CLI.

Aufgabe 1: Netzwerk erstellen

In diesem Abschnitt erstellen Sie eine VPC und zwei Subnetze darin. Dazu verwenden Sie gcloud-Befehle in der Befehlszeile in Google Cloud Shell.

1. Führen Sie Folgendes aus, um ein virtuelles privates Netzwerk zu erstellen:

gcloud compute networks create dm-stamford \ --subnet-mode=custom

2. Fügen Sie der VPC ein Subnetz für gespiegelten Traffic in hinzu:

gcloud compute networks subnets create dm-stamford-{{{project_0.default_region | REGION}}} \ --range=172.21.0.0/24 \ --network=dm-stamford \ --region={{{project_0.default_region | REGION}}}

3. Fügen Sie der VPC ein Subnetz für den Collector in hinzu:

gcloud compute networks subnets create dm-stamford-{{{project_0.default_region | REGION}}}-ids \ --range=172.21.1.0/24 \ --network=dm-stamford \ --region={{{project_0.default_region | REGION}}}

Klicken Sie auf Fortschritt prüfen.

Netzwerk erstellen

Aufgabe 2: Firewallregeln und Cloud NAT erstellen

Für dieses Lab sind insgesamt drei Firewallregeln erforderlich.

• Regel 1 lässt den Standard-HTTP-Port (TCP 80) und das ICMP-Protokoll für alle VMs aus allen Quellen zu.
• Mit Regel 2 kann das IDS SÄMTLICHEN Traffic aus ALLEN Quellen empfangen. Achten Sie darauf, der IDS-VM in den späteren Abschnitten KEINE öffentliche IP-Adresse zuzuweisen.
• Regel 3 erlaubt den TCP-Port 22 im IP-Bereich des „Google Cloud IAP Proxy“ auf ALLEN VMs, sodass Sie über die Cloud Console per SSH auf die VMs zugreifen können.

Führen Sie die folgenden Befehle aus, um die Firewallregeln zu erstellen:

gcloud compute firewall-rules create fw-dm-stamford-allow-any-web \ --direction=INGRESS \ --priority=1000 \ --network=dm-stamford \ --action=ALLOW \ --rules=tcp:80,icmp \ --source-ranges=0.0.0.0/0 gcloud compute firewall-rules create fw-dm-stamford-ids-any-any \ --direction=INGRESS \ --priority=1000 \ --network=dm-stamford \ --action=ALLOW \ --rules=all \ --source-ranges=0.0.0.0/0 \ --target-tags=ids gcloud compute firewall-rules create fw-dm-stamford-iapproxy \ --direction=INGRESS \ --priority=1000 \ --network=dm-stamford \ --action=ALLOW \ --rules=tcp:22,icmp \ --source-ranges=35.235.240.0/20

Klicken Sie auf Fortschritt prüfen.

Cloud-Firewallregeln und Cloud NAT erstellen

Cloud Router erstellen

• Als Voraussetzung für Cloud NAT muss zuerst ein Cloud-Router in der jeweiligen Region konfiguriert werden:

gcloud compute routers create router-stamford-nat-{{{project_0.default_region | REGION}}} \ --region={{{project_0.default_region | REGION}}} \ --network=dm-stamford

Cloud NAT konfigurieren

• Damit VMs ohne öffentliche IP-Adresse auf das Internet zugreifen können, muss in der jeweiligen Region eine Cloud NAT erstellt werden:

gcloud compute routers nats create nat-gw-dm-stamford-{{{project_0.default_region | REGION}}} \ --router=router-stamford-nat-{{{project_0.default_region | REGION}}} \ --router-region={{{project_0.default_region | REGION}}} \ --auto-allocate-nat-external-ips \ --nat-all-subnet-ip-ranges

Die IDS-VM wird ohne öffentliche IP-Adresse erstellt, damit sie nicht über das Internet zugänglich ist. Für das Herunterladen von Updates und die Installation von Suricata-Paketen ist jedoch Internetzugriff erforderlich.

Klicken Sie auf Fortschritt prüfen.

Cloud-Router erstellen und Cloud NAT konfigurieren

Aufgabe 3: Virtuelle Maschinen erstellen

Instanzvorlage für einen Webserver erstellen

• Mit dieser Vorlage wird ein Ubuntu-Server in vorbereitet und ein einfacher Webdienst installiert:

gcloud compute instance-templates create template-dm-stamford-web-{{{project_0.default_region | REGION}}} \ --region={{{project_0.default_region | REGION}}} \ --network=dm-stamford \ --subnet=dm-stamford-{{{project_0.default_region | REGION}}} \ --machine-type=e2-small \ --image=ubuntu-1604-xenial-v20200807 \ --image-project=ubuntu-os-cloud \ --tags=webserver \ --metadata=startup-script='#! /bin/bash apt-get update apt-get install apache2 -y vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://169.254.169.254/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html systemctl restart apache2'

Verwaltete Instanzgruppe für die Webserver erstellen

• Mit diesem Befehl werden mithilfe der Instanzvorlage aus dem vorherigen Schritt zwei Webserver erstellt:

gcloud compute instance-groups managed create mig-dm-stamford-web-{{{project_0.default_region | REGION}}} \ --template=template-dm-stamford-web-{{{project_0.default_region | REGION}}} \ --size=2 \ --zone={{{project_0.default_zone | "ZONE"}}}

Instanzvorlage für die IDS-VM erstellen

• Mit dieser Vorlage wird ein Ubuntu-Server in ohne öffentliche IP-Adresse vorbereitet:

gcloud compute instance-templates create template-dm-stamford-ids-{{{project_0.default_region | REGION}}} \ --region={{{project_0.default_region | REGION}}} \ --network=dm-stamford \ --no-address \ --subnet=dm-stamford-{{{project_0.default_region | REGION}}}-ids \ --image=ubuntu-1604-xenial-v20200807 \ --image-project=ubuntu-os-cloud \ --tags=ids,webserver \ --metadata=startup-script='#! /bin/bash apt-get update apt-get install apache2 -y vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://169.254.169.254/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html systemctl restart apache2'

Verwaltete Instanzgruppe für die IDS-VM erstellen

• Mit diesem Befehl wird mithilfe der Instanzvorlage aus dem vorherigen Schritt eine VM erstellt, die als IDS konfiguriert werden soll. Die Installation von Suricata wird in einem späteren Abschnitt behandelt.

gcloud compute instance-groups managed create mig-dm-stamford-ids-{{{project_0.default_region | REGION}}} \ --template=template-dm-stamford-ids-{{{project_0.default_region | REGION}}} \ --size=1 \ --zone={{{project_0.default_zone | "ZONE"}}}

Klicken Sie auf Fortschritt prüfen.

Virtuelle Maschinen erstellen

Aufgabe 4: Internen Load Balancer erstellen

Bei der Paketspiegelung wird ein interner Load Balancer (ILB) verwendet, um gespiegelten Traffic an eine Gruppe von Collectors weiterzuleiten. In diesem Fall umfasst die Collector-Gruppe eine einzelne VM.

1. Erstellen Sie eine grundlegende Systemdiagnose für die Backend-Dienste:

gcloud compute health-checks create tcp hc-tcp-80 --port 80

2. Erstellen Sie eine Backend-Dienstgruppe für einen ILB:

gcloud compute backend-services create be-dm-stamford-suricata-{{{project_0.default_region | REGION}}} \ --load-balancing-scheme=INTERNAL \ --health-checks=hc-tcp-80 \ --network=dm-stamford \ --protocol=TCP \ --region={{{project_0.default_region | REGION}}}

3. Fügen Sie die verwaltete IDS-Instanzgruppe der im vorherigen Schritt erstellten Backend-Dienstgruppe hinzu:

gcloud compute backend-services add-backend be-dm-stamford-suricata-{{{project_0.default_region | REGION}}} \ --instance-group=mig-dm-stamford-ids-{{{project_0.default_region | REGION}}} \ --instance-group-zone={{{project_0.default_zone | "ZONE"}}} \ --region={{{project_0.default_region | REGION}}}

4. Erstellen Sie eine Frontend-Weiterleitungsregel, die als Endpunkt der Erfassung dient:

gcloud compute forwarding-rules create ilb-dm-stamford-suricata-ilb-{{{project_0.default_region | REGION}}} \ --load-balancing-scheme=INTERNAL \ --backend-service be-dm-stamford-suricata-{{{project_0.default_region | REGION}}} \ --is-mirroring-collector \ --network=dm-stamford \ --region={{{project_0.default_region | REGION}}} \ --subnet=dm-stamford-{{{project_0.default_region | REGION}}}-ids \ --ip-protocol=TCP \ --ports=all Hinweis: Obwohl TCP als Protokoll aufgeführt ist, wird der tatsächliche Typ des gespiegelten Traffics in einem späteren Abschnitt in der Paketspiegelungsrichtlinie konfiguriert. Beachten Sie auch, dass das Flag --is-mirroring-collector festgelegt ist.

Klicken Sie auf Fortschritt prüfen.

Internen Load Balancer erstellen

Aufgabe 5: Open-Source-IDS Suricata installieren

Hinweis: In den nächsten beiden Abschnitten stellen Sie eine SSH-Verbindung zur IDS-VM her und führen die Befehle in der Shell aus. Achten Sie darauf, die Befehle nicht in Cloud Shell auszuführen.

SSH-Verbindung zur IDS-VM herstellen

1. Gehen Sie in der Cloud Console über das Navigationsmenü zu Compute Engine > VM-Instanzen.

2. Klicken Sie auf die Schaltfläche SSH neben Ihrer IDS-VM.

Dadurch wird ein neues Fenster geöffnet, in dem Sie Befehle in der IDS-VM ausführen können.

3. Aktualisieren Sie die IDS-VM:

sudo apt-get update -y

4. Installieren Sie die Suricata-Abhängigkeiten:

sudo apt-get install libpcre3-dbg libpcre3-dev autoconf automake libtool libpcap-dev libnet1-dev libyaml-dev zlib1g-dev libcap-ng-dev libmagic-dev libjansson-dev libjansson4 -y sudo apt-get install libnspr4-dev -y sudo apt-get install libnss3-dev -y sudo apt-get install liblz4-dev -y sudo apt install rustc cargo -y

5. Installieren Sie Suricata:

sudo add-apt-repository ppa:oisf/suricata-stable -y sudo apt-get update -y sudo apt-get install suricata -y Hinweis: Falls bei der Installation ein Fehler auftritt, fahren Sie mit dem folgenden Überprüfungsschritt fort.

Installation prüfen

• Prüfen Sie mit dem folgenden Befehl die Installation und die installierte Version von Suricata:

suricata -V

Die Ausgabe sollte in etwa so aussehen:

This is Suricata version 5.0.3 RELEASE

Aufgabe 6: Suricata konfigurieren und prüfen

Die Befehle und Schritte des folgenden Abschnitts sollten ebenfalls über die SSH-Verbindung der IDS-/Suricata-VM ausgeführt werden.

• Beenden Sie den Suricata-Dienst und sichern Sie die Standardkonfigurationsdatei:

sudo systemctl stop suricata sudo cp /etc/suricata/suricata.yaml /etc/suricata/suricata.backup

Neue Suricata-Konfigurationsdatei und gekürzte Regeldatei herunterladen und ersetzen

Durch die neue Konfigurationsdatei wird die Collector-Schnittstelle aktualisiert und es werden nur Benachrichtigungen für eine sehr kleine Menge an Traffic ausgelöst, wie in den Dateien my.rules und suricata.yaml konfiguriert. Die Standardeinstellungen für Suricata-Regeln und ‑Benachrichtigungen sind ziemlich umfangreich und für dieses Lab überflüssig.

• Führen Sie die folgenden Befehle aus, um die Dateien zu kopieren:

wget https://storage.googleapis.com/tech-academy-enablement/GCP-Packet-Mirroring-with-OpenSource-IDS/suricata.yaml wget https://storage.googleapis.com/tech-academy-enablement/GCP-Packet-Mirroring-with-OpenSource-IDS/my.rules sudo mkdir /etc/suricata/poc-rules sudo cp my.rules /etc/suricata/poc-rules/my.rules sudo cp suricata.yaml /etc/suricata/suricata.yaml

Suricata-Dienst starten

Gelegentlich muss der Dienst neu gestartet werden. Daher ist der Befehl restart in diesem Schritt enthalten.

sudo systemctl start suricata sudo systemctl restart suricata

Einfache Suricata-Regeln zum Testen ansehen

Für dieses Lab wurde der Suricata-Regelsatz auf vier Regeln reduziert. Die Standardinstallation von Suricata umfasst jedoch ein umfangreiches Regelwerk.

• Für diese Lab-Übung ist es besser, die Benachrichtigungen auf eine knappe und einfache Liste zu reduzieren, damit jede leicht getestet werden kann.

cat /etc/suricata/poc-rules/my.rules

Die Ausgabe sollte insgesamt vier Regeln und eine Beschreibung der einzelnen Regeln enthalten.

####RULES##### #UDP ALERTS alert udp $HOME_NET any -> 8.8.8.8 53 (msg:"BAD UDP DNS REQUEST"; sid:99996; rev:1;) #HTTP ALERTS alert http any any -> $HOME_NET 80 (msg:"BAD HTTP PHP REQUEST"; http.uri; content:"index.php"; sid:99997; rev:1;) #ICMP ALERTS alert icmp any any -> $HOME_NET any (msg:"BAD ICMP"; sid:99998; rev:1;) #TCP ALERTS alert tcp $HOME_NET any -> any 6667 (msg:"BAD TCP 6667 REQUEST"; sid:99999; rev:1;) Hinweis: Die Standardregeldatei befindet sich meist unter /etc/suricata/rules/ oder /var/lib/suricata/rules. In Schritt 2 wurde sie für dieses Lab mit einem anderen Speicherort neu konfiguriert.

Aufgabe 7: Paketspiegelungsrichtlinie konfigurieren

Kehren Sie für diesen Abschnitt des Labs zu Cloud Shell zurück.

Die Einrichtung der Paketspiegelungsrichtlinie kann mit einem einfachen Befehl oder über einen Assistenten in der GUI erfolgen. In diesem Befehl geben Sie alle fünf Attribute an, die in der Beschreibung der Paketspiegelung weiter oben erwähnt wurden.

• Region
• VPC-Netzwerk(e)
• Gespiegelte Quelle(n)
• Collector (Ziel)
• Gespiegelter Traffic (Filter)

Vielleicht ist Ihnen aufgefallen, dass hier der gespiegelte Traffic nicht erwähnt wird. Das liegt daran, dass die Richtlinie so konfiguriert wird, dass SÄMTLICHER Traffic gespiegelt wird und kein Filter erforderlich ist. Die Richtlinie legt fest, dass sowohl ein- als auch ausgehender Traffic gespiegelt und an das Suricata-IDS-Gerät, das Teil des Collector-ILB ist, weitergeleitet werden soll.

• Konfigurieren Sie die Paketspiegelungsrichtlinie, indem Sie Folgendes in Cloud Shell ausführen:

gcloud compute packet-mirrorings create mirror-dm-stamford-web \ --collector-ilb=ilb-dm-stamford-suricata-ilb-{{{project_0.default_region | REGION}}} \ --network=dm-stamford \ --mirrored-subnets=dm-stamford-{{{project_0.default_region | REGION}}} \ --region={{{project_0.default_region | REGION}}}

Jetzt sollten die Paketspiegelungs- und die Suricata-Konfiguration abgeschlossen sein. In den folgenden Abschnitten werden beide getestet.

Klicken Sie auf Fortschritt prüfen.

Paketspiegelungsrichtlinie konfigurieren

Aufgabe 8: Paketspiegelung testen

In diesem Abschnitt greifen Sie auf die IDS-VM-Shell zu. Wenn das Shell-Fenster noch geöffnet ist, verwenden Sie es. Falls das Shell-Fenster geschlossen wurde, stellen Sie die Verbindung wieder her.

Außerdem verwenden Sie Cloud Shell als „Internetclient“.

Nehmen Sie sich einige Minuten Zeit, um die externen IP-Adressen der beiden WEB-VMs herauszufinden.

Klicken Sie in der Cloud Console im Navigationsmenü auf Compute Engine > VM-Instanzen und notieren Sie sich die externen IP-Adressen der WEB-VMs. Sie werden als [PUBLIC_IP_WEB1] beziehungsweise [PUBLIC_IP_WEB2] bezeichnet.

Sie können dieselben Informationen auch über gcloud-Befehle aus Cloud Shell abrufen:

gcloud compute instances list

Kehren Sie zur IDS-VM-Shell zurück.

Paketspiegelung testen

• Führen Sie auf der IDS-/Suricata-VM eine Paketaufzeichnung (tcpdump) mit den folgenden Filtern aus:

sudo tcpdump -i ens4 -nn -n "(icmp or port 80) and net 172.21.0.0/24" Hinweis: Das Netzwerk 172.21.0.0/24 ist das GESPIEGELTE Subnetz und die IDS-VM ist nicht Teil dieses Subnetzes. Wenn die Paketspiegelung richtig konfiguriert ist, sollte die IDS-VM gespiegelten Traffic für dieses Subnetz empfangen.

Traffic zum „gespiegelten“ Subnetz generieren

1. Pingen Sie über das Cloud Shell-Terminal die WEB1 zugewiesene öffentliche Adresse. Ersetzen Sie dabei [PUBLIC_IP_WEB1] durch die öffentliche IP-Adresse von „WEB1“, die in der Cloud Console angezeigt wird:

sudo apt install iputils-ping ping -c 4 [PUBLIC_IP_WEB1]

Durch die Paketspiegelung sollte dieser Traffic dupliziert und an die IDS-VM weitergeleitet werden. Sie sollten ihn in der Paketaufzeichnung aus Schritt 1 sehen können. Die Ausgabe auf der IDS-VM sollte in etwa so aussehen, wobei X.X.X.X die Quell-IP-Adresse der ICMP-Anfragen ist. In der tcpdump-Ausgabe sollte die private IP-Adresse des WEBSERVERS enthalten sein. Google Cloud führt die Netzwerkadressübersetzung am Edge durch.

00:55:32.980666 IP X.X.X.X > 172.21.0.2: ICMP echo request, id 3399, seq 0, length 64 00:55:32.980801 IP 172.21.0.2 > X.X.X.X: ICMP echo reply, id 3399, seq 0, length 64 00:55:33.968920 IP X.X.X.X > 172.21.0.2: ICMP echo request, id 3399, seq 1, length 64 00:55:33.968965 IP 172.21.0.2 > X.X.X.X: ICMP echo reply, id 3399, seq 1, length 64 00:55:34.980472 IP X.X.X.X > 172.21.0.2: ICMP echo request, id 3399, seq 2, length 64 00:55:34.980521 IP 172.21.0.2 > X.X.X.X: ICMP echo reply, id 3399, seq 2, length 64 00:55:35.986354 IP X.X.X.X > 172.21.0.2: ICMP echo request, id 3399, seq 3, length 64 00:55:35.986445 IP 172.21.0.2 > X.X.X.X: ICMP echo reply, id 3399, seq 3, length 64

---

Das Pingen der öffentlichen Adresse von WEB2 sollte zum selben Ergebnis führen.

2. Pingen Sie die WEB2 zugewiesene öffentliche Adresse. Ersetzen Sie dabei [PUBLIC_IP_WEB2] durch die öffentliche IP-Adresse von „WEB2“.

ping -c 4 [PUBLIC_IP_WEB2]

Durch die Paketspiegelung sollte dieser Traffic an die IDS-VM weitergeleitet werden. Sie sollten ihn in der Paketaufzeichnung aus Schritt 1 sehen können. Die Ausgabe auf der IDS-VM sollte in etwa so aussehen. In der tcpdump-Ausgabe sollte die private IP-Adresse des WEBSERVERS enthalten sein. Google Cloud führt die Netzwerkadressübersetzung am Edge durch.

00:00:45.309407 IP X.X.X.X > 172.21.0.3: ICMP echo request, id 25159, seq 0, length 64 00:00:45.309736 IP 172.21.0.3 > X.X.X.X: ICMP echo reply, id 25159, seq 0, length 64 00:00:46.309406 IP X.X.X.X > 172.21.0.3: ICMP echo request, id 25159, seq 1, length 64 00:00:46.309602 IP 172.21.0.3 > X.X.X.X: ICMP echo reply, id 25159, seq 1, length 64 00:00:47.306278 IP X.X.X.X > 172.21.0.3: ICMP echo request, id 25159, seq 2, length 64 00:00:47.306406 IP 172.21.0.3 > X.X.X.X: ICMP echo reply, id 25159, seq 2, length 64 00:00:48.314506 IP X.X.X.X > 172.21.0.3: ICMP echo request, id 25159, seq 3, length 64 00:00:48.314698 IP 172.21.0.3 > X.X.X.X: ICMP echo reply, id 25159, seq 3, length 64

Zur Veranschaulichung, dass die Paketspiegelung mehr als nur die Layer 3-Header anzeigt, wird im folgenden Test ein standardmäßiger HTTP-GET-Befehl an einen der WEB-Server gesendet, einschließlich des anfänglichen TCP-Drei-Wege-Handshakes.

1. Öffnen Sie einen neuen Tab im Browser und rufen Sie die öffentliche Adresse auf, die WEB1 mit dem HTTP-Protokoll zugewiesen ist. Sie können auch das „curl“-Dienstprogramm aus der Cloud Console verwenden.

2. Ersetzen Sie [PUBLIC_IP_WEB1] durch die öffentliche IP-Adresse von „WEB1“:

http://[PUBLIC_IP_WEB1]/

Durch die Paketspiegelung sollte dieser Traffic an die IDS-VM weitergeleitet werden. Sie sollten ihn in der Paketaufzeichnung aus Schritt 1 sehen können.

Die Ausgabe auf der IDS-VM sollte in etwa so aussehen:

00:00:46.761748 IP X.X.X.60835 > 172.21.0.2.80: Flags [S]... 00:00:46.763037 IP 172.21.0.2.80 > X.X.X.60835: Flags [S.], ... ack ... 00:00:46.816407 IP X.X.X.60835 > 172.21.0.2.80: Flags [.], ack ... 00:00:46.823624 IP X.X.X.60835 > 172.21.0.2.80: Flags [P.], ... HTTP: GET / HTTP/1.1 00:00:46.823832 IP 172.21.0.2.80 > X.X.X.60835: Flags [.], ack ... 00:00:46.824549 IP 172.21.0.2.80 > X.X.X.60835: Flags [P.], ... HTTP: HTTP/1.1 200 OK 00:00:46.879214 IP X.X.X.60835 > 172.21.0.2.80: Flags [.], ack ... 00:00:46.888477 IP X.X.X.60835 > 172.21.0.2.80: Flags [F.], ... 00:00:46.888662 IP 172.21.0.2.80 > X.X.X.60835: Flags [F.], ... ack... 00:00:46.943915 IP X.X.X.60835 > 172.21.0.2.80: Flags [.], ack ...

---

3. Das Gleiche sollte passieren, wenn Sie die öffentliche Adresse von WEB2 aufrufen. Ersetzen Sie [PUBLIC_IP_WEB2] durch die öffentliche IP-Adresse von „WEB2“.

http://[PUBLIC_IP_WEB2]/

Durch die Paketspiegelung sollte dieser Traffic an die IDS-VM weitergeleitet werden. Sie sollten ihn in der Paketaufzeichnung aus Schritt 1 sehen können.

Die Ausgabe auf der IDS-VM sollte in etwa so aussehen.

00:00:58.819740 IP X.X.X.X.62335 > 172.21.0.3.80: Flags [S]... 00:00:58.820027 IP 172.21.0.3.80 > X.X.X.X.62335: Flags [S.], ... ack ... 00:00:58.875301 IP X.X.X.X.62335 > 172.21.0.3.80: Flags [.], ack ... 00:00:58.875329 IP X.X.X.X.62335 > 172.21.0.3.80: Flags [P.], ... HTTP: GET / HTTP/1.1 00:00:58.875448 IP 172.21.0.3.80 > X.X.X.X.62335: Flags [.], ack ... 00:00:58.876204 IP 172.21.0.3.80 > X.X.X.X.62335: Flags [P.], ... HTTP: HTTP/1.1 200 OK 00:00:58.929015 IP X.X.X.X.62335 > 172.21.0.3.80: Flags [.], ack ... 00:00:58.929047 IP X.X.X.X.62335 > 172.21.0.3.80: Flags [F.], ... 00:00:58.929244 IP 172.21.0.3.80 > X.X.X.X.62335: Flags [F.], ... ack... 00:00:58.993844 IP X.X.X.X.62335 > 172.21.0.3.80: Flags [.], ack ...

Geben Sie in der IDS-VM Strg + C ein, um tcpdump zu beenden.

Aufgabe 9: Suricata-IDS-Prüfung und ‑Benachrichtigungen testen

Im letzten Abschnitt dieses Labs testen Sie die Einbindung der Paketspiegelung in das Open-Source-IDS Suricata. Sehen Sie sich die vier Suricata-Regeln an, die in Schritt 4 des Abschnitts „Suricata konfigurieren und prüfen“ für Benachrichtigungen festgelegt wurden:

####RULES##### #UDP ALERTS alert udp $HOME_NET any -> 8.8.8.8 53 (msg:"BAD UDP DNS REQUEST"; sid:99996; rev:1;) #HTTP ALERTS alert http any any -> $HOME_NET 80 (msg:"BAD HTTP PHP REQUEST"; http.uri; content:"index.php"; sid:99997; rev:1;) #ICMP ALERTS alert icmp any any -> $HOME_NET any (msg:"BAD ICMP"; sid:99998; rev:1;) #TCP ALERTS alert tcp $HOME_NET any -> any 6667 (msg:"BAD TCP 6667 REQUEST"; sid:99999; rev:1;)

In den folgenden vier Schritten generieren Sie Netzwerk-Traffic, um die einzelnen Regeln auszulösen. Für jede von ihnen sollten Benachrichtigungen in der Suricata-Ereignisprotokolldatei enthalten sein.

Hinweis: Sie müssen SSH-Fenster sowohl für die IDS-VM als auch für eine Webserver-VM geöffnet haben. Sie müssen BEIDE gleichzeitig ansehen, um diesen Abschnitt abzuschließen.

TEST1 und TEST2 werden vom WEBSERVER gestartet und es wird ausgehender Traffic getestet.

TEST3 und TEST4 werden in Cloud Shell gestartet und dienen zum Testen von eingehendem Traffic.

TEST 1: Regel/Benachrichtigung für ausgehenden UDP-Traffic testen

1. Führen Sie den folgenden Befehl auf einem der WEB-Server aus, um ausgehenden DNS-Traffic zu generieren:

dig @8.8.8.8 example.com

2. Sehen Sie sich nun die Benachrichtigung in der Suricata-Ereignisprotokolldatei auf der IDS-VM an.

Wechseln Sie zum SSH-Fenster für die IDS-VM.

3. Führen Sie im SSH-Fenster für die IDS-VM den folgenden Befehl aus:

egrep "BAD UDP DNS" /var/log/suricata/eve.json

Der Logeintrag sollte in etwa so aussehen:

@GCP: {"timestamp":"2020-08-14T01:23:14.903210+0000","flow_id":412864167987242,"in_iface":"ens4","event_type":"alert","src_ip":"172.21.0.2","src_port":47020,"dest_ip":"8.8.8.8","dest_port":53,"proto":"UDP","alert":{"action":"allowed","gid":1,"signature_id":99996,"rev":1,"signature":"BAD UDP DNS REQUEST","category":"","severity":3},"dns":{"query":[{"type":"query","id":17268,"rrname":"EXAMPLE.COM","rrtype":"A","tx_id":0}]},"app_proto":"dns","flow":{"pkts_toserver":1,"pkts_toclient":0,"bytes_toserver":82,"bytes_toclient":0,"start":"2020-08-19T18:23:14.903210+0000"}}

TEST 2: Regel/Benachrichtigung für ausgehenden TCP-Traffic testen

1. Führen Sie den folgenden Befehl auf einem der WEB-Server aus, um ausgehenden TCP-Traffic zu generieren. Ersetzen Sie dabei [PUBLIC_IP_WEB2] durch die öffentliche IP-Adresse von „WEB2“:

telnet [PUBLIC_IP_WEB2] 6667

2. Drücken Sie Strg + C, um den Befehl zu beenden.

3. Sehen Sie sich nun die Benachrichtigung in der Suricata-Ereignisprotokolldatei auf der IDS-VM an.

Wechseln Sie zum SSH-Fenster für die IDS-VM.

4. Führen Sie im SSH-Fenster der IDS-VM den folgenden Befehl aus:

egrep "BAD TCP" /var/log/suricata/eve.json

Der Logeintrag sollte in etwa so aussehen:

@GCP: {"timestamp":"2020-08-14T01:27:45.058526+0000","flow_id":479376049300638,"in_iface":"ens4","event_type":"alert","src_ip":"172.21.0.2","src_port":36168,"dest_ip":"100.64.1.1","dest_port":6667,"proto":"TCP","alert":{"action":"allowed","gid":1,"signature_id":99999,"rev":1,"signature":"BAD TCP 6667 REQUEST","category":"","severity":3},"flow":{"pkts_toserver":1,"pkts_toclient":0,"bytes_toserver":74,"bytes_toclient":0,"start":"2020-08-19T18:27:45.058526+0000"}}

TEST 3: Regel/Benachrichtigung für eingehenden ICMP-Traffic testen

1. Führen Sie in Cloud Shell den folgenden Befehl aus, um EINGEHENDEN ICMP-Traffic zu generieren.

2. Ersetzen Sie [PUBLIC_IP_WEB1] durch die öffentliche IP-Adresse von „WEB1“:

ping -c 3 [PUBLIC_IP_WEB1]

3. Sehen Sie sich nun die Benachrichtigung in der Suricata-Ereignisprotokolldatei auf der IDS-VM an:

egrep "BAD ICMP" /var/log/suricata/eve.json

Der Logeintrag sollte in etwa so aussehen:

@GCP: {"timestamp":"2020-08-14T01:24:46.065250+0000","flow_id":1114966772874978,"in_iface":"ens4","event_type":"alert","src_ip":"X.X.X.X","dest_ip":"172.21.0.2","proto":"ICMP","icmp_type":8,"icmp_code":0,"alert":{"action":"allowed","gid":1,"signature_id":99998,"rev":1,"signature":"BAD ICMP","category":"","severity":3},"flow":{"pkts_toserver":1,"pkts_toclient":0,"bytes_toserver":98,"bytes_toclient":0,"start":"2020-08-19T18:24:46.065250+0000"}}

TEST 4: Regel/Benachrichtigung für eingehenden HTTP-Traffic testen

Rufen Sie mit dem Webbrowser auf Ihrem Computer oder mit curl in Cloud Shell die öffentliche Adresse auf, die WEB1 für die Seite index.php zugewiesen ist. Verwenden Sie dazu das HTTP-Protokoll.

1. Ersetzen Sie [PUBLIC_IP_WEB1] durch die öffentliche IP-Adresse von „WEB1“:

http://[PUBLIC_IP_WEB1]/index.php

2. Sehen Sie sich nun die Benachrichtigung in der Suricata-Ereignisprotokolldatei auf der IDS-VM an:

egrep "BAD HTTP" /var/log/suricata/eve.json

Der Logeintrag sollte in etwa so aussehen:

@GCP: {"timestamp":"2020-08-14T01:26:36.794124+0000","flow_id":1901424684045611,"in_iface":"ens4","event_type":"alert","src_ip":"X.X.X.X","src_port":61132,"dest_ip":"172.21.0.3","dest_port":80,"proto":"TCP","tx_id":0,"alert":{"action":"allowed","gid":1,"signature_id":99997,"rev":1,"signature":"BAD HTTP PHP REQUEST","category":"","severity":3},"http":{"hostname":"PUBLIC_IP_WEB1","url":"\/index.php","http_user_agent":"curl\/7.64.1","http_content_type":"text\/html","http_method":"GET","protocol":"HTTP\/1.1","status":404,"length":275},"app_proto":"http","flow":{"pkts_toserver":7,"pkts_toclient":6,"bytes_toserver":658,"bytes_toclient":1284,"start":"2020-08-19T18:26:36.660779+0000"}}

Glückwunsch!

Das Lab zur Verwendung der Google Cloud-Paketspiegelung mit dem Open-Source-IDS Suricata ist damit abgeschlossen.

Weitere Informationen

Weitere Informationen zur Paketspiegelung finden Sie unter:

• Paketspiegelung

• Paketspiegelung verwenden

Weitere Informationen zu Suricata finden Sie unter https://suricata-ids.org/.

Google Cloud-Schulungen und -Zertifizierungen

In unseren Schulungen erfahren Sie alles zum optimalen Einsatz unserer Google Cloud-Technologien und können sich entsprechend zertifizieren lassen. Unsere Kurse vermitteln technische Fähigkeiten und Best Practices, damit Sie möglichst schnell mit Google Cloud loslegen und Ihr Wissen fortlaufend erweitern können. Wir bieten On-Demand-, Präsenz- und virtuelle Schulungen für Anfänger wie Fortgeschrittene an, die Sie individuell in Ihrem eigenen Zeitplan absolvieren können. Mit unseren Zertifizierungen weisen Sie nach, dass Sie Experte im Bereich Google Cloud-Technologien sind.

Anleitung zuletzt am 18. November 2024 aktualisiert

Lab zuletzt am 6. September 2023 getestet

© 2025 Google LLC. Alle Rechte vorbehalten. Google und das Google-Logo sind Marken von Google LLC. Alle anderen Unternehmens- und Produktnamen können Marken der jeweils mit ihnen verbundenen Unternehmen sein.