Une attaque plus ou moins nouvelle fait parler d’elle cette semaine. Je dis « plus ou moins nouvelle », car l’attaque en elle-même n’a rien de très original. Les attaques ICMP existent depuis les années 1990. J’emploie également cette expression parce que cette attaque tranche nettement avec les attaques volumétriques très médiatisées qui font la une lorsqu’elles perturbent l’accès à la moitié d’Internet. Il s’agit d’une attaque DoS (notez qu’il n’y a qu’un seul « D », et non deux) visant des pare-feu connus et largement utilisés, qui peut, sans grand effort, mettre une entreprise à genoux.
Je ne vais pas vous assommer avec les détails du fonctionnement de cette attaque ICMP (ping !) baptisée BlackNurse (pour une raison qui m’échappe encore). Il existe déjà une multitude de ressources et de commentaires sur le sujet : Threat Post, El Reg, TDC SOC, ou encore Netresecpour commencer. Je tenais surtout à attirer l’attention sur les perturbations dévastatrices que cette attaque pourrait causer aux entreprises, en particulier à celles qui dépendent fortement d’applications dans le cloud.
Car cette attaque ne vise pas seulement à perturber l’accès aux applications de l’extérieur vers l’intérieur, mais aussi à perturber l’accès aux applications de l’intérieur vers l’extérieur. Dans son rapport, TDC SOC le souligne explicitement : « Lorsqu’une attaque est en cours, les utilisateurs du réseau local ne peuvent plus envoyer ni recevoir de trafic vers ou depuis Internet. »
Côté LAN. C’est le côté métier du pare-feu.
Nous avons tendance à considérer les pare-feu comme une réponse tactique visant à empêcher les attaquants de pénétrer dans les réseaux de notre entreprise. Ils sont les remparts autour du château, les sacs de sable le long de la rivière, le coupe-feu en pleine nature qui tente d’arrêter un incendie dévastateur. Mais les pare-feu remplissent depuis longtemps une double fonction dans l’entreprise : ils contrôlent également les accès de l’intérieur vers l’extérieur. À l’origine, ils servaient à restreindre l’accès à un Internet encore balbutiant et restent aujourd’hui un moyen de mettre en œuvre des mesures préventives contre les tentatives de « communication avec le serveur d’origine » menées par des logiciels malveillants et des virus ayant réussi à infecter des ressources internes.
Aujourd’hui, la généralisation des applications de productivité dans le cloud nécessite un accès de l’intérieur vers l’extérieur. Et si nous utilisons des applications dans le cloud, nous avons forcément besoin d’un accès à Internet. Salesforce.com. Concur. Google Docs. Les réseaux sociaux. La liste des applications situées en dehors de l’entreprise et auxquelles celle-ci doit accéder ne cesse de s’allonger. Comme l’illustre cet intéressant graphique de Skyhigh Networks, l’utilisation des applications dans le cloud en entreprise augmente régulièrement. Son rapport du quatrième trimestre 2015 indiquait d’ailleurs : « Une organisation utilise désormais en moyenne 1 154 services cloud. »
Les entreprises dépendent incontestablement du cloud.
Cela signifie que toute interruption de l’accès à ces services a des conséquences désastreuses sur la productivité, qui constitue l’un des principaux indicateurs de performance de toute entreprise.
Ainsi, une attaque comme BlackNurse, relativement facile à mener et ne nécessitant guère plus qu’un simple ordinateur portable, est extrêmement perturbatrice malgré sa relative simplicité. L’objectif de telles attaques est simple : épuiser les ressources. Les attaques lentes et à faible débit, qu’elles ciblent des pare-feu ou des serveurs web, visent à accaparer les ressources afin que l’appareil ne puisse plus répondre aux requêtes légitimes. Le problème est que ces attaques sont souvent plus difficiles à détecter que leurs équivalents volumétriques. Les volumes de trafic élevés sont facilement repérables. Ils déclenchent des alarmes et des voyants rouges, et tout le monde comprend immédiatement ce qui se passe. Au cours des dix dernières années, nous avons consacré beaucoup d’efforts à comprendre comment lutter contre ces attaques et, heureusement, nous y parvenons de mieux en mieux.
Mais détecter une attaque lente et à faible débit est plus difficile. Le processeur atteint soudainement 100 % d’utilisation et ne répond plus. Il peut s’agir d’un problème logiciel. D’un problème matériel. Ou de bien d’autres choses. Éplucher les journaux pour repérer le faible volume de paquets caractéristique de ce type d’attaque revient à chercher une aiguille dans une botte de foin. Selon les chercheurs, les attaques BlackNurse ne génèrent que 15 à 18 Mbit/s. Oui, vous avez bien lu. Il n’y a pas de « G » dans cette unité. Cela représente environ 40 000 à 50 000 paquets par seconde, ce qui est insignifiant pour les pare-feu modernes. À l’inverse, l’attaque DDoS enregistrée contre Dyn atteignait environ 1 Tbit/s. Il s’agit d’un « T », qui est plus grand que « G » et bien plus grand que « M ».
La réponse à ce type d’attaques consiste généralement à déplacer les applications vers le cloud, où les services de pare-feu ne sont pas limités par des concepts aussi archaïques que les « ressources limitées » et peuvent évoluer sans effort, comme par magie. Sauf que ce n’est pas vraiment une solution, car l’entreprise compte toujours des employés derrière le pare-feu de l’entreprise qui doivent accéder à ces applications (et à d’autres). Et c’est leur accès qui est perturbé lorsque la cible est le pare-feu de l’entreprise qui se trouve entre eux et « le cloud ».
C’est la productivité qui en pâtit.
Les entreprises doivent prendre conscience de la situation potentiellement périlleuse engendrée par les attaques qui perturbent aussi bien le trafic sortant que le trafic entrant. S’il existe déjà une mesure d’atténuation relativement simple contre BlackNurse, d’autres attaques sont probablement bien plus difficiles à contrer. Et dans un monde où nous dépendons autant des applications situées à l’intérieur du pare-feu que de celles qui se trouvent à l’extérieur, nous devons examiner de près les possibilités de telles attaques.
Si ce n’est pas encore fait, il est grand temps d’évaluer à quel point votre entreprise dépend — ou dépendra — des applications « dans le cloud », et de déterminer la meilleure façon d’en protéger l’accès face à des menaces spécifiquement conçues pour empêcher votre entreprise de vaquer à ses activités quotidiennes.
À propos de l’auteur
Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.