Cet article est le troisième d'une série d'articles intitulée « Comment prendre le contrôle de l'infrastructure réseau ». Vous pouvez trouver le contenu de tous les articles de la série et les liens. .
Il est inutile de parler d'une élimination complète des risques de sécurité. En principe, nous ne pouvons pas les réduire à zéro. Il faut également comprendre qu'en cherchant à rendre le réseau de plus en plus sûr, nos solutions deviennent progressivement plus coûteuses. Il est nécessaire de trouver un compromis raisonnable entre le prix, la complexité et la sécurité pour votre réseau.
Bien sûr, la conception de la sécurité est intégrée dans l'architecture générale, et les solutions de sécurité utilisées influencent la scalabilité, la fiabilité, la gestion, ... de l'infrastructure réseau, ce qui doit également être pris en compte.
Mais je rappelle que nous ne parlons pas actuellement de la création d'un réseau. Selon nos Nous avons déjà choisi le design, le matériel a été sélectionné et l'infrastructure a été créée. À ce stade, nous devons, dans la mesure du possible, « vivre » et trouver des solutions dans le cadre de l'approche adoptée précédemment.
Notre tâche actuelle est d'identifier les risques liés à la sécurité au niveau réseau et de les réduire à un niveau raisonnable.
Audit de sécurité réseau
Si votre organisation a mis en place des processus ISO 27k, alors l'audit de sécurité et les modifications du réseau doivent être intégrés harmonieusement dans les processus globaux de cette approche. Mais ces normes ne concernent pas spécifiquement des solutions, ni des configurations, ni des conceptions… Il n'y a pas de conseils indiscutables, pas de normes dictant en détail ce que votre réseau doit être, voilà la complexité et la beauté de cette tâche.
Je distinguerais plusieurs types d'audits de sécurité réseau :
- audit de configuration du matériel (hardening)
- audit de la conception de sécurité
- audit des accès
- audit des processus
Audit de configuration du matériel (hardening)
Il semble que dans la plupart des cas, ce soit le meilleur point de départ pour l'audit et l'amélioration de la sécurité de votre réseau. À mon avis, c'est une bonne démonstration de la loi de Pareto (20 % des efforts donnent 80 % des résultats, tandis que les 80 % restants des efforts n'apportent que 20 % des résultats).
L'essentiel est que nous avons généralement des recommandations de la part des fournisseurs concernant les « meilleures pratiques » pour la configuration du matériel en matière de sécurité. Cela s'appelle le “hardening”.
Il est également fréquent de trouver un questionnaire (ou de le créer soi-même) basé sur ces recommandations, qui vous aidera à déterminer dans quelle mesure la configuration de votre matériel correspond à ces « bonnes pratiques » et, en fonction du résultat, à apporter des modifications dans votre réseau. Cela vous permettra de réduire considérablement les risques de sécurité, en fait sans coûts significatifs.
Quelques exemples pour certains systèmes d'exploitation Cisco.
À partir de ces documents, une liste des exigences de configuration peut être créée pour chaque type de matériel. Par exemple, pour le Cisco N7K VDC, ces exigences peuvent se présenter comme suit .
Ainsi, des fichiers de configuration peuvent être créés pour différents types de matériel actif de votre infrastructure réseau. Ensuite, manuellement ou en utilisant l'automatisation, vous pouvez « télécharger » ces fichiers de configuration. Comment automatiser ce processus sera abordé en détail dans une autre série d'articles consacrés à l'orchestration et à l'automatisation.
Audit de la conception de la sécurité
Dans un réseau d'entreprise, les segments suivants sont généralement présents 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
- Filiale
- Campus (Bureau)
- Noyau
Les noms proviennent de modèles, mais il n'est pas nécessaire de s'en tenir uniquement à ces noms et à ce modèle. Il est essentiel de parler de l'essence et de ne pas se perdre dans des formalités.
Pour chacun de ces segments, les exigences en matière de niveau de sécurité, les risques et, en conséquence, les solutions varieront.
Examinons chacun d'eux séparément pour voir les problèmes que vous pourriez rencontrer au niveau de la conception de la sécurité. Bien sûr, je réitère que cet article n'a pas vocation à être exhaustif, atteindre cela sur ce sujet réellement profond et complexe est difficile (si cela est même possible), mais il reflète mon expérience personnelle.
Il n'existe pas de solution idéale (en tout cas pas actuellement). C'est toujours un compromis. Mais il est important que la décision d'appliquer une approche quelconque soit prise de manière consciente, avec une compréhension tant de ses avantages que de 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'y a pas de solution universelle ici non plus. Tout dépend fortement des exigences du réseau.
Un pare-feu est-il nécessaire ?
Il semblerait que la réponse soit évidente, mais la situation n'est pas si claire qu'elle pourrait le paraître. Votre choix peut être influencé non seulement par le prix.
Exemple 1. Les latences.
Si une latence basse entre certains segments de réseau est une exigence essentielle, ce qui est le cas par exemple sur une bourse, alors nous ne pouvons pas utiliser de pare-feu entre ces segments. Il est difficile de trouver des études sur les latences des pare-feu, mais peu de modèles de commutateurs peuvent fournir des latences inférieures ou proches de 1 µsec, donc je pense que si les microsecondes sont importantes pour vous, alors les pare-feu ne sont pas faits pour vous.
Exemple 2. Performance.
La bande passante des meilleurs commutateurs L3 est généralement supérieure d'un ordre de grandeur à celle des pare-feu les plus performants. Donc, dans le cas d'un trafic très intense, vous devrez aussi probablement contourner les pare-feu.
Exemple 3. La fiabilité.
Les pare-feu, en particulier les NGFW modernes (Next-Generation FW), sont des dispositifs complexes. Ils sont beaucoup plus sophistiqués que les commutateurs L3/L2. Ils offrent un grand nombre de services et de possibilités de configuration, ce qui explique leur fiabilité généralement inférieure. Si la continuité du service est critique pour le réseau, il peut donc être nécessaire de choisir ce qui offira la meilleure disponibilité : la sécurité via un pare-feu ou la simplicité d'un réseau construit sur des commutateurs (ou divers types de fabric) avec des ACL standard.
Dans les exemples ci-dessus, vous devrez probablement (comme d'habitude) trouver un compromis. Envisagez les solutions suivantes :
- si vous avez décidé de ne pas utiliser de pare-feu à l'intérieur du centre de données, vous devez réfléchir à la manière de limiter au maximum les accès en périphérie. Par exemple, vous pouvez ouvrir uniquement les ports nécessaires depuis Internet (pour le trafic client) et les accès administratifs au centre de données uniquement depuis des hôtes de saut. Effectuez toute vérification nécessaire (authentification, autorisation, antivirus, journalisation, …) sur les hôtes de saut.
- vous pouvez utiliser le partitionnement logique du réseau du centre de données en segments, similaire au schéma décrit dans PSEFABRIC. La routage doit être configurée de telle manière que le trafic sensible à la latence ou le trafic à forte intensité circule « à l'intérieur » d'un seul segment (dans le cas de p002, du VRF) et ne passe pas par le pare-feu. Le trafic entre différents segments continuera à passer par le pare-feu. Il est également possible d'utiliser le route leaking entre les VRF pour éviter le redirection du trafic à travers le pare-feu.
- Vous pouvez également utiliser le pare-feu en mode transparent uniquement pour les VLAN où ces facteurs (latence/performance) ne sont pas significatifs. Mais il est important d’étudier attentivement les limitations associées à cette modalité pour chaque fournisseur.
- Vous pouvez envisager d'appliquer l'architecture de chaîne de services. Cela permettra de diriger uniquement le trafic nécessaire à travers le pare-feu. Cela semble théoriquement attrayant, mais je n'ai jamais vu ce type de solution en production. Nous avons testé la chaîne de services pour Cisco ACI/Juniper SRX/F5 LTM il y a environ trois ans, mais à ce moment-là, cette solution nous a semblé « immature ».
Niveau de protection
Il est maintenant temps de se demander quels outils vous souhaitez utiliser pour filtrer le trafic. Voici quelques-unes des fonctionnalités qui sont généralement présentes dans les NGFW (par exemple, ):
- pare-feu stateful (par défaut)
- 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)
- protection contre les DOS
Et ce n'est pas si simple. Il semblerait que plus le niveau de protection est élevé, mieux c'est. Mais vous devez également considérer que
- plus vous utilisez de fonctionnalités mentionnées précédemment dans le pare-feu, plus cela sera naturellement coûteux (licences, modules supplémentaires).
- L'utilisation de certains algorithmes peut considérablement réduire la bande passante du pare-feu et augmenter les latences, voir par exemple
- Comme pour toute solution complexe, l'utilisation de méthodes de protection avancées peut diminuer la fiabilité de votre solution, par exemple, lors de l'utilisation d'un pare-feu applicatif, j'ai rencontré le blocage de certaines applications tout à fait standard (dns, smb).
Comme d'habitude, vous devez trouver la solution optimale pour votre réseau.
Il est impossible de répondre de manière définitive à la question des fonctions de sécurité qui peuvent être nécessaires. Tout d'abord, cela dépend évidemment des données que vous transférez ou stockez et que vous essayez de protéger. Deuxièmement, en réalité, le choix des moyens de protection est souvent une question de foi et de confiance envers le fournisseur. Vous ne connaissez pas les algorithmes, vous ne savez pas à quel point ils sont efficaces et vous ne pouvez pas les tester pleinement.
C'est pourquoi, dans des segments critiques, une bonne solution peut être d'utiliser des offres de différentes entreprises. Par exemple, vous pouvez activer un antivirus sur le pare-feu, mais également utiliser une protection antivirus (d'un autre fabricant) localement sur les hôtes.
Segmentation
Il s'agit de la segmentation logique du réseau du data center. Par exemple, la division en VLAN et en sous-réseaux est aussi une segmentation logique, mais nous ne l'examinerons pas en raison de son évidence. La segmentation prenant en compte des entités telles que les zones de sécurité FW, VRF (et leurs équivalents pour divers fournisseurs), dispositifs logiques (PA VSYS, Cisco N7K VDC, tenant Cisco ACI, …) est intéressante.
Un exemple de cette segmentation logique et d'un design de data center très demandé à l'heure actuelle est présenté dans .
Ayant défini les parties logiques de votre réseau, vous pouvez alors décrire comment le trafic circule entre les différents segments, sur quels dispositifs la filtration sera appliquée et par quels moyens.
Si votre réseau n'a pas de séparation logique claire 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 qu'en cas d'ouverture d'un accès particulier, vous devrez résoudre ce problème, et il est très probable que vous le ferez différemment à chaque fois.
Souvent, la segmentation est basée uniquement sur les zones de sécurité FW. Dans ce cas, vous devez répondre aux questions suivantes :
- quelles zones de sécurité vous sont nécessaires
- quel niveau de protection souhaitez-vous appliquer à chacune de ces zones
- le trafic intra-zone sera-t-il autorisé par défaut
- si non, quelles politiques de filtration du trafic seront appliquées à l'intérieur de chacune des zones
- quelles politiques de filtration du trafic seront appliquées pour chaque paire de zones (source/destination)
TCAM
Il est fréquent de rencontrer un problème de TCAM (Ternary Content Addressable Memory) insuffisant, tant pour le routage que pour les accès. À mon avis, c'est l'une des questions les plus importantes lors du choix du matériel, il est donc nécessaire de l'aborder avec le degré de soin approprié.
Exemple 1. Table de routage TCAM.
Examinons pare-feu.
Nous constatons que la taille de la table de routage IPv4* = 32K
Ce nombre de routes est total pour tous les VSYS.Supposons qu'en fonction de votre conception, vous ayez décidé d'utiliser 4 VSYS.
Chacun de ces VSYS est connecté via BGP à deux PE du réseau MPLS que vous utilisez comme BB. Ainsi, les 4 VSYS échangent toutes les routes spécifiques entre eux et ont une table de routage avec des ensembles de routes à peu près identiques (mais avec des NH différents). Comme chaque VSYS a 2 sessions BGP (avec des paramètres identiques), chaque route reçue via MPLS a 2 NH et, par conséquent, 2 enregistrements FIB dans la table de routage. Si l'on suppose que c'est le seul pare-feu dans le centre de données et qu'il doit connaître toutes les routes, cela signifiera que le nombre total de routes dans notre centre de données ne peut pas dépasser 32K/(4 * 2) = 4K.Maintenant, si l'on suppose que nous avons 2 centres de données (avec une conception identique) et que nous souhaitons utiliser des VLAN « étendus » entre les centres de données (par exemple, pour vMotion), afin de résoudre le problème de routage, nous devrons utiliser des routes hôtes. Mais cela signifie que pour 2 centres de données, nous aurons pas plus de 4096 hôtes possibles, ce qui peut être insuffisant.
Exemple 2. TCAM ACL.
Si vous prévoyez de filtrer le trafic sur des commutateurs L3 (ou d'autres solutions utilisant des commutateurs L3, par exemple, Cisco ACI), alors lors du choix du matériel, vous devez prêter attention au TCAM ACL.
Supposons que vous souhaitiez contrôler les accès sur les interfaces SVI des Cisco Catalyst 4500. Alors, comme on peut le voir dans , pour contrôler le trafic sortant (tout comme pour le trafic entrant) sur les interfaces, vous ne pouvez utiliser que 4096 lignes TCAM. Ce qui, avec TCAM3, vous donnera environ 4000 ACE (lignes ACL).
Si vous êtes confronté à un problème de TCAM insuffisant, il faut d'abord envisager une optimisation. Par exemple, en cas de problème avec la taille de la Forwarding Table, il est conseillé d'envisager l'agrégation des routes. En cas de problème avec la taille du TCAM pour les accès, il est nécessaire de procéder à un audit des accès, de supprimer les enregistrements obsolètes et redondants, ainsi que peut-être de revoir la procédure d'ouverture des accès (ce qui sera détaillé dans le chapitre consacré à l'audit des accès).
Haute Disponibilité
La question est de savoir s'il faut utiliser HA pour les pare-feu ou installer deux boîtiers indépendants « en parallèle » et, en cas de défaillance de l'un d'eux, router le trafic via le second ?
Il semblerait que la réponse soit évidente : utiliser la HA. La raison pour laquelle cette question se pose néanmoins, c'est que, malheureusement, les 99 et quelques chiffres après la virgule de disponibilité théorique et publicitaire ne sont souvent pas aussi optimistes en pratique. La HA est un concept suffisamment complexe, et sur différents matériels, avec différents fournisseurs (aucune exception), nous avons rencontré des problèmes, des bogues et des interruptions de service.
En utilisant la HA, vous aurez la possibilité d'éteindre des nœuds individuels, de basculer entre eux sans interruption de service, ce qui est important, par exemple, lors des mises à niveau. Cependant, il existe toujours une probabilité non nulle que vous perdiez les deux nœuds en même temps, ainsi que le fait que la mise à niveau en cours ne se déroule pas aussi bien que le prétend 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 la HA, vos risques en matière de double panne sont considérablement réduits (car vous avez 2 pare-feu indépendants). Cependant, comme les sessions ne sont pas synchronisées, chaque fois que vous passez d'un pare-feu à un autre, vous perdez du trafic. Bien sûr, il est possible d'utiliser un pare-feu sans état, mais dans ce cas, l'utilité du pare-feu est en grande partie perdue.
Ainsi, si lors de l'audit vous avez découvert des pare-feux isolés et que vous envisagez d'augmenter la fiabilité de votre réseau, le HA est certainement l'une des solutions recommandées, mais vous devez également prendre en compte les inconvénients associés à cette approche et il se peut qu'une autre solution soit plus adaptée à votre réseau.
Facilité de gestion
En principe, le HA concerne également la gestion. Au lieu de configurer deux appareils séparément et de résoudre le problème de synchronisation des configurations, vous les gérez en grande partie comme s'il s'agissait d'un seul appareil.
Mais peut-être que vous avez de nombreux centres de données et beaucoup de pare-feux, alors cette question se pose à un nouveau niveau. Et il ne s'agit pas seulement de configuration, mais aussi de
- sauvegarde des configurations
- mises à jour
- mises à niveau
- surveillance
- journalisation
Et toutes ces questions peuvent être résolues par des systèmes de gestion centralisés.
Par exemple, si vous utilisez des pare-feux Palo Alto, alors est une telle solution.
La suite au prochain épisode.
Source : habr.com
