OpenAppId – Snort – logiciel pfSense

OpenAppID est un plugin de sécurité réseau pour la couche application conçu pour le système de détection d’intrusion Snort.

Il s’ajoute à Snort pour permettre d’avoir une remontée d’alerte sur les utilisations des applicatifs sur un réseau.

OpenAppId utilise le langage Lua permettant de détecter les applications, elles sont souvent basées sur les protocoles comme HTTP / SSL / SIP / RTSP.

Listes des fonctionnalités d’OpenAppId :

  • Détecte les applications sur le réseau et sur les évents de Snort
  • Établie des statistiques sur les utilisations des applicatifs
  • Bloque les applications grâce aux règles établies
  • Se base sur le nom de l’application
  • Support IPv6

Plus de 1400 applications en trois catégories :

  • Protocole applicatifs
  • Applicatifs web
  • Applications client/serveur

Utilisation du préprocesseur avec OpenAppId :

Le préprocesseur est exécuté avant que l’IDS de Snort ne soit mis à contribution. Cette méthode permet de lire le paquet, de voir la requête émise et de prendre une décision.

Mise en œuvre :

1 – Installation de snort

System > Package > Available Packages

Choisir le package Snort dans la liste et l’installer

2 – Configuration des outils et mise à jour

Mise à jour de Snort :

> Services > Snort > Global Settings

Chocher Install Snort VRT Rules et inserer le code Oinkmaster

Après l’ajout du code Oinkmaster, vous devez mettre à jour les VRT rules

> Services > Snort > Updates

Cliquer sur Update pour mettre à jour les règles.

Après cette étape, veillez vérifier que la mise à jour est bien effective.

Installation et mise à jour d’OpenAppId :

Retourner sur l’onglet “Global Setting”, cocher la case “Install OpenAppID detectors” et recommencer le processus de mise à jour

3 – Configuration de l’interface

> Services > Snort > Snort Interfaces

Ajouter une nouvelle interface à l’aide du bouton “+”.

Choisir l’interface LAN dans “Iface Settings”

Pour activer le préprocesseur dans l’interface pfSense, naviguer dans l’onglet “LAN Preprocs”

Descendre dans le menu “Application ID Detection” et cocher enable.

Modifier selon les performances de votre machine pour les options de la mémoire et les logs.

4 – Création des alertes

Les alertes sont crées dans le but de détecter l’application qui va être utilisé par le client.

Le but final étant de bloquer celui qui à déclencher l’alerte (pour les protocoles/applications que vous voulez interdire).

Nous allons créer deux alertes, une avec un flux TCP l’autre avec un flux utilisant SSH.

“LAN Rules”

Dans le menu “Available Rule Categories”

Dans “Category” choisir : custom.rules

Facebook :

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"Facebook DENIED"; appid: facebook; sid:303030; classtype:misc-activity; rev:1;)

Cette alerte intercepte tous les paquets en TCP de votre LAN vers votre interface externe (WAN généralement) et classifie l’application comme une alerte (appid : facebook).

SSH :

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg: "SSH is HERE"; appid: ssh; sid:303031; classtype:policy-violation; rev:1;)

Cette alerte intercepte tous les paquets en tcp de votre LAN vers votre interface externe et si un flux SSH est détecté, l’alerte est générée.


Les classtype sont des indicateurs pour classifier le trafic en fonction de son appartenance (trojan, privilege gain, leak etc.) et de sa dangerosité par priorité (High, medium, low, very low)
Les classtype peuvent être défini par l’administrateur.

Nous vous invitons à regarder les class-type sur ce lien

5 – Bloquer le trafic si une alerte apparaît

Il est possible de déclencher une alerte sans qu’un blocage s’effectue, une utilité pour les phases de test ou d’audit, mais le meilleur moyen de rendre votre réseau plus sécurisé est de créer un blocage des adresses IP qui auront déclenché vos alertes. Le blocage peut s’effectuer sur une période de temps ou non.

Pour activer les blocages sur les alertes : “Snort Interface” > “Alert Settings” > “LAN Settings”

Dans le menu Alert Settings, cocher “Block Offenders”.

A partir de ce moment, Snort bloquera l’adresse IP de destination correspondante à l’alerte qui a été généré. Attention, il se peut que des utilisateurs qui tentent d’accéder à des sites légitimes soient bloqués par vos règles, il est nécessaire d’analyser vos flux réseaux avant de procéder à une configuration de ce type.

Sauvegarder vos configurations et passons au test.

6 – Tester les alertes

  1. Lancer un navigateur et entrer l’URL : http://www.facebook.com
  2. Vérifier les alertes sur Snort
  3. Vérifier les adresses IP distantes (Serveurs de facebook) qui se bloquent après avoir visiter www.facebook.com depuis votre navigateur

Pourquoi ma règle ne fonctionne pas? Pourquoi j’ai toujours une page qui s’affiche ?

Certainement parce que le navigateur garde son cache ou que Facebook ou une autre application dispose de plusieurs serveurs avec plusieurs adresses IP.

Rafraîchissez la page plusieurs fois et videz votre cache puis essayez d’accéder au site (en vérifiant que Snort détecte bien l’alerte et la bloque par la suite si vous avez activé le blocage).

Si le titre du site s’affiche, le comportement est tout à fait normal, le service de DNS résoud le nom et l’affiche dans le tittre, le protocole DNS n’étant pas bloqué.

Vous pouvez aussi vous tromper sur la syntaxe dans “custom.rules”, veuillez tenir compte de certaines espacements quand vous écrivez la règle.

Comment analyser les données reçues par ce module ?

Des fichiers de logs sont générés automatiquement dans /var/log/snort/{snort_interface}/

Ils sont nommés app-stats.log.

Les fichiers générés par OpenAppId sont exploitables et utiles dans un but décisionnel.
Prendre des décisions à partir des statistiques réseaux peut être un atout dans la plupart des cas, pour la sécurité et pour la mise en place d’une politique de qualité de service.

Bien que ces fichiers de log ne soient pas très visuels, des logiciels de tierces parties comme Splunk ou Talend permettent de charger, d’extraire et d’analyser les statistiques établies par les outils précédemment utilisés.

Il vous suffit d’extraire les logs crées dans /var/log/snort/snort_{interface_snort}/

Le fichier appMapping.data contient les informations sur les applications vous pouvez bloquer.

Pour récupérer le fichier :

scp user@192.168.1.1:/usr/pbi/snort-amd64/local/etc/snort/appid/odp/appMapping.data

Pour savoir si vous pouvez alerter/bloquer une application avec une règle, affichez et regardez le fichier appMapping.

Une fois récupéré, essayez les commandes si dessous avec Facebook ou une autre application, avec la commande :

grep -i «votre application» appMapping.data | cut -f7

Outils à utiliser avec OpenAppId :

u2openappid :

Quelques binaires sont mis à disposition afin d’avoir des statistiques sur les opérations de OpenAppId et de l’utilisation des applicatifs sur le réseau.

u2openappid fourni un affichage des données récupérer par le préprocesseur,

Ce binaire permet d’identifier l’applicatif et les octets qui ont été émis et reçu par cette applicatif.

Exemple u2openappid:

statTime="1394575530",appName="mdns",txBytes="534",rxBytes=”230”

u2streamer :

u2streamer va enregistrer les informations dans un fichier spécifique à l’aide du chemin où sont stockés les fichiers de log de Snort.

Ce fichier pourra être utilisé pour établir des statistiques.
Il peut aussi être utilisé si une coupure de Snort a lieu afin d’avoir une continuité dans les enregistrements.

u2streamer --path=/var/log/snort/snort_{interface}/ --name=alert.log

Affichage du ficher alert.log :

02/03/15-11:43:46.272423 ,1,303030,1,"Facebook DENIED",TCP,192.168.1.100,53322,31.13.93.3,443,27042,Misc activity,3,

Conclusion

Cette application met en avant les nouveaux modes d’identification des applications qui circulent sur le réseau.

Cette technique permet détecter dans les couches applicatives puis de bloquer la couche réseau afin d’éviter toutes récidives sur les sites distants.

OpenAppID permet ainsi :

  • de bloquer des protocoles applicatifs sans avoir à utiliser un proxy
  • d’inspecter les contenus et les connexions HTTPS
  • d’inspecter les contenus au niveau applicatif et de les bloquer au niveau réseau
  • de ne pas provoquer d’effets de bord tels que ralentissement réseau, problèmes lié au cache,
  • de ne pas avoir à couper les liaisons HTTPS pour inspecter les paquets
  • une grande fiabilité pour traiter les flux des protocoles applicatifs les plus courants
Share

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.