Cet article est le quatrième d'une série d'articles, «Comment prendre l'infrastructure réseau sous votre contrôle». Le contenu de tous les articles de la série et les liens peuvent être trouvés ici .

Dans la première partie de ce chapitre, nous avons examiné certains aspects de la sécurité réseau du segment Data Center. Cette partie sera consacrée au segment «Accès Internet».

Accès Internet

La sécurité est sans aucun doute l'un des sujets les plus complexes du monde des réseaux de données. Comme dans les cas précédents, sans prétendre à la profondeur et à l'exhaustivité, je considérerai ici assez simple, mais, à mon avis, des questions importantes, dont les réponses, je l'espère, contribueront à élever le niveau de sécurité de votre réseau.

Lors de l'audit de ce segment, faites attention aux aspects suivants:

• conception
• Paramètres BGP
• Protection DOS / DDOS
• filtrage du trafic du pare-feu

La conception

Comme exemple de la conception de ce segment pour le réseau d'entreprise, je recommanderais un guide de Cisco dans le modèle SAFE .

Bien sûr, la solution d'autres fournisseurs vous semblera peut-être plus attrayante (voir le quadrant Gartner pour 2018 ), mais sans vous inciter à suivre cette conception en détail, je trouve toujours utile de comprendre les principes et les idées qui la sous-tendent.

Remarque

Dans SAFE, le segment d'accès à distance fait partie de l'accès à Internet. Mais dans cette série d'articles, nous allons l'examiner séparément.

L'ensemble standard d'équipements de ce segment pour un réseau d'entreprise est

• routeurs frontaliers
• pare-feu

Remarque 1

Dans cette série d'articles, lorsque je parle de pare-feu, je veux dire NGFW .

Remarque 2

J'omets la prise en compte de différents types de solutions L2 / L1 ou superposition L2 sur L3 nécessaires pour assurer la connectivité L1 / L2 et je me limite aux questions de niveau L3 et supérieur. Les problèmes partiellement L1 / L2 ont été traités dans le chapitre " Nettoyage et documentation ".

Si vous n'avez pas trouvé de pare-feu dans ce segment, ne vous précipitez pas vers les conclusions.

Commençons, comme dans la partie précédente , par la question: est-il nécessaire d'utiliser un pare-feu dans ce segment dans votre cas?

Je peux dire que cela semble être l'endroit le plus justifié pour utiliser des pare-feu et pour appliquer des algorithmes complexes de filtrage du trafic. Dans la partie 1, nous avons mentionné 4 facteurs qui peuvent interférer avec l'utilisation de pare-feu dans le segment des centres de données. Mais ici, ils ne sont pas si importants.

Exemple 1. Retard

Quant à Internet, cela n'a aucun sens de parler de retards même de l'ordre de 1 milliseconde. Par conséquent, le retard dans ce segment ne peut pas être un facteur limitant l'utilisation de feux d'artifice.

Exemple 2. Performances

Dans certains cas, ce facteur peut encore être important. Par conséquent, vous devrez peut-être laisser une partie du trafic (par exemple, le trafic de l'équilibreur de charge) contourner le pare-feu.

Exemple 3. Fiabilité

Ce facteur doit encore être pris en compte, mais néanmoins, compte tenu du manque de fiabilité de l'Internet lui-même, son importance pour ce segment n'est pas aussi importante que pour le centre de données.

Supposons donc que votre service vive au-dessus de http / https (avec de courtes sessions). Dans ce cas, vous pouvez utiliser deux boîtiers indépendants (sans HA) et, en cas de problème avec l'un d'eux, le routage, transférer tout le trafic vers le second.

Ou vous pouvez utiliser des pare-feu en mode transperence et, lorsqu'ils échouent, permettre au trafic de contourner les pare-feu tout en résolvant le problème.

Par conséquent, ce n'est probablement que le prix qui peut être le facteur qui vous forcera à abandonner l'utilisation des pare-feu dans ce segment.

Important!

Il y a une tentation de combiner ce pare-feu avec le pare-feu du centre de données (utilisez un pare-feu pour ces segments). La solution, en principe, est possible, mais en même temps, vous devez comprendre que, puisque Le pare-feu «Accès Internet» se situe en fait à l'avant-garde de votre défense et «prend en charge» au moins une partie du trafic malveillant, puis, bien sûr, vous devez prendre en compte le risque accru que ce pare-feu soit désactivé. Autrement dit, en utilisant les mêmes appareils dans ces deux segments, vous réduirez considérablement la disponibilité de votre segment de centre de données.

Comme d'habitude, vous devez comprendre qu'en fonction du service fourni par l'entreprise, la conception de ce segment peut être très différente. Comme d'habitude, vous pouvez choisir différentes approches en fonction des besoins.

Exemple

Si vous êtes un fournisseur de contenu avec un réseau CDN (voir, par exemple, une série d'articles ), vous ne souhaiterez peut-être pas créer des dizaines, voire des centaines de points de présence d'infrastructure à l'aide d'appareils distincts pour le routage et le filtrage du trafic. Cela coûtera cher et pourrait être redondant.

Pour BGP, vous n'avez pas du tout besoin de routeurs dédiés, vous pouvez utiliser des outils open-source, par exemple, Quagga . Par conséquent, tout ce dont vous avez besoin est peut-être un serveur ou plusieurs serveurs, un commutateur et BGP.

Dans ce cas, votre serveur ou plusieurs serveurs peuvent jouer le rôle non seulement du serveur CDN, mais également du routeur. Bien sûr, il y a encore beaucoup de détails (par exemple, comment assurer l'équilibrage), mais c'est faisable, et nous avons appliqué avec succès cette approche pour l'un de nos partenaires.

Vous pouvez avoir plusieurs centres de données avec une protection complète (pare-feu, services de protection DDOS fournis par vos fournisseurs Internet) et des dizaines ou des centaines de points de présence «simplifiés» avec uniquement des commutateurs et serveurs L2.

Mais qu'en est-il de la protection dans ce cas?

Voyons, par exemple, la récente attaque DDOS d'amplification DNS . Son danger réside dans le fait qu'une grande quantité de trafic est générée, qui "obstrue" simplement 100% de toutes vos liaisons montantes.

Ce que nous avons dans le cas de notre conception.

• si vous utilisez AnyCast, le trafic est réparti entre vos points de présence. Si vous avez des térabits de bande passante totale, alors cela en soi (en fait, il y a eu plusieurs attaques avec un trafic malveillant de l'ordre des térabits récemment) vous protège contre les débordements de liaisons montantes
• si, néanmoins, certaines liaisons montantes sont «bouchées», alors vous mettez simplement cette plateforme hors service (arrêtez d'annoncer le préfixe)
• vous pouvez également augmenter la part du trafic provenant de vos centres de données «à part entière» (et, par conséquent, protégés), supprimant ainsi une partie importante du trafic malveillant des points de présence non protégés

Et encore une petite remarque à cet exemple. Si vous envoyez suffisamment de trafic via les IX, cela réduit également votre exposition à de telles attaques.

Configurer BGP

Il y a deux sujets.

• Connectivité
• Configurer BGP

Nous avons déjà parlé un peu de la connectivité dans la partie 1 . L'essentiel est que le trafic vers vos clients soit le meilleur moyen. Bien que l'optimalité ne soit pas toujours une question de retard, c'est généralement la faible latence qui est le principal indicateur d'optimalité. Pour certaines entreprises, c'est plus important, pour d'autres - moins. Tout dépend du service que vous fournissez.

Exemple 1

Si vous êtes un échange et que des intervalles de temps inférieurs à des millisecondes sont importants pour vos clients, alors, bien sûr, il ne peut être question d'aucun Internet.

Exemple 2

Si vous êtes une entreprise de jeux et que des dizaines de millisecondes sont importantes pour vous, alors, bien sûr, la connectivité est très importante pour vous.

Exemple 3

Vous devez également comprendre qu'en raison des propriétés du protocole TCP, le taux de transfert de données au sein d'une session TCP dépend également du RTT (Round Trip Time). Des réseaux CDN sont également en cours de construction pour résoudre ce problème, rapprochant les serveurs de distribution de contenu du consommateur de ce contenu.

L'étude de la connectivité est un sujet intéressant distinct, digne d'un article séparé ou d'une série d'articles et nécessite une bonne compréhension de la façon dont Internet est «organisé».

Ressources utiles:

ripe.net
bgp.he.net

Exemple

Je ne donnerai qu'un petit exemple.

Supposons que votre centre de données soit situé à Moscou et que vous ayez la seule liaison montante - Rostelecom (AS12389). Dans ce cas, vous n'avez pas besoin de BGP (à hébergement unique) et vous utilisez probablement le pool d'adresses de Rostelecom comme adresses publiques.

Supposons que vous fournissiez un certain service, que vous ayez un nombre suffisant de clients ukrainiens et qu'ils se plaignent de gros retards. Dans l'étude, vous avez constaté que les adresses IP de certains d'entre eux se trouvent dans le réseau 37.52.0.0/21.

En faisant traceroute, vous avez vu que le trafic passe par AS1299 (Telia), et en faisant ping, vous avez obtenu un RTT moyen de 70 à 80 millisecondes. Vous pouvez également le voir sur le miroir de Rostelecom .

Avec l'utilitaire whois (sur ripe.net ou un utilitaire local), vous pouvez facilement déterminer que le bloc 37.52.0.0/21 appartient à AS6849 (Ukrtelecom).

De plus, en allant sur bgp.he.net, vous voyez que AS6849 n'a aucune relation avec AS12389 (ils ne sont ni clients ni liaisons montantes les uns aux autres, ils n'ont pas non plus de peering). Mais si vous regardez la liste des pairs pour AS6849, vous verrez, par exemple, AS29226 (Mastertel) et AS31133 (Megafon).

En trouvant le miroir de ces fournisseurs, vous pouvez comparer le chemin d'accès et le RTT. Par exemple, pour Mastertel RTT, il y aura déjà environ 30 millisecondes.

Donc, si la différence entre 80 et 30 millisecondes est importante pour votre service, alors vous devez peut-être penser à la connectivité, obtenir votre numéro AS, votre pool d'adresses dans RIPE et connecter des liaisons montantes supplémentaires et / ou créer des points de présence sur les IX.

Lorsque vous utilisez BGP, vous avez non seulement la possibilité d'améliorer la connectivité, mais également de réserver votre connexion Internet.

Ce document contient des recommandations pour la configuration de BGP. Malgré le fait que ces recommandations ont été développées sur la base des «meilleures pratiques» des prestataires, néanmoins (si vos paramètres BGP ne sont pas très élémentaires), elles sont sans aucun doute utiles et devraient en fait faire partie du durcissement dont nous avons discuté dans la première partie .

Protection DOS / DDOS

Désormais, les attaques DOS / DDOS sont devenues une réalité quotidienne pour de nombreuses entreprises. En fait, sous une forme ou une autre, vous êtes assez souvent attaqué. Le fait que vous ne le remarquiez pas encore, signifie seulement qu'une attaque ciblée contre vous n'a pas encore été organisée, et que les défenses que vous utilisez, même éventuellement sans vous en douter (diverses défenses intégrées des systèmes d'exploitation), suffisant pour que la dégradation du service fourni soit minimisée pour vous et vos clients.

Il existe des ressources Internet qui, sur la base des journaux de l'équipement, dessinent de belles cartes d'attaque en temps réel.

Ici vous pouvez trouver des liens vers eux.

Ma carte préférée de CheckPoint.

La protection DDOS / DOS est généralement en couches. Pour comprendre pourquoi, vous devez comprendre quels types d'attaques DOS / DDOS existent (voir, par exemple, ici ou ici )

Autrement dit, nous avons trois types d'attaques:

• attaques volumétriques
• attaques de protocole
• attaques d'applications

Si vous pouvez vous protéger contre les deux derniers types d'attaques vous-même, en utilisant, par exemple, des pare-feu, vous ne serez pas protégé contre les attaques visant à «déborder» vos liaisons montantes (bien sûr, si la capacité totale de votre canal Internet n'est pas calculée en térabits, mais mieux, par dizaines térabit).

Par conséquent, la première ligne de défense est la protection contre les attaques "volumétriques" et votre ou vos fournisseurs doivent fournir cette protection. Si vous ne l'avez pas encore réalisé, alors pour l'instant vous avez juste de la chance.

Exemple

Supposons que vous ayez plusieurs liaisons montantes, mais qu'un seul des fournisseurs peut vous fournir cette protection. Mais si tout le trafic passe par un seul fournisseur, qu'en est-il de la connectivité dont nous avons brièvement parlé un peu plus tôt?

Dans ce cas, vous devrez sacrifier en partie la connectivité pendant l'attaque. Mais

• ce n'est que pour la durée de l'attaque. En cas d'attaque, vous pouvez reconfigurer manuellement ou automatiquement BGP afin que le trafic ne passe que par le fournisseur qui vous fournit le "parapluie". Après la fin de l'attaque, vous pouvez ramener le routage à son état précédent.
• il n'est pas nécessaire de traduire tout le trafic. Si, par exemple, vous voyez qu'à travers certaines liaisons montantes ou peerings il n'y a pas d'attaque (ou que le trafic n'est pas significatif), vous pouvez continuer à annoncer des préfixes avec des attributs compétitifs en direction de ces voisins BGP.

Vous pouvez également protéger les «attaques de protocole» et les «attaques d'applications» des partenaires.
Ici vous pouvez lire une bonne étude ( traduction ). Certes, l'article date d'il y a deux ans, mais cela vous donnera une idée des approches, de la façon dont vous pouvez vous protéger contre les attaques DDOS.

En principe, vous pouvez vous y limiter en externalisant complètement votre protection. Il y a des avantages à cette solution, mais il y a un inconvénient évident. Le fait est que nous pouvons parler (encore une fois, selon ce que fait votre entreprise) de la survie de l'entreprise. Et confiez de telles choses à des tiers ...

Par conséquent, voyons comment organiser une deuxième et une troisième ligne de défense (en complément de la protection du fournisseur).

Ainsi, la deuxième ligne de défense est le filtrage et les policiers à l'entrée de votre réseau.

Exemple 1

Supposons que vous «fermiez avec un parapluie» de DDOS en utilisant l'un des fournisseurs. Supposons que ce fournisseur utilise Arbour pour filtrer le trafic et les filtres en bordure de son réseau.

La bande qu'Arbour peut «gérer» est limitée, et le fournisseur, bien sûr, ne peut pas constamment passer le trafic de tous ses partenaires qui ont commandé ce service via un équipement de filtrage. Par conséquent, dans des conditions normales, le trafic n'est pas filtré.

Supposons qu'une attaque par inondation SYN soit en cours. Même si vous avez commandé un service dans lequel, en cas d'attaque, le trafic passe automatiquement au filtrage, cela ne se fait pas instantanément. Pendant une minute ou plus, vous restez attaqué. Et cela peut entraîner la défaillance de votre équipement ou la dégradation du service. Dans ce cas, la limitation du trafic sur le routage des limites, bien que, conduira au fait que certaines sessions TCP ne seront pas établies pendant ce temps, mais cela sauvera votre infrastructure de problèmes plus importants.

Exemple 2

Un nombre anormalement élevé de paquets SYN peut non seulement être le résultat d'une attaque par saturation SYN. Supposons que vous fournissiez un service dans lequel vous pouvez avoir simultanément environ 100 000 connexions TCP (dans un centre de données).

Supposons qu'à la suite d'un problème à court terme avec l'un de vos principaux prestataires, la moitié des séances vous «donnent un coup de pied». Si votre application est conçue de telle manière que, sans y réfléchir à deux fois, immédiatement (ou après un intervalle de temps identique pour toutes les sessions) tente de rétablir la connexion, vous recevrez au moins 50 000 paquets SYN approximativement simultanément.

Si, en plus de ces sessions, par exemple, vous devez avoir une poignée de main ssl / tls, ce qui implique l'échange de certificats, alors du point de vue du manque de ressources pour votre équilibreur de charge, ce sera un "DDOS" beaucoup plus fort qu'un simple déluge SYN. Il semblerait que les équilibreurs devraient travailler sur un tel événement, mais ... malheureusement, nous étions confrontés à un tel problème en pleine croissance.

Et, bien sûr, le policier du routeur frontalier économisera également votre équipement dans ce cas.

Le troisième niveau de protection contre DDOS / DOS concerne les paramètres de votre pare-feu.

Ici, vous pouvez arrêter les deux attaques du deuxième et du troisième type. En général, tout ce qui atteint le pare-feu peut être filtré ici.

Astuce

Essayez de donner au pare-feu le moins de travail possible en filtrant autant que possible sur les deux premières lignes de défense. Et voici pourquoi.

Il ne vous est pas arrivé que par accident, en générant du trafic afin de vérifier, par exemple, la résistance de vos attaques DDOS au système d'exploitation, vous avez "tué" votre pare-feu, en le chargeant à 100%, avec un trafic d'intensité normale? Sinon, peut-être simplement parce que vous ne l'avez pas essayé?

En général, un pare-feu, comme je l'ai déjà dit, est une chose compliquée, et il fonctionne bien avec les vulnérabilités connues et les solutions testées, mais si vous envoyez quelque chose d'inhabituel, juste des ordures ou des paquets avec des en-têtes incorrects, alors vous avec certains avec une si petite probabilité (basée sur mon expérience), vous pouvez introduire un équipement haut de gamme dans une stupeur. Par conséquent, à l'étape 2, en utilisant des listes de contrôle d'accès régulières (au niveau L3 / L4), autorisez uniquement le trafic à entrer dans votre réseau.

Filtrage du trafic du pare-feu

Nous continuons la conversation sur le pare-feu. Vous devez comprendre que les attaques DOS / DDOS ne sont qu'un type de cyberattaque.

En plus de la protection DOS / DDOS, nous pouvons toujours avoir quelque chose comme la liste de fonctionnalités suivante:

• pare-feu d'application
• prévention des menaces (antivirus, anti-spyware et vulnérabilité)
• Filtrage d'URL
• filtrage des données (filtrage de contenu)
• blocage de fichiers (blocage de types de fichiers)

C'est à vous de voir ce dont vous avez besoin dans cette liste.

À suivre