Wie Sie die DNS-Exfiltration in der Google Cloud blockieren

Die Sicherung Ihres Cloud-Netzwerks (VPC) durch Firewall-Regeln ist gängige Praxis. Die Firewall-Regeln von Google Cloud gelten jedoch nicht für Cloud DNS-Aufrufe, die vom Metadaten-Server aus erfolgen. Daher können Sie Daten exfiltrieren, indem Sie von Ihrer Instanz aus öffentliche Domains abfragen. In diesem Blog werde ich Ihnen erklären, wie das passiert und was Sie dagegen tun können.

DNS-Datenexfiltration?

Nachdem Sie sich Zugang zu persönlichen/Unternehmensdaten verschafft haben, besteht die Herausforderung darin, die Daten wieder herauszubekommen. Normalerweise blockiert die Firewall des Unternehmens den Internetzugang, so dass Sie eine Alternative benötigen, um die Daten zu exfiltrieren.

Um Daten mithilfe von DNS zu exfiltrieren, senden Sie mehrere Abfragen an Ihren eigenen Namensserver. Jede Abfrage enthält einen Teil der zu exfiltrierenden Daten:

1. a0123zzlaure01.meine-teuflische-domain.de
2. a0123zzns0002.my-evil-domain.com
3. a0123zzloves03.my-evil-domain.com
4. a0123zzcloud04.meine-böse-domain.de

Auf Ihrem Namensserver kombinieren Sie Abfrageprotokolle, um persönliche/Unternehmensdaten zurückzugeben. In diesem Fall: laurens liebt Cloud.

Namensauflösung für Cloud DNS

Ressourcen, die in Google Cloud ausgeführt werden, verwenden standardmäßig den Metadatenserver (169.254.169.254) als Nameserver. Dieser Nameserver verwendet die DNS-Konfiguration Ihrer VPC, die standardmäßig öffentlich verfügbare DNS-Server abfragt, um die IP-Adresse aufzulösen und Ihre Daten herauszugeben.

Um dies zu ändern, können Sie zones, server policies und response policies konfigurieren. Mit Zonen können Sie Ihre eigenen DNS-Einträge für eine bestimmte Domain konfigurieren, z.B. example.com. Serverrichtlinien ermöglichen es Ihnen, DNS-Anfragen an Ihre eigenen Nameserver weiterzuleiten, um z.B. interne DNS-Einträge aufzulösen. Antwortrichtlinien ermöglichen es Ihnen, die Ergebnisse von DNS-Anfragen zu ändern.

Das endgültige Verhalten folgt der folgenden Logik:

• Wenn eine Richtlinie für ausgehende Server gilt, werden alle DNS-Anfragen an die alternativen Server weitergeleitet.
• Ohne eine Ausgangsserver-Richtlinie gilt die folgende Priorität von zones und response policies für die beste Übereinstimmung (längste Suffix-Übereinstimmung):
  1. Reaktionspolitik
  2. private Zone wie die private Cloud DNS-Zone, Weiterleitungszone und/oder Peering-Zone
  3. interne DNS der Compute Engine z.B. my-vm.europe-west4-a.c.my-project.internal
  4. öffentliche dns

Blockieren öffentlicher DNS-Anfragen

Um die Daten zu erhalten, müssen Sie die öffentlichen DNS-Anfragen einschränken. Eine Brute-Force-Lösung besteht darin, alle öffentlichen DNS-Anfragen über die private Zone der obersten Ebene zu blockieren: ..

resource "google_dns_managed_zone" "black_hole" {
  project  = var.project_id
  name     = "black-hole"
  dns_name = "."

  visibility = "private"

  private_visibility_config {
    networks {
      network_url = var.network_id
    }
  }
}

Dies mag zwar für eine isolierte VPC funktionieren, aber die Deaktivierung von DNS wird die meisten Lösungen zunichte machen. Leider ist eine von Google verwaltete Standardlösung derzeit nicht verfügbar. Daher könnten Sie Ihren eigenen sicheren DNS-Server betreiben oder eine benutzerdefinierte Logik implementieren, die die DNS-Protokolle durchsucht und Antwortrichtlinien konfiguriert, um bestimmte Domains zu blockieren.

Fazit

Es sind zusätzliche Maßnahmen erforderlich, um Ihre Daten vor DNS-Exfiltrationsangriffen zu schützen. Leider werden diese Maßnahmen noch nicht als von Google verwalteter Service angeboten. Wenn Sie jedoch den Angriff und die verfügbaren GCP-Optionen verstehen, sind Sie gut gerüstet, den Angriff zu überwachen und entsprechend zu reagieren.

Bild von Susanne Jutzeler, Schweiz von Pixabay