Cet article est le quatrième de la série d'articles « Comment prendre le contrôle de votre infrastructure réseau ». Vous pouvez trouver le contenu de tous les articles de la série et les liens. .
Dans Dans ce chapitre, nous avons examiné certains aspects de la sécurité réseau du segment « Data Center ». Cette partie sera consacrée au segment « Internet Access ».
Accès Internet
Le sujet de la sécurité est sans aucun doute l'un des plus complexes du monde des réseaux de transmission de données. Comme dans les cas précédents, sans prétendre à une profondeur ou une exhaustivité, je vais ici aborder des questions relativement simples, mais, à mon avis importantes, dont les réponses, je l'espère, contribueront à améliorer la sécurité de votre réseau.
Lors de l'audit de ce segment, portez une attention particulière aux aspects suivants :
- design
- configurations BGP
- Protection DOS/DDOS
- filtrage du trafic sur le pare-feu
Design
À titre d'exemple de conception de ce segment pour le réseau d'entreprise, je recommanderais de Cisco dans le cadre de .
Bien sûr, il est possible que les solutions d'autres fournisseurs vous paraissent plus attractives (voir ), mais, sans vous inciter à suivre ce modèle dans les détails, je pense qu'il est néanmoins utile de comprendre les principes et les idées qui le sous-tendent.
Remarque
Dans le modèle SAFE, le segment « Remote Access » est une partie de « Internet Access ». Mais dans cette série d'articles, nous allons l'examiner séparément.
L'ensemble standard de matériel dans ce segment pour le réseau d'entreprise est composé de
- routeurs de périmètre (border routers)
- pare-feu
Note 1
Dans cette série d'articles, lorsque je parle de pare-feu, je fais référence à .
Note 2
Je ne traiterai pas des différents types de solutions L2/L1 ou des solutions L2 sur L3 nécessaires pour assurer la connectivité L1/L2 et je me limiterai aux questions de niveau L3 et supérieur. En partie, les questions L1/L2 ont été abordées dans le chapitre ««.
Si vous n'avez pas trouvé de pare-feu dans ce segment, ne soyez pas trop rapide à tirer des conclusions.
Voyons, comme dans , commençons par la question : est-il nécessaire d'utiliser un pare-feu dans ce segment dans votre cas ?
Je peux dire qu'il semble que ce soit l'endroit le plus justifié pour l'utilisation de pare-feu et pour l'application d'algorithmes complexes de filtrage du trafic. Dans nous avons mentionné 4 facteurs qui peuvent entraver l'utilisation de pare-feu dans le segment des centres de données. Mais ici, ils sont déjà moins significatifs.
Exemple 1. Latence
En ce qui concerne Internet, il n'est pas pertinent de parler de latences même de l'ordre de 1 milliseconde. Par conséquent, la latence dans ce segment ne peut pas être un facteur limitant l'utilisation des pare-feu.
Exemple 2. Performance
Dans certains cas, ce facteur peut tout de même être significatif. Il se peut donc que vous deviez diriger une partie du trafic (par exemple, le trafic des équilibreurs de charge) en contournant le pare-feu.
Exemple 3. Fiabilité
Ce facteur doit toujours être pris en compte, mais étant donné l'instabilité propre à Internet, son importance pour ce segment n'est pas aussi significative que pour le centre de données.
Supposons que votre service fonctionne via http/https (avec des sessions courtes). Dans ce cas, vous pouvez utiliser deux boîtiers indépendants (sans HA) et en cas de problème avec l'un d'eux, rediriger tout le trafic vers le second.
Ou vous pouvez utiliser des pare-feu en mode transparent et, lors de leur panne temporaire, laisser le trafic passer en contournant les pare-feu.
Il est donc probable que ce soit uniquement le prix ce facteur qui vous incitera à renoncer à l'utilisation des pare-feu dans ce segment.
Attention !
On est tenté de combiner ce pare-feu avec le pare-feu du centre de données (utiliser un seul pare-feu pour ces segments). Une solution qui est en principe possible, mais il faut comprendre que, puisque le pare-feu « Internet Access » est en fait en première ligne de votre défense et gère au moins une partie du trafic malveillant, il faut bien sûr tenir compte du risque accru que ce pare-feu tombe en panne. En d'autres termes, utiliser les mêmes dispositifs dans ces deux segments réduit considérablement la disponibilité de votre segment de centre de données.
Comme d'habitude, il faut comprendre qu'en fonction du service que l'entreprise fournit, la conception de ce segment peut différer considérablement. Vous pouvez, comme d'habitude, choisir différentes approches en fonction des exigences.
Exemple
Si vous êtes un fournisseur de contenu, avec un réseau CDN (voir par exemple, ), vous pourriez ne pas souhaiter créer une infrastructure de points de présence dans des dizaines, voire des centaines, d'endroits avec l'utilisation de dispositifs séparés pour la routage et le filtrage du trafic. Cela pourrait être coûteux et simplement excessif.
Pour BGP, il n'est pas nécessaire d'avoir des routeurs dédiés, vous pouvez utiliser des outils open-source, par exemple, . Donc, peut-être que tout ce dont vous avez besoin est un serveur 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 y a encore beaucoup de détails (par exemple, comment assurer l'équilibrage), mais c'est réalisable, et cette approche a été appliquée avec succès pour l'un de nos partenaires.
Vous pouvez avoir plusieurs centres de données avec une protection complète (pare-feu, services de protection contre les attaques DDoS fournis par vos fournisseurs d'accès Internet) et des dizaines ou des centaines de points de présence « simplifiés » avec uniquement des commutateurs L2 et des serveurs.
Et qu'en est-il de la protection dans ce cas?
Prenons par exemple l'attaque par amplification DNS, qui est devenue populaire ces derniers temps. . Son danger réside dans le fait qu'une énorme quantité de trafic est générée, ce qui « saturera » à 100 % tous vos uplinks.
Que disposons-nous dans le cas de notre conception.
- si vous utilisez AnyCast, le trafic est réparti entre vos points de présence. Si la bande passante totale est de plusieurs térabits, cela vous protège pratiquement (ces derniers temps, il y a eu plusieurs attaques avec un trafic malveillant d'environ un térabit) d'un « débordement » des uplinks.
- si certains uplinks sont néanmoins « saturés », vous pouvez simplement retirer ce site du service (cesser d'annoncer le préfixe).
- vous pouvez également augmenter la part de trafic provenant de vos centres de données « complets » (et, par conséquent, protégés), éliminant ainsi une grande partie du trafic malveillant provenant de points de présence non protégés.
Et une dernière remarque à ce sujet. Si une quantité suffisante de trafic transit par les IX, cela diminue également votre vulnérabilité à de telles attaques.
Configuration de BGP
Ici, nous avons deux thèmes.
- Connectivité
- Configuration de BGP
Nous avons déjà parlé un peu de la connectivité dans . L'essentiel est que le trafic vers vos clients emprunte le chemin optimal. Cependant, l'optimisation ne concerne pas toujours uniquement la latence, mais la faible latence est généralement le principal indicateur d'optimalité. Pour certaines entreprises, c'est plus important ; pour d'autres, moins. Tout dépend du service que vous offrez.
Exemple 1
Si vous êtes une bourse et que des intervalles de temps inférieurs à la milliseconde sont importants pour vos clients, il est clair qu'aucune discussion sur Internet n'est envisageable.
Exemple 2
Si vous êtes une entreprise de jeux vidéo et que des dizaines de millisecondes sont essentielles pour vous, alors bien sûr, la connectivité est très importante.
Exemple 3
Il est également nécessaire de comprendre que, en raison des propriétés du protocole TCP, la vitesse de transmission des données au sein d'une session TCP dépend également du RTT (Round Trip Time). Les réseaux CDN sont construits en partie pour résoudre ce problème en rapprochant les serveurs de distribution de contenu des consommateurs de ce contenu.
L'étude de la connectivité est un sujet intéressant à part entière, qui mérite un article ou une série d'articles et nécessite une bonne compréhension de la manière dont Internet est "structuré".
Ressources utiles :
Exemple
Je vais donner juste un petit exemple.
Supposons que votre centre de données est situé à Moscou et que vous avez un seul uplink - Rostelecom (AS12389). Dans ce cas (single homed), le BGP n'est pas nécessaire, et vous utilisez probablement un pool d'adresses de Rostelecom pour vos adresses publiques.
Supposons que vous offrez un certain service et que vous avez un nombre suffisant de clients en Ukraine, et qu'ils se plaignent de délais élevés. En enquêtant, vous découvrez que les adresses IP de certains d'entre eux se trouvent dans la plage 37.52.0.0/21.
En effectuant un traceroute, vous voyez que le trafic passe par AS1299 (Telia), et en exécutant un ping, vous obtenez un RTT moyen de 70 à 80 millisecondes. Vous pouvez également le voir sur .
Avec l'outil whois (sur le site 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 sur vous voyez que AS6849 n'a pas de relations avec AS12389 (ils ne sont ni clients ni uplinks l'un pour l'autre, et ils n'ont pas de peering). Mais si vous regardez la pour AS6849, vous verrez, par exemple, AS29226 (Mastertel) et AS31133 (Megafon).
En trouvant le looking glass de ces fournisseurs, vous pouvez comparer le chemin et le RTT. Par exemple, pour Mastertel, le RTT sera d'environ 30 millisecondes.
Donc, si la différence entre 80 et 30 millisecondes est significative pour votre service, il serait peut-être temps de réfléchir à la connectivité, d'obtenir votre numéro AS chez RIPE, votre pool d'adresses et de connecter des uplinks supplémentaires et/ou de créer des points de présence dans les IX.
En utilisant BGP, vous avez non seulement la possibilité d'améliorer la connectivité, mais aussi de sécuriser votre connexion à Internet.
contient des recommandations pour la configuration de BGP. Bien que ces recommandations aient été établies sur la base des « meilleures pratiques » des fournisseurs, elles sont sans aucun doute utiles et devraient en fait faire partie du durcissement dont nous avons discuté dans .
Protection DOS/DDOS
Les attaques DOS/DDoS sont devenues une réalité quotidienne pour de nombreuses entreprises. En réalité, sous une forme ou une autre, vous êtes attaqué assez souvent. Le fait que vous ne le remarquiez pas encore indique simplement qu'aucune attaque ciblée n'a été organisée contre vous, et que les mesures de protection que vous utilisez, même si vous n'en êtes pas conscient (comme les diverses protections intégrées des systèmes d'exploitation), sont suffisantes pour minimiser la dégradation du service pour vous et vos clients.
Il existe des ressources en ligne qui, à partir des journaux de l'équipement, dessinent en temps réel de belles cartes des attaques.
vous pouvez y trouver des liens.
Ma carte préférée La protection contre les attaques DDoS/DOS est généralement en couches. Pour comprendre pourquoi, il est nécessaire de connaître les types d'attaques DOS/DDoS qui existent (voir par exemple,
Nous avons donc trois types d'attaques : ou )
attaques volumétriques
- attaques de protocole
- attaques d'application
- Si vous pouvez vous protéger vous-même contre les deux derniers types d'attaques en utilisant, par exemple, des pare-feu, vous ne pourrez pas vous protéger contre les attaques visant à « saturer » vos uplinks (bien sûr, si votre capacité totale des canaux Internet n'est pas mesurée en térabits, et mieux encore, en dizaines de térabits).
Ainsi, la première ligne de défense est la protection contre les attaques volumétriques, et cette protection doit vous être fournie par votre fournisseur ou vos fournisseurs. Si vous ne l’avez pas encore réalisé, vous avez simplement de la chance jusqu’à présent.
Supposons que vous ayez plusieurs uplinks, mais qu'un seul des fournisseurs puisse 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 discuté précédemment ?
Exemple
Au moment de l'attaque, vous devrez dans ce cas sacrifier en partie la connectivité. Mais
Pendant l'attaque, vous devrez en partie sacrifier la connectivité.
- C'est uniquement pendant une attaque. Vous pouvez, en cas d'attaque, reconfigurer manuellement ou automatiquement le BGP, de sorte que le trafic passe uniquement par le fournisseur qui vous fournit le « parapluie ». Une fois l'attaque terminée, vous pouvez rétablir le routage à son état d'origine.
- Il n'est pas nécessaire de rediriger tout le trafic. Si, par exemple, vous constatez qu'il n'y a pas d'attaques (ou que le trafic n'est pas significatif) via certains uplinks ou peering, vous pouvez continuer à annoncer des préfixes avec des attributs concurrentiels vers ces voisins BGP.
Vous pouvez également confier la protection contre les « attaques de protocoles » et les « attaques d'applications » à des partenaires.
Voici Vous pouvez lire une bonne étude (). Certes, l'article date de deux ans, mais cela vous donnera une idée des approches pour vous protéger contre les attaques DDoS.
En principe, vous pouvez vous limiter à cela en externalisant entièrement votre protection. Cette solution présente des avantages, mais aussi un inconvénient évident. En effet, il peut s'agir (encore une fois selon l'activité de votre entreprise) de la survie de l'entreprise. Faire confiance à de telles choses à des organisations tierces…
Nous allons donc examiner 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 la filtration et les limiteurs de trafic (policers) à l'entrée de votre réseau.
Exemple 1
Supposons que vous soyez « protégé par un parapluie » contre les DDoS grâce à l'un des fournisseurs. Supposons que ce fournisseur utilise Arbor pour filtrer le trafic et des filtres à la frontière de son réseau.
La bande passante que Arbor peut « traiter » est limitée, et le fournisseur ne peut certainement pas laisser passer en permanence le trafic de tous ses partenaires ayant commandé ce service à travers l'équipement de filtrage. Par conséquent, dans des conditions normales, le trafic n'est pas filtré.
Supposons qu'une attaque SYN flood soit en cours. Même si vous avez souscrit à un service qui redirige automatiquement le trafic vers un filtre en cas d'attaque, cela ne se produit pas instantanément. Pendant une minute ou plus, vous restez sous attaque. Cela peut entraîner des pannes de votre matériel ou une dégradation du service. Dans ce cas, la limitation du trafic au niveau du routage limite, bien qu'elle signifie que certaines sessions TCP ne seront pas établies pendant ce temps, mais cela protégera votre infrastructure de problèmes plus importants.
Exemple 2
Un nombre anormalement élevé de paquets SYN peut être non seulement le résultat d'une attaque SYN flood. Supposons que vous offrez un service qui peut gérer simultanément environ 100 000 connexions TCP (dans un seul centre de données).
Supposons qu'à la suite d'un problème temporaire avec l'un de vos principaux fournisseurs, la moitié de vos sessions ait été 'kickée'. Si votre application est conçue de telle manière qu'elle tente immédiatement (ou après un intervalle de temps identique pour toutes les sessions) de rétablir la connexion, vous recevrez à peu près en même temps au moins 50 000 paquets SYN.
Si, en plus de ces sessions, un ssl/tls handshake doit fonctionner, ce qui implique un échange de certificats, cela constituera un « DDOS » beaucoup plus sévère pour votre répartiteur de charge en termes d'épuisement des ressources qu'un simple SYN flood. On pourrait penser que les répartiteurs de charge devraient gérer de tels événements, mais... malheureusement, nous avons été confrontés à un problème de plein fouet.
Et bien sûr, un policer sur le routeur de bord protégera votre équipement dans ce cas.
Le troisième niveau de protection contre les DDOS/DOS concerne les paramètres de votre pare-feu.
Ici, vous pouvez atténuer à la fois les attaques de deuxième et de troisième type. En général, tout ce qui atteindra le pare-feu pourra être filtré ici.
Conseil
Essayez de donner le moins de travail possible au pare-feu en filtrant autant que possible lors des deux premières lignes de défense. Et voici pourquoi.
Avez-vous déjà rencontré le cas où, en générant du trafic pour vérifier, par exemple, la résistance de votre système d'exploitation serveur aux attaques DDoS, vous avez « tué » votre pare-feu en le surchargeant à 100 % avec un trafic d'intensité normale ? Si ce n'est pas le cas, c'est peut-être simplement parce que vous ne l'avez pas essayé ?
En général, le pare-feu, comme je l'ai déjà dit, est un élément complexe qui fonctionne bien avec des vulnérabilités connues et des solutions éprouvées. Cependant, si vous envoyez quelque chose d'inhabituel, que ce soit des déchets ou des paquets avec des en-têtes incorrects, il y a une probabilité non négligeable (selon mon expérience) que vous puissiez perturber même du matériel haut de gamme. C'est pourquoi, à l'étape 2, avec des ACL classiques (au niveau L3/L4), ne laissez passer dans votre réseau que le trafic qui est censé y entrer.
Filtrage du trafic sur le pare-feu
Continuons notre discussion sur le pare-feu. Il est important de comprendre que les attaques DOS/DDoS ne sont qu'un type d'attaque cybernétique.
En plus de la protection contre les attaques DOS/DDoS, nous pouvons également avoir quelque chose comme la liste suivante de fonctionnalités :
- pare-feu applicatif
- prévention des menaces (antivirus, anti-espion et vulnérabilités)
- filtrage d'URL
- filtrage de données (filtrage de contenu)
- blocage de fichiers (blocage de types de fichiers)
C'est à vous de décider ce dont vous avez besoin dans cette liste.
La suite à suivre
Source : habr.com
