pfSense : Comment ajuster manuellement le Timeout pour les services sensibles (VoIP)

Auteur & Source :Grégory Mouchon  |  IT-Central.fr

Certaines personnes peuvent rencontrer des problèmes avec des services ou protocoles réseau plus sensibles que d’autres en termes de latence comme les services de VoIP. Ce genre de services ont souvent besoin de conserver l’enregistrement de la connexion pour une durée généralement plus importante que ce qui est souvent rencontré par défaut sur les pare-feux et routeurs. Le problème est que pfSense efface la table d’état des connexions ouvertes après une certaine période prédéfinie, très souvent inférieur aux prérequis de la VoIP.

Ces périodes prédéfinies se trouvent dans des profils ou stratégies. Ces profils se trouvent dans System> Advanced > Firewall & NAT > Firewall Optimization Options :

pfSense : choix du Profils du timeout

Les différents profils préréglés du Timeout

En générale, il est plus courant et plus facile de résoudre ces problèmes de latence en réduisant tout simplement de manière globale le niveau d’agression du pare-feu/Nat vis-à-vis de toutes les connexions ouvertes. C’est ce qu’il est possible de faire dans pfSense via ces profils.

Mais c’est bien dommage, car le trafic VoIP est presque toujours basé uniquement sur UDP. Normal, car il faut des latences très courtes que le TCP ne peut pas fournir. Du coup, le fait de modifier ces paramètres va aussi prendre en compte tous les autres protocoles, alors qu’ils n’en ont pas besoin.  Un risque supplémentaire pour problèmes d’incompatibilité dans l’avenir. Et puis c’est plus pro…merde quoi !

Voici un exemple parmi d’autres des prérequis de l’offre Centrex d’OVH:

  • Le trafic vers les réseaux 91.121.128.0/24 et 91.121.129.0/24 doit être autorisé.
  • Pour le protocole SIP : le trafic doit être autorisé sur les ports 5060 et 5962 en UDP.
  • Pour le protocole MGCP : le trafic doit être autorisé sur les ports 2424 et 2427 en UDP.
  • La plage de ports 30000 à 40000 en UDP doit également être ouverte (ports RTP, plage de son).
  • La durée de vie des sessions UDP (Time/Timeout/NAT Session) doit être supérieure ou égale à 180 secondes.
  • La fonction SIP ALG doit être désactivée sur les équipements actifs (si possible).
  • Pour une ligne sans Plug&Phone : le client SIP utilisé doit avoir une durée d’enregistrement de 1800 secondes.

Pour obtenir une qualité de communication optimale, assurez-vous que les
valeurs suivantes sont bonnes :

  • Le débit disponible recommandé est de 100kbps par ligne (envoi ET réception).
  • La gigue* idéale est inférieure à 5ms (entre votre téléphone et le serveur OVH).

Comme vous pouvez le constater, il n’y a que de l’UDP.

Si nous définissons le profil sur conservative, ce qui aura pour effet d’augmenter le Timeout sur toutes les connexions (UDP, TCP etc), il y aura inévitablement plus de consommation mémoire et CPU que nécessaire. Ce qui n’est probablement pas ce que la plupart des professionnels souhaitent, car il y a en général beaucoup de connexions réseau ouvertes en dehors d’UDP.

Pour pallier à cela, il existe une bien meilleure méthode pour obtenir exactement le même résultat. Il s’agit d’ajuster manuellement les délais d’attente pour un type de trafic en particulier. En l’occurrence pour la VoIP, UDP.

Il est possible de visualiser les délais d’attente configurés par défaut pour chacun des profils proposés dans pfSense. Ce qui nous permettra d’avoir une idée sur ce qu’il convient de changer ou pas. Par exemple nous pouvons vérifier si ces données sont conformes aux prérequis de notre prestataire VoIP ou tout autre service externalisé de VoIP ( ex: voir ci-dessus pour OVH).

Pour cela allez dans Diagnostics > Invite de commandes et tapez pfctl -st

pfSense : Command Prompt en mode navigateur

pfSense: Command Prompt en mode navigateur

Avec le profil Conservative, nous pouvons voir ceci:

pfSense : Commande Prompt pfctl -st

Et si nous revenons et sélectionnons à la place le profil Normal, plus agressif, nous pouvons voir ceci:

pfSense : Commande Prompt pfctl -st

Dans le but d’analyser nos propres besoins, nous nous rendons dans Diagnostics > States, en prenant soin de filtrer la liste avec l’IP de la cible qui nous intéresser et qui nous pose un problème (ici un téléphone IP sur offre Centrex), et de déterminer le type (State) de trafic. Il y a trois State possibles : FIRST, SINGLE ou MULTIPLE, une fois repéré vous pourrez par la suite ajuster vos timeout de manière granulaire en fonction du trafic provenant du périphérique ou service qui pose problème.

pfSense : Diagnostics/States

Donc, dans mon cas, on voit bien que mes sessions sont basées sur UDP et qu’ils ont une ou deux State associés à savoir SINGLE et MULTIPLE. Ce sont ces valeurs qui nous intéressent pour pouvoir régler nos Timeout.

Revenons dans Système > Avancé > Pare-feu et NAT, et remettons le profil par défaut Normal  dans «Option d’optimisation du pare-feu».

pfSense : Firewall Optimization Options

Faites défiler jusqu’au bas de la page dans la partie State Timeouts:

C’est à cet endroit que vous pouvez rentrer vos Timeouts. Ici pour notre démonstration et selon notre diagnostic vu précédemment, nous allons changer UDP SINGLE  et UDP MULTIPLE  afin de respecter les minimas recommandés par OVH, c’est à dire supérieur ou égale à 180 secondes pour UDP Single et beaucoup plus pour UDP Multiple.

Note: Voici d’autres pistes pouvant orienter les personnes confronté à des problèmes avec le protocole VoIP dans pfSense.

Grégory Mouchon

Share

pfSense : Snort

Nous vous proposons dans ce tutoriel de mettre en œuvre le fameux NIDS Snort.

Snort est un système de détection d’intrusion (ou NIDS) libre publié sous licence GNU GPL. Il appartient actuellement à Sourcefire (récemment racheté par Cisco). Snort est l’un des plus actifs NIDS Open Source et possède une communauté importante qui a largement contribuée à son succès.

Snort est disponible sous forme de package au sein du logiciel pfSense®. Il s’installe en un click et dispose d’une fenêtre autonome située dans Services >> Snort.

pfsense: Snort interfaces

Qu’est-ce que Snort et comment cela fonctionne ?

Snort analyse en temps réel les paquets qui circulent sur une ou plusieurs interfaces de votre firewall (couche application et transport du modèle TCP/IP). L’analyse permet de détecter les anomalies au sein des paquets (paquets trafiqués = forged packets) ou de repérer les signatures typiques d’un très grand nombre d’attaques réseau connues.

Le blocage des paquets est majoritairement effectué à partir d’une analyse de la signature des paquets (payload).

Snort détecte donc une grande variété d’attaques comme des dépassements de buffers, scans, attaques sur des CGI, sondes SMB, essai d’OS fingerprintings…

Snort permet une normalisation des principaux protocoles mis en œuvre dans les réseaux IP (TCP, UDP, ICMP), ainsi que des protocoles les plus courants (SMTP, POP, IMAP, HTTP, SSL, …).

Snort utilise des règles pour effectuer ses analyses. Celles-ci sont écrites par Sourcefire ou bien fournies par la communauté. Snort dispose d’un jeu de règles de base qui doit être mis à jour régulièrement afin de d’être réellement utile.

Snort peut également être utilisé avec d’autres projets open source tels que SnortSnarf, ACID, sguil et BASE (qui utilise ACID) afin de fournir une représentation visuelle des données et des intrusions ayant eu lieu sur votre réseau. Ces modules ne sont pas nativement compatibles avec la version Snort pfSense® proposée.

Comment installer Snort ?

Allez dans System > Package > Available Packages

Choisir le package Snort dans la liste et l’installer

Configuration initiale de Snort et mise à jour

Il est nécessaire de télécharger un jeu de règles afin de pouvoir ensuite les appliquer au filtrage de votre contenu. Vous disposez de plusieurs jeux de règles qui sont soit payants, soit gratuits.

pfsense: Snort Global Settings

Services > Snort > Global Settings

Pour des règles payantes : cocher “Install Snort VRT Rules” et insérer le code Oinkmaster
Si vous n’avez pas de code, enregistrez-vous sur le site Snort ici : https://www.snort.org/users/sign_up

Il est recommandé, même si vous ne souhaitez pas acheter des règles payantes, de disposer d’un compte et d’un code Oinkmaster. Après l’ajout du code Oinkmaster, vous devez mettre à jour les règles VRT.

Vous pouvez aussi décider d’installer d’autres jeux de règles (Snort Community et Emerging Threat), ces jeux de règles sont moins stables que les règles fournies par Snort et produisent beaucoup plus de faux positifs. Il faut bien prendre soin, dans un premier temps, de ne pas bloquer les trames identifiées par le filtre.

Cliquer sur “Update” pour mettre à jour vos règles :

Services > Snort > Updates

Les règles vont se mettre automatiquement à jour et un message vous indiquera que l’opération est terminée. Vous pouvez vérifier cela dans la fenêtre “Updates”

pfsense: Snort Updates

Configuration de l’interface

Afin de pouvoir utiliser vos règles, il est nécessaire de les appliquer sur une interface de votre firewall. Il s’agit assez souvent de l’interface WAN, mais certaines règles peuvent aussi s’appliquer à d’autres interfaces (LAN, DMZ, …).

Dans le cadre du déploiement dans un DataCenter, vous préférerez déployer cela sur le WAN car les attaques doivent être contrées au niveau du WAN. Pour empêcher vos utilisateurs d’utiliser des protocoles non souhaités, il est préférable de déployer cela sur le LAN.

Snort > Snort Interfaces

Ajouter une nouvelle interface à l’aide du bouton “+”.
Choisir l’interface WAN ou LAN dans “Iface Settings” suivant vos besoins.

pfsense: Snort Services

Les interfaces Snort disposent de très nombreuses options que vous allez bientôt découvrir.

Par défaut ne modifiez que ce qui est nécessaire. Certaines règles étant liées à la façon dont une interface est configurée, la modification de paramètres au niveau des interfaces peut conduire à un blocage du démarrage de votre serveur (ayez cela en tête lors des phases de débug).

pfsense: Snort interface Wan - Edit Settings

Lors d’une première application d’un nouveau jeu de règles, prenez soin de désactiver l’option figurant ci-dessous « Block Offenders ». Cela aura pour effet de passer votre serveur en mode filtrage, mais sans blocage des alertes.

Activation des règles dans Snort :

Vous disposez de nombreux jeux de règles qui peuvent s’appliquer  à partir d’un simple click.
Rendez-vous dans la section « WAN Categories » et activez les jeux de règles qui vous semblent le plus opportun pour votre cas de figure.

pfsense: Snort interface Wan - Categories

Une fois les règles activées, vous pourrez simplement y accéder et les configurer de façon plus fines à partir de l’onglet « WAN Rules » situé à droite de « WAN Categroies ». Chaque catégorie dispose de ses propres règles qui sont activées ou désactivées par défaut.

Prenez le temps de bien analyser vos besoins et repassez sur chaque catégorie pour bien valider les règles que vous avez activées.

Par exemple : rien ne sert d’activer des règles pour IIS si vous ne disposez que de serveurs Apache,…

pfsense: Snort interface Wan - Rules

Les catégories peuvent contenir plusieurs centaines de règles. Les règles sont activées ou désactivées suivant des réglages établis par défaut et qu’il convient souvent de modifier.

L’onglet WAN Rules vous permet de configurer (activer / désactiver / modifier) chaque règle contenue à l’intérieur d’une catégorie. L’accès aux règles d’une catégorie se fait par l’intermédiaire du pop-up « Category » qui est présent sur la page.

Les règles sont identifiées par leur SID (numéro unique). Elles utilisent souvent des alias définis sous forme de $NOM_DE_L_ALIAS – ces derniers peuvent et doivent être configurés dans la section « WAN Variables » de Snort.

Par défaut certains Alias sont déjà configurés, les autres doivent être créés sous forme d’alias à partir de la section “Firewall > Alias” de pfSense.

pfsense: Snort interface Wan - Preprocessors and Flow

L’onglet « WAN Preprocs » permet de régler des paramètres relatifs à l’analyse des trames. Il permet notamment d’assurer une normalisation des paquets selon un certain nombre de protocoles définis (HTTP, FTP, Telnet, IMAP, …) ou une normalisation au niveau des protocoles IP (TCP, UDP, ICMP).

Attention : l’activation ou la désactivation des règles de pré-processing peut entrainer des blocages de Snort au démarrage. Certaines règles ayant besoin de certaine fonction de pré-processing pour fonctionner. Veillez donc à conserver une cohérence entre vos règles et les pré-process activés.

Vous devriez maintenant être en mesure de démarrer votre IDS Snort. Pour cela rendez-vous sur la page « Snort Interfaces » et démarrez cette interface en cliquant sur la croix rouge. Votre NIDS devrait démarrer sans problème. Si ce n’est pas le cas reportez-vous à la section « Logs » décrite ci-dessous pour une analyse plus approfondie du problème rencontré.

La section « Log » permet d’avoir un aperçu des logs du module Snort. Ces logs peuvent aussi être renvoyés vers le système de log par défaut du firewall.

Analyse des paquets bloqués

Il est maintenant possible de regarder ce que votre IDS à bloqué. Pour ce faire, rendez-vous sur la page « Alerts » qui présente une liste des alertes interceptées par votre NIDS.

Une fois la vérification de l’absence de faux positifs, vous pouvez activer le mode bloquant dans l’interface Snort Interfaces > WAN Settings.

pfsense: Snort Alerts

Conclusion

Nous avons vu dans cet article comment activer et configurer un serveur Snort à partir de l’interface mise à votre disposition sous le logiciel pfSense®.
Vous devriez donc être en mesure d’utiliser un NIDS de façon efficace pour contrer de nombreuses attaques issues d’Internet.

L’analyse de la signature des paquets n’est pas l’arme ultime car il est toujours possible de forger des paquets et de contrer ce type de contrôle. Cependant la mise en œuvre de ce type d’attaque avec une modification du payload des paquets est réservée à une petite élite d’un très haut niveau…

Dans un prochain article nous verrons comment mettre en œuvre OpenAppID, une fonction nouvelle de Snort qui permet de bloquer plus de 2700 protocoles applicatifs (y compris : Twitter, Facebook, Apple iTunes, Gmail, …).

Share

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