Cet article est le troisième d'une série d'articles « 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 .
Il ne sert à rien de parler d’élimination complète des risques de sécurité. En principe, on ne peut pas les réduire à zéro. Nous devons également comprendre qu’à mesure que nous nous efforçons de rendre le réseau de plus en plus sécurisé, nos solutions deviennent de plus en plus coûteuses. Vous devez trouver un compromis entre coût, complexité et sécurité qui soit adapté à votre réseau.
Bien entendu, la conception de la sécurité est organiquement intégrée à l'architecture globale et les solutions de sécurité utilisées affectent l'évolutivité, la fiabilité, la gérabilité, ... de l'infrastructure réseau, qui doivent également être prises en compte.
Mais permettez-moi de vous rappeler qu'il ne s'agit plus désormais de créer un réseau. Selon nos nous avons déjà choisi la conception, sélectionné les équipements et créé l'infrastructure, et à ce stade, si possible, nous devons « vivre » et trouver des solutions dans le contexte de l'approche préalablement choisie.
Notre tâche consiste désormais à identifier les risques liés à la sécurité au niveau du réseau et à les réduire à un niveau raisonnable.
Audit de sécurité du réseau
Si votre organisation a mis en œuvre des processus ISO 27k, les audits de sécurité et les modifications du réseau doivent s'intégrer parfaitement aux processus globaux de cette approche. Mais ces normes ne concernent toujours pas des solutions spécifiques, ni une configuration, ni une conception... Il n'y a pas de conseils clairs, pas de normes dictant en détail à quoi devrait ressembler votre réseau, c'est là toute la complexité et la beauté de cette tâche.
Je voudrais souligner plusieurs audits de sécurité réseau possibles :
- audit de configuration des équipements (durcissement)
- audit de conception de sécurité
- vérification des accès
- audit de processus
Audit de configuration des équipements (durcissement)
Il semble que dans la plupart des cas, ce soit le meilleur point de départ pour auditer et améliorer la sécurité de votre réseau. À mon humble avis, c'est une bonne démonstration de la loi de Pareto (20 % de l'effort produit 80 % du résultat, et les 80 % d'effort restants ne produisent que 20 % du résultat).
En fin de compte, nous recevons généralement des recommandations de la part des fournisseurs concernant les « meilleures pratiques » en matière de sécurité lors de la configuration des équipements. C’est ce qu’on appelle le « durcissement ».
Vous pouvez aussi souvent trouver un questionnaire (ou en créer un vous-même) basé sur ces recommandations, qui vous aidera à déterminer dans quelle mesure la configuration de vos équipements est conforme à ces « bonnes pratiques » et, en fonction du résultat, à apporter des modifications à votre réseau. . Cela vous permettra de réduire considérablement les risques de sécurité assez facilement et pratiquement sans frais.
Plusieurs exemples pour certains systèmes d'exploitation Cisco.
Sur la base de ces documents, une liste d'exigences de configuration pour chaque type d'équipement peut être créée. Par exemple, pour un VDC Cisco N7K, ces exigences peuvent ressembler à .
De cette manière, des fichiers de configuration peuvent être créés pour différents types d'équipements actifs dans votre infrastructure réseau. Ensuite, manuellement ou en utilisant l'automatisation, vous pouvez « télécharger » ces fichiers de configuration. La manière d'automatiser ce processus sera abordée en détail dans une autre série d'articles sur l'orchestration et l'automatisation.
Audit de conception de sécurité
En règle générale, un réseau d'entreprise contient les segments suivants sous une forme ou une autre :
- DC (DMZ des services publics et centre de données Intranet)
- Accès Internet
- VPN d'accès à distance
- Bordure WAN
- Branche
- Campus (Bureau)
- Core
Titres tirés de modèle, mais il n'est pas nécessaire, bien entendu, de s'attacher précisément à ces noms et à ce modèle. Pourtant, je veux parler de l'essentiel et ne pas m'enliser dans les formalités.
Pour chacun de ces segments, les exigences de sécurité, les risques et, par conséquent, les solutions seront différents.
Examinons chacun d'eux séparément pour les problèmes que vous pouvez rencontrer du point de vue de la conception de la sécurité. Bien sûr, je répète encore une fois que cet article ne prétend en aucun cas être complet, ce qui n'est pas facile (voire impossible) à réaliser dans ce sujet vraiment profond et multiforme, mais il reflète mon expérience personnelle.
Il n’existe pas de solution parfaite (du moins pas encore). C'est toujours un compromis. Mais il est important que la décision d’utiliser une approche ou une autre soit prise consciemment, en comprenant à la fois ses avantages et ses inconvénients.
Centre de données
Le segment le plus critique du point de vue de la sécurité.
Et comme d’habitude, il n’existe pas non plus de solution universelle. Tout dépend fortement des exigences du réseau.
Un pare-feu est-il nécessaire ou non ?
Il semblerait que la réponse soit évidente, mais tout n’est pas aussi clair qu’il y paraît. Et votre choix peut être influencé non seulement prix.
Exemple 1. Des retards.
Si une faible latence est une exigence essentielle entre certains segments du réseau, ce qui est par exemple le cas dans le cas d'un échange, alors nous ne pourrons pas utiliser de pare-feu entre ces segments. Il est difficile de trouver des études sur la latence des pare-feu, mais peu de modèles de commutateurs peuvent fournir une latence inférieure ou de l'ordre de 1 mksec. Je pense donc que si les microsecondes sont importantes pour vous, alors les pare-feu ne sont pas pour vous.
Exemple 2. Performance.
Le débit des principaux commutateurs L3 est généralement d’un ordre de grandeur supérieur à celui des pare-feu les plus puissants. Par conséquent, dans le cas d’un trafic à haute intensité, vous devrez probablement également autoriser ce trafic à contourner les pare-feu.
Exemple 3. Fiabilité.
Les pare-feu, en particulier les NGFW (Next-Generation FW) modernes, sont des dispositifs complexes. Ils sont beaucoup plus complexes que les commutateurs L3/L2. Ils offrent un grand nombre de services et d'options de configuration, il n'est donc pas surprenant que leur fiabilité soit bien moindre. Si la continuité du service est essentielle pour le réseau, vous devrez peut-être choisir ce qui mènera à une meilleure disponibilité : la sécurité avec un pare-feu ou la simplicité d'un réseau construit sur des commutateurs (ou divers types de structures) utilisant des ACL classiques.
Dans le cas des exemples ci-dessus, vous devrez très probablement (comme d'habitude) trouver un compromis. Recherchez les solutions suivantes :
- si vous décidez de ne pas utiliser de pare-feu à l'intérieur du centre de données, vous devez alors réfléchir à la manière de limiter autant que possible l'accès autour du périmètre. Par exemple, vous pouvez ouvrir uniquement les ports nécessaires depuis Internet (pour le trafic client) et l'accès administratif au centre de données uniquement à partir d'hôtes de saut. Sur les hôtes jump, effectuez toutes les vérifications nécessaires (authentification/autorisation, antivirus, journalisation, ...)
- vous pouvez utiliser une partition logique du réseau du centre de données en segments, similaire au schéma décrit dans PSEFABRIC . Dans ce cas, le routage doit être configuré de manière à ce que le trafic sensible au retard ou à haute intensité passe « à l'intérieur » d'un segment (dans le cas de p002, VRF) et ne traverse pas le pare-feu. Le trafic entre les différents segments continuera de passer par le pare-feu. Vous pouvez également utiliser la fuite de route entre les VRF pour éviter de rediriger le trafic via le pare-feu.
- Vous pouvez également utiliser un pare-feu en mode transparent et uniquement pour les VLAN où ces facteurs (latence/performance) ne sont pas significatifs. Mais vous devez étudier attentivement les restrictions associées à l'utilisation de ce mod pour chaque fournisseur.
- vous souhaiterez peut-être envisager d’utiliser une architecture de chaîne de services. Cela permettra uniquement au trafic nécessaire de passer à travers le pare-feu. Cela a l'air sympa en théorie, mais je n'ai jamais vu cette solution en production. Nous avons testé la chaîne de services pour Cisco ACI/Juniper SRX/F5 LTM il y a environ 3 ans, mais à cette époque cette solution nous paraissait « grossière ».
Niveau de protection
Vous devez maintenant répondre à la question de savoir quels outils vous souhaitez utiliser pour filtrer le trafic. Voici quelques-unes des fonctionnalités habituellement présentes dans NGFW (par exemple, ):
- pare-feu avec état (par défaut)
- 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)
- protection dos
Et tout n’est pas clair non plus. Il semblerait que plus le niveau de protection est élevé, mieux c'est. Mais il faut aussi considérer que
- Plus vous utilisez les fonctions de pare-feu ci-dessus, plus cela sera naturellement cher (licences, modules supplémentaires)
- l'utilisation de certains algorithmes peut réduire considérablement le débit du pare-feu et également augmenter les délais, voir par exemple
- comme toute solution complexe, l'utilisation de méthodes de protection complexes peut réduire la fiabilité de votre solution, par exemple, lors de l'utilisation du pare-feu applicatif, j'ai rencontré le blocage de certaines applications de travail assez classiques (dns, smb)
Comme toujours, vous devez trouver la meilleure solution pour votre réseau.
Il est impossible de répondre définitivement à la question de savoir quelles fonctions de protection peuvent être requises. D’abord parce que cela dépend bien sûr des données que vous transmettez ou stockez et que vous essayez de protéger. Deuxièmement, en réalité, le choix des outils de sécurité est souvent une question de confiance dans le fournisseur. Vous ne connaissez pas les algorithmes, vous ne savez pas à quel point ils sont efficaces et vous ne pouvez pas les tester complètement.
Par conséquent, dans les segments critiques, une bonne solution peut consister à utiliser les offres de différentes entreprises. Par exemple, vous pouvez activer l'antivirus sur le pare-feu, mais également utiliser une protection antivirus (d'un autre fabricant) localement sur les hôtes.
Segmentation
Nous parlons de la segmentation logique du réseau des centres de données. Par exemple, le partitionnement en VLAN et sous-réseaux est également une segmentation logique, mais nous ne la considérerons pas en raison de son évidence. Segmentation intéressante prenant en compte des entités telles que les zones de sécurité FW, les VRF (et leurs analogues par rapport à divers fournisseurs), les périphériques logiques (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...
Un exemple d'une telle segmentation logique et de la conception de centre de données actuellement en demande est donné dans .
Après avoir défini les parties logiques de votre réseau, vous pouvez ensuite décrire comment le trafic se déplace entre les différents segments, sur quels appareils le filtrage sera effectué et par quels moyens.
Si votre réseau ne dispose pas d'une partition logique claire et que les règles d'application des politiques de sécurité pour les différents flux de données ne sont pas formalisées, cela signifie que lorsque vous ouvrez tel ou tel accès, vous êtes obligé de résoudre ce problème, et avec une forte probabilité vous le résoudra à chaque fois différemment.
Souvent, la segmentation est basée uniquement sur les zones de sécurité FW. Ensuite, vous devez répondre aux questions suivantes :
- de quelles zones de sécurité avez-vous besoin
- quel niveau de protection souhaitez-vous appliquer à chacune de ces zones
- le trafic intra-zone sera-t-il autorisé par défaut ?
- sinon, quelles politiques de filtrage du trafic seront appliquées dans chaque zone
- quelles politiques de filtrage du trafic seront appliquées pour chaque paire de zones (source/destination)
TCAM
Un problème courant est l'insuffisance de TCAM (Ternary Content Addressable Memory), à la fois pour le routage et pour les accès. À mon humble avis, c'est l'un des problèmes les plus importants lors du choix de l'équipement, vous devez donc traiter ce problème avec le degré de soin approprié.
Exemple 1. Table de transfert TCAM.
Considérons pare-feu
Nous voyons que la taille de la table de transfert IPv4* = 32 Ko
De plus, ce nombre de routes est commun à tous les VSYS.Supposons que, selon votre conception, vous décidez d'utiliser 4 VSYS.
Chacun de ces VSYS est connecté via BGP à deux PE MPLS du cloud que vous utilisez comme BB. Ainsi, 4 VSYS échangent toutes les routes spécifiques entre eux et disposent d'une table de transfert avec approximativement les mêmes ensembles de routes (mais des NH différents). Parce que chaque VSYS a 2 sessions BGP (avec les mêmes paramètres), puis chaque route reçue via MPLS a 2 NH et, par conséquent, 2 entrées FIB dans la table de transfert. Si nous supposons qu'il s'agit du seul pare-feu du centre de données et qu'il doit connaître toutes les routes, cela signifie que le nombre total de routes dans notre centre de données ne peut pas dépasser 32 4/(2 * 4) = XNUMX XNUMX.Maintenant, si nous supposons que nous avons 2 centres de données (avec la même conception) et que nous voulons utiliser des VLAN « étirés » entre les centres de données (par exemple, pour vMotion), alors pour résoudre le problème de routage, nous devons utiliser des routes hôtes. . Mais cela signifie que pour 2 centres de données, nous n'aurons pas plus de 4096 hôtes possibles et, bien sûr, cela pourrait ne pas suffire.
Exemple 2. ACL TCAM.
Si vous envisagez de filtrer le trafic sur les commutateurs L3 (ou d'autres solutions utilisant des commutateurs L3, par exemple Cisco ACI), vous devez faire attention à l'ACL TCAM lors du choix de l'équipement.
Supposons que vous souhaitiez contrôler l'accès aux interfaces SVI du Cisco Catalyst 4500. Ensuite, comme le montre , pour contrôler le trafic sortant (ainsi que entrant) sur les interfaces, vous ne pouvez utiliser que 4096 lignes TCAM. Ce qui, en utilisant TCAM3, vous donnera environ 4000 XNUMX XNUMX ACE (lignes ACL).
Si vous êtes confronté au problème d'un TCAM insuffisant, vous devez tout d'abord, bien sûr, envisager la possibilité d'une optimisation. Ainsi, en cas de problème avec la taille de la Forwarding Table, vous devez envisager la possibilité de regrouper les routes. En cas de problème avec la taille TCAM des accès, auditez les accès, supprimez les enregistrements obsolètes et qui se chevauchent, et éventuellement révisez la procédure d'ouverture des accès (cela sera discuté en détail dans le chapitre sur l'audit des accès).
Haute Disponibilité
La question est : dois-je utiliser HA pour les pare-feu ou installer deux boîtiers indépendants « en parallèle » et, si l’un d’eux tombe en panne, acheminer le trafic via le second ?
Il semblerait que la réponse soit évidente : utilisez HA. La raison pour laquelle cette question se pose encore est que, malheureusement, les prévisions théoriques et publicitaires ainsi que plusieurs pourcentages décimaux d'accessibilité dans la pratique s'avèrent malheureusement loin d'être aussi roses. La haute disponibilité est logiquement une chose assez complexe, et sur différents équipements et avec différents fournisseurs (il n'y a eu aucune exception), nous avons détecté des problèmes, des bugs et des arrêts de service.
Si vous utilisez HA, vous aurez la possibilité de désactiver des nœuds individuels, de basculer entre eux sans arrêter le service, ce qui est important, par exemple, lors des mises à niveau, mais en même temps, vous avez une probabilité loin d'être nulle que les deux nœuds se brisera en même temps, et aussi que la prochaine mise à niveau ne se déroulera pas aussi bien que le promet le fournisseur (ce problème peut être évité si vous avez la possibilité de tester la mise à niveau sur du matériel de laboratoire).
Si vous n'utilisez pas HA, alors du point de vue de la double panne vos risques sont bien moindres (puisque vous disposez de 2 pare-feu indépendants), mais puisque... les sessions ne sont pas synchronisées, alors chaque fois que vous basculez entre ces pare-feu, vous perdrez du trafic. Vous pouvez bien sûr utiliser un pare-feu sans état, mais l’intérêt d’utiliser un pare-feu est alors largement perdu.
Par conséquent, si à la suite de l'audit vous avez découvert des pare-feu isolés et que vous envisagez d'augmenter la fiabilité de votre réseau, alors la haute disponibilité est bien sûr l'une des solutions recommandées, mais vous devez également prendre en compte les inconvénients associés. avec cette approche et, peut-être, spécifiquement pour votre réseau, une autre solution serait plus adaptée.
Gérabilité
En principe, HA est aussi une question de contrôlabilité. Au lieu de configurer 2 boîtiers séparément et de résoudre le problème de la synchronisation des configurations, vous les gérez comme si vous n'aviez qu'un seul appareil.
Mais peut-être avez-vous de nombreux centres de données et de nombreux pare-feu, alors cette question se pose à un nouveau niveau. Et la question ne concerne pas seulement la configuration, mais aussi
- configurations de sauvegarde
- mises à jour
- mises à niveau
- surveillance
- enregistrement
Et tout cela peut être résolu par des systèmes de gestion centralisés.
Ainsi, par exemple, si vous utilisez des pare-feu Palo Alto, alors est une telle solution.
A suivre.
Source: habr.com