Gagne de la cryptomonnaie GRATUITE en 5 clics et aide institut numérique à propager la connaissance universitaire >> CLIQUEZ ICI <<

Chapitre IV : Proposition sur les résultats d’analyses et audits obtenus pour l’amélioration du réseau de signalisation de la Sonatel

Non classé

IV.1 Analyse des résultats

Dans le cadre de l’amélioration du réseau de signalisation de la Sonatel, des analyses de tous les résultats émanent des études et audits au niveau des plateformes STP et aux liens des signalisations ont été effectué. L’objectif de cette analyse c’est de pouvoir identifier certains disfonctionnements s’ils existent dans le réseau et d’apporter quelles que proposions afin d’améliorer la performance du réseau. En examinant d’une manière détaillée les résultats des études faites dans les différentes entités du réseau de signalisation, les disfonctionnement décelés dans l’intervalle d’observation n’ont pas été très critiques. Mais lors d’une vérification dans l’ensemble des autres fichiers contenant les KPI observés dans les périodes et jours qui n’ont pas été inclus dans notre cadre d’étude, certains défauts ont été détecté dans le réseau.

Puisqu’il sera très difficile d’introduire dans ce document l’étude et analyse faites pour tous les fichiers des indicateurs hebdomadaire ou journalier, nous avons conservé dans ce document que les études d’une journée. Dans les paragraphes qui suivent des décisions ou propositions seront prises suite aux résultats donnés pendent les analyses du système globale (SYSTOT) et ses composant (COMP)

IV.1.1 Décision sur les résultats du SYSTOT(STP)

La plateforme EAGLE STP intègre plusieurs mesures permettant d’analyser le comportement en temps réel ou à la demande du système ou les services installés. Parmi ces mesures il y a ceux qui sont exécuté automatiquement à la mise en service du STP et ceux qui sont lancé à l’aide des commandes. L’administrateur du système peut avoir le choix d’observer certaines mesures pour contrôler seulement un groupe d’entité ou de service. Concernant les mesures du système total appelé en langage technique SYSTOT sont déjà lancées et disponible. Actuellement ces mesures ne sont pas traitées par les administrateurs du système et pourtant ces mesures donnent des indicateurs très pertinents permettant de suivre le fonctionnement du système. Vu les résultats obtenus pendant les études et analyses de cette catégorie de mesures, nous avons décidé de mettre en oeuvre un système de traitement pour ces mesures dans le but d’avoir une statistique globale du traitement des messages dans le STP. L’obtention de ces statistiques est rendu possible par des calculs réalisés sur les indicateurs de mesures donnés. Dans ce cas nous allons proposer aux administrateurs de la plateforme STP de tenir compte de la liste des indicateurs suivant avec une méthode de traitement de ces compteurs :

– ORIGMSUS : Le nombre total des messages sortant qui ont passé avec succès au niveau 2 pour être transmis, tout en portant le PS de STP dans le champ d’OPC.
– ORMSUOCT : Le nombre total d’octets sortants associés à MSU portant le point code de STP dans le champ OPC. Cela inclut les octets ajoutés pour les processus du MTP niveau 2.
– THRSWMSU : Le nombre total de MSU qui ne portent pas le point code du STP dans le champ OPC ou DPC, et ont été passé au niveau 2 pour la transmission.
– TRMSUOCT : Le nombre total d’octets associés aux messages (MSU) entrants portant le point code de STP dans le champ DPC, y compris les octets enlevés pour les traitements du niveau 2.
– TRMDMSUS : Le nombre total des MSUs entrants portant le point code STP dans la
– DPC.
– OMSINVDPC : Nombre de MSU avec un invalide DPC.
– MSULOST2 : Nombre de MSU rejetés parce que la mémoire tampon de routage était en débordement.
– MSULOST4 : Nombre de MSU rejetés car la réception avait une file d’attente débordant.
– MSUDSCRD : Le nombre totale des MSUs qui ont subi l’echec de traitement par la fonction gatewaye screenig (GWS) et ont été rejeté. Voir les compteurs du rapport des faisceaux.
– MSINVDPC : Nombre de message MSU reçus et rejetés car le DPC n’a pas pu être trouvée dans la table de routage STP.
– MSNACDPC : Le nombre total de MSU rejetée à cause d’un inaccessibles DPC.
– GTTPERFD : Le nombre total de MSU ayant réussi la traduction du (GTT).
– GTTUN1NT : Le nombre de fois que SCCP n’a pas pu trouver une traduction dans la table de traduction. Cela comprend la traduction des GT, les traductions de point code, et les traductions Subsystem (SSN).
– PKSCCPMH : La charge maximale du système des messages traités par le SCCP en transactions par second.
– NMSCCPMH : La charge maximale du système journalière la plus récente des messages traités par le SCCP en transaction par second.
– CRSYSAL : Le nombre total des alarmes critique du système.

Comme déjà démontré dans les précédents paragraphes (III.2.1.1 et III.2.1.2) ces indicateurs permettent de savoir la quantité des messages destinés à l’STP et ceux qui le transite. Ils permettent de distinguer le nombre des messages ISUP et les messages SCCP. Ces indicateurs donnent également les nombres de MSU rejetés à cause d’un disfonctionnement qui sera indiqué dans le compteur en question. La capacité en transaction par second (TPS) consommée par le système est mesurée à l’aide de ces indicateurs en affichant en temps réel la consommation maxi en TPS. A l’aide des applications plus connues comme Microsoft Access et Excel, il est plus aisé d’informatiser ces indicateurs afin d’avoir les résultats mentionnés précédemment d’une manière automatique. Nous souhaitons mettre en oeuvre ce projet à la fin du stage en mettant en place une base de donne sur MYSQL ou ACCESS qui facilitera le traitement de ces indicateurs.

IV.1.2 Décision sur les résultats des composants (COMP)

Les résultats obtenus pendant les analyses des différents composants comme les liens LSL, HSL et SGTRAN ont fait apparaitre certains dysfonctionnements que nous allons proposer des solutions pour les résoudre. Comme dysfonctionnement rencontré au cours des analyses c’est les déséquilibres énormes du taux d’occupation des liens de certains faisceaux. Du fait qu’un faisceau qui dispose plus de deux liens de signalisations, si l’un de ces liens devrait écouler du trafic de signalisation qui occupera plus de 40%, l’autre lien doit prendre le trafic pour équilibrer le faisceau. Ce n’est pas le cas pour le faisceau de TIGO vers le STP du site TNP, le lien tnptigo1 occupe 11.99% de son débit pendant que le lien rptigo1 occupe plus de 56% de débit. Les causes ont été citées dans le paragraphe III.2.2.1.1 et maintenant nous allons donner quelques propositions aux administrateurs du réseau de signalisation pour l’éradication des erreurs sur les LINKs.

– Au cours des analyses les compteurs (KPI) liés à la congestion et autres erreurs des liens n’ont rien affiché. C’est pour cette raison que nous suggérons que l’équipe de la maintenance de la plateforme STP et celui de la transmission doivent se concerter pour localiser le coté du problème.
– Ils doivent se référer aux recommandations fixées par l’UIT-T pour faciliter la résolution de ces genres d’erreurs, ici c’est la recommandation Q.706 qui traite cette partie.
– Plusieurs manières existent pour le dépannage des canaux défaillants :
Dans notre cas, des retransmissions de messages sur certains canaux à cause des défaillances survenues sur ces canaux sémaphores sont éprouvés (les liens tigo, de la plateforme VMS etc …)

Les hypothèses suivant sont à tenir compte :

– Mesurer la qualité de la liaison sémaphore de données par son taux d’erreur sur les canaux sémaphores.
– Vérifier si le taux d’erreur sur les bits exploités sur les liaisons est inférieur à 10-5.
– Si le taux d’erreur sur les trames sémaphores dépasse le 4×10-3 le dispositif de surveillance des erreurs d’éclanche le passage sur le canal sémaphore de secours.
– Etc ….

Concernant les liens SIGTRAN, il n’y avait pas des erreurs qui peuvent entrainer des disfonctionnement dans les liaisons IP détectées.
Actuellement les indicateurs utilisés pour le suivit et la performance du réseau de signalisation ce sont les indicateurs liés seulement aux liaisons et faisceaux sémaphore. Les administrateurs sont intéressé par les indicateurs leurs permettant de calculer la charge des liens (LSL, HSL et SIGTRAN) ainsi que les congestions.

Pour améliorer la qualité de service du réseau, nous leurs proposons de tenir compte encore plus les indicateurs suivant :

– MSURETRN : Nombre de MSU retransmis depuis le STP sur ce lien à cause des erreurs.
– MSGSRGTT : Nombre total de MSU entrants nécessitant une traduction du GTT.
– GAPACKSR : Le nombre d’écart de bloques d’accusé de reception (Gap Ack Block) dans un SACK (Selection Acknowledgement) d’unité de contrôle (control Chunk) réçu de SCTP pair distant, indiquant les écarts d’occurrences des blocs de donnés reçus dans les pairs représenter par leur transport de numéro de séquence (TSNs). Ces mesures permettent au personnel du réseau de juger la performance de livraison des messages des couches d’adaptation relative à l’écart limite d’accuser de réception.
– PEERFAIL : Le nombre de détection des pannes pour les pairs terminaux distants dû aux événements d’association, comme le franchissement de seuil maximal des retransmissions association.
– ASMAXRTO : La valeur maximale observée de l’etat de la variable de dépassement de la retransmission (RTO) de SCTP, en milliseconde, pour les paquets SCTP qui devraient être transmis mais ils n’ont pas été transmis à l’hôte distant. Cette valeur est seulement pour l’intervalle d’observation.

Ces indicateurs sont inclus dans les liaisons sémaphores et SIGTRAN.

IV.2 Dimensionnement du réseau de signalisation

L’analyse et l’audit effectués dans le réseau de signalisations de la Sonatel ont fourni beaucoup des résultats et des paramètres permettant de bien déterminer la performance du réseau et son état de lieu. Dès lors, tenant compte de ce qui ont été obtenu comme résultats, nous pouvons estimer que le réseau de signalisation de la Sonatel est dimensionné à 75%. En observant sur des cas particuliers comme le lien ogb5002 qui est occupé à 81.85%, nous suggérons de dimensionner le faisceau de ce lien en vu de préserver la qualité de service de cette destination. L’ajout d’un deuxième lien sur ce faisceau sera suffisant si l’operateur a les moyens. Concernant les autres liens comme les liens du faisceau MSC05NAT1 ne nécessitent pas à présent de les dimensionner mais l’idéal c’est d’équilibrer le trafic sur les deux liens. Par exemple le lien rpmsc5nat1 portant le COC 0 est chargé à 47,13% tandis que le deuxième est de 19,69%, si un partage de charge n’est pas appliqué sur ce faisceau il est préférable de le faire.

IV.3 Méthodes de sécurisation du réseau SIGTRAN

Les réseaux IP prennent de plus en plus d’importance dans les réseaux des télécommunications, de l’accès jusqu’au transport.

. Comment sécuriser le réseau SS7 standard

La sécurité dans les réseaux téléphoniques est principalement basée sur la fermeture totale d’un réseau. Deux principaux protocoles sont utilisés :

– Les protocoles d’accès RNIS (et les autres)
– Les protocoles de la pile SS7 du coeur réseau

Comme les réseaux de signalisations de base (SS7) sont souvent éloignés physiquement et/ou inaccessibles à l’utilisateur, il est supposé qu’ils sont protégés contre les utilisateurs malveillants. Les équipements télécoms sont souvent sous clés. Entre une frontière du réseau et le réseau SS7, le filtrage de paquets est parfois utilisé. Les utilisateurs finaux ne sont pas directement connectés à des réseaux SS7. Les protocoles d’accès sont utilisés pour l’utilisateur final de signalisation. Les protocoles de signalisations de l’utilisateur final sont traduits en protocoles SS7 de base des commutateurs téléphoniques gérés par des opérateurs de réseau. Les autorités de la réglementation exigent souvent les commutateurs SS7 avec des connexions à différents commutateurs SS7 d’être conforme au niveau national et/ou aux spécifications de test international. Il n’y a pas des méthodes normalisées d’utilisation des technologies de cryptage pour assurer la confidentialité ou l’utilisation de technologies d’authentification. Cette description s’applique aux réseaux de téléphonie exploité par un opérateur unique, et aussi de multiples réseaux de téléphonie étant connectés et gérés par des opérateurs différents.

. Comment sécuriser le réseau SS7 sur IP

Contrairement dans un réseau IP quels que soit les protocoles déployés, la sécurité de la communication est obligatoire dans certains scénarios du réseau pour prévenir les attaques malveillantes. Tous les protocoles SIGTRAN utilisent le Stream Control Transmission Protocol (SCTP) comme protocole de transport. Quand un réseau utilisant les protocoles SIGTRAN implique plus qu’une partie, il peut ne pas être raisonnable de s’attendre à ce que toutes les parties ont mis en oeuvre la sécurité d’une manière suffisante. De bout en bout la sécurité devrait être le but, par conséquent, il est recommandé qu’IPSec (IP Security Protocols) ou TLS (Transport Layer Security) soit utilisé pour assurer la confidentialité de la charge utile de l’utilisateur. Ces protocoles de sécurité visent à sécuriser les échanges au niveau de la couche réseau.

Il est clair que le réseau sémaphore était jusqu’à récemment considérée comme un périmètre inviolable, et c’était en effet le cas tant qu’il restait sous le contrôle exclusif de l’opérateur. Cela n’est plus le cas aujourd’hui, IP étant rentré dans la place à travers la suite des protocoles SIGTRAN. En transportant la signalisation (les briques de la pile protocolaire SS7) à travers un protocole fiable (SCTP), les risques d’exposer le coeur du réseau sont toujours présents. En effet, à travers un point d’accès SIGTRAN accessible en IP, et moyennant une couche d’adaptation au protocole sous-jacent (M3UA pour MTP3, M2UA pour MTP2, IUA pour ISDN, etc…), les passerelles de signalisation SS7 deviennent joignables. Le coeur de réseau est alors à portée aux mains des malveillants.

. Imagination d’un scénario d’attaque

Plusieurs possibilités de lancer des attaques offensives dans un réseau d’un opérateur actuellement semblent beaucoup faciles pour les malveillants compétents, nous pouvons citer:

– Les lookups HLR: si un pirate envoie un message MAP SendRoutingInfo, il recevrait un accusé en retour le MSC sur lequel est localisé le mobile (et donc le pays). Mais au fait, « qui a dit que le pirate était bien un HLR ? » Une fois le mobile localisé, on peut imaginer toutes les conséquences, dès les plus légères (SPAM géolocalisé…) aux plus sérieuses (cambriolage…)
– Les attaques ISUP: si les points sémaphores des commutateurs du réseau sont connus, rien de plus facile que de formater un message ISUP, en indiquant le commutateur d’origine, de destination, et le circuit (CIC). Un message initial d’adresse (IAM) va par exemple initier une communication et donc occuper un circuit: il est facile à ce rythme de saturer les circuits disponibles en créant un déni de service.
– Autre type d’attaque: l’envoi d’un message de libération (REL) au hasard va libérer une communication établie entre utilisateurs légitime.
– Un message de location update a pour objet légitime de signaler la nouvelle localisation d’un mobile. Mais l’utilisé frauduleusement, peut faire croire au réseau qu’un abonné mobile promène dans le réseau de la Sonatel et pour tant il est en roaming dans un autre réseau. Mais il sera difficile au MSC de joindre cet abonné dans le réseau où il fait le roaming.
– Au-delà des attaques du réseau, la fraude peut prendre un tour purement financier, comme l’envoi de SMS “gratuits” par exemple.

Dans tous les cas, nous voyons que les dégâts financiers et l’image de l’opérateur sont considérables.

Par conséquent, nous voyons que de bout en bout, tout le périmètre du réseau mobile est susceptible d’être vulnérable. Des sociétés spécialisées comme P1 security et serial entrepreneurs etc…, sont fondés sur ce constat de vulnérabilité, développent des produits d’audits, des surveillances réseaux télécom. Ces genres des outils proposés aux opérateurs permettent de restituer la cartographie SS7 du réseau (points sémaphores, mais aussi points d’accès SCTP, numéros de sous-systèmes SCCP, etc…). Cette cartographie est obtenue à travers un scan extensif du réseau:

– points d’entrée SCTP,
– points sémaphores,
– sous-systèmes SCCP,
– et enfin applications de test (MAP, INAP, CAP, etc …)

L’opérateur exploitant ces genres d’outils peut avoir une vue globale de son réseau, se prévenir à des éventuelles attaques et renforcer la sécurité de son réseau de signalisation.

Page suivante : Conclusion

Retour au menu : Audit et analyse de la qualité et de la performance du réseau de signalisation SS7/SIGTRAN de la Sonatel