Principes de prévention contre les attaques par déni de service

Numéro : TR12-001
Date : 22 février 2012

Public cible

Le présent rapport d'information est rédigé à l'intention des professionnels et gestionnaires de la TI des gouvernements fédéral, provinciaux et territoriaux et des administrations municipales, ainsi que des industries à infrastructure critique et autres industries connexes. Les personnes ayant obtenu le présent produit peuvent le divulguer aux intervenants techniques dans leur organisme.

Objectif

Ce rapport d'information renseigne le personnel chargé de la sécurité informatique sur les attaques par déni de service distribué (DSD) et leur modus operandi. Il décrit la procédure recommandée pour faciliter les étapes de préparation, d'identification, de confinement et de reprise des services, ainsi que les efforts d'amélioration que l'organisation doit déployer en tout temps pour limiter les risques de s'exposer à telles attaques. Ce document est destiné aux administrateurs de système, aux équipes d'intervention en cas d'incident informatique (EIII), aux Centres des opérations de sécurité informatique et aux autres groupes technologiques concernés.

Présentation

Dirigées contre les réseaux, les attaques par déni de service sont des actions malveillantes répandues visant à empêcher les utilisateurs légitimes d'avoir accès à des ressources informatiques. Ces actions, en particulier les attaques par déni de service distribué (DSD), se sont récemment multipliées en raison de la disponibilité des services de déni de service loués par des zombimestres (des opérateurs de réseaux d'ordinateurs zombies) et de l'accès à de nombreux outils de piratage gratuits et faciles à utiliser. Ces outils ont permis aux « hacktivistes », des activistes qui font appel au piratage informatique - le hacking - pour défendre leur cause, de lever efficacement une armée de partisans qui appuient et facilitent leurs cyberattaques, leur permettant ainsi d'étendre leur réseau de distribution et d'accroître leur pouvoir. Parmi les attaques par déni de service les plus connues, on retrouve celle du groupe de pirates informatiques Anonymous avec l'application LOIC (Low Orbit Ion Cannon) pour appuyer Wikileaks[Footnote 1] et des attaques DSD contre les infrastructures nationales de la Corée[Footnote 2], de la Géorgie[Footnote 3] et de l'Estonie[Footnote 4].

Déni de service et déni de service distribué - définitions

Une attaque par déni de service est une attaque ayant pour but de rendre indisponible un service, d'empêcher les utilisateurs légitimes d'un service de l'utiliser[Footnote 5]. Une attaque par déni de service distribué (DSD) se produit lorsqu'une multitude de systèmes « inondent » de diverses requêtes simultanées les ressources d'un réseau informatique, rendant ces dernières inaccessibles. Contrairement aux attaques par déni de service, les attaques DSD ne sont pas perpétrées par un seul attaquant, mais bien des centaines, voire des milliers. Il est donc plus difficile de coordonner les mesures d'atténuation pour les contrer, et le trafic qu'elles génèrent endommage encore plus l'infrastructure ciblée.

Les attaques DSD reposent souvent sur l'exploitation de protocoles sans état, tel UDP et ICMP, mais utilisent également des protocoles avec état lorsque les connexions sont rendues instables par une attaque par saturation de type TCP SYN. Les deux techniques facilitent l'usurpation d'adresses IP tout en brouillant les pistes menant à l'origine des attaques.

Cinq étapes pour se protéger des attaques DSD

Préparation

La préparation est l'étape la plus importante de la défense contre les attaques DSD. Il faut établir une série exhaustive de procédures et de lignes directrices claires avant qu'elles ne surviennent. Toute organisation peut être victime d'attaques DSD directes ou indirectes. Elle doit donc instaurer un plan de protection rigoureux pour réduire les risques et atténuer les effets de ces attaques.

Identification

Une attaque DSD se manifeste entre autres choses par le piètre rendement du réseau, des services indisponibles et des pannes de système. La capacité à la reconnaître, à en comprendre la nature et à en identifier les cibles facilite le processus de confinement et la reprise des services. C'est pourquoi chaque organisation a besoin d'outils qui lui permettent de voir l'ensemble de son infrastructure de technologie de l'information gérée. L'attaquant effectue souvent une reconnaissance du réseau ciblé avant de lancer une attaque DSD contre lui. Il cherchera ainsi à y déceler des vulnérabilités connues ou à y envoyer des paquets mal formés pour analyser les changements du temps de réaction. Une telle activité de reconnaissance s'avère parfois difficile à détecter, surtout parce qu'elle précède longtemps à l'avance l'attaque proprement dite. Un attaquant chevronné s'assurera également de limiter le trafic servant à l'analyse ne dépasse pas le seuil de déclenchement des alarmes par des outils de surveillance du réseau. Cependant, l'organisation peut avoir accès à de l'information qui l'informe d'une recrudescence des risques d'attaques DSD dirigées conte elle. Un exemple bien connu : les opérations du collectif Anonymous (ou anonops)Footnote 6 qui fait largement étalage de ses intentions et de ses cibles.

Confinement

Un plan de confinement comportant divers scénarios et établi au préalable réduit considérablement le temps de réaction à une attaque DSD et l'étendue des dommages. Ainsi, on n'appliquera pas la même stratégie de confinement au serveur de courriel et au serveur Web. Négliger cette étape de la défense se traduit par des erreurs et d'importants dommages collatéraux. Il est donc crucial de bien comprendre la nature des attaques DSD et de documenter les processus décisionnels afférents. L'organisation doit identifier clairement le périmètre de son réseau et dresser la liste exhaustive des ressources exposées. Une organisation tirera profit de divers outils lui permettant de confiner une attaque DSD en cours, comme des équilibreurs de charge, des dispositifs pare-feu modernes (inspection approfondie des paquets, les serveurs mandataires, filtrage d'application), la mise en antémémoire du contenu, la diversité géographique des sites d'hébergement du contenu, le service DNS dynamique et les services de protection contre les attaques DSD fournis par les fournisseur d'accès Internet (FAI).

Reprise des services

La pression exercée sur l'organisation pour qu'elle assure la reprise de ses services à la suite d'une attaque DSD varie en fonction de sa stratégie de confinement et de sa fragilité aux dommages collatéraux. Elle doit donc savoir reconnaître les caractéristiques d'une telle attaque pour assurer une reprise adéquate de ses services. L'attaque DSD tire profit des limites des ressources suivantes :

Les attaques DSD exploitent l'une ou l'autre de ces limites, ou plusieurs d'entre elles à la fois. Si l'organisation a appliqué un modèle souple de service à la demande à ces ressources, elle pourra s'adapter rapidement et résister à des attaques SDS soutenues. En revanche, certaines attaques profiteront des vulnérabilités des protocoles ou des logiciels pour causer d'importants dommages impossibles à prévoir. Footnote 7 L'organisation qui s'est dotée d'un mécanisme de capture des paquets sera en mesure de comprendre le mode de prestation de l'attaque et de concevoir une solution efficace combinant système de prévention des intrusions et dispositif pare-feu. Certaines attaques DSD se poursuivront malgré les mesures d'atténuation en place. Pour assurer la coordination des mesures d'atténuation et permettre d'enquêter sur les sources criminelles, l'organisation utilisera ses journaux de session et d'autres outils pour signaler à son FAI en amont, aux services de police et à l'Équipe nationale d'intervention d'urgence en informatique (EIUI) les adresses IP suspectes - si elle n'ont pas été usurpées - qui pourraient avoir servi à perpétrer de telles attaques.

Leçons retenues

Cette étape essentielle de la défense est trop souvent omise. Il faut faire le point le plus rapidement possible à la suite d'un incident et examiner chacune de décisions et des mesures prises tout au long de la gestion de la crise. Cet exercice permet de cerner ce qui doit être amélioré dans les procédures appliquées.

L'examen des leçons retenues comporte un volet particulièrement difficile à réaliser : la documentation des répercussions de l'incident sur l'organisation et les coûts qu'il représente. Bien qu'elle prenne beaucoup de temps, cette étape est essentielle puisqu'elle permet à l'organisation de justifier adéquatement l'acquisition de ressources de sécurité et de bien évaluer le rendement du capital investi. Les dommages subis par l'organisation se mesurent quantitativement d'une part, par exemple le volume de ventes perdues et la baisse de la productivité, et d'autre part qualitativement, quand la réputation et l'image de marque sont entachées.

L'examen systématique des leçons retenues permet à l'organisation de s'améliorer sans cesse et de réduire considérablement les répercussions négatives des incidents.

Liste de contrôle

La liste de contrôle ci-dessous facilite la prise de mesures d'atténuation durant les diverses phases d'une attaque DSD. Bon nombre de ces mesures s'appliquent également aux autres types d'attaques cybernétiques et doivent être envisagées en conséquence.

Liste de contrôle pour les phases d'atténuation d'attaques DSD
Contrôle En cours Terminé
Préparation
1. Identifier les ressources matérielles les plus cruciales et les services dont elles assurent la prestation.
  • Les derniers correctifs ont-ils été installés?
  • Exécutent-elles des services inutiles comme Telnet, FTP, etc.?
   
2. De concert avec le fournisseur d'accès Internet (FAI), établir des procédures pour connaître l'étendue du soutien qu'il peut apporter à l'organisation lorsqu'elle fait l'objet d'une attaque DSD. Savoir s'il existe un accord sur les niveaux de services (ANS) et connaître les coûts à assumer.    
3. Dresser la liste des personnes-ressources du FAI que l'on peut joindre en tout temps, ainsi que des autres moyens de communiquer avec elles.    
4. Bloquer tout trafic qui présente des signes évidents d'usurpation d'identité (p. ex., les adresses IP à l'intérieur du réseau de l'organisation qui ne devraient pas être associées à du trafic entrant ou sortant). Instaurer une liste de filtrage Bogon (plage d'adresses non allouées) au périmètre du réseau.    
5. Établir des procédures sur la façon de cloisonner les réseaux de l'organisation en cas d'attaque DSD. Se servir des appareils existants, comme les routeurs et les commutateurs gérés, pour s'en protéger. Dans la mesure du possible, configurer les routeurs du périmètre pour filtrer les services afin de réduire la charge imposée aux dispositifs de sécurité, tels les pare-feu, qui analysent le trafic.    
6. Désactiver tout service inutile et bloquer tout accès non autorisé vers et depuis les hôtes critiques identifiés précédemment.    
7. Créer une liste blanche des adresses IP source s'il est nécessaire d'établir un trafic prioritaire durant une attaque.    
8. Documenter la topologie de réseau, y compris toutes les adresses IP. Tenir cette information à jour.    
9. Passer en revue plan de continuité des opérations (PCO) de l'organisation et s'assurer que la haute direction et le service du contentieux comprennent bien ce qu'est une attaque DSD et les rôles et responsabilités qui leur sont dévolus.    
10. Comprendre ce que constituent des conditions normales. Établir le niveau de référence du trafic sur le réseau, de la charge de travail imposée aux processeurs, de l'utilisation des connexions et de la mémoire des hôtes essentiels en situation normale afin que les outils de surveillance du réseau entrent en œuvre lorsqu'une variation anormale se produit.    
11. Reconnaître que l'organisation peut être attaquée. Solliciter la direction afin d'obtenir son approbation en vue d'élaborer et de mettre en œuvre des politiques, plans et procédures pour se défendre contre les attaques DSD. Identifier et obtenir les ressources nécessaires pour mettre en œuvre ces politiques, plans et procédures.    
12. Attribuer les rôles et responsabilités. Connaître les intervenants dans la défense contre les attaques DSD et s'assurer qu'ils sont au fait de cette responsabilité. Ces personnes devraient appartenir au personnel affecté aux fonctions opérationnelles essentielles, aux opérations de TI, à la sécurité des réseaux et des TI, au service du contentieux et aux relations publiques. Tenir à jour la liste des points de contacts primaires et secondaires. Le réseau étant susceptible d'être en panne, y compris les appareils mobiles, mettre également en place d'autres mécanismes de communication.    
13. Effectuer des exercices. Ce n'est plus le temps de faire l'essai des plans et des procédures lorsqu'une attaque se produit.    
Identification
1. Savoir si l'organisation est une victime ciblée ou accidentelle. (P. ex., la cible est-elle le fournisseur d'accès Internet (FAI) en amont ou le fournisseur de services d'hébergement de contenu?)    
2. Comprendre le déroulement logique de l'attaque.    
3. Déterminer le trafic dont se sert l'attaquant en identifiant les adresses IP, les ports et les protocoles qu'il exploite.    
4. Envisager de recourir à des outils d'analyse du réseau pour déterminer le type de trafic qu'exploite l'attaquant (p. ex., TcpDump, Wireshark, Snort).    
5. Consulter les journaux de serveur pour comprendre le fonctionnement de l'attaque et les cibles visées.    
6. Aviser le personnel concerné, notamment celui de la haute direction et du service du contentieux.    
Confinement
1. Communiquer avec le FAI pour mettre en place un mécanisme de filtrage du trafic.    
2. Bloquer le trafic le plus près possible du réseau en nuage (p. ex., avec un routeur, un pare-feu, un équilibreur de charges).    
3. Changer l'adresse IP de l'hôte ciblé par l'attaque. Il s'agit là d'une solution provisoire.    
4. Si l'attaque vise une application en particulier, envisager sa désactivation temporaire.    
5. Identifier et corriger la vulnérabilité ou la faiblesse du système qui est exploitée. Il peut s'agir par exemple d'un service inutilisé maintenu involontairement en activité sur un dispositif destiné au public ou d'un système d'exploitation dont les correctifs n'ont pas été installés.    
6. Mettre en place un mécanisme de filtrage en fonction des caractéristiques de l'attaque, par exemple le blocage des paquets IMCP Echo.    
7. Limiter le trafic de certains protocoles à un nombre quelconque de paquets par seconde ou en n'autorisant l'accès des paquets qu'à certains hôtes.    
Reprise des services
1. Confirmer que l'attaque DSD a pris fin et que les services sont de nouveau disponibles.    
2. Confirmer que le niveau de performance de référence des réseaux est rétabli.    
3. Au besoin, installer les correctifs et les mises à jour sur les machines touchées.    
4. Dans la mesure du possible, identifier l'origine de l'attaque. Solliciter l'aide du FAI.    
5. Passer en revue les registres de journalisation pour y repérer la trace des tentatives de reconnaissance. Conserver ces registres en vue d'éventuelles poursuites judiciaires.    
Leçons retenues
1. Rédiger ou mettre à jour les documents suivants :
  • Procédures d'opération normalisées
  • Procédures d'opération d'urgence
  • Plans de continuité des opérations
   

Recommandations

Le CCRIC recommande aux organisations d'évaluer les risques qu'elles soient exposées à des attaques par déni de service, qu'elles soient provoquées accidentellement ou volontairement. Elles sont invitées à prendre en considération les mesures d'atténuation conseillées dans le présent document et de les mettre en œuvre en fonction de leur propre environnement de GI-TI.

Références

  1. US-CERT, Understanding Denial-of-Service Attacks (Comprendre les attaques par déni de service)
    http://www.us-cert.gov/cas/tips/ST04-015.html (en anglais)
  2. NIST, Computer Security Incident Handling Guide (Guide de gestion des incidents touchant la sécurité informatique)
    http://csrc.nist.gov/publications/nistpubs/800-61-rev1/SP800-61rev1.pdf (en anglais)
  3. GovCERT.NL, Factsheet: Protect your online services against dDoS attacks (Protégez vos services en ligne contre les attaques DSD)
    http://www.govcert.nl/english/service-provision/knowledge-and-publications/factsheets/protect-your-online-services-against-ddos-attacks.html (en anglais)
  4. CERT Société Générale - Déni de service distribué
    http://cert.societegenerale.com/resources/files/IRM-4-DDoS.pdf (en anglais)

Signalement

Les opérateurs d'infrastructure critique canadiens peuvent signaler des incidents en utilisant la clé de chiffrement PGP de l'agent de cybersécurité de service du CCRIC (disponible à l'adresse http://www.securitepublique.gc.ca/cnt/ntnl-scrt/cbr-scrt/rprt-eng.aspx) et transmettre les rapports connexes par courriel à l'adresse cyber-incident@ps-sp.gc.ca.

Note cruciale

Certains des renseignements du présent message ne sont fournis qu'aux fins de reconfiguration défensive des biens du destinataire. Le CCRIC tient à avertir le destinataire de n'effectuer aucune activité de collecte de données hors du périmètre de son réseau selon les renseignements du présent bulletin cybernétique, notamment l'exploration, le téléchargement, le balayage, ou même une recherche Web selon tout texte du présent rapport.

AVIS : Le présent message et toutes les pièces jointes qui l'accompagnent contiennent de l'information destinée uniquement à la personne ou à l'entité à laquelle elle est adressée. Toute diffusion, distribution ou copie de son contenu par une autre personne que son destinataire est strictement interdite. Si vous avez reçu ce message par erreur, veuillez informer immédiatement l'expéditeur à l'adresse ci-dessus puis l'effacer.

Le présent message et toutes les pièces jointes qui l'accompagnent contiennent des renseignements qui peuvent avoir été recueillis de diverses sources externes dont le CCRIC ne peut vérifier ni la fiabilité ni l'intégrité. Le CCRIC n'assume aucune responsabilité pour des conséquences négatives résultant de l'utilisation des renseignements fournis dans la présente.

Les liens vers d'autres sites Web ne relevant pas du gouvernement du Canada sont fournis aux utilisateurs uniquement pour des raisons de commodité. Le gouvernement du Canada n'assume donc pas la responsabilité de l'exactitude, du caractère actuel ni de la fiabilité de leur contenu. Il n'offre aucune garantie à cet égard et n'est pas responsable des renseignements associés à ces liens, pas plus qu'il ne cautionne ces sites et leur contenu.

Note aux lecteurs

En appui à la mission de Sécurité publique Canada de bâtir un Canada sécuritaire et résilient, le mandat du CCRIC est d'aider à assurer la sécurité et la résilience des cybersystèmes essentiels non gouvernementaux à la base de la sécurité nationale, de la sécurité publique et de la prospérité économique du pays. À titre d'équipe d'intervention en cas d'incident lié à la sécurité informatique du Canada, le CCRIC agit comme centre national de coordination pour la prévention, l'atténuation, l'intervention et le rétablissement liés aux incidents cybernétiques commis contre des systèmes non fédéraux. Pour ce faire, il formule des conseils éclairés, offre du soutien et coordonne l'échange de renseignements ainsi que l'intervention.

S'il vous plaît noter que la clé PGP du CCRIC a récemment été mise à jour.
http://www.securitepublique.gc.ca/cnt/ntnl-scrt/cbr-scrt/_fl/CCIRCPublicPGPKey.txt

Pour obtenir des renseignements de nature générale, veuillez communiquer avec la division des Affaires publiques de l'organisme :

Téléphone : 613-944-4875 ou 1-800-830-3118  
Télécopieur : 613-998-9589 
Courriel : ps.communications-communications.sp@canada.ca

Footnotes

  1. 1

    Présentation de l'application LOIC : http://fr.wikipedia.org/wiki/LOIC

  2. 2

    http://blogs.mcafee.com/mcafee-labs/malware-in-recent-korean-ddos-attacks-destroys-systems (en anglais)

  3. 3

    http://asert.arbornetworks.com/2008/08/georgia-ddos-attacks-a-quick-summary-of-observations/ (en anglais)

  4. 4

    http://en.wikipedia.org/wiki/2007_cyberattacks_on_Estonia] (en anglais)

  5. 5

    Définition : http://fr.wikipedia.org/wiki/Attaque_par_d%C3%A9ni_de_service

  6. 6

    http://anonops.blogspot.com/2011/09/tar-sands-action-september-3-press_04.html

  7. 7

    http://www.theregister.co.uk/2011/08/24/devastating_apache_vuln/

Date de modification :