Klassifizierungs- und Erkennungsfehler des P2P-Plug-ins für Anwendungen mit SSL-Datenflüssen in ASR5x00

Einführung

In diesem Dokument wird ein bestimmtes Szenario beschrieben, in dem der Teilnehmer Anwendungen mit freier Übertragungsrate wie Whatsapp, Snapchat usw. mit SSL-Datenflüssen (Secure Sockets Layer) verwendet und gleichzeitig anderen Benutzerdatenverkehr blockiert. Diese Anwendung wird auf Cisco Aggregated Service Routern (ASR) der Serie 5x00 ausgeführt. SSL ist ein Netzwerk-Protokoll für Computer, das die Serverauthentifizierung, die Client-Authentifizierung und die verschlüsselte Kommunikation zwischen Servern und Clients verwaltet.

Problem

Um eine beliebige App zu erkennen, benötigen Sie einige erste Pakete für die Analyse. Diese beiden widersprüchlichen Anforderungen sind so weit wie möglich erfüllt.

a) Die Erkennung muss im ersten Paket selbst erfolgen.

b) Die Genauigkeit der Erkennung muss 100 % betragen.

Wenn Sie versuchen, die Anforderung (a) zu erfüllen und alle Apps im ersten Paket zu kennzeichnen (dies ist nicht praktisch möglich), leidet die Anforderung (b) an der Erkennungsgenauigkeit.Um die Erkennungsgenauigkeit zu verbessern, benötigen Sie mehr Pakete, um viele Anwendungen zu analysieren (es gibt Anwendungen und Datenflüsse, bei denen die App im ersten Paket selbst erkannt wird). Im Fall derselben App können Sie möglicherweise einige Datenflüsse im ersten Paket selbst markieren, während andere Datenflüsse derselben App mehr Pakete für die Analyse benötigen.

Wenn also eine App frei bewertet wird und anderen Datenverkehr blockiert, kann es passieren, dass das ursprüngliche Paket der App nicht erkannt wird, da es nicht genügend Informationen enthält. Bei Anwendungen, die auf SSL-Datenflüssen basieren, wird das Protokoll entweder mit dem im Client-Hello-Paket vorhandenen Feld für die Servernamenanzeige oder mit dem im SSL-Zertifikat enthaltenen allgemeinen Namen gekennzeichnet. Da der Servername ein optionales Feld ist, ist es nicht immer vorhanden.  Wie in diesem Bild gezeigt, wird in einem Whatsapp SSL-Fluss nach dem Three-Way-Handshake (TWH) das Client-Hello-Paket von der App gesendet. Eine PCAP-Ablaufverfolgung ohne das Feld "Server Name Indication (SNI)" (Servernamenanzeige). Ebenfalls sichtbar sind mehrere Neuübertragungen von Client-Hello-Paketen, die schließlich verworfen werden.

 Wie in diesem Bild gezeigt, sind ihre Hex-Bytes für das Client-Hello-Paket, in dem das SNI-Feld zum Markieren von Whatsapp nicht vorhanden ist. Daher kann das Client-Hello-Paket nicht als Whatsapp markiert werden und wird nicht erkannt. Da dieses Paket in eine andere Bewertungsgruppe fällt, wird es verworfen und daher werden mehrere Neuübertragungen von Client-Hello-Paketen angezeigt (siehe Frame Nr. 5449, 5453, 5469). Schließlich wird die Verbindung beendet. Mehrere solche Ströme sind in der pcap gesehen. Aus diesem Grund können keine nützlichen Aktivitäten, z. B. das Hochladen von Bildern für Whatsapp, durchgeführt werden.

Fehlerbehebung

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

Diese Befehle geben den Analysatorstatus für die Anwendungen an.

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

So prüfen Sie die Plug-in-Version:

#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

Lösung

Um dies zu vermeiden, müssen Sie sicherstellen, dass die Pakete vor einer App (z. B. whatsapp) markiert und durchlaufen werden. 

Verwenden Sie dieses Regeldef:

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

Jedes Paket, das mit der obigen Regel übereinstimmt, darf nicht verworfen werden. Die Priorität dieses Regeldefs muss genau über der Standardregeldef (ip-any rules-def) liegen, die mit diesem Paket übereinstimmt und dazu führt, dass es verworfen wird.

Bei Verwendung dieser Konfiguration werden nur die Pakete, die mit den drei oben genannten Regellinien übereinstimmen, als "free" eingestuft. Dazu gehören nur die anfänglichen Handshake-Pakete im SSL-Fluss (z. B. client-hello, server-hello), die mit dieser Regel zulässig sind, während alle anderen Pakete im SSL-Fluss nicht mit dieser Regel übereinstimmen. Wenn es also einen SSLflow gibt, der zu einer anderen App gehört (außer einer Whatsanwendung, die Sie freigeben möchten), kann es keine sinnvolle Transaktion geben, da nur die ersten zwei bis drei Pakete eines SSL-Datenflusses diese Regel verwenden dürfen.

Beispielkonfiguration

Die vorgeschlagene Regeldef muss eine höhere Priorität haben als all-ip_004_012_00016 rulesdef (ip any-match = TRUE), und

Ladeaktion, die den Datenverkehr ähnlich whatsapp regelndef.(sid_040_rg_400_rate_9999/sid_040_rg_400_rate_00032/ sid_040_rg_400_rate_00 064 mit Ratinggruppe 400 und beliebigem Rating).

Mit dieser Konfiguration trifft das Client-Hello-Paket auf die vorgeschlagene Regeldef und darf nicht umgeleitet werden. Dies sind die beiden Regeln, in denen Whatsapp-Regeln angezeigt werden:

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