RÉSUMÉ Au sein de DeiC, le réseau de recherche au Danemark, nous avons développé un service de protection contre les attaques DDoS qui est basé sur la distribution des règles firewall vers les routeurs de bordure par le biais de BGP FlowSpec. Par rapport aux solutions alternatives, cette méthode a un coût très réduit puisqu'elle est basée sur des composants open source uniquement. Dans cette phase du projet la détection des attaques est faite au moyen de FastNetMon, mais grâce aux interfaces ouvertes, d'autres outils IDS peuvent être utilisés. Nous présenterons un retour d'expérience pour ce service qui est actuellement en cours de déploiement au sein de DeIC.

1. P10 January, 2018 1
> FlowSpec
contre les attaques DDoS
> L'expérience danoise
15 novembre 2017
Head of NREN Martin Bech
martin.bech@deic.dk

2. P10 January, 2018 2
> Vous êtes dans la bonne salle…
… si vous voulez écouter quelque chose sur
> Les attaques DDoS (brièvement)
> Les procédures d’un NREN en cas d’attaques DDoS, aujourd’hui
> Ce qui nous a incité à créer un nouveau système de protection contre les attaques DDoS
> Les idées sous-jacentes et le cahier des charges de notre système
> Sa mise en œuvre
> Les limitations
> Nos perspectives

3. P10 January, 2018 3
> La création des attaques DDoS
> DDoS = Distributed Denial of Service attacks
= Attaque distribué de type déni de service avec le but de mettre la cible hors service
> Un client
> Quelqu’un qui achète un attaque DDoS anonymement sur l’Internet. Les prix varient entre quelque euros
et des milliers d’euros.
> Un vendeur
> Quelqu’un qui possède d’un botnet (une armée de serveurs sur Internet sous son contrôle) qu’il a acheté
ou créé au biais de virus/malware etc.
> Des opérateurs de réseaux
> Qui permettent que leurs utilisateurs participent aux botnet/attaques DDoS

4. P10 January, 2018 4
> Les attaques DDoS
> On distingue normalement deux types:
> 1. Les attaques volumétriques
> « Remplir les tuyaux »..
> De plus en plus populaires ces 2-3 dernières années en raison des attaques d’amplification
> Il est possible d’amplifier les attaques par un facteur +200
> Les attaques utilisent en général des protocoles sans état (ex : UDP) en usurpant les adresses source
(spoofing)
> 2. Les attaques chirurgicales ou ciblant des applications
> Elles ciblent un infrastructure spécifique
> Elles exigent une préparation et davantage de compétences
> Typiquement contre des applications, où l’on peut épuiser la capacité E/S

5. P10 January, 2018 5
> Les attaques DDoS – un problème en croissance
En particulier pour les raisons suivantes:
> IPv6: Internet grandit et il y a un nombre de plus en
plus important d’objets connectés ;
> l’Internet des objets (IoT) où le niveau de sécurité
est souvent très faible – et il est aisé de prendre
contrôle des objets ;
> les connexions privées à Internet sont de plus en
plus rapide – alors même que les foyers comptent
un nombre de plus en plus important d’objets
connectés ;
> Et bien sûr les Bitcoins : les délinquants
informatiques ont désormais leur argent liquide et
peuvent exiger des paiements pour leurs services. Source: Arbor Networks special report, vol. XII

6. P10 January, 2018 6
> Qui peut agir contre les attaques DDoS
> FAI
> Remédier aux grandes attaques
volumétriques contre les clients
> Donner la possibilité aux clients de
créer des filtres contre les attaques
> Filtrage BCP38
> Gestion des abus
> Client
> Remédier aux attaques chirurgicales ou
ciblant des applications contre ses
équipements
> S’assurer que tous les services exposés
à Internet sont préparés
> Avoir des systèmes pare-feu, IDS/IPS
pour la protection et la détection des
attaques contre les services
> Système d’anti-usurpation des adresses
IP (uRPF par exemple)
> Mitigation des attaques DDoS sortantes
> Aider le FAI en communiquant lors des
attaques

7. P10 January, 2018 7
> DeiC (Danish e-Infrastructure Cooperation)
> Le réseau de recherche national au Danemark
> Notre taille est peut-être comparable aux réseaux
régionaux connectés à RENATER
> Notre propre infrastructure sur des fibres noires
(3800km) louées sous conditions IRU sur 20 ans
> Nos propres équipements DWDM (liens 10G et
100G)
> Connecté à NORDUnet et à l’Internet au DIX
> Environ 100 institutions desservies
> Environ 100 000 adresses IP déléguées aux
institutions
> NOC (Centre de contrôle) à Lyngby, au nord de
Copenhague

8. P10 January, 2018 8
> Normalement, tous les incidents sur le réseau
sont réglés par le NOC
> Pourquoi n’est-ce pas le cas pour les attaques DDoS?
> Peut-on traiter ce problème par surveillance du volume
du trafic?
> …et installer des filtres dans nos routeurs de bordure –
manuellement?
> Cela ne peut jamais fonctionner car nos n’avons pas
suffisamment d’informations au niveau du NOC
> Notre service classique, c’est l’installation –
manuellement – de filtres dans les routeurs de bordure
(RTBH) après un e-mail au NOC.
> Souvent, l’attaque a disparu quand les filtres sont
finalement installés ;-)

9. P10 January, 2018 10
> Un attaque réelle du point de vue de l’utilisateur
Basé sur des données netflow

10. P10 January, 2018 11
> Le même attaque vue du NOC
Attaque DDoS ici

11. P10 January, 2018 12
> Tous les FAI offrent une protection contre les
attaques DDoS
19-05-

12. P10 January, 2018 13
> …basée sur le « scrubbing » de services
spécifiques

13. P10 January, 2018 14

14. P10 January, 2018 15
> Un service de protetion contre les attaques DDoS
> Il faut des outils/équipements speciaux pour répondre a ce
problème
> Nous avons besoin de communication avec nos utilisateurs en
temps réel
> Nos utilisateurs attendent de nous un tel service – car ils ne
peuvent pas le produire eux-même
> Tous les FAI commerciaux ont un service de protection DDoS
> Notre réseau de recherche apparaît archaïque sans un tel
service
C’est pourquoi nous avons lancé un projet pour créer un service de
protection contre les attaques DDoS – nommé DDPS.

15. P10 January, 2018 16
> Nos voeux pour le service
> Logiciels libres + open source
> Les solutions faites en commun avec autant de participants que possible
> Couvrant des blocs entiers d’adresses IP
> Pouvant traiter toute notre volume de trafic
> Sans policy-routing
> Sans changer le DNS pour les services protégés
> Sans ”scrubbing” (sans grosses machines à laver le trafic)
> Ouvert vers plusieurs systèmes de détection d’attaques
> Possibilité de ne pas participer pour les clients qui ne sont pas intéressés
> Détection automatique des attaques
> Remédiation automatique des attaques détectées
> Possibilité pour les institutions de modifier/créer manuellement des règles
> Possibilité pour le NOC de modifier/créer manuellement des règles
> Possibilité de voir un aperçu des règles actives a tout moment ainsi qu’un historique
> Coût réduit

16. P10 January, 2018 17
> Les deux composants très importants
> FastNetMon Community Edition, de Pavel Odintsov
> Dæmon pour l’analyse des attaques DoS/DDoS focalisé sur la vitesse
> Script de notification en cas de détection d’une attaque
> 10 Gbps, 14 Mpps sur port miroir (Intel NIC 82599) avec netmap
> BGP FlowSpec - RFC 5575
> Une extension du protocole BGP permettant de distribuer des règles
pare-feu entre routeurs
> Pour simplifier : règles de filtrage dynamiques via BGP
> Possibilité de propager ces règles en amont via BGP
> Les règles peuvent être plus détaillées qu’avec black hole routing
> Problème initial : notre équipement (au début du projet) n’était pas
compatible avec RFC 5575

17. P10 January, 2018 18
> Il nous restait à développer…
> Possibilité pour les institutions de modifier/créer manuellement des règles
> Possibilité pour le NOC de modifier/créer manuellement des règles
> Possibilité de voir le statut du système ainsi qu’un historique
> Une base de données centrale, des statistiques et une interface utilisateur Web
étaient également nécessaires

18. P10 January, 2018 19
Internet sauvage
FastNetMon
Routeur NORDUnet
Routeur DeiC
La malheureuse victime
Le routeur de la malheureuse victimeNetFlow
Base de données
avec les règles
FlowSpec
FlowSpec
FlowSpec
Gestion
manuelle
des règles Création automatique
des règles

19. P10 January, 2018 20
> L’architecture
> Auprès de l’institution :
> Une instance de FastNetMon avec 2 cartes réseaux.
> Une carte 10 Gbps vers un port miroir dans l’équipement du client (mode moniteur)
> Une carte 1 Gbps pour une communication hors bande avec la base de données centrale à
DeIC
> À DeiC :
> Une base de données centrale
> Une interface utilisateur Web avec un accès à la base de données
> Une méthode pour exporter les règles de la base de données en règles BGP FlowSpec
> Une méthode pour propager les règles BGP FlowSpec à nos routeurs de cœur de réseau

20. P10 January, 2018 21
> L’architechture…

21. P10 January, 2018 22
> Au niveau de l’institution

22. P10 January, 2018 23
> Au niveau du NREN

23. P10 January, 2018 24
> L’architecture

24. P10 January, 2018 25
> Une architecture
extensible

25. P10 January, 2018 26
> Interface utilisateur : Login
> Login/password simple
> Nous travaillons au moment
à implémenter aussi l’accès
par notre fédération
d’identité

26. P10 January, 2018 27
> Dashboard

27. P10 January, 2018 28

28. P10 January, 2018 29
> Règles

29. P10 January, 2018 30
> Créer une règle
> Création d’une règle
manuellement
> Normalement, les règles
sont créés
automatiquement
> Au moment, nous n’avons
pas implémenté tous les
protocoles IP – seulement
TCP, UDP et ICMP
> Supprimer une règle

30. P10 January, 2018 31
> Notifications

31. P10 January, 2018 32
> Gestion des
utilisateurs

32. P10 January, 2018 33
> Désactivation d’un utilisateur

33. P10 January, 2018 34
> Utilisateur inactif

34. P10 January, 2018 35
> Modifier un client

35. P10 January, 2018 36
> Ajouter/supprimer des
réseaux clients

36. P10 January, 2018 37
> Nos principes de conception
> Attention portée à la sécurité
> L’instance de FastNetMon au niveau de l’institution n’a aucun service accessible par Internet
> La communication entre FastNetMon et DeiC a lieu via OpenVPN
> Les seuls services accessibles par Internet le sont par OpenVPN et protégé par pare-feu redondant OpenBSD
> Principe de précaution
> Les inputs sont validés plusieurs fois au cours du processus
> Le système est conçu pour être aussi fail-safe que possible
> Le système peut fonctionner sans la détection et la remédiation automatiques – c’est-à-dire sans FastNetMon
> Modularité
> Il est possible de changer le système de détection ou de le renforcer par d’autres technologies
> Il est possible d’utiliser d’autres méthodes que BGP FlowSpec pour la remédiation
> Open Source
> Nous utilisons et nous produisons des logiciels Open Source
> Tout est accessible sur GitHub

37. P10 January, 2018 38
> Limitations
> Uniquement pour les attaques DDoS entrantes
> Le filtrage des attaques DDoS sortantes est à la charge du client
> FastNetMon ne peut pas détecter les attaques ciblant la couche applicative
> Les valeurs des seuils pour la détection des attaques dans FastNetMon sont fixes
> Valeurs pour pps, mbps et flows.
> IPv6 n’est pas pris en charge par FastNetMon à l’heure actuelle
> L’accès à l’interface utilisateur Web par le client lorsqu’il est attaqué doit peut-être avoir lieu
via le réseau 3G
> Très grandes attaques DDoS supérieures à 100 Gbps

38. P10 January, 2018 39
> L’avenir
> DeiC espère collaborer avec GÉANT et d’autres NRENs pour continuer à élaborer ce système
> Collaboration avec NORDUnet
> But : envoyer les règles BGP FlowSpec en amont de DeiC
> Blackholing sélectif – avec la distance comme vecteur
> Blackholing sélectif – avec le facteur de risque comme vecteur
> DKCERT travaille sur un projet d’analyse des données Netflow qui pourrait être utilisé
> Nos données sont accessibles aux chercheurs qui s’intéressent aux attaques DDoS et à leur
remédiation

39. P10 January, 2018 40
> Remerciements
> DDPS
> Anders Mundt Due
> Ashokaditya Mohanty
> Kasper Sort
> Nicolai Brunvoll Ernst
> Niels Thomas Haugård
> Tangui Coulouarn
> Open Source
> Pavel Odintsov - FastNetMon
> Longue liste de projets Open Source : Linux, OpenBSD, PostgreSQL, InfluxDB, Node.js,
OpenVPN, OpenSSH, ExaBGP og mange flere

40. P10 January, 2018 41
> Nous cherchons des partenaires…
> Au niveau régional/national/international :
> Participation au développement du service et du logiciel
> Un effort pour étendre les bordures au plus loin possible
> Institutions utilisatrices :
> Expériences avec le service
> Intégration avec nouveaux équipements de détection (les
IDS etc.)
Merci & questions:
> Tangui Coulouarn
<tangui.coulouarn@deic.dk>
> Martin Bech
<martin.bech@deic.dk>