Securing network applications in software defined networking
Sécurisation des applications réseau dans des réseaux définis par logiciel
Résumé
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 9security 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. (...)
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.
Domaines
Cryptographie et sécurité [cs.CR]
Origine : Version validée par le jury (STAR)
Loading...