Protéger les serveurs IoT contre les attaques par inondation UDP
Apprends comment protéger les serveurs IoT contre les attaques par inondation UDP.
― 6 min lire
Table des matières
L'Internet des Objets (IoT) connecte des milliards de dispositifs, rendant les tâches quotidiennes plus faciles. Mais cette connexion amène aussi de nouveaux risques, surtout les cyberattaques. Une menace parmi d'autres est l'attaque par UDP Flood, qui peut submerger les serveurs IoT. Cet article parle de comment protéger ces serveurs contre ces attaques pour qu'ils puissent continuer à fonctionner efficacement.
C’est quoi une attaque par UDP Flood ?
Une attaque par UDP Flood se produit quand des attaquants envoient un énorme nombre de paquets de User Datagram Protocol (UDP) à un serveur. Cette pluie de paquets peut créer une congestion, rendant difficile pour le serveur de traiter le trafic légitime. Quand le serveur est submergé, il peut tomber en panne ou devenir super lent. C'est un gros souci pour les serveurs IoT qui doivent analyser les données entrantes en temps réel pour rester opérationnels.
Les défis rencontrés par les serveurs IoT
Les serveurs IoT recueillent des données de divers dispositifs. Quand une attaque survient, les serveurs ne peuvent pas suivre le trafic entrant, ce qui mène à deux problèmes principaux :
Réponse lente : Le serveur a du mal à traiter les paquets légitimes. Ça peut nuire à sa capacité à analyser les données, détecter des problèmes ou réagir à des situations critiques.
Perte de données : Des informations importantes peuvent être perdues dans le chaos. Cette perte de données peut provoquer de fausses lectures ou des alertes manquées, ce qui peut être grave dans plein d'applications, comme la santé ou les maisons intelligentes.
Besoin de protection
Comme les serveurs IoT sont vulnérables à ces attaques, il y a un besoin urgent de trouver des solutions pour qu'ils continuent à tourner sans encombre, même sous pression. L'objectif est de maintenir la qualité de service (QoS) nécessaire pour gérer efficacement les paquets entrants.
Présentation d'une nouvelle approche
Pour lutter contre ces attaques, un nouveau système a été proposé. Le système utilise un dispositif spécial appelé Smart Quasi-Deterministic Forwarder (SQF). Ce dispositif agit comme un filtre, gérant le flux de paquets entrants avant qu'ils n'atteignent le serveur.
Comment fonctionne le SQF
Le SQF aide en façonnant le trafic entrant. Il contrôle quand les paquets sont envoyés au serveur, s'assurant que le serveur n'est pas submergé. Les caractéristiques importantes du SQF incluent :
Façonnage de trafic : Au lieu d'envoyer tous les paquets instantanément, le SQF les transmet à un rythme régulier. Ça aide à éviter les pics soudains de trafic qui peuvent causer de la congestion.
Gestion des délais : En gérant les délais, le SQF s'assure que le temps d'attente global pour les paquets reste constant, ce qui aide le serveur à fonctionner au mieux.
Aide pendant les attaques : Si une attaque débute, le SQF peut gérer l’inondation de paquets entrants, permettant au serveur de continuer à traiter les données légitimes.
Tester le système
Pour évaluer l'efficacité du SQF, plusieurs tests ont été menés avec un groupe de dispositifs Raspberry Pi agissant comme sources de trafic IoT. Pendant ces tests, un Raspberry Pi a été configuré pour simuler une attaque par UDP Flood pendant que d'autres envoyaient un trafic normal au serveur.
Résultats sans le SQF
Quand l'attaque a eu lieu sans le SQF, le serveur est rapidement devenu submergé. Le nombre de paquets dans la file d'attente du serveur a augmenté rapidement, provoquant un retard. Ce retard a empêché le serveur de fonctionner normalement, ralentissant significativement sa capacité à traiter les données et à répondre aux requêtes légitimes.
Résultats avec le SQF
Quand le SQF était en fonctionnement pendant les tests, les résultats étaient très différents. Il a réussi à contrôler le flux des paquets, ce qui a fait que le serveur a souffert de beaucoup moins de congestion. Les principaux avantages observés étaient :
Longueur de file d'attente réduite : Le nombre de paquets s'accumulant au serveur est resté faible, lui permettant de continuer à traiter les requêtes sans grands délais.
Temps de traitement stables : Le SQF a aidé à garder les temps de traitement du serveur constants, même pendant une attaque. Bien qu'il y ait eu une légère augmentation des temps de traitement, c'était gérable, évitant les délais extrêmes observés sans le SQF.
Meilleure gestion des paquets d'attaque : Le SQF a efficacement tamponné les paquets d'attaque entrants, permettant au serveur de se concentrer sur les données légitimes. Ça a assuré que le serveur pouvait toujours réaliser ses tâches critiques même sous pression.
Atténuer d'autres impacts
Bien que le SQF ait montré de bonnes performances lors des tests, certains défis sont restés. On a découvert que le SQF pouvait accumuler des paquets d'attaque dans sa propre file d'attente. Si cette file devenait trop pleine, ça pouvait ralentir les performances globales du système. Pour y remédier, une stratégie d'atténuation a été mise en place.
La stratégie d'atténuation consistait à fixer un seuil pour le nombre de paquets reçus par le SQF dans un court laps de temps. Si le trafic entrant dépassait ce seuil, le SQF laissait temporairement tomber tous les paquets entrants pendant une courte période. Cette approche a aidé à vider le trafic excessif et à maintenir la performance du système.
Défis de l'atténuation
Bien que la politique d'atténuation basée sur la chute soit efficace, elle a un inconvénient. Des paquets légitimes provenant de dispositifs non compromis peuvent aussi être perdus durant ce processus, entraînant une perte de données potentielle. Donc, il est crucial de trouver un équilibre dans la mise en œuvre de telles mesures.
Conclusion
La montée des cybermenaces, en particulier des attaques par UDP Flood, pose un défi important pour les serveurs IoT. Ces attaques peuvent perturber les opérations normales et causer des pertes de données. Cependant, en introduisant des mesures comme le Smart Quasi-Deterministic Forwarder, il est possible de gérer le trafic entrant et de protéger les serveurs contre le surmenage.
Avec l'avancement technologique continu et la recherche en cours, des systèmes peuvent être développés pour améliorer encore la sécurité et l'efficacité des serveurs IoT. Les travaux futurs impliqueront de tester ces systèmes dans des environnements plus complexes, s'assurant qu'ils peuvent gérer des modèles de trafic variés et maintenir la qualité de service même dans des situations difficiles.
En résumé, protéger les serveurs IoT est essentiel pour maintenir l'intégrité et l'efficacité des systèmes IoT. En mettant en œuvre des solutions innovantes, l'impact des cyberattaques peut être atténué, garantissant que les dispositifs IoT continuent de fonctionner de manière fluide et sécurisée.
Titre: Protecting IoT Servers Against Flood Attacks with the Quasi Deterministic Transmission Policy
Résumé: IoT Servers that receive and process packets from IoT devices should meet the QoS needs of incoming packets, and support Attack Detection software that analyzes the incoming traffic to identify and discard packets that may be part of a Cyberattack. Since UDP Flood Attacks can overwhelm IoT Servers by creating congestion that paralyzes their operation and limits their ability to conduct timely Attack Detection, this paper proposes and evaluates a simple architecture to protect a Server that is connected to a Local Area Network, using a Quasi Deterministic Transmission Policy Forwarder (SQF) at its input port. This Forwarder shapes the incoming traffic, sends it to the Server in a manner which does not modify the overall delay of the packets, and avoids congestion inside the Server. The relevant theoretical background is briefly reviewed, and measurements during a UDP Flood Attack are provided to compare the Server performance, with and without the Forwarder. It is seen that during a UDP Flood Attack, the Forwarder protects the Server from congestion allowing it to effectively identify Attack Packets. On the other hand, the resulting Forwarder congestion can also be eliminated at the Forwarder with "drop" commands generated by the Forwarder itself, or sent by the Server to the Forwarder.
Auteurs: Erol Gelenbe, Mohammed Nasereddin
Dernière mise à jour: 2023-06-19 00:00:00
Langue: English
Source URL: https://arxiv.org/abs/2306.11007
Source PDF: https://arxiv.org/pdf/2306.11007
Licence: https://creativecommons.org/licenses/by/4.0/
Changements: Ce résumé a été créé avec l'aide de l'IA et peut contenir des inexactitudes. Pour obtenir des informations précises, veuillez vous référer aux documents sources originaux dont les liens figurent ici.
Merci à arxiv pour l'utilisation de son interopérabilité en libre accès.