La version 12.1 de BIG-IP est disponible depuis le 10 Juin et apporte son lot de nouveautés. En ce qui concerne ASM, il y a 13 nouvelles fonctionnalités en 12.1 comme rappelé dans la release note ASM 12.1.

Voici le top 10 des fonctionnalités les plus importantes (à mon sens) :

 

10 - Prise en charge de multiple profile de logging

Avec cette version 12.1, il est possible de créer plusieurs profils de logging distants et les assigner à chaque Virtual Serveur.

Si le besoin est d'avoir un logging local et un logging distant, il est nécessaire de créer deux profils car un profil de logging peut envoyer des logs soit localement soit distant (mais pas les deux en même temps).

Un cas d'usage est de créer deux profils de loging, un pour loguer les requêtes illégales localement et un autre pour loguer toutes les requêtes à outil de log distant (comme Big-IQ).

Un autre cas d'usage est de créer deux profils de logging distant, chacun pour loguer les requêtes à destination de différents SIEMs (come Splunk et Arcsight)

 

9 - Amélioration du Policy Builder

L’amélioration phare apportée au Policy Builder a été faite en 12.0 avec l’unification des moteurs de définition manuels et automatiques pour la construction de politiques de sécurité. Pour rappel, dans la 12.0, il existe un seul écran pour les suggestions d’apprentissage pour les politiques de sécurité définies de façon automatique et pour celles que l’on définit manuellement.

En 12.1, Il a été apporté les améliorations suivantes au Policy Builder:

  • En mode d'apprentissage automatique (Automatic Learning), le Policy Builder active les signatures individuellement plutôt que toutes les signatures en même temps. La méthode précédente avec tendance une introduire un délai dans l'enforcement des signatures.
  • La logique de l'apprentissage a été modifiée dans le but d'accélérer l'apprentissage et de réduire la consommation mémoire en apportant les modifications suivantes dans la zone de construction de politique de l'écran Learning and Blockinig Settings :
    • Le critère d'ajustement (stabilisation) de la politique est désormais basé sur le nombre de requêtes, le temps et les suggestions d'apprentissage avec un score d'apprentissage spécifique alors qu'il était précédemment basé sur nombre de requêtes, le temps, les sessions et les adresses IP.
    • Le nombre minimum de requêtes requises pour stabiliser une politique a été modifié.
    • Le critère d'ajustement de Politique est configuré pour être le même pour les sources de confiance et non de confiance. Auparavant, les valeurs étaient différentes pour différentes sources.
  • Il est possible d'effectuer l'action d'accepter une suggestion “Accept Suggestion" aussi en mode manuel et accepter seulement les suggestions déclenchées par des violations. Précédemment, l'action d'accepter une suggestion "Accept Suggestion" ne fonctionnait qu'en mode automatique et elle acceptait toutes les suggestions.
  • La présentation de l'ajustement de suggestion a été revue pour activer les violations et les sous-violations.

 

8 - Atténuation DDoS basée sur l'analyse comportementale

F5 Networks a développé une technologie innovante qui atténue les attaques en DDOS, pas juste en tirant partie des règles et signatures dans ASM, mais aussi en détectant les attaques par analyse comportementale en utilisant du machine learning et les analytics Big data.

Voici les avantages de l'atténuation comportementale:

- Détection automatique des attaques (D)DoS en utilisant des données comportementales

- Caractérisation du trafic attaquant et atténuation automatique du flux malveillant.

- L'intervention de l'administrateur n'est pas requise pour configurer les seuils DDOS ou pour les maintenir. Le moteur s'auto ajuste et s'adapte aux changements.

- Elle alerte et atténue avant que le service attaqué ne tombe.

Cette fonctionnalité peut être activée sur ASM et enrichit grandement la protection DDOS en complétant les mécanismes anti-DDOS existants.

 

7- Détection d'anomalies par tracking d'ID de devices

En plus de des mécanismes utilisés dans les versions précédentes, ASM dans cette version utilise aussi l'ID de Device (Device ID) pour détecter les tentatives de DOS, brute force ainsi que le piratage de sessions (session hijacking). Lorsque cette fonctionnalité est activée, le système va régler les nombre de violations causés par les devices durant une certaine période dans le but de loguer ou de bloquer les requêtes relatives à ces devices.

Pour pouvoir utiliser cette fonctionnalité (qui est désactivée par défaut en cas d'upgrade depuis une version antérieure), le navigateur doit prendre en charge JavaScript. Attention cependant, l'utilisation de cette fonctionnalité Device ID bloque les clients qui ne prennent pas en charge JavaScript, même si la politique de sécurité ASM est en mode transparent.

 

6 - Prévention de piratage de session (Session Hijacking)

ASM utilise désormais la fonctionnalité device ID pour détecter et prévenir le piratage de session en plus des méthodes utilisée dans les versions précédentes.

Lorsqu'une session est piratée, le système génère une violation sur le hijacking de cookie ASM avec l'une des descriptions suivantes affichées dans le Log de requêtes : Message key mismatch between cookies, Device ID mismatch, ou Device ID mismatch et message key mismatch between cookies.

Il est possible de définir une page de réponse de blocage spécifique pour la violation de piratage de session.

 

5 - Ajout automatique à une liste noire des adresses IP en attaque L7 (Auto Shun)

Il est possible de mettre en liste noire (blacklist) automatiquement des adresses IP de clients qui échouent à répondre aux chalenges (les adresses IP qui sont droppées 90% du temps par le mécanisme de protection DOS niveau 7). L'intérêt de cette fonctionnalité est que le système n'a pas besoin de consommer des ressources ASM pour atténuer le trafic an provenance de ces adresses IP.

Une fois que les adresses IP sont blacklistés, le système drop automatiquement les paquets en provenance de ces adresses IP pour une durée de deux (2) minutes.

Les adresses IP blacklistées sont automatiquement ajoutées à la catégorie Black List (Security > Network Firewall > IP Intelligence > Black List category).

Cette fonctionnalité s'active depuis le menu IP Intelligence et ne requiert pas de licence AFM Advanced Firewall module additionnelle. Elle nécessite en revanche une souscription IP Intelligence.

 

4 - Prise en charge du Proactive Bot Defense en iRules

Il est possible d'utiliser des iRules pour effectuer des taches de configuration des mécanismes de Proactive Bot Defense.

Un nouveau jeu de primitives est disponible Plus d'information et d'exemples sont disponibles sur DevCentral.

Quelque exemples de ce qu’on pourrait faire avec ces primitives que l’on peut déclencher via les évènements BOTDEFENSE_REQUEST et BOTDEFENSE_ACTION:

  1. Remplacer le TCP RESET par un redirect à un pot de miel.
  2. Envoyer un message HSL lors d’un blocage et des actions de chalenge.
  3. Filtrer Bot defense en fonction des entêtes ou des URLs.
  4. Forcer un chalenge JavaScript sur certaines URLs.
  5. Forcer un chalenge CAPTCHA

 

3 - Protection des pages de Login, Logout en AJAX/JSON

La prise en charge des pages de Login pour AJAX/JSON a été ajoutée pour la configuration manuelle et la découverte automatiques. Il aussi été ajouté un écran de configuration pour les pages de Logout sous le menu Application Security > Sessions and Logins.

 

2 - Sécurité des API REST et Gestion des méthodes au niveau de l'URL

Il est possible de définir une liste de méthodes autorisées et non autorisées pour chaque URL qui prend précédence sur la liste de méthode définies au niveau de la politique de sécurité. Cette liste de méthodes s’applique aussi à des URLs API REST et du coup, il est possible de définir de façon granulaire quelle méthodes HTTP qui s’appliquent à des URLs spécifiques de votre API REST à protéger.

L’intérêt de cette fonctionnalité est la protection d’une API REST qui autoriserait toutes les méthodes HTTP normales y compris le PUT, DELETE, MERGE et MODIFY qui vont faire courir un risque de sécurité si l’implémentation de l’API ne prévoit pas (ou insuffisamment) de mécanismes de protections intégrées.

Toute méthode HTTP qui ne sera pas spécifiée pour l’URL va générer une violation de type illegal-use. Il est aussi possible de définir vos propres méthodes customisées.

 

…et la fonctionnalité phare de la 12.1 :

 

1 - Protection des WebSocket

ASM est le premier WAF sur le marché à fournir une protection complète des WebSocket.

Avec la version 12.1, il est désormais possible des protéger les URLs dans l'application Web qui seront autorisées ou pas à utiliser le protocole Websocket.

Pour rappel, le protocole WebSocket fournit une communication bidirectionnelle entre un client et le serveur. Contrairement à HTTP, avec les Websocket, le client ou le serveur peuvent indifféremment s'envoyer des données en streaming.

L'objectif de cette technologie est de fournir un mécanisme pour les applications basées sur des navigateurs web qui nécessitent une communication bidirectionnelle avec des serveurs sans avoir à ouvrir de multiples connexions http, comme le Chat ou les flux de news.

Je reviendrai plus en détail, dans un autre article, sur certaines de ces fonctionnalités et en particulier la partie protection des WebSocket.