Wenn von Anwendungs-Firewalls die Rede ist, werden oft verschiedene Dinge unter einem Oberbegriff zusammengefasst. Doch nicht alle Firewalls sind gleich, und das Verständnis der Unterschiede zwischen ihnen ist wichtig, besonders wenn Sie herausfinden möchten, welchen Schutz Ihre Anwendung tatsächlich benötigt.
Lassen Sie uns das genauer betrachten. Es gibt drei Hauptschichten der Anwendungssicherheit, die Sie kennen sollten: WAFs, In-App und In-Kernel. RASP und einige ADRs sind In-App, während eBPF-basierte ADRs auf niedrigerer Ebene In-Kernel sind. Sie alle verfolgen das gleiche übergeordnete Ziel, schädliche Ereignisse für Ihre Anwendung zu verhindern, doch die Art und Weise, wie sie dies tun, ist sehr unterschiedlich. Kurz gesagt: WAF sieht die Anfrage, In-App sieht den Code und In-Kernel sieht das Betriebssystem.
Welche benötigen Sie? Wenn Sie die bestmögliche Sicherheitslage anstreben, höchstwahrscheinlich mehr als eine. In diesem Artikel erklären wir, was WAFs, RASP, ADR und eBPF sind, wofür jede einzelne am effektivsten ist und helfen Ihnen zu entscheiden, welche davon Sie benötigen.
WAF VS RASP VS ASP: Wie funktionieren die drei Schichten der Anwendungssicherheit?
Anwendungssicherheitstools arbeiten auf drei verschiedenen Ebenen, und jedes fängt Dinge ab, die die anderen nicht können.
WAF: Edge-Sicherheit
WAFs sitzen vollständig außerhalb Ihrer Anwendung und inspizieren eingehenden HTTP-Verkehr, bevor er Ihre Anwendung erreicht. Kein Anwendungskontext, aber hervorragend für Bedrohungen mit hohem Volumen.
In-App Runtime Security: innerhalb der Anwendung
In-App-Sicherheitsinstrumente greifen direkt in Ihre Anwendung ein. Sie klinken sich in die Ausführung Ihres Codes ein, verfolgen, wie Benutzereingaben durch Ihre Anwendung fließen, und können Angriffe genau an dem Punkt blockieren, an dem sie gefährlich werden, bevor eine bösartige Payload Ihren Datenbanktreiber erreicht oder eine Shell startet. Da sie einen vollständigen Anwendungskontext hat, ist sie präzise. RASP-Tools, eine Unterkategorie von ADR, fallen in diese Kategorie.
In-Kernel Runtime Security: unterhalb der Anwendung
In-Kernel Runtime Security Tools sitzen vollständig unterhalb Ihrer Anwendung, auf Betriebssystemebene. Anstatt sich in den Anwendungscode einzuklinken, überwachen sie jeden Systemaufruf, der von jedem Prozess auf dem Host getätigt wird. Sie haben keine Ahnung, was Ihre Anwendungslogik tut, sehen aber alles auf Betriebssystemebene, einschließlich dessen, was passiert, nachdem ein Angreifer bereits eingedrungen ist. eBPF-basierte ADR-Tools fallen in diese Kategorie.
Wir werden uns zunächst WAF ansehen, dann In-App und In-Kernel durch die Brille von RASP und ADR.
Was ist WAF?
Eine WAF (Web Application Firewall) sitzt außerhalb Ihrer Anwendung, am Edge. Bevor eine Anfrage Ihre Anwendung überhaupt erreicht, fängt die WAF sie ab und prüft sie anhand einer Liste bekannter Angriffsmuster wie SQL-Injection-Strings, bösartiger Header oder verdächtiger URLs. Wenn etwas einem Muster entspricht, wird es blockiert.
Wo WAFs wirklich unersetzlich sind, ist bei volumetrischen Angriffen, wie DDoS-Verkehr, Bot-Floods und Scrapern. WAFs sind für hochvolumige Brute-Force-Angriffe konzipiert. Cloudflare beispielsweise ist extrem gut darin, groß angelegte Angriffe abzufangen, bevor sie überhaupt mit Ihrer Infrastruktur interagieren. Sie sind auch einfach bereitzustellen. Meistens eine DNS- oder Proxy-Änderung, kein Code zu schreiben, nichts in Ihrer Anwendung zu installieren. WAFs sind auch sehr konfigurierbar mit benutzerdefinierten Regeln, Allowlists und Regelanpassungen, und Sie können auch entscheiden, ob Sie etwas Verdächtiges blockieren oder nur erkennen möchten.
Der Haken ist, dass eine WAF keine Ahnung hat, was passiert, sobald eine Anfrage die Tür passiert hat. Sie kann eine verdächtig aussehende Payload erkennen, aber sie kann Ihnen nicht sagen, ob diese Payload tatsächlich etwas Gefährliches anrichten wird, da sie keine Ahnung hat, was Ihre Anwendung tatsächlich mit einer Anfrage tun wird. Sie sieht eingehenden Verkehr, gleicht ihn mit den Mustern ab, die sie stoppen soll, und entscheidet, ob sie ihn blockiert.
Infolgedessen sind False Positives ein echtes Problem, und sie kann Anfragen leicht überblockieren. Ein Benutzer kann nach etwas suchen, das wie SQL aussieht, und wird blockiert, während ein cleverer Angreifer seine Payload anders kodiert und durchkommt. Und wenn eine WAF einen bösartigen Benutzer stoppen will, blockiert sie dessen IP. Dann kann ein Angreifer einfach ein VPN verwenden, um dies zu umgehen. Wenn Sie dann aber versuchen, den gesamten VPN-Verkehr zu blockieren, blockieren Sie auch echte Benutzer.
Infolgedessen ist die WAF-Abstimmung ein fortlaufender Prozess, bei dem Regeln verschärft, False Positives überwacht und bei Bedarf gelockert werden. Dies ist einer der Gründe, warum WAFs im Vergleich zu RASP wartungsintensiver sein können, das weitaus weniger fortlaufende Abstimmung benötigt, da es den Anwendungskontext hat, um bessere Entscheidungen ohne manuelles Eingreifen zu treffen.
Beispiele: Cloudflare, AWS WAF, Imperva
Open Source: ModSecurity (via OWASP)
Was ist RASP?
RASP (Runtime Application Self-Protection) und In-App-ADR sind Laufzeit-Sicherheitslösungen, die in Ihrer Anwendung residieren und diese während der Ausführung von innen überwachen, anstatt außerhalb Ihrer Anwendung den eingehenden Traffic wie ein WAF zu inspizieren.
Um zu verstehen, warum dies wichtig ist, müssen Sie Sinks kennen. Ein Sink ist eine Funktion – in Ihrem Code, einer Bibliothek oder einem integrierten Modul –, bei der Benutzereingaben aufhören, reine Daten zu sein, und als etwas Sinnvolles ausgeführt werden. Eine SQL-Injection kann als Beispiel dienen. Ein Angreifer platziert bösartigen Code in einem Formularfeld, der durch Ihre Anwendung fließt, auf Ihren Datenbanktreiber trifft (einige db.query()), und an diesem Punkt hört es auf, Text zu sein, und wird zu einem Befehl. Diese Abfragefunktion ist der Sink. Was In-App-Sicherheitstools wie RASP tun, ist, sich in diese Sinks einzuhaken und zu beobachten, wie Eingaben durch die App fließen, und sie bis zur gefährlichen Funktion zu verfolgen.
Da diese In-App-Tools nun einmal in Ihrer Anwendung laufen, wissen sie, was die Eingabe ist, woher sie kam und wohin sie geht. Anstatt zu raten, ob ' OR 1=1-- ein Angriff oder eine legitime Suchzeichenfolge ist, weiß ein In-App-Tool, dass diese spezifische Zeichenfolge von req.body.user, unsaniert verkettet wurde und kurz davor steht, einen pg.query() Aufruf zu treffen. Blockieren Sie es!
Die Fehlalarmraten sind viel niedriger als bei WAF und eBPF-basiertem ADR, da es nicht nur blind Muster abgleicht. Es kann eine Benutzer-ID statt nur einer IP blockieren, sodass ein Angreifer nicht einfach ein VPN verwenden kann. Und da es den Datenfluss verfolgt, anstatt bekannte Signaturen abzugleichen, kann es neue Angriffspayloads erkennen, die noch niemand zuvor gesehen hat. Solide Zero-Day-Abdeckung für Injection-Angriffe!
RASP und In-App-ADRs decken auch Drittanbieter-Abhängigkeiten ab. Sie können Ihren eigenen Code perfekt bereinigen, aber wenn eine von Ihnen verwendete Bibliothek eine Schwachstelle aufweist, liegt das außerhalb Ihrer Kontrolle (falls Ihr SCA-Scanner dies nicht ebenfalls erkannt hat). RASP arbeitet auf Sink-Ebene, unabhängig davon, woher der Code stammt.
Die eine primäre Einschränkung der In-App-Sicherheit besteht darin, dass, wenn ein Angreifer die Laufzeit vollständig umgeht, sei es durch ein natives Addon oder einen direkten Systemaufruf, die Hooks niemals ausgelöst werden. Und sobald eine Shell erzeugt wird, sieht RASP den ursprünglichen Aufruf, aber nicht, was danach in dieser Shell geschieht. Hier kommt die dritte Schicht ins Spiel.
Beispiele: Aikido Zen (Open Source und kostenpflichtige Version)
Was ist ADR?
ADR (Application Detection and Response) ist die breitere, moderne Kategorie, unter die RASP fällt. Jedes RASP ist ADR, aber nicht jedes ADR ist RASP. Der Begriff ADR umfasst jedes Tool, das Angriffe zur Laufzeit überwacht und darauf reagiert, sei es innerhalb Ihrer Anwendung oder vollständig darunter.
In der Praxis teilen sich ADR-Tools in zwei Varianten auf. In-App-ADR (was RASP schon immer war) sitzt direkt in Ihrer Anwendung und verfügt über den vollständigen Code-Level-Kontext. Alles, was im obigen RASP-Abschnitt über In-App-Sicherheit behandelt wurde, gilt hier. ADR impliziert auch einen breiteren Anwendungsbereich als RASP; während RASP primär ein Blocking-Tool ist, umfasst ADR auch Erkennungs-, Sichtbarkeits- und Incident-Response-Funktionen. Nicht jedes ADR-Tool leistet all dies, aber es ist die Richtung, in die sich die Kategorie bewegt.
Die andere Art von ADR, In-Kernel-ADR oder eBPF-basiertes ADR, verfolgt einen anderen Ansatz zum Schutz von Anwendungen. Anstatt sich in Ihre Anwendung einzuhaken, sitzt es auf der Ebene des Linux-Kernels und überwacht jeden Systemaufruf, der von jedem Prozess auf dem Host getätigt wird. Es weiß nichts über die Logik Ihrer Anwendung, sieht aber alles auf Betriebssystemebene.
Sobald ein Angreifer eine Shell erzeugt hat, bietet In-Kernel-ADR die nächste Ebene der Sichtbarkeit nach der Ausnutzung, die In-App-ADR nicht sehen kann. In-Kernel-ADR sieht jeden Befehl, der innerhalb dieser Shell ausgeführt wird, wie Dateilesevorgänge, Netzwerkaufrufe und laterale Bewegungen. Wenn ein Angreifer die Laufzeit vollständig umgeht, sieht ADR immer noch den execve unabhängig davon, wie er ausgelöst wurde. In der Praxis ist das häufigste Szenario für Node.js-Anwendungen ein bösartiges natives Addon, das durch einen Supply-Chain-Angriff eingeschleust wird (eine kompromittierte Abhängigkeit, die nativen Code enthält, den Ihre Laufzeit nicht inspiziert).
eBPF (Extended Berkeley Packet Filter) ist die zugrunde liegende Kernel-Technologie, die In-Kernel-ADR-Tools antreibt. eBPF ermöglicht es Ihnen, ein sicheres Überwachungsprogramm an den Linux-Kernel anzuhängen, das spezifische Ereignisse auf Betriebssystemebene beobachten kann, ohne den Kernel selbst zu berühren. Normalerweise müssten Sie, wenn Sie eine benutzerdefinierte Überwachung oder Logik auf Kernel-Ebene hinzufügen möchten, entweder den Quellcode des Kernels direkt ändern (riskant, komplex) oder ein Kernel-Modul schreiben (ebenfalls riskant, da ein Fehler das gesamte System zum Absturz bringen kann). eBPF umgeht dies, indem es Ihnen ermöglicht, kleine Programme in den Kernel zu injizieren, die in einer Sandbox-Umgebung ausgeführt werden. Diese Programme beobachten spezifische Systemaufrufe und melden sie an das ADR-Tool zurück, das dann entscheidet, ob die Aktion zugelassen oder blockiert werden soll.
Der Kompromiss bei In-Kernel-ADR, ähnlich wie bei WAF, ist das Fehlen von App-Kontext. Es werden rohe Systemaufrufe erfasst, wie „Prozess 4821 hat ein Programm ausgeführt“, aber es gibt keine Information darüber, welche HTTP-Anfrage oder welcher Benutzer dies ausgelöst hat. Ohne diesen Kontext muss sich die In-Kernel-Sicherheit stattdessen auf Richtlinien stützen, d.h. Regeln wie „dieser Prozess sollte niemals eine Shell starten“ oder „dieser Container sollte niemals in dieses Verzeichnis schreiben“. Das funktioniert, um klare Verstöße zu erkennen, macht es aber recht binär und lässt keine Nuancen zu.
Bei Injection-Angriffen wie SQL-Injection ist In-Kernel-ADR weitgehend blind. Wenn der Angriff die Systemaufruf-Ebene erreicht, ist der SQL-Payload nur noch rohe Bytes innerhalb eines Netzwerkpuffers. In-Runtime-Exploits sind ein weiterer blinder Fleck. Einige Angriffe erfolgen vollständig innerhalb der Sprach-Runtime, sodass sie erst dann eine ungewöhnliche Operation auf Betriebssystem-Ebene erzeugen, wenn es bereits zu spät ist.
Im Gegensatz zu traditionellen RASP-Tools erfordert diese Art von ADR keine Änderungen am App-Code für die Einrichtung. Allerdings sind die Einrichtung und die Anforderungen höher als bei WAF oder RASP, da ADR-Tools im Allgemeinen einen relativ modernen Linux-Kernel und erhöhte Systemberechtigungen benötigen.
Beispiele: Tetragon, Falco, KubeArmor (Open Source)
Oligo ADR (kommerziell)
WAF, RASP, ADR, eBPF: Welches brauche ich?
Inzwischen haben wir viele Begriffe behandelt – WAF, RASP, ADR, eBPF, In-App, In-Kernel. Die kurze Antwort ist, dass Sie Schutz auf mehreren Ebenen wünschen. Die längere Antwort hängt davon ab, welche Ebenen. Wenn es um RASP vs. ADR geht, ist RASP eine Unterkategorie von ADR, daher stellt sich die Frage: Möchten Sie In-App-Sicherheit, In-Kernel-Sicherheit oder beides?
Die verschiedenen Ebenen sind komplementär und nicht konkurrierend, da jede Dinge erfasst, die die anderen nicht können. Deshalb lautet die Antwort auf „WAF oder RASP?“ meistens „beides“, und das Hinzufügen von In-Kernel-ADR bietet Ihnen die Post-Exploitation- und Kernel-Ebene-Abdeckung, die das Gesamtbild abrundet.
Die drei Ebenen stellen grundlegend unterschiedliche Fragen:
- WAF: „Entspricht diese HTTP-Anfrage einem bekannten Angriffsmuster?“
- In-App-Sicherheit (RASP und ADR): „Wird diese Benutzereingabe gleich eine gefährliche Funktion in meiner App treffen?“
- In-Kernel-Sicherheit (ADR): „Hat dieser Prozess gerade etwas getan, was er auf Betriebssystem-Ebene nicht hätte tun sollen?“
TL;DR: Besorgen Sie sich zuerst eine WAF und ein In-App-Sicherheitstool. Ein eBPF-gestütztes ADR können Sie später hinzufügen, wenn Sie eine spezifische Kernel-Ebene-Verarbeitung benötigen.
In-App-Sicherheit wie RASP ist die einzige Ebene, die Kontext darüber hat, wie Daten mit der spezifischen App interagieren, und somit die einzige Ebene, die wirklich präzises Blocking durchführen kann. Daher hat sie natürlich die wenigsten False Positives im Vergleich zu den anderen beiden. Während In-App-Laufzeitschutz die meisten Angriffe auf Anwendungsebene oder Injection-Angriffe bewältigen kann, ist eine WAF für Angriffe mit hohem Volumen, wie DDoS, erforderlich. Da WAFs außerhalb der Anwendung sitzen, können sie Tausende von Bot-Anfragen verarbeiten, bevor diese Ihre Anwendung erreichen und deren Ressourcen belasten, und dies erfordert nicht viel Kontext, um zu funktionieren. Zusammen decken In-App-Sicherheit wie Aikido Zen in Kombination mit einer WAF die überwiegende Mehrheit der Probleme ab, denen Sie begegnen werden.
Wenn Sie an dem Punkt sind, an dem Sie volle Post-Exploitation-Sichtbarkeit benötigen, sich Sorgen um Lateral Movement machen oder eine Kernel-Ebene-Richtliniendurchsetzung über mehrere Prozesse hinweg benötigen, dann sollten Sie über die Hinzufügung von In-Kernel-ADR nachdenken. Es ist das richtige Tool für ein ausgereifteres Sicherheits-Setup, wenn auch nicht unbedingt das erste, wonach man greifen sollte. Einige In-App-ADR-Tools decken mehr ab als andere. Aikido Zen zum Beispiel überwacht ausgehende Aktivitäten (SQL-Abfragen, Shell-Befehle, Dateilesevorgänge und ausgehende HTTP-Aufrufe), die Ihre App tätigt. Und im Vergleich zu einem komplizierteren In-Kernel-ADR-Setup können Teams Zen mit einem einzigen npm install und einer Codezeile einrichten.
Das Einzige, was In-Kernel-ADR über Zen hinaus abdeckt, ist das, was passiert, nachdem eine Shell bereits gestartet wurde und der Angreifer auf Betriebssystem-Ebene agiert. Zen wird eBPF also nicht ersetzen, wenn Sie diese volle Post-Exploitation-Sichtbarkeit und Kernel-Ebene-Richtliniendurchsetzung über alle Prozesse hinweg benötigen. Für die meisten Teams deckt es jedoch die Angriffsfläche ab, die am wichtigsten ist (Injection-Angriffe, Zero-Days und Autorisierungslogik). Wenn Sie jedoch ein anderes RASP haben, das die ausgehenden Aktivitäten und SQL-Injections nicht abdeckt, benötigen Sie eBPF möglicherweise früher.
Zen von Aikido: Das moderne In-App-ADR
Obwohl sie ähnliche Ziele verfolgen, sind nicht alle In-App-Sicherheitstools gleich. Neue ADRs wie Zen, Aikidos Open-Source In-App-Firewall, befinden sich im Bereich der In-App-Sicherheit, decken aber Bereiche ab, die ein Standard-RASP-Tool nicht abdeckt.
Zen bietet den vollen App-Kontext traditioneller RASPs, wie Taint Tracing, Sink-Level-Blocking, Benutzer-ID-Erkennung und wenige False Positives. Als modernes ADR überwacht Zen jedoch auch ausgehende Aktivitäten, so wie es In-Kernel-ADR tut. Das umfasst jede SQL-Abfrage, jeden Shell-Befehl, jeden Dateilesevorgang und jeden ausgehenden HTTP-Aufruf, den Ihre App tätigt. Sein Schwachstellenalgorithmus ist ab der ersten Anfrage deterministisch, sodass es kein Kaltstartproblem und keine fortlaufende Regelwartung gibt, wie sie andere RASPs haben.
Zen geht auch über Injection-Angriffe hinaus. Es parst jede SQL-Abfrage zur Laufzeit mithilfe eines vollständigen SQL-Parsers (in Rust entwickelt) und erzwingt Tenant Scoping automatisch. Wenn einer Abfrage ein Tenant-Filter fehlt oder die falsche Tenant-ID verwendet wird, löst Zen einen Fehler aus, bevor sie ausgeliefert wird. IDORs (Insecure Direct Object References) sind die häufigste Ursache für mandantenübergreifende Datenlecks in Multi-Tenant-SaaS und notorisch schwer in Code-Reviews zu erkennen. Zen macht es unmöglich, sie versehentlich zu deployen.
Weiterführende Lektüre: Zero-Day-Angriffsprävention für Node.js mit Aikido Zen
Häufig gestellte Fragen
Was ist eine WAF?
Eine WAF (Web Application Firewall) sitzt außerhalb Ihrer Anwendung und inspiziert eingehenden HTTP-Traffic auf bekannte Angriffsmuster. Sie ist besonders gut darin, volumetrische Bedrohungen wie DDoS-Angriffe und Bot-Traffic zu handhaben, hat aber keine Sichtbarkeit darüber, was Ihre App tatsächlich mit einer Anfrage macht.
Was ist RASP-Sicherheit?
RASP (Runtime Application Self-Protection) ist ein Sicherheitstool, das innerhalb Ihrer Anwendung läuft. Es überwacht, wie Benutzereingaben durch Ihren Code fließen, und blockiert Angriffe an dem Punkt, an dem sie gefährlich werden: dem Sink. Da es den vollständigen App-Kontext hat, ist es bei Injection-Angriffen wesentlich genauer als eine WAF.
Was ist der Unterschied zwischen WAF und RASP?
Eine WAF befindet sich außerhalb Ihrer App und blockiert Traffic basierend auf Mustern. Ein RASP befindet sich innerhalb Ihrer App und blockiert Angriffe basierend darauf, was Ihr Code tatsächlich mit Benutzereingaben vorhat. WAFs sind einfacher bereitzustellen und eignen sich hervorragend für volumetrische Bedrohungen. RASPs haben niedrigere Fehlalarmraten und eine bessere Abdeckung für Injection-Angriffe und Zero-Days.
Benötige ich sowohl eine WAF als auch ein RASP?
Ja, sie ergänzen sich, anstatt zu konkurrieren. Eine WAF übernimmt den Edge-Level-Schutz und volumetrischen Traffic. Ein RASP kümmert sich um Injection-Angriffe und Zero-Days, die WAFs routinemäßig übersehen. Die meisten ausgereiften Sicherheitskonfigurationen verwenden beide.
Was ist ADR vs. RASP?
Im Allgemeinen umfasst ADR Tools, die entweder In-App- oder In-Kernel-Sicherheit bieten. RASP bezieht sich auf In-App-Tools und ist eine Untergruppe von ADR. RASP und In-App-ADR sind technisch gesehen derselbe Ansatz, nur unterschiedliche Bezeichnungen im Laufe der Zeit. Das ADR-Label ist neuer und umfassender. Manchmal wird ADR als Kurzform oder austauschbar mit eBPF, kernelbasierten ADR-Tools, verwendet. Die Begriffe für RASP und ADR variieren leicht, je nachdem, wen man fragt. Beachten Sie dies bei weiteren Recherchen zu diesem Thema.
Was ist ADR / eBPF in der Anwendungssicherheit?
ADR (Application Detection and Response) umfasst sowohl In-App- als auch In-Kernel-Sicherheit. In-Kernel-ADR-Tools wie Tetragon oder Falco arbeiten auf Linux-Kernel-Ebene und überwachen jeden Systemaufruf über jeden Prozess auf dem Host. Sie sind stark in der Post-Exploitation-Sichtbarkeit und beim Abfangen von Kernel-Level-Bypässen, haben aber keinen App-Kontext, was sie eher zu einer Ergänzung für RASP als zu einem Ersatz macht. eBPF (Extended Berkeley Packet Filter) ist die zugrunde liegende Kernel-Technologie, die In-Kernel-ADR-Tools antreibt.
Wenn alle Eingaben korrekt bereinigt werden, benötige ich dann immer noch RASP?
Ja. Die Bereinigung ist nicht immer perfekt umzusetzen. Besonders wenn SAST- und Code-Qualitäts-Tools während der Entwicklung fehlen, können Sicherheitslücken in die Codebasis gelangen. Betrachten Sie es weniger als Ersatz für gute sichere Codierungspraktiken, sondern eher als Laufzeit-Absicherung für den Fall, dass diese Praktiken nicht perfekt sind (was sie in der Praxis natürlich nie sind). RASP stoppt auch Probleme, die von Drittanbieter-Abhängigkeiten herrühren.
