Échec de la classification et de la détection des plug-ins P2P pour l'application avec les flux SSL dans ASR5x00

Introduction

Ce document décrit un scénario spécifique dans lequel l'abonné utilise des applications gratuites telles que WhatsApp, Snapchat, etc. avec des flux SSL (Secure Sockets Layer) tout en bloquant le trafic d'autres utilisateurs. Cette application particulière s'exécute sur la gamme Cisco ASR 5x00. SSL est un protocole de réseau informatique qui gère l'authentification des serveurs, l'authentification des clients et la communication cryptée entre les serveurs et les clients.

Problème

Pour détecter une application, vous avez besoin de paquets initiaux pour l'analyse. Ces deux exigences contradictoires sont remplies dans toute la mesure possible.

a) La détection doit se produire dans le premier paquet lui-même

b) La précision de détection doit être de 100 %

Si vous essayez de remplir la condition (a) et de marquer toutes les applications du premier paquet (ce qui n'est pas possible), la condition (b) sur la précision de détection souffre.Afin de rendre la précision de détection correcte, vous avez besoin de plus de paquets pour analyser beaucoup d'applications (il y a des applications et des flux où l'application est détectée dans le premier paquet lui-même). Dans le cas d'une même application, il peut arriver que vous puissiez marquer certains flux dans le premier paquet lui-même, alors que d'autres flux de la même application ont besoin de plus de paquets pour l'analyse.

Ainsi, si une application est gratuite tout en bloquant tout autre trafic, il peut arriver que le paquet initial de l'application ne soit pas détecté car il ne contient pas suffisamment d'informations. En particulier pour les applications basées sur les flux SSL, le protocole est marqué à l'aide du champ nom-serveur-indication présent dans le paquet hello-client ou du nom commun présent dans le certificat SSL. Comme le nom du serveur est un champ facultatif, il n'est pas toujours présent.  Comme l'illustre cette image, dans un flux WhatsApp SSL, après une connexion en trois étapes (TWH), le paquet Hello du client est envoyé par l'application. Une trace PCAP ne montrant aucun champ SNI (Server Name Indication). On peut également voir plusieurs retransmissions de paquets Hello client qui finissent par être abandonnés.

 En outre, comme l'illustre cette image, ils sont les hex-octets du paquet client-hello dans lequel le champ SNI, utilisé pour le marquage de WhatsApp, n'est pas présent. Par conséquent, le paquet client-hello ne peut pas être marqué comme WhatsApp et n'est pas détecté. Comme ce paquet entre dans un autre groupe de notation, il est abandonné et donc plusieurs retransmissions de paquet client-hello sont vues (voir trame n° 5449, 5453, 5469). Enfin, la connexion est interrompue. Plusieurs de ces flux sont observés dans le pcap. C'est la raison pour laquelle aucune activité utile, par exemple le téléchargement d'image pour WhatsApp, ne peut être effectuée.

Dépannage

1. capture  monitor subscriber imsi XXXX with following options
19 - User L3
X - PDU Hexdump
Verbosity level 5

Ces commandes donnent les statistiques de l'analyseur pour les applications.

# show act analyzer statistics name p2p application snapchat
# show act analyzer statistics name p2p application whatsapp

Pour vérifier la version du plug-in :

#show plugin p2p
Wednesday July 29 22:12:07 SAST 2015
plugin p2p
  patch-directory /var/opt/lib
  base-directory /lib
  base-version 1.50.52055
  module priority 1 version 1.139.505

Solution

Afin d'éviter, vous devez vous assurer que les paquets avant qu'une application (disons WhatApp) soit marquée et passe par. 

Utilisez cette règle :

ruledef ssl_clienthello
      tcp either-port = 443
      tcp payload-length >= 44
      tcp payload  starts-with hex-signature 16-03
#exit

Tout paquet correspondant à la règle ci-dessus ne doit pas être abandonné. La priorité de cette règle doit être juste au-dessus de la règle par défaut (ip-any ruledef) qui correspondait à ce paquet et qui l'a fait tomber.

En utilisant cette configuration, seuls les paquets correspondant aux trois lignes de règle ci-dessus sont libres. Celles-ci incluent uniquement les paquets de connexion initiaux dans le flux SSL (tels que client-hello, server-hello) qui sont autorisés à utiliser cette règle, alors que tous les autres paquets dans le flux SSL ne correspondent pas à cette règle. Ainsi, s'il y a un SSLflow qui appartient à une autre application (autre que ce que vous voulez libérer), il ne peut pas y avoir de transaction utile, puisque seuls les deux à trois premiers paquets d'un flux SSL sont autorisés à utiliser cette règle.

Exemple de configuration

La règle suggérée doit avoir une priorité supérieure à all-ip_004_012_00016 ruledef (ip any-match = TRUE) et

action de charge qui autorise le trafic similaire à la règle whapp.(sid_040_rg_400_rate_99999/sid_040_rg_400_rate_00032/ sid_040_rg_400_rate_00 064 avec le groupe de notation 400 et tout tarif).

Avec cette configuration, le paquet Hello du client atteint la règle proposée et est autorisé plutôt que redirigé. Voici les deux bases de règles où sont observées les règles de l'analyse des risques :

rulebase mbc-internet-rs
action priority 1087 dynamic-only ruledef WhatsApp_P2P_040_400_99999_All_internet charging-action sid_040_rg_400_rate_99999
action priority 1088 dynamic-only ruledef WhatsApp_P2P_040_400_00064_All_internet charging-action sid_040_rg_400_rate_00064
action priority 1089 dynamic-only ruledef WhatsApp_P2P_040_400_00032_All_internet charging-action sid_040_rg_400_rate_00032
action priority [1090-9909] dynamic-only ruledef ssl_clienthello charging-action sid_040_rg_400_rate99999/00064/00032 --> Higher priority than all-ip ruledef and charging action with rating group 400
action priority 9910 dynamic-only ruledef all-ip_004_012_00016_MI_internet charging-action sid_004_rg_012_rate_00016
action priority 9920 dynamic-only ruledef all-ip_004_012_00032_MI_internet charging-action sid_004_rg_012_rate_00032
action priority 9930 dynamic-only ruledef all-ip_004_012_00064_MI_internet charging-action sid_004_rg_012_rate_00064


rulebase mbc-iphone-rs
action priority 1206 dynamic-only ruledef WhatsApp_P2P_040_400_99999_All_iphone charging-action sid_040_rg_400_rate_99999
action priority 1207 dynamic-only ruledef WhatsApp_P2P_040_400_00064_All_iphone charging-action sid_040_rg_400_rate_00064
action priority 1208 dynamic-only ruledef WhatsApp_P2P_040_400_00032_All_iphone charging-action sid_040_rg_400_rate_00032
action priority [1209-8999] dynamic-only ruledef ssl_clienthello charging-action sid_040_rg_400_rate99999/00064/00032 --> Higher priority than all-ip ruledef and charging action with rating group 400
action priority 9000 dynamic-only ruledef all-ip_015_150_00016_ALL_iphone charging-action sid_015_rg_150_rate_00016
action priority 9010 dynamic-only ruledef all-ip_015_150_00032_ALL_iphone charging-action sid_015_rg_150_rate_00032
action priority 9020 dynamic-only ruledef all-ip_015_150_00064_ALL_iphone charging-action sid_015_rg_150_rate_00064
action priority 9030 dynamic-only ruledef all-ip_015_150_99999_ALL_iphone charging-action sid_015_rg_150_rate_99999

charging-action sid_040_rg_400_rate_99999
content-id 400
service-identifier 40
billing-action egcdr
cca charging credit
exit

ruledef ssl_clienthello
tcp either-port = 443
tcp payload-length >= 44
tcp payload  starts-with hex-signature 16-03
exit