{"id":55733,"date":"2020-01-27T00:00:00","date_gmt":"2020-01-26T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/evolyutsiya-web-application-firewall-ot-setevyh-ekranov-do-oblachnyh-sistem-zashhity-s-mashinnym-obucheniem"},"modified":"2020-02-18T14:03:52","modified_gmt":"2020-02-18T11:03:52","slug":"evolyutsiya-web-application-firewall-ot-setevyh-ekranov-do-oblachnyh-sistem-zashhity-s-mashinnym-obucheniem","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/evolyutsiya-web-application-firewall-ot-setevyh-ekranov-do-oblachnyh-sistem-zashhity-s-mashinnym-obucheniem","title":{"rendered":"Die Evolution des Web Application Firewalls: von Netzwerk-Firewalls zu Cloud-Sicherheitssystemen mit maschinellem Lernen.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

In unserem vorherigen Material zum Thema Cloud haben wir und berichteten<\/a><\/noindex>, wie man IT-Ressourcen in der Public Cloud sch\u00fctzt und warum traditionelle Antivirenl\u00f6sungen daf\u00fcr nicht ganz geeignet sind. In diesem Beitrag setzen wir das Thema Cloud-Sicherheit fort und sprechen \u00fcber die Entwicklung von WAF und dar\u00fcber, was besser zu w\u00e4hlen ist: Hardware, Software oder Cloud.\u00a0<\/b><\/p>\n

\"Die
\n<\/p>\n

Was ist WAF<\/h3>\n

\nM\u00e1s de 75 % der Hackerangriffe zielen auf Schwachstellen in Webanwendungen und Websites ab: Solche Angriffe sind in der Regel f\u00fcr die Informationssicherheitsinfrastruktur und -dienste nicht erkennbar. Schwachstellen in Webanwendungen bergen wiederum Risiken von Kompromittierung und Betrug bei Benutzerkonten und personenbezogenen Daten, Passw\u00f6rtern, Kreditkartennummern. Dar\u00fcber hinaus dienen Schwachstellen auf Websites Cyberkriminellen als Einstiegspunkt in das Unternehmensnetzwerk.<\/p>\n

Ein Webanwendungsfirewall (WAF) ist eine Schutzmauer, die Angriffe auf Webanwendungen blockiert: SQL-Injection, Cross-Site-Scripting, Remote Code Execution, Brute Force und Authentifizierungsumgehung (Auth Bypass). Dazu geh\u00f6ren auch Angriffe, die Zero-Day-Schwachstellen ausnutzen. Anwendungsfirewalls bieten Schutz, indem sie den Inhalt von Webseiten \u00fcberwachen, einschlie\u00dflich HTML, DHTML und CSS, und potenziell sch\u00e4dliche HTTP\/HTTPS-Anfragen filtern.
\n<\/a><\/noindex><\/p>\n

Wie sahen die ersten L\u00f6sungen aus?<\/h3>\n

\nDie ersten Versuche, eine Webanwendungsfirewall zu entwickeln, wurden bereits zu Beginn der 90er Jahre unternommen. Es ist bekannt, dass mindestens drei Ingenieure in diesem Bereich t\u00e4tig waren. Der erste ist Professor der Informatik Jean Spafford von der Purdue University. Er beschrieb die Architektur einer Anwendungsfirewall mit Proxy und ver\u00f6ffentlichte sie 1991 in seinem Buch \u201ePractical UNIX Security\u201c<\/a><\/noindex>.<\/p>\n

Die zweiten und dritten waren die Informationssicherheitsexperten William Cheswick und Marcus Ranum von Bell Labs. Sie entwickelten einen der ersten Prototypen von Anwendungsfirewalls. Die Verbreitung \u00fcbernahm das Unternehmen DEC \u2013 das Produkt wurde unter dem Namen SEAL (Secure External Access Link) ver\u00f6ffentlicht. <\/p>\n

SEAL war jedoch keine vollwertige WAF-L\u00f6sung. Es handelte sich um eine klassische Netzwerkwall mit erweiterten Funktionen \u2013 der M\u00f6glichkeit, Angriffe auf FTP und RSH zu blockieren. Aus diesem Grund gilt heute das Produkt des Unternehmens Perfecto Technologies (sp\u00e4ter Sanctum) als erste WAF-L\u00f6sung. Im Jahr 1999 brachte es heraus. hat<\/a><\/noindex> AppShield-System. Zu dieser Zeit entwickelte Perfecto Technologies Informationssicherheitsl\u00f6sungen f\u00fcr den E-Commerce, und die Zielgruppe ihres neuen Produkts waren Online-Shops. AppShield konnte HTTP-Anfragen analysieren und Angriffe basierend auf dynamischen Informationssicherheitsrichtlinien blockieren.<\/p>\n

Etwa zur gleichen Zeit wie AppShield (im Jahr 2002) wurde das erste Open-Source-WAF eingef\u00fchrt. Es wurde ModSecurity<\/a><\/noindex>. Es wurde mit dem Ziel entwickelt, WAF-Technologien popul\u00e4r zu machen, und wird bis heute von der IT-Community unterst\u00fctzt (hier ist sein Repository auf GitHub<\/a><\/noindex>). ModSecurity blockiert Angriffe auf Anwendungen, basierend auf einem standardm\u00e4\u00dfigen Satz von regul\u00e4ren Ausdr\u00fccken (Signaturen) \u2014 Tools zur \u00dcberpr\u00fcfung von Anfragen anhand von Mustern \u2014 OWASP Core Rule Set<\/a><\/noindex>.<\/p>\n

Insgesamt gelang es den Entwicklern, ihr Ziel zu erreichen \u2014 neue WAF-L\u00f6sungen begannen auf dem Markt zu erscheinen, darunter auch solche, die auf ModSecurity basieren.<\/p>\n

Drei Generationen \u2014 bereits Geschichte<\/h3>\n

\nEs ist \u00fcblich, drei Generationen von WAF-Systemen zu unterscheiden, die sich mit der Weiterentwicklung der Technologie entwickelt haben.<\/p>\n

Die erste Generation<\/b>. Arbeitet mit regul\u00e4ren Ausdr\u00fccken (oder Grammatiken). Dazu geh\u00f6rt ModSecurity. Der Anbieter des Systems untersucht die Arten von Angriffen auf Anwendungen und erstellt Muster, die legitime und potenziell sch\u00e4dliche Anfragen beschreiben. WAF vergleicht sich mit diesen Listen und entscheidet, was in einer bestimmten Situation zu tun ist \u2014 den Datenverkehr zu blockieren oder nicht.<\/p>\n

Ein Beispiel f\u00fcr die Erkennung auf Basis von regul\u00e4ren Ausdr\u00fccken ist das bereits erw\u00e4hnte Projekt Core Rule Set<\/a><\/noindex> aus open source. Ein weiteres Beispiel ist Naxsi<\/a><\/noindex>, das ebenfalls Open Source ist. Systeme mit regul\u00e4ren Ausdr\u00fccken haben eine Reihe von Nachteilen, insbesondere wenn eine neue Schwachstelle entdeckt wird, muss der Administrator zus\u00e4tzliche Regeln manuell erstellen. Bei einer umfangreichen IT-Infrastruktur k\u00f6nnen es mehrere tausend Regeln sein. Mit einer solchen Anzahl von regul\u00e4ren Ausdr\u00fccken umzugehen, ist ziemlich schwierig, ganz zu schweigen davon, dass deren \u00dcberpr\u00fcfung die Netzwerkleistung beeintr\u00e4chtigen kann.<\/p>\n

Regul\u00e4re Ausdr\u00fccke weisen ebenfalls eine relativ hohe Rate an Fehlalarmen auf. Der ber\u00fchmte Linguist Noam Chomsky schlug eine Klassifikation von Grammatiken vor, die sie in vier bedingte Schwierigkeitsgrade unterteilt. Gem\u00e4\u00df dieser Klassifikation k\u00f6nnen regul\u00e4re Ausdr\u00fccke nur Regeln f\u00fcr Firewalls beschreiben, die keine Abweichungen vom Muster vorsehen. Das bedeutet, dass Angreifer WAFs der ersten Generation leicht \"\u00fcberlisten\" k\u00f6nnen. Eine Methode zur Bek\u00e4mpfung dessen besteht darin, spezielle Zeichen zu den Anfragen an die Anwendungen hinzuzuf\u00fcgen, die die Logik der sch\u00e4dlichen Daten nicht beeinflussen, aber die Signaturregel verletzen.<\/p>\n

\"Die
\n
\nDie zweite Generation<\/b>. Um die Probleme im Zusammenhang mit der Leistung und Genauigkeit von WAFs zu umgehen, wurden Firewalls der zweiten Generation entwickelt. In diesen wurden Parser eingef\u00fchrt, die daf\u00fcr zust\u00e4ndig sind, eindeutig definierte Angriffsarten (auf HTML, JS usw.) zu identifizieren. Diese Parser arbeiten mit speziellen Tokens, die die Anfragen beschreiben (z.B. variable, string, unknown, number). Potenziell sch\u00e4dliche Tokenfolgen werden in eine separate Liste ausgegliedert, mit der das WAF-System regelm\u00e4\u00dfig abgeglichen wird. Dieser Ansatz wurde erstmals auf der Black Hat 2012 Konferenz in Form einer C\/C++\u00a0Bibliothek libinjection<\/a><\/noindex>, die es erm\u00f6glicht, SQL-Injektionen zu erkennen.<\/p>\n

Im Vergleich zu WAFs der ersten Generation k\u00f6nnen spezialisierte Parser schneller arbeiten. Dennoch haben sie die Herausforderungen im Zusammenhang mit der manuellen Anpassung des Systems bei neuen sch\u00e4dlichen Angriffen nicht gel\u00f6st. <\/p>\n

\"Die
\n
\nDie dritte Generation<\/b>. Die Evolution der Erkennung logischer Mechanismen der dritten Generation beruht auf dem Einsatz von Methoden des maschinellen Lernens, die es erm\u00f6glichen, die Erkennungsgrammatik maximal an die echte Grammatik von SQL\/HTML\/JS der gesch\u00fctzten Systeme anzupassen. Diese Erkennungslogik kann die Turingmaschine anpassen, um rekursiv aufgelistete Grammatiken zu erfassen. Zuvor war die Aufgabe, eine anpassbare Turingmaschine zu schaffen, unl\u00f6sbar, bis die ersten Forschungen \u00fcber neuronale Turingmaschinen ver\u00f6ffentlicht wurden.<\/p>\n

Maschinelles Lernen bietet die einzigartige M\u00f6glichkeit, jede Grammatik anzupassen, um jeden Typ von Angriff zu erfassen, ohne manuell Signaturlisten zu erstellen, wie es bei der Erkennung der ersten Generation erforderlich war, und ohne neue Tokenizer\/Parser f\u00fcr neue Angriffstypen wie Memcached-, Redis-, Cassandra- oder SSRF-Exploits entwickeln zu m\u00fcssen, wie es die Methodik der zweiten Generation verlangte. <\/p>\n

Indem wir alle drei Generationen der Erkennungslogik kombinieren, k\u00f6nnen wir ein neues Diagramm zeichnen, in dem die dritte Generation der Erkennung (Abb. 3) rot umrissen dargestellt ist. Zu dieser Generation geh\u00f6rt eine der L\u00f6sungen, die wir gemeinsam mit \u201eOnsec\u201c, dem Entwickler der Plattform f\u00fcr adaptive Webanwendungs- und API-Sicherheit Valarm, in der Cloud implementieren. <\/p>\n

Jetzt wird in der Erkennungslogik Feedback von der Anwendung zur Selbstjustierung verwendet. Im Rahmen des maschinellen Lernens wird dieser Feedbackzyklus als \u201eVerst\u00e4rkung\u201c bezeichnet. In der Regel gibt es einen oder mehrere Typen solcher Verst\u00e4rkungen:<\/p>\n