Jetzt abonnieren, um Benachrichtigungen über neue Beiträge zu erhalten:

So haben wir mit unserer neuer GraphQL Analytics API die Firewall Analytics entwickelt

2019-12-12

Lesezeit: 4 Min.
Dieser Beitrag ist auch auf English, Español, und Français verfügbar.

Firewall Analytics ist das erste Produkt im Cloudflare-Dashboard, das die neue GraphQL Analytics API verwendet. Alle Produkte im Cloudflare-Dashboard werden mit denselben öffentlichen APIs entwickelt, die wir auch unseren Kunden zur Verfügung stellen. Auf diese Weise lernen auch wir auch die Schwierigkeiten kennen, die beim Einsatz unserer APIs auftreten können. Durch diese Gleichbehandlung können wir unsere eigenen Produkte besser entwickeln und gestalten, zuletzt die neue GraphQL Analytics API, die wir heute voller Stolz präsentieren.

Durch Definition der gewünschten Daten und des Antwortformats können wir mit unserer GraphQL Analytics API Prototypen neuer Funktionen erstellen und auf der Basis des Feedbacks unserer Beta-Anwender schnell iterieren. Damit können wir unseren Kunden innerhalb des Cloudflare-Dashboards informativere Analysetools anbieten.

Im Rahmen unserer Anwenderstudien und Tests für Firewall Analytics sind häufige Anwendungsfälle im Workflow unserer Kunden zutage getreten:

  • Spitzen der Firewall-Aktivität im Zeitverlauf identifizieren

  • Gemeinsame Eigenschaften von Bedrohungen herausfinden

  • Granulare Details eines einzelnen Ereignisses unter die Lupe nehmen, um mögliche falsch-positive Ergebnisse zu erkennen

Mit unserer neuen GraphQL Analytics API können wir all diese Anwendungsfälle abdecken.

GraphQL-Grundlagen

Bevor wir uns damit beschäftigen, wie wir diese Anwendungsfälle abdecken, werfen wir einen Blick auf das Format einer GraphQL-Abfrage und die Struktur unseres Schemas.

Eine GraphQL-Abfrage besteht aus einem strukturierten Satz von Feldern, für die der Server in seiner Antwort entsprechende Werte zurückliefert. Im Schema wird definiert, welche Felder verfügbar sind und welchen Typ sie haben. Weitere Informationen zur GraphQL-Abfragesyntax und zum Format finden Sie in der offiziellen GraphQL-Dokumentation.

Wenn Sie GraphQL-Abfragen ausführen möchten, empfehlen wir, einen GraphQL-Client wie GraphiQL herunterzuladen. Mit diesem können Sie sich unser Schema ansehen und einige Abfragen ausführen. In unseren Entwicklerdokumenten finden Sie eine Dokumentation für den Einstieg.

Auf der obersten Ebene des Schemas befindet sich das Feld viewer. Es stellt den obersten Knoten des Benutzers dar, der die Abfrage ausführt. Innerhalb davon können wir das Feld zones abfragen, um Zonen zu finden, auf die der aktuelle Benutzer Zugriff hat. Dazu geben wir ein filter-Argument an, das ein zoneTag enthält, mit dem wir die Zone identifizieren, auf die wir die Suche einschränken möchten.

{
  viewer {
    zones(filter: { zoneTag: "YOUR_ZONE_ID" }) {
      # Here is where we'll query our firewall events
    }
  }
}

Nachdem wir nun eine Abfrage haben, mit der wir unsere Zone finden, können wir die Firewall Events abfragen, die in dieser Zone aufgetreten sind, um einige der von uns gefundenen Anwendungsfälle zu lösen.

Spitzen der Firewall-Aktivität visualisieren

Unsere Kunden müssen Anomalien und Spitzen in ihrer Firewall-Aktivität visualisieren und verstehen können, denn diese könnten auf einen Angriff hinweisen oder das Ergebnis einer Fehlkonfiguration sein.

Wenn die Ereignisse in einem Zeitreihendiagramm nach der jeweiligen Aktion dargestellt werden, bekommen die Anwender einen visuellen Überblick über den Trend ihrer Firewall Events.

In der oben erstellten Abfrage können wir im Feld zones mit dem Feld firewallEventsAdaptiveGroups Aggregate der Firewall Events abfragen. Dabei verwenden wir Argumente zur Einschränkung der Anzahl der Gruppen, einen Filter für den gesuchten Datumsbereich (in Kombination mit vom Benutzer definierten Filtern) und eine Liste der Felder, nach denen sortiert werden soll; das ist in diesem Fall nur das Feld datetimeHour, nach dem wir auch gruppieren.

In der oben erstellten Abfrage können wir im Feld zones mit dem Feld firewallEventsAdaptiveGroups weiter nach Aggregaten der Firewall Events abfragen. Dabei verwenden wir folgende Argumente:

  • ein Limit für die Anzahl der Gruppen

  • einen Filter für den gesuchten Datumsbereich (kombiniert mit beliebigen vom Benutzer definierten Filtern)

  • eine Liste der Felder, nach denen sortiert werden soll (orderBy-Klausel, in diesem Fall nur das Feld datetimeHour, nach dem wir auch gruppieren).

Wir fügen das Feld dimensions hinzu und fragen damit Gruppen von Firewall Events ab, die nach den in dimensions verschachtelten Feldern aggregiert werden. In diesem Fall enthält unsere Abfrage die Felder action und datetimeHour; als Antwort werden deshalb Gruppen von Firewall Events mit der gleichen Aktion und innerhalb derselben Stunde zurückgegeben. Außerdem nehmen wir ein Feld count in die Abfrage auf, mit dem die Anzahl der Ereignisse innerhalb jeder Gruppe gezählt wird.

query FirewallEventsByTime($zoneTag: string, $filter: FirewallEventsAdaptiveGroupsFilter_InputObject) {
  viewer {
    zones(filter: { zoneTag: $zoneTag }) {
      firewallEventsAdaptiveGroups(
        limit: 576
        filter: $filter
        orderBy: [datetimeHour_DESC]
      ) {
        count
        dimensions {
          action
          datetimeHour
        }
      }
    }
  }
}

Hinweis: Für jede der Gruppenabfragen muss ein Limit festgelegt werden. Ein Firewall Event kann eine von acht möglichen Aktionen haben, und unsere Abfrage betrifft einen Zeitraum von 72 Stunden. Wir werden höchstens 567 Gruppen bekommen, sodass wir dies als Limit für unsere Abfrage festlegen können.

Diese Abfrage liefert eine Antwort in folgendem Format zurück:

{
  "viewer": {
    "zones": [
      {
        "firewallEventsAdaptiveGroups": [
          {
            "count": 5,
            "dimensions": {
              "action": "jschallenge",
              "datetimeHour": "2019-09-12T18:00:00Z"
            }
          }
          ...
        ]
      }
    ]
  }
}

Wir können diese Gruppen dann jeweils als Punkt in einem Zeitreihendiagramm darstellen. Durch Zuordnung zum Array firewallEventsAdaptiveGroups können wir das Attribut count für die y-Achse unseres Diagramms verwenden. Von den im Objekt dimensions verschachtelten Feldern verwenden wir action als eindeutige Reihe und die datetimeHour als Zeitstempel auf der x-Achse.

Top N

Nachdem wir eine Aktivitätsspitze erkannt haben, besteht der nächste Schritt darin, Ereignisse mit gemeinsamen Attributen hervorzuheben. Wenn z. B. eine bestimmte IP-Adresse oder ein einzelner User Agent viele Firewall Events auslöst, kann dies ein Zeichen für einen einzelnen Angreifer sein – oder ein falsch-positives Ergebnis.

Ähnlich wie oben können wir aggregierte Gruppen von Firewall Events über das Feld firewallEventsAdaptiveGroups abfragen. In diesem Fall können wir jedoch einzelne Felder hinzufügen, für die wir gemeinsame Gruppen suchen möchten, anstatt action und datetimeHour bei den dimensions der Gruppe anzugeben.

Wenn wir die Gruppen absteigend nach Anzahl sortieren, bekommen wir zuerst die Gruppen mit der höchsten Gemeinsamkeit. Dies begrenzen wir jeweils auf die obersten 5 Gruppen. Wir können innerhalb der dimensions ein einzelnes Feld verschachteln, um danach zu gruppieren. Wenn man z. B. clientIP aufnimmt, werden die fünf Gruppen mit den IP-Adressen angezeigt, die die meisten Events verursachen.

Wir können auch ein Feld firewallEventsAdaptiveGroups ohne verschachtelte dimensions aufnehmen. Dadurch wird eine einzelne Gruppe erstellt, mit der wir die Gesamtzahl der Events ermitteln können, die unserem Filter entsprechen.

query FirewallEventsTopNs($zoneTag: string, $filter: FirewallEventsAdaptiveGroupsFilter_InputObject) {
  viewer {
    zones(filter: { zoneTag: $zoneTag }) {
      topIPs: firewallEventsAdaptiveGroups(
        limit: 5
        filter: $filter
        orderBy: [count_DESC]
      ) {
        count
        dimensions {
          clientIP
        }
      }
      topUserAgents: firewallEventsAdaptiveGroups(
        limit: 5
        filter: $filter
        orderBy: [count_DESC]
      ) {
        count
        dimensions {
          userAgent
        }
      }
      total: firewallEventsAdaptiveGroups(
        limit: 1
        filter: $filter
      ) {
        count
      }
    }
  }
}

Hinweis: Wir können das Feld firewallEventsAdaptiveGroups innerhalb einer einzelnen Abfrage mehrmals angeben, jedes Mal mit einem anderen Alias. Auf diese Weise können wir mehrere verschiedene Gruppierungen nach verschiedenen Feldern oder ganz ohne Gruppierungen abrufen. In diesem Fall rufen wir eine Liste der obersten IP-Adressen, der obersten User Agents und die Anzahl aller Events ab.

In der Benutzeroberfläche kann man dann auf jeden dieser Aliase Bezug nehmen und durch Zuordnung zu den jeweiligen Gruppen jede Zeile mit der zugehörigen Anzahl erzeugen. Dazu wird ein Balken dargestellt, der den Anteil jeder Zeile an der Gesamtanzahl der Events verdeutlicht.

Sind diese Firewall Events falsch-positive Ergebnisse?

Nachdem Benutzer Spitzen, Anomalien und gemeinsame Attribute identifiziert hatten, wollten wir weitere Informationen darüber zutage fördern, ob es sich dabei um böswilligen Traffic oder falsch-positive Ergebnisse handelt.

Hierfür wollten wir neben den reinen Zählern zusätzlichen Kontext zu den Events selbst anbieten. Dazu fragen wir das Feld firewallEventsAdaptive für diese Events ab.

In unserem GraphQL-Schema wird sowohl für das Aggregatfeld firewallEventsAdaptiveGroups als auch für das Rohdatenfeld firewallEventsAdaptive dasselbe Filterformat verwendet. Dadurch können wir für den Abruf der einzelnen Events die gleichen Filter verwenden, mit denen auch die Zähler und Aggregate in den oben genannten Visualisierungen aufsummiert werden.

query FirewallEventsList($zoneTag: string, $filter: FirewallEventsAdaptiveFilter_InputObject) {
  viewer {
    zones(filter: { zoneTag: $zoneTag }) {
      firewallEventsAdaptive(
        filter: $filter
        limit: 10
        orderBy: [datetime_DESC]
      ) {
        action
        clientAsn
        clientCountryName
        clientIP
        clientRequestPath
        clientRequestQuery
        datetime
        rayName
        source
        userAgent
      }
    }
  }
}

Sobald wir die einzelnen Events haben, können wir alle angeforderten individuellen Felder erzeugen. Dadurch liefern wir den Anwendern den zusätzlichen Kontext für das Event, mit dem sie feststellen können, ob es sich um ein falsch-positives Ergebnis handelt oder nicht.

Auf diese Weise haben wir mit unserer neuer GraphQL Analytics API die Firewall Analytics entwickelt und einige der häufigsten sicherheitsbezogenen Anwendungsfälle unserer Kunden einer Lösung näher gebracht. Wir sind schon gespannt, was Sie damit entwickeln und welche Probleme Sie damit anpacken werden.

In unserer Entwicklerdokumentation finden Sie alle notwendigen Informationen für das Abfragen unserer GraphQL Analytics API mit GraphiQL. Mehr über das Schreiben von GraphQL-Abfragen erfahren Sie in der offiziellen Dokumentation der GraphQL Foundation.

Wir schützen komplette Firmennetzwerke, helfen Kunden dabei, Internetanwendungen effizient zu erstellen, jede Website oder Internetanwendung zu beschleunigen, DDoS-Angriffe abzuwehren, Hacker in Schach zu halten, und unterstützen Sie bei Ihrer Umstellung auf Zero Trust.

Greifen Sie von einem beliebigen Gerät auf 1.1.1.1 zu und nutzen Sie unsere kostenlose App, die Ihr Internet schneller und sicherer macht.

Wenn Sie mehr über unsere Mission, das Internet besser zu machen, erfahren möchten, beginnen Sie hier. Sie möchten sich beruflich neu orientieren? Dann werfen Sie doch einen Blick auf unsere offenen Stellen.
Produkt-NewsAnalytics (DE)API (DE)GraphQL

Folgen auf X

Cloudflare|@cloudflare

Verwandte Beiträge

08. Oktober 2024 um 13:00

Cloudflare acquires Kivera to add simple, preventive cloud security to Cloudflare One

The acquisition and integration of Kivera broadens the scope of Cloudflare’s SASE platform beyond just apps, incorporating increased cloud security through proactive configuration management of cloud services. ...

27. September 2024 um 13:00

AI Everywhere with the WAF Rule Builder Assistant, Cloudflare Radar AI Insights, and updated AI bot protection

This year for Cloudflare’s birthday, we’ve extended our AI Assistant capabilities to help you build new WAF rules, added new AI bot & crawler traffic insights to Radar, and given customers new AI bot blocking capabilities...

26. September 2024 um 13:00

Making Workers AI faster and more efficient: Performance optimization with KV cache compression and speculative decoding

With a new generation of data center accelerator hardware and using optimization techniques such as KV cache compression and speculative decoding, we’ve made large language model (LLM) inference lightning-fast on the Cloudflare Workers AI platform....

26. September 2024 um 13:00

Zero-latency SQLite storage in every Durable Object

Traditional cloud storage is inherently slow because it is accessed over a network and must synchronize many clients. But what if we could instead put your application code deep into the storage layer, such that your code runs where the data is stored? Durable Objects with SQLite do just that. ...