Sécurisation des applications réseau dans des réseaux définis par logiciel‏‏

Suite à l'introduction de divers services Internet, les réseaux informatiques ont été reconnus ‏comme ayant joué un rôle essentiel dans la vie moderne au cours du dernier demi-siècle. Le ‏développement rapide et la convergence des technologies informatiques et de communication ‏créent le besoin de connecter divers périphériques avec différents systèmes d'exploitation ‏et protocoles. Il en résulte de nombreux défis pour fournir une intégration transparente ‏d'une grande quantité de dispositifs physiques ou d'entités hétérogènes. Ainsi, les réseaux ‏définis par logiciel (Software Defined Networks, SDN) en tant que paradigme émergent ont ‏le potentiel de révolutionner la gestion des réseaux en centralisant le contrôle et la visibilité ‏globale sur l'ensemble du réseau. Cependant, les problèmes de sécurité demeurent une préoccupation ‏importante et empêchent l'adoption généralisée du SDN.‏‏ Pour identifier les menaces, nous avons effectué une analyse en 3 dimensions pour évaluer ‏la sécurité de SDN. Dans cette analyse, nous avons repris 9 principes de sécurité pour ‏le contrôleur SDN et vérifié la sécurité des contrôleurs SDN actuels avec ces principes. ‏Nous avons constaté que les contrôleurs SDN, ONOS et OpenContrail sont relativement plus ‏sécurisés que les autres selon notre méthodologie d'analyse. Nous avons également trouvé ‏le besoin urgent d'atténuer le problème d'injection d'applications malveillantes. Par conséquent, ‏nous avons proposé une couche d'amélioration de la sécurité (Security-enhancing layer, couche SE) ‏pour protéger l'interaction entre le plan de contrôle et le plan d’application. ‏‏Cette couche SE est indépendante du contrôleur et peut fonctionner avec OpenDaylight, ONOS, ‏Floodlight, Ryu et POX, avec une faible complexité de déploiement. Aucune modification de ‏leurs codes sources n'est requise dans leur mise en œuvre alors que la sécurité globale du ‏contrôleur SDN est améliorée. Le prototype I, Controller SEPA, protège le contrôleur ‏SDN avec l'authentification de l'application réseau, l'autorisation, l'isolation des ‏applications et le blindage de l'information avec un coût additionnel négligeable de moins ‏de 0,1% à 0,3%. Nous avons développé le prototype II de la couche SE, appelé Controller DAC, ‏qui rend dynamique le contrôle d'accès. Le controller DAC peut détecter l'utilisation ‏abusive de l'API en comptabilisant les opérations de l'application réseau avec un coût ‏additionnel inférieure à 0,5%.‏‏ Grâce à cette couche SE, la sécurité globale du contrôleur SDN est améliorée mais avec un ‏coût additionnel inférieure à 0,5%. De plus, nous avons tenté de fournir un framework de ‏déploiement d'application réseau sécurisé pour le contrôleur SDN avec un orchestrateur. ‏Tout d'abord, nous avons sécurisé le contrôleur SDN en utilisant la file d'attente de ‏messages pour remplacer les interfaces populaires actuelles, y compris les RESTful APIs ‏et les APIs internes, à l'aide d'une interface orientée événement décomposable. Avec cette ‏nouvelle interface northbound, l'orchestrateur peut déployer les applications réseau dans ‏le bac à sable(sanbox) avec contrôle des ressources et contrôle d'accès. Cette approche ‏peut efficacement protéger contre les menaces, qui incluent les attaques d'épuisement des ‏ressources (Resource exhaustion attacks) et le traitement des données sur le contrôleur SDN ‏actuel. Nous avons également implémenté une application réseau déployée par l'orchestrateur ‏pour détecter une attaque spécifique à OpenFlow, appelée attaque par contournement de priorité, ‏pour évaluer l'utilité de l'interface norttbound. À long terme, le temps de traitement d'un ‏message packet_in dans cette interface est inférieur à cinq millisecondes mais l'application ‏réseau peut être complètement découplée et isolée du contrôleur SDN.‏‏The rapid development and convergence of computing technologies and communications ‏create the need to connect diverse devices with different operating systems and protocols.‏ This resulted in numerous challenges to provide seamless integration of a large amount of ‏heterogeneous physical devices or entities. Hence, Software-defined Networks (SDN), as an ‏emerging paradigm, has the potential to revolutionize the legacy network management and‏ accelerate the network innovation by centralizing the control and visibility over the network. ‏However, security issues remain a significant concern and impede SDN from being widely‏ adopted.‏‏To identity the threats that inherent to SDN, we conducted a deep analysis in 3 dimensions‏ to evaluate the security of the proposed architecture. In this analysis, we summarized 9‏security principles for the SDN controller and checked the security of the current well-known‏ SDN controllers with those principles. We found that the SDN controllers, namely ONOS ‏and OpenContrail, are relatively two more secure controllers according to our conducted ‏methodology. We also found the urgent need to integrate the mechanisms such as connection ‏verification, application-based access control, and data-to-control traffic control for securely ‏implementing a SDN controller. In this thesis, we focus on the app-to-control threats, which ‏could be partially mitigated by the application-based access control. As the malicious network ‏application can be injected to the SDN controller through external APIs, i.e., RESTful APIs, or ‏internal APIs, including OSGi bundles, Java APIs, Python APIs etc. In this thesis, we discuss ‏how to protect the SDN controller against the malicious operations caused by the network‏ application injection both through the external APIs and the internal APIs. ‏We proposed a security-enhancing layer (SE-layer) to protect the interaction between the‏ control plane and the application plane in an efficient way with the fine-grained access control, ‏especially hardening the SDN controller against the attacks from the external APIs. This‏ SE-layer is implemented in the RESTful-based northbound interfaces in the SDN controller‏ and hence it is controller-independent for working with most popular controllers, such as‏ OpenDaylight, ONOS, Floodlight, Ryu and POX, with low deployment complexity. No‏ modifications of the source codes are required in their implementations while the overall security ‏of the SDN controller is enhanced. Our developed prototype I, Controller SEPA, protects well‏ the SDN controller with network application authentication, authorization, application isolation,‏ and information shielding with negligible latency from less than 0.1% to 0.3% for protecting‏ SDN controller against the attacks via external APIs, i.e, RESTful APIs. We developed also‏ the SE-layer prototype II, called Controller DAC, which makes dynamic the access control.‏ Controller DAC can detect the API abuse from the external APIs by accounting the network‏ application operation with latency less than 0.5%. Thanks to this SE-layer, the overall security of the SDN controller is improved but with a latency of less than 0.5%. However, the SE-layer can isolate the network application to communicate the controller only through the RESTful APIs. However, the RESTful APIs is ‏insufficient in the use cases which needs the real-time service to deliver the OpenFlow messages. ‏Therefore, we proposed a security-enhancing architecture for securing the network application‏ deployment through the internal APIs in SDN, with a new SDN architecture dubbed SENAD. In‏ SENAD, we split the SDN controller in: (1) a data plane controller (DPC), and (2) an application ‏plane controller (APC) and adopt the message bus system as the northbound interface instead ‏of the RESTful APIs for providing the service to deliver the OpenFlow messages in real-time.‏ (...