Cet article est le quatrième de la série « Comment prendre le contrôle de votre infrastructure réseau ». Le contenu de tous les articles de la série et les liens peuvent être trouvés .
В Dans ce chapitre, nous avons examiné certains aspects de la sécurité des réseaux dans le segment des centres de données. Cette partie sera consacrée au segment « Accès Internet ».
Accès Internet
Le thème de 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é, j'examinerai ici des questions assez simples, mais, à mon avis, 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 sur le pare-feu
Conception
À titre d'exemple de conception de ce segment pour un réseau d'entreprise, je recommanderais de Cisco à l'intérieur .
Bien sûr, peut-être que la solution d'autres fournisseurs vous semblera plus attractive (voir. ), mais sans vous encourager à suivre cette conception en détail, je trouve quand même utile de comprendre les principes et les idées qui la sous-tendent.
Note:
Dans SAFE, le segment « Accès à distance » fait partie du segment « Accès Internet ». Mais dans cette série d’articles, nous l’examinerons séparément.
L'ensemble standard d'équipements dans ce segment pour un réseau d'entreprise est
- routeurs frontaliers
- pare-feu
Note 1
Dans cette série d'articles, quand je parle de pare-feu, je veux dire .
Note 2
J'omets de prendre en compte les différents types de solutions L2/L1 ou de superposition L2 sur L3 nécessaires pour assurer la connectivité L1/L2 et me limite uniquement aux problèmes au niveau L3 et au-dessus. En partie, les problèmes L1/L2 ont été abordés dans le chapitre ««.
Si vous n'avez pas trouvé de pare-feu dans ce segment, ne vous précipitez pas pour tirer des conclusions.
Faisons la même chose que dans Commençons 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 appliquer des algorithmes complexes de filtrage du trafic. DANS Nous avons mentionné 4 facteurs pouvant interférer avec l'utilisation de pare-feu dans le segment des centres de données. Mais ici, ils ne sont plus aussi importants.
Exemple 1. Retardé
En ce qui concerne Internet, cela n'a aucun sens de parler de retards, même d'environ 1 milliseconde. Le retard sur ce segment ne peut donc pas être un facteur limitant l’utilisation du pare-feu.
Exemple 2. Performance
Dans certains cas, ce facteur peut encore être important. Par conséquent, vous devrez peut-être autoriser une partie du trafic (par exemple, le trafic des équilibreurs de charge) à contourner le pare-feu.
Exemple 3. Fiabilité
Ce facteur doit encore être pris en compte, mais néanmoins, étant donné le manque de fiabilité d'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 repose sur http/https (avec de courtes sessions). Dans ce cas, vous pouvez utiliser deux boitiers indépendants (sans HA) et s'il y a un problème de routage avec l'un d'eux, transférer tout le trafic vers le second.
Vous pouvez également utiliser des pare-feu en mode transparent et, s'ils échouent, permettre au trafic de contourner le pare-feu tout en résolvant le problème.
Par conséquent, il est fort probable que prix C'est peut-être le facteur qui vous obligera à abandonner l'utilisation de pare-feu dans ce segment.
Important!
Il est tentant de combiner ce pare-feu avec le pare-feu du centre de données (utilisez un pare-feu pour ces segments). La solution est, en principe, possible, mais il faut le comprendre car Un pare-feu d'accès Internet est en fait à l'avant-garde de votre défense et « prend en charge » au moins une partie du trafic malveillant, alors, 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 toujours, vous devez comprendre qu'en fonction du service fourni par l'entreprise, la conception de ce segment peut varier considérablement. Comme toujours, vous pouvez choisir différentes approches en fonction de vos besoins.
Exemple
Si vous êtes un fournisseur de contenu, disposant d'un réseau CDN (voir par exemple, ), alors vous ne souhaiterez peut-être pas créer une infrastructure sur des dizaines, voire des centaines de points de présence en utilisant des appareils distincts pour acheminer et filtrer le trafic. Cela coûtera cher et pourrait être tout simplement inutile.
Pour BGP, vous n'avez pas nécessairement besoin de routeurs dédiés, vous pouvez utiliser des outils open source comme . Alors peut-être que tout ce dont vous avez besoin est un ou plusieurs serveurs, un commutateur et BGP.
Dans ce cas, votre serveur ou plusieurs serveurs peuvent jouer le rôle non seulement de serveur CDN, mais aussi de routeur. Bien sûr, il reste encore beaucoup de détails (comme comment assurer l’équilibrage), mais c’est faisable, et c’est une approche que nous avons utilisée avec succès pour l’un de nos partenaires.
Vous pouvez disposer de plusieurs centres de données avec une protection complète (pare-feu, services de protection DDOS fournis par vos fournisseurs Internet) et de dizaines ou centaines de points de présence « simplifiés » avec uniquement des commutateurs et des serveurs L2.
Mais qu’en est-il de la protection dans ce cas ?
Regardons, par exemple, le récemment populaire . 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.
Qu'avons-nous dans le cas de notre conception.
- si vous utilisez AnyCast, alors le trafic est réparti entre vos points de présence. Si votre bande passante totale est de térabits, cela en soi (cependant, il y a eu récemment plusieurs attaques avec du trafic malveillant de l'ordre de térabits) vous protège des liaisons montantes « débordantes ».
- Si, toutefois, certaines liaisons montantes sont obstruées, vous supprimez simplement ce site du service (arrêtez de faire la publicité du préfixe)
- vous pouvez également augmenter la part du trafic envoyé depuis vos centres de données « complets » (et donc protégés), supprimant ainsi une part importante du trafic malveillant des points de présence non protégés
Et encore une petite note à cet exemple. Si vous envoyez suffisamment de trafic via les IX, cela réduit également votre vulnérabilité à de telles attaques.
Configuration de BGP
Il y a deux sujets ici.
- Connectivité
- Configuration de BGP
Nous avons déjà parlé un peu de connectivité dans . Le but est de garantir que le trafic vers vos clients suit le chemin optimal. Bien que l’optimalité ne soit pas toujours une question de latence, une faible latence est généralement le principal indicateur d’optimalité. Pour certaines entreprises, c’est plus important, pour d’autres, c’est moins. Tout dépend du service que vous fournissez.
Exemple 1
Si vous êtes une bourse et que des intervalles de temps inférieurs à la milliseconde sont importants pour vos clients, alors, bien sûr, il ne peut être question d'aucun type d'Internet.
Exemple 2
Si vous êtes une société de jeux et que les 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 en rapprochant les serveurs de distribution de contenu du consommateur de ce contenu.
L’étude de la connectivité est un sujet intéressant en soi, digne d’un article ou d’une série d’articles, et nécessite une bonne compréhension du « fonctionnement » d’Internet.
Ressources utiles :
Exemple
Je vais donner juste un petit exemple.
Supposons que votre centre de données soit situé à Moscou et que vous disposiez d'une seule liaison montante - Rostelecom (AS12389). Dans ce cas (hébergement unique), vous n'avez pas besoin de BGP et vous utilisez très probablement le pool d'adresses de Rostelecom comme adresses publiques.
Supposons que vous fournissez un certain service et que vous ayez un nombre suffisant de clients ukrainiens qui se plaignent de longs retards. Lors de vos recherches, vous avez découvert que les adresses IP de certains d’entre eux se trouvent dans la grille 37.52.0.0/21.
En exécutant un traceroute, vous avez vu que le trafic passait par AS1299 (Telia), et en exécutant un ping, vous avez obtenu un RTT moyen de 70 à 80 millisecondes. Vous pouvez également le voir sur .
À l'aide de 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).
Ensuite, en allant à vous voyez que AS6849 n'a aucune relation avec AS12389 (ils ne sont ni clients ni liaisons montantes les uns vers les autres, et n'ont pas non plus de peering). Mais si tu regardes pour AS6849, vous verrez par exemple AS29226 (Mastertel) et AS31133 (Megafon).
Une fois que vous avez trouvé le miroir de ces fournisseurs, vous pouvez comparer le chemin et le RTT. Par exemple, pour Mastertel, RTT sera d'environ 30 millisecondes.
Ainsi, si la différence entre 80 et 30 millisecondes est significative pour votre service, vous devez peut-être penser à la connectivité, obtenir votre numéro AS, votre pool d'adresses auprès de 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 vous maintenez également votre connexion Internet de manière redondante.
contient des recommandations pour la configuration de BGP. Bien que ces recommandations aient été élaborées sur la base des « meilleures pratiques » des fournisseurs, elles sont néanmoins sans aucun doute utiles (si vos paramètres BGP ne sont pas tout à fait basiques) et devraient en fait faire partie du durcissement dont nous avons parlé dans .
Protection DOS/DDOS
Les attaques DOS/DDOS sont désormais devenues une réalité quotidienne pour de nombreuses entreprises. En fait, vous êtes assez souvent attaqué sous une forme ou une autre. Le fait que vous ne l'ayez pas encore remarqué signifie simplement qu'une attaque ciblée n'a pas encore été organisée contre vous, et que les mesures de protection que vous utilisez, même peut-être sans le savoir (diverses protections intégrées aux systèmes d'exploitation), suffisent à veillez à ce que la dégradation du service fourni soit minimisée pour vous et vos clients.
Il existe des ressources Internet qui, à partir des journaux des équipements, dessinent de belles cartes d'attaques en temps réel.
vous pouvez trouver des liens vers eux.
Mon préféré de CheckPoint.
La protection contre DDOS/DOS est généralement multicouche. Pour comprendre pourquoi, vous devez comprendre quels types d'attaques DOS/DDOS existent (voir, par exemple, ou )
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 en utilisant, par exemple, des pare-feu, alors vous ne pouvez pas vous protéger contre les attaques visant à « submerger » vos liaisons montantes (bien sûr, si votre capacité totale de canaux Internet n'est pas calculée en térabits, ou mieux encore, en dizaines de térabits).
Par conséquent, la première ligne de défense est la protection contre les attaques « volumétriques », et votre ou vos prestataires doivent vous fournir cette protection. Si vous ne l'avez pas encore réalisé, alors vous avez de la chance pour le moment.
Exemple
Disons que vous disposez de plusieurs liaisons montantes, mais qu'un seul des fournisseurs peut vous offrir 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é lors de 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 pour que le trafic passe uniquement par le fournisseur qui vous fournit le « parapluie ». Une fois l'attaque terminée, vous pouvez remettre le routage à son état précédent
- Il n'est pas nécessaire de transférer tout le trafic. Si, par exemple, vous constatez qu'il n'y a pas d'attaques via certaines liaisons montantes ou peerings (ou si le trafic n'est pas important), vous pouvez continuer à annoncer des préfixes avec des attributs compétitifs vers ces voisins BGP.
Vous pouvez également déléguer la protection contre les « attaques de protocole » et les « attaques d’applications » à vos partenaires.
Ici vous pouvez lire une bonne étude (). Certes, l'article date de deux ans, mais il vous donnera une idée des approches permettant de vous protéger contre les attaques DDOS.
En principe, vous pouvez vous limiter à cela en externalisant totalement votre protection. Cette décision présente des avantages, mais elle présente également un inconvénient évident. Le fait est que l’on peut parler (encore une fois, selon ce que fait votre entreprise) de la survie de l’entreprise. Et confiez de telles choses à des tiers...
Voyons donc comment organiser les deuxième et troisième lignes de défense (en complément de la protection du fournisseur).
Ainsi, la deuxième ligne de défense est le filtrage et les limiteurs de trafic (policers) à l'entrée de votre réseau.
Exemple 1
Supposons que vous vous soyez couvert d'une protection contre les DDOS avec l'aide de l'un des fournisseurs. Supposons que ce fournisseur utilise Arbor pour filtrer le trafic et filtre à la périphérie de son réseau.
La bande passante qu'Arbour peut « traiter » est limitée et le fournisseur, bien entendu, ne peut pas constamment faire passer le trafic de tous ses partenaires qui commandent ce service via des équipements de filtrage. Par conséquent, dans des conditions normales, le trafic n’est pas filtré.
Supposons qu'il y ait une attaque par inondation SYN. Même si vous avez commandé un service qui bascule automatiquement le trafic vers le filtrage en cas d'attaque, cela ne se produit pas instantanément. Pendant une minute ou plus, vous restez attaqué. Et cela peut entraîner une panne de votre équipement ou une dégradation du service. Dans ce cas, limiter le trafic au niveau du routage périphérique, même si cela entraînera le fait que certaines sessions TCP ne seront pas établies pendant ce temps, évitera à votre infrastructure des problèmes à plus grande échelle.
Exemple 2
Un nombre anormalement élevé de paquets SYN peut ne pas être uniquement le résultat d’une attaque par inondation SYN. Supposons que vous fournissiez un service dans lequel vous pouvez disposer simultanément d'environ 100 XNUMX connexions TCP (vers un centre de données).
Disons qu'à la suite d'un problème à court terme avec l'un de vos principaux fournisseurs, la moitié de vos sessions sont interrompues. Si votre application est conçue de telle manière que, sans y réfléchir à deux fois, elle essaie immédiatement (ou après un certain intervalle de temps identique pour toutes les sessions) de rétablir la connexion, alors vous recevrez au moins 50 XNUMX paquets SYN environ simultanément.
Si, par exemple, vous devez exécuter une négociation ssl/tls en plus de ces sessions, ce qui implique l'échange de certificats, alors du point de vue de l'épuisement des ressources de votre équilibreur de charge, ce sera un « DDOS » beaucoup plus puissant qu'un simple Inondation SYN. Il semblerait que les équilibreurs devraient gérer de tels événements, mais... malheureusement, nous sommes confrontés à un tel problème.
Et bien sûr, un régulateur sur le routeur périphérique sauvegardera é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 attaques des deuxième et troisième types. En général, tout ce qui atteint le pare-feu peut être filtré ici.
Conseil
Essayez de donner le moins de travail possible au pare-feu, en filtrant autant que possible sur les deux premières lignes de défense. Et c'est pourquoi.
Vous est-il déjà arrivé que par hasard, en générant du trafic pour vérifier, par exemple, la résistance du système d'exploitation de vos serveurs aux attaques DDOS, vous ayez « tué » votre pare-feu en le chargeant à 100 %, avec un trafic à intensité normale ? ? Sinon, c'est peut-être simplement parce que vous n'avez pas essayé ?
En général, un pare-feu, comme je l'ai dit, est une chose complexe, et il fonctionne bien avec des vulnérabilités connues et des solutions testées, mais si vous envoyez quelque chose d'inhabituel, juste des déchets ou des paquets avec des en-têtes incorrects, alors vous êtes avec certains, pas avec avec une si faible probabilité (d'après mon expérience), vous pouvez stupéfier même un équipement haut de gamme. Par conséquent, à l’étape 2, en utilisant des ACL standard (au niveau L3/L4), autorisez uniquement le trafic dans votre réseau qui devrait y entrer.
Filtrage du trafic sur le pare-feu
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 également avoir quelque chose comme la liste de fonctionnalités suivante :
- pare-feu d'applications
- prévention des menaces (antivirus, anti-spyware et vulnérabilité)
- Filtrage d'URL
- filtrage des données (filtrage de contenu)
- blocage de fichiers (blocage des types de fichiers)
C'est à vous de décider ce dont vous avez besoin dans cette liste.
se poursuivre
Source: habr.com