ASM – Rapid Deployment

Hallo liebe Leser,

heute möchte ich mich einem ASM (Application Security Manager) Thema, also der WebApplication Firewall von F5 widmen.

Sehr oft erlebe ich bei Kunden die Anforderung Webapplikationen vor Angriffen zu schützen.

ASM bietet die Möglichkeit, einen sehr umfangreichen, granularen und hohen Sicherheitsschutz zu implementieren. Dies ist aber gleichzeitig mit einem erhöhten administrativen Aufwand verbunden, da diese Policies sehr applikationsnah sind und typischerweise eine enge Zusammenarbeit mit den Applikationsentwicklern erfordert.

Damit eine schnelle und gute Grundsicherung der Applikationen realisiert werden kann, bietet ASM auch die Möglichkeit eine Policy auf Basis von Signaturen, also bekannten Angriffen, zu erstellen.

Hierbei werden Signaturen auf der Gundlage der eingesetzten Applikationsumgebung ausgewählt (Betriebssystem, Webserver, Datenbankserver, Programmiersprache, ...). Diese Signaturen erkennen bekannte Angriffe und können diese entsprechend blocken.

Typischerweise konfiguriert man die Policy so, dass diese Signaturen erst nach einer „Staging“-Phase in den Blocking-Mode wechseln. Während dieser „Staging“-Phase können eventuell auftretende False-Positives (Fehlalarme) abgeschaltet werden.

Aber fangen wir doch mal an und erstellen uns eine Policy:

Erstellen einer Policy

Die Konfiguration einer ASM Policy findet unter dem Reiter Security/Application Security im linken Menüpunkt der BIG-IP statt.

Wird eine neue Policy erstellt, kann diese automatisch an einen bereits existierenden virtuellen Server gebunden werden, oder man konfiguriert gleichzeitig auch einen neuen virtuellen Server.

Deployment Scenario

In diesem Fall wird nur eine Policy erstellt, die zu einem späteren Zeitpunkt an einen virtuellen Server gebunden werden kann.

Policy Properties

Anschließend kann man die Methode wählen, wie die Policy erstellt werden soll. Hier wird das manuelle Erstellen einer Policy gewählt.

Unter diesem Punkt wird der Name der Policy vergeben.

Language

Sehr wichtig ist das Auswählen der „Application Language“. Diese muss unbedingt richtig gewählt werden, da Attacken sonst nicht sicher erkannt werden oder viele False-Positives enstehen.

Die Information sollte normalerweise in der Webseite mit angegeben sein. Schaut man sich den Quelltext einer Webseite an, erhält man diese Information.

Sollte diese Information nicht angegeben sein, ist es ratsam mit dem Entwickler zu sprechen und sich diese Information einzuholen.

Enforcement Readiness Period

Der Punkt „Enforcement Readiness Period“ gibt an, wie lange neu gelernte Elemente sich im so genannten „Staging“ befinden. Das bedeutet, diese Elemente wurden neu gelernt bzw. hinzugefügt und müssen sich erst „beweisen“, dass es auch valide Elemente sind. Hierzu zählen z.B. URLs, Pfade, Signaturen, usw.

Da sich in diesem Fall die Policy „nur“ auf Signaturen bezieht, wird sich das Staging bzw. die Readiness Period auch nur auf diese auswirken. Dies ist aber wichtig, denn wenn neue Signaturen hinzugefügt werden (z.B. Signatur-Update), sollten diese nicht gleich blocken, sondern erst in der Staging-Phase, in der sie sich zu Beginn befinden, auf False-Positives überprüft werden.

Attack Sigantures

Nun werden, entsprechend der zu schützenden Systeme, die zu verwendenden Attack-Signaturen ausgewählt.

Signature Staging

Der Hacken „Signature Staging“ ist zu setzen, damit die Signaturen sich für den Zeitraum der „Enforcement Readiness Period“ im Staging befinden und somit auch nicht blocken. Nach dem Ablauf der „Enforcement Readiness Period“ sind die Signaturen „Ready for Enforcement“ und müssen dann manuell „enforced“ werden. Das bedeutet, die Siganturen können nun Angiffe blocken, wenn die Policy im Modus „blocken“ betrieben wird. Hierzu gibt es später mehr Details.

Anschließend bekommt man eine kurze Übersicht über die gewählte Konfiguration und kann diese dann mit „Finish“ abschließen.

All Policy Properties

Auf der folgenden Seite bekommt man die Einstellungen der Policy angezeigt.

Der „Enforcement Mode“ der Policy ist per default auf „Transparent“ gestellt. Das bedeutet, die Policy wird bei dem Erkennen eines Angiffs diesen nicht blocken, sondern loggen.

Wird der Mode auf „Blocking“ geändert und die Signatur befindet sich nicht im „Staging“ Mode, wird der Angriff geblockt.

Policy Änderungen

Wichtig: Nimmt man Policy-Änderungen vor, müssen diese „applied“ werden.

History

Über das Ändern einer Policy wird ein History Log geführt, indem auch „alte“ Policies wieder zurückgespielt werden können.

Policy-Log

Welche Änderungen wann von wem durchgeführt wurden, kann man dem Policy-Log entnehmen:

Policy Setting Parameter Level: URL

Diese Policy kann nun an einen virtuellen Server gebunden werden. Damit im Falle eines False-Positives aber Signaturen nicht global ausgeschaltet werden, ist es ratsam, den Parameter Level der Policy auf „URL“ zu stellen. Dadurch kann man Signaturen pro Parameter und URL abschalten.

Binden einer Policy an einen virtuellen Server

Ist der virtuelle Server bereits konfiguriert, kann diesem die Policy unter dem Reiter „Security“ hinzugefügt werden (Application Security Policy). Ebenfalls sollte man hier die Auswahl eines entsprechenden Log Profiles treffen.

Schon hat man eine Policy erstellt und diese an einen virtuellen Server gebunden. Nun geht es noch darum ggf. auftretenden False-Positives zu ermitteln und abzuschalten.

Bevor ich aber darauf eingehe möchte kurz einige Begriffe und „Phasen“ wiederholen.

Staging

Wenn sich ein Element (Parameter, URL, Signatur, ...) im Staging befindet, wird für dieses Element kein „Blocken“ bei dem Erkennen einer Policyverletzung durchgeführt. Unabhängig des Enforcement Modes.

Enforcement Mode

Transparent oder Blocking. Im ersten Fall (Transparent) blockt die Policy nie. Hier kann lediglich geloggt werden. –Also wenn ein Angriff erkannt wurde.

Ist die Policy im Blocking Mode und die Signaturen oder entsprechende weitere Elemente (URL, Parameter, ...) nicht im Staging Mode, dann wird der Angriff geblockt.

Das Einstellen des Enforcement Modes kann über die Seite Security/Application Security: Security Policies/Properties unter Enforcement Mode ausgwählt werden.

Alternativ auch über Security/Application Security Blocking: Settings.

Unter den Blocking Settings können ebenfalls auch weitere Schutzmechanismen aktivieren, sofern diese vorher konfiguriert wurden.

RFC Violations

Ebenfalls kann auch hier das Erkennen und Blocken von RFC Violations durchgeführt werden. Per Default sind einige Violations bereits durch das Konfigurieren des Rapid Deplyments aktiviert.

Enforcement Readiness

Sind Objekte (URLs, Paramenter, Signaturen, ...) bereits über die „Enforcement Readiness Period“ der Policy bekannt, werden diese unter der Spalte „Ready To Be Enforced“ dargestellt und können entsprechend „enforced“ und damit „scharf“ geschaltet werden. „Scharf“ bedeutet im Blocking Mode, dass geblockt und geloggt wird, im Transparent Mode nur geloggt.

Möchte man die Signaturen sofort im „Ready To Be Enforced“ Mode haben, kann man die „Enforcement Readiness Period“ auf „0“ stellen.

Für später neue Signaturen (Update) empfiehlt es sich, diese dann wieder auf einen höheren Wert zu setzen.

Okay, kommen wir nun zum Eliminieren von False-Potitives.

Eliminieren von False-Positives

Nun ist die Policy im transparenten Modus, die Signaturen im Staging und der Parameter-Level auf URL gestellt.

Manual Traffic Learning

Findet nun eine Verletzung der Policy statt, also eine Signatur erkennt einen Angriff, so findet man diese Information unter: Security/Application Security/Policy Building/Manual Traffic Learning.

Hier kann man nun auf den Link „Attack signatures detected“ klicken und anschließend bekommt man die Violations aufgelistet.

Durch das Klicken auf den Signatur Namen bekommt man Informationen zu der Signatur, die angeschlagen hat:

Wenn dies tatsächlich ein Angriff war, kann man den Eintrag durch den „Clear“ Button entfernen. War es jedoch ein False-Positive, kann die entsprechende Signatur durch den „Accept Button“ auf dem Parameter und der URL disabled werden.

Hier wird die Sigantur-ID 200002147 für den Parameter „username“ auf der URL „login.php“ ausgeschaltet.

Gelernte Parameter und URLs

Den Parameter sowie die URL lernt ASM automatisch mit. Wichtig ist hierbei, dass der jeweilige Wildcard Eintrag „*“ nicht im Staging ist, da sonst der Angriff durch die Signatur nicht geblockt werden würde.

Ready To Be Enforced

Dies kann nun während der Enforcement-Readiness-Period durchgeführt werden. Anschließend befinden sich die Signaturen im „Ready To Be Enforced“ Mode und können „enforced“ werden.

Wird nun ein Angriff erkannt, so wird dieser, so lange die Policy noch im transparenten Modus ist, nicht geblockt sondern nur geloggt.

Eventlogging

Das Logging findet man unter Security/Event Logs/Application/Requests:

An dem roten Fähnchen kann man den Verstoß erkennen. Wäre die Policy im Blocking Mode, würde hier stattdessen das Durchfahrtsverbotszeichen erscheinen.

Angriffsdetails

Details zu dem Angiff kann man nun durch das Klicken auf das Fähnchensymbol erhalten.

Weitere Details kann man durch die Auswahl des „HTTP Request“ Reiters erhalten.

Details zu dem Angriff erhält man durch das Klicken des entsprechenden Links in den General Details.

Möchte man die Meldung aus dem Log entfernen, kann man dies mit Hilfe des Clear Buttons durchführen.

Bereinigen von False-Positives

Handelt es sich um einen False-Positive, kann man diesen durch das Anklicken des „Learn“ Buttons lösen. Hierdurch ruft man automatisch die bekannte Traffic Learning Page auf.

Wenn sich die Policy etabliert hat und es keine False-Positives mehr entstehen, kann man die Policy in den Blocking Mode schalten.

Blocking Page

Wird ein Angriff nun erkannt, bekommt der Client eine entsprechende Meldung im Browser angezeigt.

Diese Seite kann auch individuell angepasst werden:

Attack Signature Lists

Möchte man sich die Liste der verwendeten Signaturen innerhalb einer Policy anzeigen lassen, kann man dies unter Security/Application Security/Attack Signatures/Attack Signatures List tun.

Dies ist auch mit erweiterten Filter Details möglich. Hier werden z.B. nur Signaturen angezeigt, die Veränderungen durch URL- und Parameterausnahmen haben. Also Ausnahmen, die durch False-Positives erzeugt wurden.

Das wars auch schon. Natürlich kann diese Policy auch um weitere Schutz-Funktionen ergänzt werden. Dies kann nun für einzelene virtuelle Server, vielleicht in Abhängigkeit des Gefahrenpotentials, durchgeführt werden.

Ergänzen möchte ich den Beitrag noch zu einer ganz kurzen Abgrenzung vom ASM gegenüber IDS/IPS, da dies oft ein Thema bei Kunden ist, die solche Systeme bereits im Einsatz haben.

Ich denke es ist wichtig zu Verstehen, dass die beiden Systeme ASM und IDS/IPS sich nicht gegenseitig ersetzen, sondern vielmehr ergänzen. IDS/IPS verfolgen eher einen generischen netzwerkspezifischen Einsatz, hingegen ASM speziell auf HTTP(S) optimiert ist und bei diesem Protokoll typischerweise entsprechende Vorteile hat, selbst wenn „nur“ Signaturen eingesetzt werden. Das liegt zum einen daran, dass die Signaturen einer Webapplication Firewall in der Regel wesentlich mehr Angriffe kennen, aber auch an der Netzarchitektur und der damit verbundenen Position, an dem die Geräte plaziert sind.

IDS/IPS Systeme sind oft unmittelbar vor oder nach der Netzwerkfirewall eingesetzt und hier ist der Traffic häufig verschlüsselt. Somit haben diese Systeme gar keine Chance HTTP-Angriffe zu erkennen.

Verschlüsselter Traffic wird in der Regel auf dem Loadbalancer (LTM) terminiert und auf dem gleichen System befindet sich dann auch oft das ASM Modul. Domit liegen die Informationen im Klartext vor und das ASM Modul kann schützen. Ein weiterer Vorteil des ASM Modul im HTTP Umfeld ist es, das die Signaturen im Falle eines False-Positives nicht global abgeschaltet werden müssen, sondern pro Policy auf URL und Parameter Ebene. Das bedeutet also, wenn bei einer bestimmten Policy und einer explizieten URL an einem dedizierten Parameter eine Signatur falsch anschlägt, dann kann diese auch genau dafür abgeschaltet werden und schützt weiterhin auf der gesamten Webseite.

Jetzt wünsche ich Ihnen viel Spass bei dem Erstellen der nächsten Policies und hoffe, der Artikel kann Ihnen ein wenig dabei helfen.

Ihr F5-Blogger, Sven Müller