Cet article est le troisième d'une série d'articles intitulée «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 .



Cela n'a aucun sens de parler de l'élimination complète des risques de sécurité. En principe, nous ne pouvons pas les réduire à zéro. Vous devez également comprendre que, comme 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 raisonnable pour votre réseau entre le prix, la complexité et la sécurité.

Bien sûr, la conception de la sécurité est organiquement intégrée dans l'architecture globale et les solutions de sécurité utilisées affectent l'évolutivité, la fiabilité, la gérabilité, ... l'infrastructure réseau, qui doit également être prise en compte.

Mais, je vous rappelle que maintenant nous ne parlons pas de créer un réseau. Conformément à nos conditions initiales , nous avons déjà choisi un design, des équipements sélectionnés, et créé une infrastructure, et à ce stade nous devons, si possible, «vivre» et trouver des solutions dans le cadre de l'approche choisie précédemment.

Notre tâche consiste désormais à identifier les risques liés à la sécurité au niveau du réseau et à les réduire à une valeur raisonnable.

Audit de sécurité réseau

Si votre organisation a mis en œuvre des processus ISO 27k, les audits de sécurité et les changements de réseau doivent être organiquement intégrés dans les processus globaux dans le cadre de cette approche. Mais ces normes ne concernent toujours pas des solutions spécifiques, pas de configuration, pas de conception ... Il n'y a pas de conseils précis, il n'y a pas de normes qui dictent en détail ce que devrait être votre réseau, c'est 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)
• conception d'audit de sécurité
• audit d'accès
• audit de processus

Audit de configuration matérielle (durcissement)

Dans la plupart des cas, cela semble être le meilleur point de départ pour l'audit et l'amélioration de la sécurité de votre réseau. À mon humble avis, il s'agit d'une bonne démonstration de la loi de Pareto (20% de l'effort donne 80% du résultat, et les 80% restants de l'effort ne représentent que 20% du résultat).

L'essentiel est que nous avons généralement des recommandations des fournisseurs concernant les «meilleures pratiques» en matière de sécurité lors de la configuration de l'équipement. C'est ce qu'on appelle le durcissement.

Vous pouvez également souvent trouver un questionnaire (ou le composer vous-même) basé sur ces recommandations, qui vous aidera à déterminer comment votre configuration matérielle correspond à ces «meilleures pratiques» et à apporter des modifications à votre réseau en fonction du résultat. Cela vous permettra de réduire assez facilement, pratiquement gratuitement, les risques de sécurité.

Quelques exemples pour certains systèmes d'exploitation Cisco.

Renforcement de la configuration Cisco IOS
Renforcement de la configuration de Cisco IOS-XR
Renforcement de la configuration de Cisco NX-OS
Liste de vérification de sécurité Cisco Baseline

Sur la base de ces documents, une liste des exigences de configuration pour chaque type d'équipement peut être créée. Par exemple, pour un VDC Cisco N7K, ces exigences peuvent ressembler à ceci .

Ainsi, des fichiers de configuration pour différents types d'équipements actifs de votre infrastructure réseau peuvent être créés. De plus, manuellement ou en utilisant l'automatisation, vous pouvez «télécharger» ces fichiers de configuration. Comment automatiser ce processus sera discuté en détail dans une autre série d'articles sur l'orchestration et l'automatisation.

Conception d'audit de sécurité

En règle générale, un réseau d'entreprise sous une forme ou une autre contient les segments suivants:

• DC (DMZ des services publics et centre de données intranet)
• Accès Internet
• VPN d'accès à distance
• Bord blême
• Succursale
• Campus (bureau)
• Noyau

Les noms sont tirés du modèle Cisco SAFE , mais il n'est pas nécessaire, bien sûr, de se lier à ces noms et à ce modèle. Je veux quand même parler de l'essence et ne pas m'enliser dans les formalités.

Pour chacun de ces segments, les exigences concernant le niveau de sécurité, les risques et, par conséquent, les décisions seront différentes.

Nous considérerons chacun d'eux individuellement pour les problèmes que vous pourriez rencontrer en termes de conception de 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 dans ce sujet vraiment profond et multiforme n'est pas facile à réaliser (si possible), mais reflète mon expérience personnelle.

Il n'y a pas de solution parfaite (du moins pour l'instant). C'est toujours un compromis. Mais il est important que la décision d'appliquer telle ou telle approche soit prise consciemment, en comprenant à la fois ses avantages et ses inconvénients.

Centre de données

Le segment de sécurité le plus critique.
Et, comme d'habitude, il n'y a pas non plus de solution universelle. Tout dépend 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 affecté non seulement par le prix .

Exemple 1. Retards.

Si entre certains segments du réseau une faible latence est une exigence essentielle, ce qui, par exemple, est vrai dans le cas d'un échange, alors entre ces segments nous ne pourrons pas utiliser de pare-feu. Il est difficile de trouver des études sur les retards dans les pare-feu, mais seuls quelques modèles de commutateurs peuvent fournir des retards inférieurs à environ 1 milliseconde, donc je pense que si les microsecondes sont importantes pour vous, les pare-feu ne sont pas pour vous.

Exemple 2. Performances.

La bande passante des commutateurs L3 supérieurs est généralement d'un ordre de grandeur supérieur à la bande passante des pare-feu les plus productifs. Par conséquent, dans le cas d'un trafic à haute intensité, vous devrez très probablement également autoriser ce trafic à contourner les pare-feu.

Exemple 3. Fiabilité.

Les pare-feu, en particulier les NGFW modernes (FW de nouvelle génération) sont des appareils complexes. Ils sont nettement plus complexes que les commutateurs L3 / L2. Ils fournissent un grand nombre de services et d'options de configuration, il n'est donc pas surprenant que leur fiabilité soit beaucoup plus faible. Si la continuité du service est critique pour le réseau, vous devrez peut-être choisir ce qui conduira à une meilleure disponibilité - la sécurité du pare-feu ou la simplicité d'un réseau basé sur des commutateurs (ou différents types d'usines) utilisant des ACL ordinaires.

Dans le cas des exemples ci-dessus, vous devrez probablement (comme d'habitude) trouver un compromis. Regardez vers les solutions suivantes:

• si vous décidez de ne pas utiliser de pare-feu à l'intérieur du centre de données, vous devez réfléchir à la façon de limiter autant que possible l'accès au périmètre. Par exemple, vous ne pouvez ouvrir que les ports nécessaires à partir d'Internet (pour le trafic client) et l'accès administratif au centre de données uniquement à partir des hôtes de saut. Sur les hôtes de saut, effectuez toutes les vérifications nécessaires (authentification / autorisation, antivirus, journalisation, ...)
• vous pouvez utiliser le partitionnement logique du réseau du centre de données en segments, semblable au schéma décrit dans l' exemple P00FABRIC p002 . Dans le même temps, le routage doit être configuré de sorte que le trafic sensible aux retards ou au trafic à haute intensité entre «à l'intérieur» d'un segment (dans le cas de p002, VRF-a) et ne passe pas par le pare-feu. Le trafic entre les différents segments passera toujours 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 le pare-feu en mode transparent et uniquement pour les VLAN où ces facteurs (retard / performances) ne sont pas significatifs. Mais vous devez étudier attentivement les limitations associées à l'utilisation de ce mod pour chaque fournisseur
• vous pourriez envisager d'appliquer une architecture de chaîne de services. Cela vous permettra de diriger uniquement le trafic nécessaire à travers le pare-feu. Il est théoriquement beau, mais je n'ai jamais vu cette solution en production. Nous avons testé la chaîne de service pour Cisco ACI / Juniper SRX / F5 LTM il y a environ 3 ans, mais à cette époque cette solution nous semblait «brute»

Niveau de protection

Vous devez maintenant répondre à la question des outils que vous souhaitez utiliser pour filtrer le trafic. Voici quelques-unes des fonctionnalités généralement présentes dans NGFW (par exemple, ici ):

• pare-feu avec état (par défaut)
• 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)
• protection dos

Et tout n'est pas clair non plus. Il semblerait que plus le niveau de protection est élevé, mieux c'est. Mais vous devez également considérer que

• plus vous utilisez les fonctions de pare-feu ci-dessus, plus cela coûtera naturellement cher (licences, modules supplémentaires)
• l'utilisation de certains algorithmes peut réduire considérablement le débit du pare-feu et augmenter les retards, voir par exemple ici
• 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 d'application, je suis tombé sur le blocage de certaines applications de travail assez standard (dns, smb)

Comme d'habitude, vous devez trouver la meilleure solution pour votre réseau.

Il est impossible de répondre sans ambiguïté à la question de savoir quelles fonctions de protection peuvent être requises. Tout d'abord, car cela dépend bien sûr des données que vous transférez ou stockez et que vous essayez de protéger. Deuxièmement, en réalité, le choix des recours est souvent une question de foi et de confiance envers le vendeur. 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 être d'utiliser les offres de différentes sociétés. Par exemple, vous pouvez activer l'antivirus sur un pare-feu, mais également utiliser la protection antivirus (d'un autre fabricant) localement sur les hôtes.

Segmentation

Il s'agit d'une segmentation logique du réseau du centre de données. Par exemple, la division en VLAN et sous-réseaux est également une segmentation logique, mais nous ne la considérerons pas en raison de son évidence. La segmentation est intéressante compte tenu d'entités telles que les zones de sécurité FW, VRF (et leurs analogues par rapport à divers fournisseurs), les dispositifs logiques (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...

Un exemple d'une telle segmentation logique et de la conception actuellement requise du centre de données est donné en p002 du projet PSEFABRIC .

Après avoir défini les parties logiques de votre réseau, vous pouvez décrire plus en détail comment le trafic circule entre les différents segments, sur quels appareils le filtrage sera effectué et par quels moyens.

Si votre réseau n'a pas de partitionnement logique clair et que les règles d'application des politiques de sécurité pour 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ésolverez à chaque fois de différentes manières.

La segmentation est souvent 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
• information indiquant si le trafic intra-zone sera 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

Il y a souvent le problème de l'insuffisance de TCAM (Ternary Content Addressable Memory), à la fois pour le routage et 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 bon degré de précision.

Exemple 1. Table de transfert TCAM.

Regardons le pare-feu Palo Alto 7k .
Nous voyons que la taille de la table de transfert IPv4 * = 32 Ko
En même temps, ce nombre de routes est commun à tous les VSYS.

Supposons que vous décidiez d'utiliser 4 VSYS selon votre conception.
Chacun de ces VSPS BGPS est connecté à deux PE cloud MPLS que vous utilisez comme BB. Ainsi, 4 VSYS échangent toutes les routes spécifiques les unes avec les autres et ont 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 devrait connaître toutes les routes, cela signifie que le nombre total de routes dans notre centre de données ne peut pas dépasser 32K / (4 * 2) = 4K.

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 itinéraires 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 peut ne pas être suffisant.

Exemple 2. ACL TCAM.

Si vous prévoyez de filtrer le trafic sur les commutateurs L3 (ou d'autres solutions utilisant des commutateurs L3, par exemple, Cisco ACI), vous devez faire attention aux ACL TCAM lors du choix de l'équipement.

Supposons que vous souhaitiez contrôler l'accès sur les interfaces SVI du Cisco Catalyst 4500. Ensuite, comme vous pouvez le voir dans cet article , vous ne pouvez utiliser que 4096 lignes de TCAM pour contrôler le trafic sortant (ainsi que le trafic entrant) sur les interfaces. Ce qui lors de l'utilisation de TCAM3 vous donnera environ 4000 mille ACE (lignes ACL).

Si vous êtes confronté au problème de TCAM insuffisant, alors, tout d'abord, bien sûr, vous devez considérer la possibilité d'optimisation. Donc, en cas de problème avec la taille de la table de transfert, vous devez considérer la possibilité d'agréger les routes. En cas de problème avec la taille TCAM des accès - audit des accès, suppression des enregistrements obsolètes et superposés, ainsi que, éventuellement, révision de la procédure d'ouverture des accès (elle sera discutée en détail dans le chapitre sur l'audit des accès).

Haute disponibilité

La question est de savoir si utiliser HA pour les pare-feu ou de mettre deux boîtiers indépendants «en parallèle» et dans le cas où l'un d'eux se bloque, acheminer le trafic à travers le second?

Il semblerait que la réponse soit évidente - utilisez HA. La raison pour laquelle cette question se pose néanmoins est que, malheureusement, les chiffres théoriques et publicitaires 99 et quelques neuf après la virgule décimale du pourcentage d'accessibilité se révèlent en pratique beaucoup moins rose. HA est logiquement une chose plutôt compliquée, et sur différents équipements, et avec différents fournisseurs (il n'y avait pas d'exceptions), nous avons détecté des problèmes et des bugs et l'arrêt du service.

Dans le cas de l'utilisation de HA, vous pourrez désactiver des nœuds individuels, basculer entre eux sans arrêter le service, ce qui est important, par exemple, lors de la mise à niveau, mais vous avez une probabilité loin d'être nulle que les deux nœuds se cassent en même temps, et aussi que le prochain La mise à niveau ne se fera pas aussi bien que le promet le vendeur (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, du point de vue du double dommage, vos risques sont beaucoup plus faibles (puisque vous avez 2 pare-feu indépendants), mais parce que Étant donné que les sessions ne sont pas synchronisées, chaque fois que le basculement entre ces pare-feu se produit, vous perdrez du trafic. Vous pouvez bien sûr utiliser un pare-feu sans état, mais le sens de l'utilisation d'un pare-feu est alors largement perdu.

Par conséquent, si à la suite d'un audit, vous trouvez des pare-feu solitaires et que vous pensez à augmenter la fiabilité de votre réseau, HA, bien sûr, est l'une des solutions recommandées, mais vous devez prendre en compte les inconvénients associés à cette approche et, peut-être, juste pour votre une autre solution serait plus appropriée.

Commodité dans la gestion (gérabilité)

En principe, HA concerne également la gérabilité. Au lieu de configurer 2 boîtiers individuellement et de résoudre le problème de synchronisation des configurations, vous les gérez de plusieurs manières comme si vous n'aviez qu'un seul appareil.

Mais peut-être que vous avez de nombreux centres de données et de nombreux pare-feu, cette question s'élève à 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 Panorama est une telle solution.

À suivre.