Les Bonnes pratiques anti DDoS

Transcript

Rebonjour, nous revoilà pour cette deuxième session du jour, après cette intense deep dive VPC. Nous allons maintenant parler des bonnes pratiques pour lutter contre les DDoS. Sujet qui devrait susciter pas mal de questions. Un bref rappel peut-être sur ce sujet, ce qu'est le DDoS. DDoS signifie déni de services distribués et très simplement, c'est une attaque concertée effectuée à partir d'un très grand nombre d'adresses IP, un très grand nombre de sources à destination d'une seule cible, d'un seul site. L'idée étant évidemment de multiplier au maximum les sources d'attaque, de les disperser géographiquement pour rendre le filtrage et l'identification des auteurs compliqués, et de saturer au maximum la malheureuse cible. Si vous suivez les informations comme moi, vous voyez ces articles qui sont tous récents, c'est octobre, septembre, novembre, j'ai vraiment pris les trois qui me sont tombés sous la main. On n'entend parler que de ça depuis quelques semaines, en particulier de réseaux d'objets connectés, des fameux botnets de caméras, etc., qui attaquent par dizaines ou centaines de milliers les cibles, qui arrivent à monter des attaques à des niveaux jamais vus jusqu'ici, 500, 600 gigabits, des attaques hyper massives et surtout malheureusement de plus en plus faciles à mettre en œuvre. Il ne s'agit pas forcément d'équipes organisées, il s'agit parfois d'ados, de jeunes, désœuvrés sûrement, qui s'amusent à faire ça et qui arrivent à monter des attaques extrêmement puissantes, qui sont extrêmement problématiques à contrer. Petite statistique, au-delà de la presse et des articles qu'on lit tous les jours, Imperva, qui est une société de sécurité, sort un rapport périodique sur ces sujets et nous dit que pratiquement la moitié des entreprises et des organisations ont été victimes d'une attaque DDoS. Le coût moyen d'une attaque horaire est élevé, 40 000 dollars, et dans certains cas, vous imaginez s'il s'agit de sites e-commerce ou de sites financiers, les pertes peuvent être infiniment plus élevées. Et de manière étonnante, en tout cas moi ce chiffre-là m'a surpris, la majorité des attaques sont des attaques très courtes. On parle souvent d'attaques qui durent des jours, voire une semaine, etc. Effectivement, elles se produisent aussi, mais la majorité des attaques sont des attaques courtes, de quelques minutes ou de quelques dizaines de minutes. Ce qui signifie que le délai de réaction va être forcément extrêmement court et qu'il faut mettre en place des solutions qui permettent d'être déployables et activables instantanément ou en tout cas le plus rapidement possible. Et bien sûr, nos clients et vous tous, j'ai souvent ces questions sur comment AWS me protège contre le DDoS, comment est-ce que je sais si je suis assisté, vous attaquer ou pas ? Quels types d'attaques vous nous protégez ? Et jusqu'où vous pouvez nous protéger ? Il y a toutes ces questions qui reviennent. Jusqu'à récemment, on avait malheureusement peu de choses à vous communiquer, ce qui ne veut pas dire qu'on ne faisait rien, loin de là, on va en parler tout à l'heure, mais on n'avait pas pour politique de communiquer sur le sujet. Vous allez voir que ça a un peu changé. On va parler rapidement des différents types d'attaques DDoS. On va faire un petit rappel. J'espère que ça ne vous donnera pas d'idée maléfique. On va parler des difficultés à gérer ces attaques. Qu'est-ce qui est compliqué ? Pourquoi c'est difficile de contrer du DDoS ? Ensuite, on abordera quelques bonnes pratiques de résilience et vous verrez, ce sont des pratiques qui sont utiles pour lutter contre les DDoS mais utiles en général pour la haute disponibilité, double raison de s'y intéresser. On parlera ensuite des services AWS qui peuvent vous aider à bâtir des plateformes résistantes aux DDoS, y compris AWS Shield qui a été récemment annoncé, et puis comme d'habitude on répondra à vos questions, n'hésitez pas à les envoyer à Hugo au fur et à mesure. Il est là pour vous écouter et moi pour y répondre du mieux que je peux. Alors commençons par les attaques. On ne va pas faire un cours de réseau, surtout pas après le deep dive de tout à l'heure. Vous reconnaissez le modèle en 7 couches du réseau. Et on va trouver les attaques essentiellement à 3 niveaux. On va trouver des attaques sur la couche réseau, donc couche 3, qui vont être surtout des attaques dites volumétriques. Et comme leur nom l'indique, ce sont des attaques qui ont pour but de saturer les réseaux, de les encombrer avec des quantités absurdes de trafic et tout simplement de saturer la capacité des liens et donc de rendre le transit de la cible inopérant, et donc de la couper d'internet. Un exemple qui est fréquemment utilisé ces temps-ci, ce qu'on appelle les attaques par réflexion, les attaques par amplification. Il y a une attaque DNS particulièrement efficace qui se base sur des serveurs DNS ouverts. Ces serveurs de DNS soit disparaissent progressivement, soit sont sécurisés. Il en reste toujours. Cette attaque permet à un pirate, en envoyant un paquet malicieux, un unique paquet à ces serveurs, de générer, avec un effet de levier important, une grande quantité de données destinées à la cible. En envoyant un paquet de 64 octets, on arrive à générer plusieurs requêtes pour un total de plus de 3 cas. Donc ça fait un facteur, pratiquement 50 si je sais compter. D'où le nom d'attaque par amplification. Vous multipliez ça par des milliers de requêtes entrantes, des dizaines ou des centaines de serveurs DNS, etc. Et on arrive à des trafics qui sont capables de faire tomber des gros liens de transit de la cible. C'est bête et méchant mais hyper efficace. Et non, je ne ferai pas de démo. Deuxième couche où les attaques peuvent se produire, la couche transport, la couche 4. Cette fois, on ne va pas chercher à saturer le lien à proprement parler, on va chercher à épuiser les ressources. On va s'appuyer sur les protocoles, c'est la couche 4, c'est la couche qui va gérer la fiabilité, qui va gérer l'état, c'est une couche de connexion, qui va gérer l'état des connexions. On va chercher à exploiter les protocoles et à les utiliser contre eux-mêmes en fait, en créant des connexions TCP, en essayant de saturer des firewalls, en essayant de saturer des load balancers, enfin, en essayant de saturer l'état des protocoles. Un exemple étant le classique et efficace Synflood TCP qui nécessite extrêmement peu de trafic mais qui sur une cible pas configurée, en tout cas pas préparée à ce genre d'attaque, reste une attaque malheureusement efficace. Et puis il y a les attaques en couche 7 qui sont des attaques contre l'application et qui là aussi vont chercher soit à saturer, soit à épuiser finalement l'applicatif. Voilà deux exemples, donc là on va attaquer une application web, ce qui est quand même le cas le plus fréquent. On peut faire un flood de HTTP GET. Ça paraît rustique et tout le monde pense que tout le monde est prémuni contre ce genre d'attaque, vous seriez surpris. Il y a encore beaucoup d'infrastructures qui ne sont pas configurées pour lutter contre cette attaque, qui n'est pas forcément difficile à contrer mais encore faut-il avoir fait la bonne configuration sur ces équipements. Donc un bon vieux flood, il y a des outils tout faits pour le faire que je ne citerai pas, vous les trouverez tout seul, qui sont capables de faire tomber encore bien des sites web. Et puis il y en a une que j'apprécie à titre intellectuel qui est Slowloris, qui est une attaque qui date maintenant, mais qui est cette fois une attaque non pas de saturation massive, mais au contraire une attaque de saturation par la lenteur, où on va ouvrir des connexions sur un serveur web, qu'on va volontairement ouvrir et traiter de manière hyper lente. Ce qui fait qu'en faisant ça en parallèle, on va créer un grand nombre de connexions qui ne se terminent jamais. Et donc si le load balancer ou si le serveur web sont une fois de plus mal configurés ou en tout cas pas configurés pour cette attaque, on va avec très très peu de ressources et de manière très progressive et très pernicieuse, saturer un serveur web qui en lui envoyant ses requêtes lentes qui ne se terminent jamais. Voilà, enfin ça c'est deux parmi plein, mais ces deux-là sont des exemples qu'on rencontre encore beaucoup. De manière plus globale, la majorité, la grosse majorité des attaques restent des attaques volumétriques et de fait les attaques qui ont fait la une des journaux depuis quelques semaines et quelques mois étaient plutôt des attaques volumétriques par amplification DNS en particulier. Et le dernier tiers se répartissait à peu près à part égale entre de la couche 7 et de la couche 4. Qu'est-ce qui est difficile là-dedans ? Pourquoi c'est compliqué pour une entreprise de lutter efficacement contre des attaques DDoS ? Il y a deux types de difficultés. Il y a la difficulté à mettre en place la protection initiale, puis il y a la difficulté à activer la protection au moment où on en a besoin. La première chose c'est effectivement comment est-ce qu'on met en place la protection. La protection généralement elle n'est pas liée à un seul équipement. Il va falloir protéger une chaîne d'équipement, il va falloir protéger le router edge, il va falloir protéger les load balancer qui sont derrière les routers, il va falloir protéger... et ça, ça va nous protéger au niveau peut-être 4, ou alors on va devoir faire du filtrage d'URL et d'emblée sur ces équipements en couche 7, mais bon, ce n'est pas toujours évident. Et puis ensuite, il va falloir configurer les serveurs web et les proxys, etc. Enfin, vous connaissez vos infrastructures web, vous savez à quoi elles ressemblent. Il n'y a pas un unique endroit finalement où vous pouvez activer une protection et vous garantir que vous êtes tranquille sur toutes les typologies d'attaques. Donc, il y a pas mal de boulot et comme d'habitude c'est facile d'oublier une étape et de se faire piéger. Ensuite sur les attaques volumétriques, le point principal est toujours de dire quelle est la capacité de ma vente passante en 30 et qu'est-ce qui se passe si je reçois 2 fois, 3 fois, 5 fois le trafic. Là c'est en amont de votre infrastructure, est-ce que tout le monde est prêt à payer 10 fois plus de bandes passantes au cas où une attaque se produise. Donc finalement, l'entonnoir de la bande passante est toujours là et ça peut être une façon simple de faire tomber un site, même s'il a été bien protégé en termes de système et d'infrastructure. Et puis dans certains cas, en fonction de l'application, vous pouvez être obligé de faire des modifications sur votre architecture, vous pouvez être obligé de découper une appli en plusieurs applis différentes pour finalement étaler la surface d'attaque. Bien évidemment, ce sont des choses auxquelles on ne pense pas quand on conçoit l'application. C'est du refactoring a posteriori. Si mon ami Boris est à l'écoute, il sait que le refactoring d'application strictement pour des questions sécuritaires est un sujet qui est souvent difficile à faire passer aux équipes de développement et aux équipes de management. Et puis le dernier point c'est le coût, c'est que tout ça c'est du temps, c'est de l'argent et si vous décidez de déployer des équipements matériels qui vont vous protéger contre le DDoS et qui sont peut-être chez vos opérateurs, ça va coûter très très cher, surtout si vous voulez protéger une quantité de bandes passantes importante. Donc voilà, c'est difficile à mettre en place, c'est difficile à vendre, c'est difficile à déployer. J'ai eu ce sujet sur la table plusieurs fois, c'est des discussions qui sont compliquées. Et puis, bien sûr, le moment venu, vous devez activer la protection et ça c'est délicat, d'autant plus qu'on l'a vu tout à l'heure, une grande partie des attaques est courte. Le script qui s'amuse à lancer les attaques de deux minutes et puis qui s'en va, puis qui revient une heure après et qui recommence deux minutes, etc. L'attaque est déjà finie que vous n'avez pas pu même réagir et peut-être même pas détecter l'attaque. Donc sur des attaques courtes, vous serez toujours un peu en retard. Et sur des attaques plus longues, plus massives, généralement, vous devrez impliquer votre opérateur télécom, vous allez lui demander de nettoyer votre trafic, pour faire ça, ou votre fournisseur de services, il y a des fournisseurs qui font ça aussi, très bien, mais il faut l'activer, il faut rerouter le trafic vers une destination de nettoyage, peut-être que ce reroutage induit une latence supplémentaire pour vos utilisateurs, en plus de la latence causée par l'attaque, bref tout ça est un peu compliqué et puis le temps c'est de l'argent, si l'attaque vous coûte 50 000 dollars de l'heure, disons 60 000, chaque minute c'est 1000 dollars, donc chaque minute perdue à activer votre plan de défense c'est de l'argent perdu. Voilà donc c'est compliqué, c'est des sujets vraiment compliqués à travailler. Quelques bonnes pratiques pour la résilience, avant de parler spécifiquement de Shield et d'autres outils. On a un white paper qui est sorti il y a quelques temps, qui a été, contrairement à ce que l'URL laisse penser, mis à jour en juin 2016. Je vous le conseille vraiment très fortement, j'aurais dû l'écrire en rouge. Pourquoi ? Parce que certes les sujets sont abordés dans un cadre anti-DDOS mais de manière générale les pratiques qui sont décrites là sont des pratiques avant tout de haute disponibilité et de performance. Donc vraiment toutes les pratiques qui sont dans ces sujets devraient être mises en œuvre sur les architectures AWS indépendamment des sujets DDoS. Au coin du feu pendant Noël avec les 58 vidéos Re:Invent que vous avez déjà regardées. Vous pouvez rajouter ce white paper qui est bien intéressant. Je vais revenir sur quelques-unes des mesures qui sont préconisées et qui aboutissent à ce genre d'architecture. Rassurez-vous, je ne vais pas l'expliquer en détail, mais en fait, si je dois en parler 30 secondes, qu'est-ce qu'on voit sur cette architecture ? On voit en amont, à gauche, on voit CloudFront qui est un élément clé pour lutter contre des pics de trafic qui soient légitimes ou issus d'attaques DDoS. On va revenir sur CloudFront tout à l'heure. On voit Route 53, idem, qui est un service DNS managé qui est lui-même capable d'encaisser du trafic massif. Donc des services managés frontaux qui vont déjà assurer une première ligne de protection et de défense de votre infrastructure. Puis ensuite des load balancer, des choses comme ça avec une DMZ qui va vous permettre de nettoyer un peu votre trafic. Pourquoi pas un web application firewall ? On reparlera aussi de ce sujet tout à l'heure. Si vous utilisez un WAF d'un de nos partenaires, vous allez avoir cette jolie architecture dite du WAF sandwich avec un ELB en frontal, le WAF en auto-scaling pour lui-même être capable de scaler face à un des pics de trafic et puis un deuxième ELB qui va envoyer le trafic nettoyé vers vos frontaux, vers vos serveurs web qui sont eux-mêmes aussi dans un groupe d'auto-scaling pour absorber du trafic. Et puis en back-end, pourquoi pas MySQL ou RDS ou d'autres services. Vous voyez les points clés, c'est de se dire une première ligne de défense avec des services managés, de l'auto-scaling partout où le trafic peut croître de manière forte, la capacité à nettoyer du trafic avec des ELB, avec les security groupes, avec le WAF, des security group sur les LB, etc. Là aussi il y aurait moyen de parler pendant deux heures uniquement sur ce slide et je vous invite à lire le white paper et vous aurez toutes les bonnes pratiques à l'intérieur. Alors je vais juste en lister quelques unes qui sont vraiment là plus pertinentes sur les aspects des DDoS, donc qui sont réduire la surface d'attaque, se préparer à mettre son infrastructure à l'échelle en cas d'attaque, en cas de pic de trafic, étudier le comportement de cette plateforme pour connaître finalement le cas d'utilisation normale et être capable de détecter ce qui est déviant, et puis surveiller son trafic réseau avec les flux VPC, les VPC Flow Logs en anglais, et puis utiliser des services pour contrer les attaques en amont. Alors réduire sa surface d'attaque, qu'est-ce que ça veut dire ? Ça veut dire tout simplement faire en sorte que vous n'exposiez pas tous vos services de manière incontrôlée sur internet. On l'a vu sur l'architecture de référence que j'ai montrée, le trafic commence par rentrer, il entre sur un point précis qui permet de le filtrer, qui permet de le nettoyer, qui permet de dropper si c'est nécessaire du trafic. Et puis une fois qu'on a fait déjà cette première défense là, ensuite on commence à envoyer du trafic vers les frontaux et vers les applications. Donc veillez à ce que vous n'ayez pas 50 frontaux exposés individuellement sur Internet ou ce genre de choses. Vraiment chaque IP, chaque port 80, chaque port ouvert sur Internet c'est une avenue d'attaque, d'autant plus si le port est ouvert sur une pauvre instance qui n'est pas en auto-scaling, etc. Faites attention à ce que vous exposez, ouvrez le minimum de port et concentrez le trafic sur des points d'entrée que vous maîtrisez, que vous contrôlez. N'hésitez pas à séparer le trafic et l'infra des différents services, il n'y a rien de pire que le serveur qui gère 8 applications différentes, ça c'est mauvais, si vous faites tomber ce serveur-là, tout tombe. Donc séparer vos services sur différentes fermes d'instances frontales avec des ELB dédiés, des security group dédiés, etc. Et puis quand c'est possible, autorisez explicitement, validez explicitement les utilisateurs et le trafic, vous pouvez utiliser des URL signées, vous pouvez utiliser les ACL réseau pour vérifier, je ne sais pas, l'IP source de vos utilisateurs. Si vous arrivez à définir comme ça des utilisateurs autorisés et des utilisateurs a priori pas autorisés, vous pouvez les filtrer très en amont aussi. Vous pouvez déjà commencer à resserrer un peu les boulons comme ça. Les mécanismes pour le faire, on en a parlé, il y a évidemment les load balancer qui sont importants parce que c'est un service manager qui va scaler en cas de besoin. Vous pouvez appliquer des security groups sur les load balancers, fermer, enfin en tout cas ne pas autoriser des ports s'ils ne doivent pas être présents, avoir des instances distinctes dans des sous-réseaux différents, dans des availability zones différentes, etc. Utiliser, je l'ai dit, les security groups, les ACL réseaux. Et puis il y a un dernier point que je voulais mentionner qui est sans doute peu connu, qui est qu'en fait, pour les services publics, pensez à utiliser des IP élastiques. Pourquoi ? Parce qu'elles ont deux propriétés qui sont vraiment intéressantes, c'est qu'elles sont réassignables. Donc si vous avez un serveur qui est attaqué, vous pouvez détacher son IP et la réattacher à un autre, soit ne pas la réattacher du tout et lui réattacher une nouvelle IP élastique qui elle n'est pas attaquée. Donc ça peut être une façon tout simplement de dire voilà cette IP là elle est compromise temporairement parce qu'elle est attaquée, donc je vais attacher une autre IP élastique que mes services peuvent utiliser et je remets en ligne finalement mon service. Et surtout ces IP sont non contiguës. Elles sont non-continues et donc elles ne peuvent pas être attaquées de manière systématique par des scans réseau bêtes et méchants par rapport à des ranges d'adresses prédéfinies. Donc vous pouvez avoir des serveurs qui font la même chose, qui sont dans le même groupe, etc., qui ont la même application, mais qui ont des IP qui sont complètement non-continues et très différentes. Donc ça complique un peu la tâche de l'attaquant. Le deuxième point, c'est préparer la mise à l'échelle. Alors, à l'instant, j'ai dit réduire la surface d'attaque. Donc réduire la surface d'attaque, ça veut dire protéger vos ressources, faire en sorte qu'il y ait un entonnoir que vous maîtrisez bien, qui est le seul moyen d'accéder à vos ressources. Et en revanche, vous pouvez compliquer la tâche de l'attaquant en l'obligeant à vous attaquer sur une surface plus large. On va voir comment faire ça par exemple avec CloudFront. Donc ça va obliger vos attaquants à déployer beaucoup plus de ressources pour effectivement vous mettre en difficulté ou en tout cas faire monter l'attaque et ça va le ralentir. Et ce ralentissement-là, ça vous laisse le temps de détecter l'attaque, de comprendre d'où elle vient et de répliquer, ou en tout cas de réagir, répliquer ça c'est à vous de voir, mais de réagir en tout cas en mettant en œuvre les bonnes mesures. Alors la mise à l'échelle, on l'a vu tout à l'heure, vous pouvez renforcer la capacité réseau de vos instances en utilisant le NN Networking, qui je le rappelle doit être maintenant à peu près actif sur toutes vos instances si elles sont récentes. Utiliser le load balancing, utiliser le security group du load balancer, utiliser l'auto scaling pour faire grossir les fermes de serveurs qui servent à une application donnée, utiliser CloudFront, on va en parler tout de suite, et utiliser Route53 qui est un DNS managé, plutôt que d'utiliser vos propres serveurs DNS, on a vu tout à l'heure que le DNS est souvent une cible favorite des attaquants. Attaquer les serveurs DNS c'est aussi une excellente façon de vous faire tomber parce que si vos serveurs DNS ne sont plus capables de résoudre vos domaines, assez vite vous devenez invisible, inaccessible sur Internet. Donc utiliser Route53 c'est aussi une bonne façon de se protéger contre des attaques directes sur vos serveurs DNS. Alors étudier le comportement normal. Comment vous savez que vous êtes attaqué ? Comment vous savez que le trafic que vous recevez c'est du trafic anormal ? Comment vous faites la différence entre un pic de trafic et une attaque ? Pour ça, il n'y a pas cinq ans de solution, vous devez faire de la métrologie et vous devez connaître votre niveau d'utilisation normal. Il faut que vous ayez le monitoring en place pour vous dire ça c'est du trafic normal, ça c'est pas normal. Donc vous pouvez définir tout ça avec quelques métriques CloudWatch qu'on va voir après. Et puis mon conseil c'est aussi de temps en temps faire des tests de charge, c'est une bonne pratique de manière générale et ça vous montrera où est-ce que votre infrastructure commence à chauffer lorsque le trafic augmente. Et c'est pas toujours là où on l'attend malheureusement. Donc voilà, il y a un ensemble de métriques qui sont intéressantes, les groupes d'autoscaling, le nombre de requêtes CloudFront, le nombre de requêtes sur les ELB, les codes d'erreur sur les ELB qui peuvent vous indiquer que si vous avez un pic d'erreur 500, il est en train de se passer quelque chose, etc. On ne va pas toutes les lister, mais pour du scaling normal et a fortiori pour du scaling contre des attaques, ces métriques-là vont vous indiquer ce qu'il est en train de se passer sur vos instances. Donc observez bien ces métriques, suivez-les et définissez des alarmes avec des seuils qui sont toujours... Il faut toujours un peu de temps pour définir des seuils, c'est toujours trop haut, trop bas, trop haut ça sonne jamais, trop bas ça sonne tout le temps. Donc trouvez des seuils qui sont significatifs et qui vous indiquent qu'en particulier si plusieurs seuils sont franchis, si vous avez un peak CloudFront massif et une augmentation de la latence sur les frontaux et un pic d'erreur 500, vous avez un problème. Donc voilà, ces métriques-là sont un bon point de départ pour commencer à surveiller votre infra. Et puis ce mécanisme que j'espère que vous connaissez, les VPC Flow Logs, qui permettent d'envoyer vers CloudWatch Logs l'intégralité du trafic réseau de votre VPC, y compris ce qui arrive à la frontière de votre VPC et ce qui est droppé par les ACL par exemple. C'est la visibilité totale sur ce qui se passe aux frontières réseaux de votre infrastructure. Vous trouverez dans les blog posts qui sont décrits là comment intégrer ces VPC Flowlogs avec Elasticsearch, Kibana, etc. pour avoir une visualisation en temps réel de ce qui se passe. Donc là aussi ça peut vous aider à surveiller ce qui se passe dans votre infra et puis avoir visuellement le sentiment qu'il se passe quelque chose de bizarre en ce moment. Donc les VPC Flowlogs c'est vraiment la bonne façon de surveiller tout le trafic réseau qui arrive sur un VPC. Alors voilà quelques bonnes pratiques en général et sincèrement j'aurais pu en parler indépendamment de tout contexte des DDoS, c'est des bonnes pratiques de scalabilité et de monitoring. Maintenant voyons spécifiquement ce que AWS peut faire pour vous en termes d'anti-DDoS. Alors il y a quatre services dont on va parler, à mon grand désespoir on n'a toujours pas un service qui s'appelle Gandalf, ça viendra peut-être un jour. CloudFront, API Gateway, le WAF et le fameux AWS Shield. Alors CloudFront aujourd'hui, c'est notre CDN, je pense que vous le savez, on a 68 points de présence dans le monde qui peuvent servir à servir votre contenu statique et dynamique au plus près des utilisateurs. Donc l'utilisation traditionnelle de CloudFront, c'est de réduire la latence sur des accès éloignés de votre infrastructure. Mais on peut aussi utiliser CloudFront comme un excellent mécanisme anti-DDoS. Pourquoi ? Tout simplement parce qu'au travers de ces points de présence, imaginez que vous soyez attaqué, je ne sais pas, en Asie au hasard, depuis l'Asie et depuis l'Europe de l'Est au hasard, là aussi, les attaquants vont attaquer votre site à partir du trafic qui est servi depuis CloudFront. Ce qui veut dire qu'au lieu d'attaquer une origine qui se trouverait par exemple en Irlande, dans la région de Dublin, en utilisant CloudFront sur une grande partie de votre contenu, finalement vous les obligez à attaquer plusieurs sources qui vont être les points CloudFront qui sont les plus proches des lieux de l'attaque. Si vous êtes attaqué, disons depuis la Chine, CloudFront en Chine va déjà servir du trafic à partir de l'infrastructure de la région chinoise. Et donc déjà tout ce trafic-là, c'est du trafic qui ne sera pas servi depuis une origine lointaine. Et puis si vous êtes attaqué depuis l'Europe de l'Est, les POP CloudFront d'Europe de l'Est, là aussi, vont déjà répondre à ces attaques en servant du trafic. Et donc ça permet déjà de dévier une grande partie du trafic d'attaque en le servant depuis les edge locations et sans avoir besoin de l'acheminer déjà, de commencer à construire le goulot d'étranglement sur la région Irlandaise par exemple. Donc CloudFront c'est vraiment un très bon service de ce point de vue là. Une deuxième solution, c'est d'utiliser l'API Gateway. L'API Gateway, c'est un service géré qui permet de construire des API REST. Très pratique pour faire des back-ends, des web services, etc. Mais en particulier, l'API Gateway vous permet d'authentifier l'utilisateur. Vous pouvez avoir des URL signées, des tokens, etc. Donc dans le cas de trafic que vous arrivez à authentifier, vous pouvez vous protéger avec ce mécanisme. Vous pouvez aussi faire du throttling, vous pouvez limiter le nombre de hits par seconde sur une API donnée. Ça déjà, ça permet de dropper en amont des ressources qui implémentent les API. Ça vous permet déjà de dropper tout un tas de trafic. Et puis il y a un mécanisme de cache qui va lui aussi la répondre très rapidement sans avoir à solliciter l'infrastructure qui est en aval. Donc là ça ne s'applique bien que sur des API mais ça peut être une partie importante de votre application et du coup vous avez Service Manager qui est là aussi une ligne de défense qui va protéger tout ce qui se trouve en aval, tout ce qui implémente vos API, par exemple vos instances EC2. Donc voilà un schéma typique, vous voyez on a des API qui sont implémentées soit avec Lambda, soit avec EC2, soit avec Beanstalk, soit avec autre chose. Et donc vous pouvez avec cette authentification et ce filtrage, enfin ce throttling plutôt, vous pouvez déjà nettoyer votre trafic avant même qu'il arrive sur les ressources les plus précieuses. Le troisième mécanisme que vous pouvez utiliser c'est le web Application Firewall qui a été lancé il y a plus d'un an maintenant, qui a un WAF traditionnel, c'est un service géré, facile à mettre en œuvre, que vous payez à l'usage, vous payez par règle, etc. L'intérêt de ce service c'est que vous allez pouvoir définir des règles de niveau 7, HTTP, qui vont inspecter le trafic entrant et qui, sur la base de ces règles, vont autoriser ou pas le trafic à poursuivre sa route. Donc il y a un ensemble de règles déjà prédéfinies, on a un wizard qui vous permet de bloquer des IP, de bloquer des injections SQL, de bloquer des chaînes de caractères, par exemple si vous voulez bloquer un user agent ou si vous voulez bloquer le bot d'un moteur de recherche un petit peu intrusif sur votre infra, au hasard, vous pouvez le faire avec le WAF. Et vraiment ça se fait en 5 minutes. Alors jusqu'à il y a très récemment, le WAF était uniquement intégré avec CloudFront, donc il fallait d'abord créer des distributions CloudFront pour votre site web et devant cette distribution vous pouviez intégrer le WAF et donc depuis Re:Invent, vous pouvez aussi intégrer le WAF sur les applications Load Balancer. Donc plus près de vos instances et sans avoir besoin de créer forcément des distributions CloudFront. Donc le WAF c'est vraiment une bonne façon de nettoyer le trafic avec des règles qui sont relativement faciles à écrire. Voilà donc ça permet de faire ça, de laisser passer du trafic légitime et de bloquer le trafic des attaquants sur la base d'IP, vous voulez bloquer un pays entier dans lequel vous n'avez pas de business et qui vous envoie que du trafic malicieux, vous pouvez le faire sur le WAF en une règle. C'est facile à faire. Alors si vous voulez utiliser un WAF tiers, vous pouvez le faire. C'est tout à fait possible, c'est cette fameuse architecture sandwich dont je parlais tout à l'heure. Donc un ELB qui va servir de point d'entrée, le WAF qui tournera dans une instance EC2 ou en l'occurrence un ensemble d'instances EC2 puisque vous avez besoin probablement d'auto-scaler le WAF lui-même en cas de pic de trafic et puis en sortie du WAF le trafic est nettoyé et part vers un ELB qui va être lui l'ELB applicatif qui va envoyer ce trafic nettoyé à vos applications. Donc voilà, un WAF qui tourne dans une instance EC2, autoscalé, avec un ELB de part et d'autre, d'où le sandwich. On a différents partenaires qui vont vous proposer ces solutions, vous les retrouverez sur la Marketplace. Il y a tout cet ensemble de WAF qui sont disponibles. N'hésitez pas à les essayer, je crois que la plupart, pour ne pas dire tous, sont disponibles à l'heure, vous pouvez tester pendant une heure un WAF, puis s'il ne vous plaît pas, vous en essayez un autre, et puis s'il vous plaît, vous continuez à l'utiliser, vous le déployez en production. Vraiment la marketplace, c'est un excellent moyen de tester tout un tas de solutions très rapidement, et à très faible coût surtout. Et puis, le dernier service, bien sûr, le dernier en date, le service Shield, bien nommé, qui a été annoncé à Re:Invent il y a quelques semaines et qui existe dans deux niveaux de protection. AWS Shield vous protège tous d'un certain nombre d'attaques sans aucun coût supplémentaire. Vous êtes protégés contre un grand nombre d'attaques DOS grâce à ce service. Pour les utilisateurs qui ont besoin de fonctionnalités avancées, il y a un niveau supplémentaire, la protection avancée, qui est un service payant offrant des fonctionnalités et protections supplémentaires. Le Shield Standard protège contre les attaques en couches 3 et 4, qui constituent la plus grande partie des attaques DOS observées aujourd'hui. Ce service fonctionne complètement automatiquement, sans configuration de votre part. Les attaques sont détectées et contrées automatiquement par l'infrastructure AWS. Vous êtes protégés contre les attaques les plus courantes, comme les floods, les attaques par réflexion, etc. Ce service est intégré avec d'autres services AWS. Si quelqu'un attaque vos services CloudFront ou vos load balancers, le Shield fait son travail dès aujourd'hui. Ce qui n'est pas inclus dans le niveau standard, c'est la protection de niveau 7. Si vous souhaitez protéger votre application de niveau 7, vous activerez le WAF, qui est un service self-service et payé à l'usage. Vous payez par règle par mois et pouvez protéger telle ou telle partie du site contre telle ou telle attaque. En combinant le WAF avec le niveau standard de Shield, vous pouvez avoir un bon niveau de protection et extrêmement économique, puisque Shield ne coûte rien et WAF est configurable. Le coût est faible, quelques dollars par mois par règle. Si vous avez besoin de plus, si vous êtes particulièrement exposé, vous pouvez utiliser Shield Advanced, qui est intégré avec les load balancers, les ELB, les application load balancers, et les services Edge comme CloudFront et Route 53. Shield Advanced est disponible en Irlande et sera progressivement déployé dans d'autres régions. Si vous êtes hébergé en Irlande, vous pouvez activer Shield Advanced. Shield Advanced offre un monitoring permanent, protège contre davantage d'attaques sur toutes les couches, y compris les attaques plus sophistiquées en couche 7, et intègre le WAF. En cas d'attaque, vous recevrez des notifications, des rapports sur les attaques, et un accès en permanence à la DDoS Response Team d'AWS. Vous pourrez être contacté directement ou contacter l'équipe pour discuter des mesures à prendre. Vous avez également une protection de votre facture AWS, ce qui signifie que toutes les ressources supplémentaires créées pour lutter contre l'attaque ne seront pas facturées. Le coût du service Advanced est de 3000 dollars par mois, plus le coût de transfert sortant sur les services protégés. Pour la plupart des utilisateurs, la protection standard suffira. Si votre secteur d'activité nécessite une réaction à des attaques plus lourdes et sophistiquées, la protection avancée peut se justifier. Elle a un certain coût mais vous protège contre presque tout et offre de la visibilité et un accès direct aux experts en cas de problème. Pour plus d'informations, n'hésitez pas à contacter vos gestionnaires de comptes et vos solution architects. Si vous avez des contrats de support, vous pouvez également discuter avec vos interlocuteurs de support. C'est un engagement d'un an, donc il vaut mieux réfléchir à deux fois et discuter avec les équipes d'AWS pour savoir si le niveau de protection avancée est justifié. Quelques ressources supplémentaires : le blog sécurité d'AWS, le livre blanc sur la résilience des DOS, et deux sessions récentes de reInvent, une pour le lancement de Shield et une sur des use cases concrets pour se protéger contre les attaques DOS. Merci beaucoup. Hugo va vous afficher le sondage de satisfaction. 5, vous êtes très contents, 1, vous n'êtes pas content du tout. Merci pour le feedback et nous allons passer aux questions. Vous avez deux minutes pour voter. Manifestement, vous êtes satisfait. C'est bien, ça me fait plaisir. Depuis le temps que vous attendiez des réponses d'AWS sur les sujets des DOS. Première question d'Alexandre : Pourquoi réagir à une attaque courte ? Ces attaques, que j'appelle les snipers, sont typiquement des attaques qui durent une minute, toutes les heures, ou toutes les quarts d'heure. Elles rendent fou car vous n'avez pas le temps d'analyser l'attaque avant qu'elle ne recommence. Il faut un mécanisme de protection permanente qui détecte et stoppe ces attaques en quelques secondes. Les attaques courtes sont particulièrement pénibles. Question de Julien : Est-ce que WAF est disponible actuellement ? Oui, WAF a été lancé au printemps 2016 et est disponible en Irlande. Question d'Alexandre : Est-ce qu'il y a besoin d'utiliser Shield avec API Gateway ? Non, vous pouvez utiliser l'API Gateway indépendamment. Si vous avez besoin de protéger des API derrière l'API Gateway, vous pouvez activer le throttling, etc. Question de Julien : Y a-t-il une date de sortie de Shield Advanced sur Francfort ? Je n'ai pas de date à communiquer, mais les services arrivent généralement d'abord en Irlande, puis à Francfort. Question de Jean : Le service Shield s'applique-t-il à l'ensemble du compte ? Oui, il s'applique à l'ensemble du compte et est intégré avec les services Edge, CloudFront, Route53, et les load balancers. Question de Jean : Serait-il possible de partager des ressources sur WAF, par exemple pour bloquer les bots non identifiés, les scrapers, etc. ? Vous pouvez définir des ACL dans la console WAF, il y a un wizard pour le faire. Vous pouvez vous protéger contre du XSS, filtrer les IP, limiter les tailles de paquets, vous protéger contre l'injection SQL, et faire du string matching. C'est vraiment simple. Question de Damien : Quid d'un attaquant qui se trouve chez AWS suite à un piratage de comptes ? Si vous subissez des attaques d'instances EC2, créez un ticket de support, signalez l'abuse, et le support vérifiera le problème et contactera le propriétaire du compte. Si l'attaque ne cesse pas, des mesures coercitives seront prises. Question de Christophe : Est-ce qu'il y a des notifications sans être dans Shield Advanced ? Non, les mécanismes de reporting et de notification sont uniquement inclus dans Shield Advanced. Question : Peut-on tester notre solution anti-DDoS sans risquer de se faire blacklister nos IP par AWS ? Si vous voulez faire des tests de charge ou des tests de pénétration, vous devez contacter le support pour obtenir une autorisation. Suivez le process pour éviter de vous faire blacklister. Question de Joseph : Quels critères pour choisir un partenaire WAF ? Essayez-les, faites une matrice d'évaluation en fonction de vos problématiques, et choisissez ceux qui vous paraissent les plus faciles à configurer et les plus agréables. Question : Est-il possible d'avoir de la protection DOS sur des load balancer classiques ? Oui, le Shield est actif sur les ELB. Question : En cas d'attaque DDoS sur CloudFront, y a-t-il une limite à ce que CloudFront accepte de prendre ? La capacité réseau de CloudFront est importante, mais tout a une limite. Nous pensons être capables d'encaisser de très fortes charges. On n'a plus de temps ? Non, je vois Hugo qui me fait les gros yeux. On n'a plus de temps. Je vais regarder les questions restantes et essayer d'y répondre dans le prochain webinaire. Merci d'avoir assisté à ce webinaire. Demain, nous ferons la deuxième partie de l'update reInvent, avec une démo d'Amazon Athena et une session sur CloudTrail. Merci encore, bonne soirée, et bon shopping de Noël. Rendez-vous demain pour ReInvent, deuxième chapitre, et CloudTrail. Merci, bonne soirée.