Barracuda WAF-as-a-Service REST API

Wären Sie gerne einmal faul? Möchten Sie mit weniger Aufwand mehr schaffen und Angriffe auf Ihre Websites verhindern? Dann sollten Sie diesen Artikel lesen! Wir haben ein paar tolle technische Tipps bezüglich der REST-API von Barracuda WAF-as-a-Service. Ich weiß, was Sie denken. Aber glauben Sie mir, das ist wirklich interessant für Sie. Es handelt sich nicht um ein Whitepaper. Es ist kein technisches Handbuch. Dies hier ist keine Abhandlung über hochmoderne Cloud-Automatisierung, und das muss es auch nicht sein. Wir können Sie mit einem Augenzwinkern beruhigen: Bei der Erstellung dieses Blogs kamen keine durchschnittlichen WAF-Nutzer zu Schaden. Wie bei den meisten Schulungsinhalten, die ich vermittle, gilt auch hier mein Motto: Sie müssen kein Experte sein!Barracuda WAF-as-a-Service bietet in der Cloud bereitgestellte, für Unternehmen geeignete Anwendungssicherheit ohne den Verwaltungsaufwand einer Hardware oder eines virtuellen Systems. Mit WAF-as-a-Service können Sie Ihre Anwendungen unabhängig von ihrem Standort innerhalb von Minuten sichern. Sie müssen keine Infrastruktur bereitstellen, skalieren, anpassen oder warten. Sie können in unserer eleganten, modernen REACT-Grafikschnittstelle klicken und tippen und darüber hinaus verfügt WAF-as-a-Service auch über eine großartige REST-API, mit der Sie Ihre Aufgaben automatisieren können.

Was ist diese sogenannte „REST-API“?

Anwendungsprogrammierschnittstellen (Application Programming Interfaces, kurz API) erleichtern die Arbeit. Sie ermöglichen es uns, Anwendungen zu schreiben, die automatisch Daten und Aktionen mit anderen Anwendungen austauschen. Diese Programme kommunizieren mit anderen Programmen und sind imstande, Einstellungen zu konfigurieren, Daten zu beobachten und zu messen sowie entsprechend zu agieren und zu reagieren. Diese Programme können sehr einfach sein, nämlich nur aus ein paar Zeilen Bash-Skript bestehen, aber auch so komplex wie eine voll funktionsfähige Produktionsanwendung.

API erleichtern uns das Leben, denn mit ihnen können wir Aufgaben aller Größenordnungen sehr zuverlässig und reproduzierbar bewältigen. API führen diese Aufgaben wiederholt aus – tausende Male, jedes Mal auf genau dieselbe Weise. Ohne API müssten wir dieselbe Aufgabe immer wieder manuell durchführen, und zwar fehlerfrei und blitzschnell. Unabhängig davon, wie benutzerfreundlich unsere grafische Benutzeroberfläche auch sein mag, wird dieser manuelle Ansatz in absehbarer Zeit nicht mit der Geschwindigkeit und Genauigkeit eines API-Ansatzes mithalten können.

Auch in unserer Netzwerk-, Sicherheits- und Cloud-Umgebung sind API sehr verbreitet. In unserer kürzlich durchgeführten Umfrage zum Stand der Anwendungssicherheit im Jahr 2021 gaben die Befragten an, dass sie im Durchschnitt 33 öffentlich zugängliche API haben. Ich denke, dass das wenig ist. Es ist jedoch verständlich, da es in vielen Unternehmen API gibt, die nicht bekannt sind.

Die Absicherung von API ist zwar von entscheidender Bedeutung, da eine ungeschützte API ein noch größeres Risiko darstellt als eine ungeschützte Website, doch heute geht es um die Verwendung von API für die Konfiguration und Verwaltung von WAF-as-a-Service. Wir konzentrieren uns dabei auf den API-Typ Representational State Transfer (REST), der kurz als REST-API bezeichnet wird.  Eine REST-API funktioniert folgendermaßen:

• Eine Client-Anwendung löst einen API-Aufruf aus, um bestimmte Informationen abzurufen. Dies wird als Anfrage bezeichnet.


• Diese Anfrage erfolgt über HTTPS und enthält ein Anfrageverb, Kopfzeilen und manchmal einen Anfragetext.


• Der Server empfängt die Anfrage und sendet eine HTTPS-Antwort mit den angeforderten Informationen.


• Die Client-Anwendung erhält die API-Antwort und verfügt somit über die angeforderten Informationen.

Grundlage von REST-API ist die Angabe von Aktionen mit HTTP-Methoden wie POST, GET, PUT und DELETE auf weitgehend ähnlichen Routen. (Eine „Route“ ist im Zusammenhang mit Web-API der Pfad zu einem API-Endpunkt, der in jeder Hinsicht einer URL sehr ähnlich ist, sollten Sie mit diesen vertraut sein.) Diese API ermöglichen es uns, Elemente eines bestimmten Dienstes zu erstellen, abzurufen, zu aktualisieren oder zu löschen, ohne dass wir für jede Aktion eine eigene URL erstellen müssen.

Angenommen, wir verwalten für ein landesweites Haustierdienstleistungsunternehmen eine Datenbank zur Pflege und medizinischen Versorgung von Haustieren. Diese Datenbank enthält die Daten von Zehntausenden von Haustieren.

Wir haben eine REST-API für unsere Haustierdatenbank erstellt, damit unser Entwicklerteam, welches das Web-Frontend programmiert, mit unserer Datenbank interagieren kann. Es ist wichtig, die Krankengeschichte eines Haustieres genau zu erfassen. Deshalb wird jedem Haustier eine eindeutige Identitätsnummer zugewiesen, die sich nie ändert. Wir verwenden diese eindeutige Nummer und nicht den Namen des Tieres, weil sich der Name irgendwann in der Zukunft ändern kann.

Haustiere haben auch Spitznamen, sodass sich in Bezug auf die Haustierkennung 10369 die folgenden exemplarischen REST-API-Transaktionen ergeben könnten, um einige einfache Aufgaben im Zusammenhang mit Spitznamen zu erledigen.

Gewünschte Aktion	HTTP-Methode (und Daten, falls vorhanden)	API-Route (im Prinzip eine URL)
Liste der Spitznamen für Haustier-ID 10639 abrufen	GET	/api/2.2/haustiere/10639/spitznamen
Den neuen Spitznamen „Snuffles“ zur Liste der Spitznamen für das Haustier 10639 hinzufügen	POST {"nicknames":{"name":"snuffles",}}	/api/2.2/haustiere/10639/spitznamen
Den Spitznamen „Snuffles„ in „Couchslayer“ ändern	PUT {"name":" couchslayer"}	/api/2.2/haustiere/10639/spitznamen/snuffles
Den Spitznamen „Couchslayer“ löschen	Löschen	/api/2.2/haustiere/10639/spitznamen/couchslayer

 
Bei diesem Beispiel handelt es sich um eine REST-API, da die URL (oder „Route“) im Wesentlichen gleich bleibt und sich nur die HTTP-Methode ändert, je nachdem, was erreicht werden soll. Wir benötigen nicht für jede Aktion („holen“, „hinzufügen“, „ändern“, „löschen“) eine andere URL (oder „Route“). Wir behalten die URL im Wesentlichen unverändert bei und ändern nur die HTTP-Methode.

Im Gegensatz zu älteren API-Technologien im Web, wie XML und SOAP, handelt es sich bei REST-API um eine moderne Technologie für die API-Entwicklung. Dazu gehören auch weitere Technologien, von denen ich hier zwei anführen möchte: graphQL und gRPC.

Diese drei sind die wichtigsten Bausteine für die moderne API-Entwicklung. Von diesen drei sind REST-API bei weitem am beliebtesten. Laut der RapidAPI 2019-2020 API-Umfrage haben 70,9 % der Befragten REST-APIs entweder in der Produktion oder in einem Proof of Concept (POC), verglichen mit nur 12,4 % für GraphQL und nur 7,3 % für gRPC.

Nachdem wir also die REST-API recht ausführlich vorgestellt haben, wollen wir nun kurz Barracuda WAF-as-a-Service vorstellen.

Barracuda WAF-as-a-Service

Barracuda WAF-as-a-Services (WAFAaS) ist ein voll funktionsfähiger, in der Cloud bereitgestellter Anwendungssicherheitsservice, der über Barracuda verfügbar ist und im Azure Marketplace und AWS Marketplace enthalten ist.

REST API in Kombination mit WAF-as-a-Service!

Die zentrale Start-Route der Barracuda WAF-as-a-Service REST-API ist https://api.waas.barracudanetworks.com/.

Wir verfolgen in diesem Beitrag einen Ansatz mit wenig Code, sodass Sie kein Entwickler oder gar Programmierer sein müssen, um diese Tipps nutzen zu können. Außerdem werden wir den „Crawl-Walk-Run“-Ansatz verwenden, den ich in Schulungen gerne zur Veranschaulichung nutze. Wir werden also der Reihe nach zuerst Swagger verwenden („Crawl“) und damit einen webbasierten, von der Benutzeroberfläche ausgehenden Ansatz verfolgen. Anschließend werden wir auch etwas cURL („Walk“) und schließlich ein wenig Python verwenden („Run“, auch wenn es eher wie Joggen anmutet und weniger wie ein Sprint).

Kommen wir zu den API-Versionen und ihrem Vorkommen in Routen. Nicht selten enthalten REST-API-Routen eine Versionsangabe. Sowohl für den cURL- als auch für den Python-Ansatz wird die „v2“-Version unserer API verwendet, sodass die Start-Route https://api.waas.barracudanetworks.com/v2/ lautet.

Zudem werden wir die Swagger-Schnittstelle verwenden. Dabei handelt es sich um eine Webseite, auf der wir die API ausprobieren und einige API-Aufrufe über eine grafische Benutzeroberfläche tätigen können. (Ja, ich weiß, das ist ein ziemlicher Widerspruch, aber glauben Sie mir, es wird am Ende alles Sinn ergeben). Swagger verwendet nicht die /v2, wodurch die vollständige URL https://api.waas.barracudanetworks.com/.

Crawling: Swagger

Swagger ist ein Open-Source-Framework, das eine automatisierte Dokumentation, Codegenerierung und Testfallerstellung unterstützt.

Die Swagger-URL lautet https://api.waas.barracudanetworks.com/swagger/#/, und Sie können diese in Ihrem Browser aufrufen.

Einloggen

Zunächst müssen Sie sich über die API-Anmeldung und -Authentifizierung anmelden, um die WAF-as-a-Service zu nutzen. Nach erfolgter Authentifizierung können Sie alle API-Befehle verwenden.

Klicken Sie auf Anmelden, klicken Sie auf Ausprobieren, geben Sie Ihren Benutzernamen und Ihr Passwort ein und gehen Sie auf Ausführen.

Hinweis: Ihre Anmeldedaten werden zwar durch SSL geschützt, werden jedoch unverschlüsselt angezeigt. Es wird daher dringend empfohlen, Ihren Bildschirm nicht herzuzeigen, z. B. im Falle, dass Sie ihn gemeinsam nutzen. Achten Sie also darauf, dass Sie an dieser entscheidenden Stelle keinen Zoom-Fehler machen!

 

 

 

Scrollen Sie nach der Anmeldung nach unten, bis Sie den Antworttext sehen, wählen Sie dann den gesamten Schlüssel aus (also alles zwischen dem Doppelpunkt und dem letzten Anführungszeichen) und kopieren Sie ihn.

Wenn der Schlüssel beispielsweise „AAAAasdlfkjasdlfkjasdflkjasdflkj..asdflkjZZZZ“ lautet, wie im Folgenden in gelber Farbe dargestellt, wählen Sie alles aus und kopieren alles zwischen „auth-api:“ und „-d“ (ohne die Anführungszeichen).  Das heißt, Sie kopieren von dem ersten A bis zu dem letzten Z, ohne Anführungszeichen:

curl -X POST "https://api.waas.barracudanetworks.com/v2/waasapi/api_login/" -H "accept: application/json" -H "Content-Type: application/x-www-form-urlencoded" -H "auth-api: AAAAdflkjasdflkjasdflkjasdflkjasdflkjasdflkjasdflkjasdflkjasdflkjasdflkjasdflkjasdlkfjasdlkjasldfkjasdlfkjasdflkjasdlfkjasldfkjasldfkjalsdZZZZ" -d "email=brett%40wolmarans.com&password=REDACTED"

Beim Kopieren können Sie die Maus verwenden, um den Text zu markieren und zu kopieren, oder nutzen Sie Strg-C, was auch immer Sie normalerweise zum Kopieren von Text verwenden – nehmen Sie das, was für Sie am besten funktioniert!

Mit dem API-Schlüssel (auch „Token“ genannt) in der Zwischenablage klicken Sie jetzt oben rechts auf Autorisieren klicken, wie hier gezeigt:

Fügen Sie Ihren API-Schlüssel ein, klicken Sie ein weiteres Mal auf Autorisieren und überprüfen Sie dann, ob „Autorisiert“ angezeigt wird (siehe unten).



 

 

Es versteht sich von selbst, aber ich werde es trotzdem sagen: Klicken Sie nicht auf die Schaltfläche „Abmelden“. Auch wenn die Versuchung noch so groß ist. Klicken Sie einfach vorsichtig auf Schließen.

Wenn alles geklappt hat, sehen Sie jetzt ein kleines Vorhängeschloss-Symbol auf der rechten Seite Ihrer Swagger-Oberfläche, wie hier abgebildet. Das Vorhängeschloss ist geschlossen, was bedeutet, dass Sie angemeldet sind (was etwas ungewohnt ist).

 

 

Abrufen einer Liste von Anwendungen

Klicken Sie auf Anwendungen und dann auf Ausprobieren. Klicken Sie auf Ausführen

 

 

Daraufhin werden Ihnen die Anzahl der Anwendungen, die Anwendungs-ID und die Endpunkt-ID angezeigt.

Im vorliegenden Beispiel gibt es zwei Anwendungen, aber nur die erste ist auf diesem Screenshot zu sehen.

Sie können die Anwendungs-ID für die erste Anwendung und die Endpunkt-ID sehen.

Außerdem sehen Sie, dass der Server Response Code eine 200 ist. Das ist sehr wichtig, denn die 200 zeigt Ihnen, dass der Befehl ohne Tippfehler funktioniert hat!

 

Perfekt, Sie haben es geschafft! So einfach ist das! Weitere Informationen über Swagger finden Sie unter https://swagger.io/. Gehen wir also einen Schritt weiter und untersuchen, wie man cURL verwendet, um einige REST-API-Aktionen durchzuführen.

Eine Anmerkung zu Anwendungs-IDs

Oben sehen Sie, dass die Anwendungs-ID für meine Anwendung 11818 lautet. Ihre einzelnen Anwendungen werden durch eine eindeutige Anwendungs-ID identifiziert und diese benötigen Sie, um die Routen für Ihre API-Aufrufe einzurichten. In den nächsten Beispielen werden deshalb weitere Anwendungs-IDs zu sehen sein.

Ein Hinweis zum Kopieren und Einfügen von cURL-Beispielen von Swagger

Swagger liefert Ihnen tolle cURL-Beispiele, wenn Sie Befehle ausführen. Diese können Sie kopieren und in Ihre cURL-Aktionen einfügen, um sie zu verwenden. Das erleichtert Ihnen die Arbeit! Wenn ich beispielsweise etwas relativ Übliches tun wollte, wie eine Anwendung vom „Passiv“-Modus (bei dem Angriffe protokolliert, aber nicht geblockt werden) in den „Aktiv“-Modus (bei dem Angriffe geblockt werden) zu versetzen, könnte ich dies zunächst in Swagger tun. Dazu müsste ich, wie hier gezeigt, nach unten zu den „Sicherheitsgrundlagen“ scrollen. Die Pfeile verdeutlichen, wo ich meine Anwendungs-ID eingegeben habe und wo ich „Aktiv“ eingegeben habe.

Wenn Sie dann etwas nach unten scrollen, finden Sie das cURL-Beispiel:

 

 

Sie können dieses Beispiel einfach kopieren und einfügen, ohne es zu ändern oder abzutippen. Das Ergebnis sieht folgendermaßen aus (die Pfeile kennzeichnen die ID und den aktiven Schutzmodus).  Es war nicht sehr aufwändig, dieses Beispiel zu erstellen. Nur ein paar Rechtsklicks mit der Maus und schon war alles fertig!

 

 

Walking: cURL

Beim Thema API bestand der erste Schritt aus dem Crawl, dem wir uns im Zusammenhang mit Swagger gewidmet haben. Jetzt lernen wir, wie man cURL verwendet.

cURL (Client-URL) ist ein Verfahren für unkomplizierte API-Aufrufe. Sie unterstützt eine Vielzahl von Protokollen und kann auf so gut wie jeder heute existierenden Plattform und Hardware verwendet werden. Für die Produktionsautomatisierung wird sie nicht empfohlen, aber sie lässt sich besser automatisieren als die Verwendung von Swagger über den Webbrowser.

Wenn Sie cURL verwenden, müssen Sie jedes Mal den Anmeldeschlüssel-Token verwenden, da wir diese Aufrufe autorisieren möchten.

Sie können ein kleines Hilfsskript verwenden, um Ihren Anmeldeschlüssel-Token als Umgebungsvariable zu setzen. Hier ist eins, das ich bereits erstellt habe. Sie können es hier finden:

https://raw.githubusercontent.com/bwolmarans/legendary-disco/main/bwafaas_login.sh

Hier ein Beispiel für die Verwendung dieses Hilfsskripts zum Anmelden. Sie haben wahrscheinlich schon bemerkt, dass die Anmeldedaten bei diesem kleinen Hilfsskript unverschlüsselt in die Bash-Befehlszeile übertragen werden. Es versteht sich von selbst, dass dies keineswegs die beste Vorgehensweise ist. Es gibt zwar einige sinnvolle Methoden, um Anmeldedaten sicher an Bash-Skripte zu übertragen, aber keine davon wird hier verwendet.

Teilen Sie also nicht Ihren Zoom-Bildschirm, während Sie die erste Anmeldung ausführen!

 

 

Sobald Sie sich nun angemeldet haben und Ihre Umgebungsvariable WAAS_API_KEY gesetzt ist, können Sie API-Aufrufe über cURL tätigen, ohne diese lästigen Anmeldedaten übergeben zu müssen, da der Token das für Sie übernimmt.

Wenn Sie nun ein wenig über Ihren Bildschirm scrollen, können Sie Ihren Zoom-Bildschirm ohne Probleme zeigen, während Sie Ihren Kollegen die verschiedenen cURL-Befehle vorführen, um Ihr WAFaaS wie hier gezeigt zum Laufen zu bringen, ohne jemals Ihre Anmeldedaten preiszugeben.

Ein Beispiel für die Abfrage aller Infos zu allen Anwendungen in Ihrem WAFaaS-Konto:

 

 

Wenn Sie nicht alle Einzelheiten sehen möchten, können Sie sich die Namen und ID-Nummern Ihrer Anwendungen schnell und einfach anzeigen lassen, ohne dass es zu kompliziert wird. Hier geht es weder um Geschwindigkeits- oder Effizienzweltrekorde, noch um einen Wettbewerb auf https://www.topcoder.com/. Wir versuchen nur, etwas zu verdeutlichen, und zwar: Es ist ganz einfach!

 

 

Wissen Sie noch, wie wichtig diese Anwendungs-IDs waren? Hier sehen Sie, wie man sie erhält. Das ist wichtig, wenn Sie beispielsweise eine Anwendung von „Aktiv“ auf „Passiv“ umstellen möchten. Das können Sie mit cURL tun, aber Sie benötigen die ID (nicht den Namen), wie Sie hier sehen:

 

 

Und wie jeder, der mich kennt, bestätigen kann: ich bin faul und tippe nicht gerne. Also habe ich diese langatmigen cURL-Befehle nicht mühsam von Hand eingetippt. Ich habe sie aus der Swagger-Web-Benutzeroberfläche kopiert und eingefügt, die wir weiter oben im Abschnitt „Crawl“ behandelt haben. Das ist sehr wichtig.

Run: Python

Python ist eine sehr beliebte Programmiersprache und der empfohlene Ansatz für die Automatisierung. Um diese Sprache geht es im nächsten Schritt unseres „Crawl-Walk-Run-Ansatzes“.

Hier ein Beispiel für ein einfaches Python-Skript für die Anmeldung und Auflistung der Anwendungen. Das Skript erhalten Sie hier:

https://raw.githubusercontent.com/barracudanetworks/waf-automation/master/waf-as-a-service-api/waas_rest_api_example.py

 

 

Wenn wir zum Beispiel das Skript ausführen, sehen wir etwas Ähnliches wie bei der Verwendung von cURL, nämlich eine Liste mit unseren Anwendungen:

 

 

Zusammenfassung

Zusammenfassend lässt sich sagen, dass wir über eine voll funktionsfähige REST-API für Barracuda WAF-as-a-Service verfügen. Mit der API können Sie die wichtigen Grundlagen für eine Automatisierung und DevOps schaffen. Dazu gehört nicht zuletzt, dass Sie eine Aufgabe immer wieder auf die gleiche Weise ausführen können, indem Sie Programmierschnittstellen verwenden.

Wir haben mittels des „Crawl-Walk-Run“-Ansatzes drei Möglichkeiten kennengelernt, mit der API zu arbeiten. Begonnen haben wir mit der einfachen Verwendung der Swagger-Schnittstelle, anschließend sind wir dazu übergegangen, einige cURL-Befehle zu verwenden, und schließlich haben wir uns angesehen, wie man die API in Python nutzen kann.

Doch wie, so werden Sie sich fragen, lässt sich das alles in eine vollständige CI/CD-Pipeline für Anwendungen integrieren? Ich jogge gerne, aber ich sprinte noch viel lieber! Gibt es Beispiele für den Aufbau einer Pipeline, über die wir unsere WAF-as-a-Service-Konfiguration mit denselben DevOps-Mustern bereitstellen können, die wir für die Bereitstellung unserer Anwendungen verwenden? Die Antwort auf diese und weitere Fragen werden wir in einem weiteren Blog-Beitrag zum Thema API in nicht allzu ferner Zukunft geben. Es lohnt sich also, dranzubleiben!

Sollten Sie Fragen zu dieser grundlegenden Einführung in unsere REST-API haben oder Fehler in meinen Beispielen finden, zögern Sie bitte nicht, sich mit mir, Brett Wolmarans, über bwolmarans@barracuda.com in Verbindung zu setzen.