7 tips pour réussir votre migration de firewall En tant que consultant en sécurité réseau nous sommes très régulièrement impliqués dans des migrations de firewall. Face à de nouvelles problématiques de sécurité, les firewalls ont beaucoup évolué ces 10 dernières années et il est donc normal pour une entreprise de décider de changer ses équipements. Cependant, ce changement implique une migration de sa configuration existante sur le nouveau firewall. Pour un grand nombre de nos clients, cette migration était très compliquée. Les firewalls ont très souvent un historique de plus de 10 ans, comportant plusieurs milliers d’objets et de règles de sécurité. Vous l’aurez deviné, ces migrations sont très souvent difficiles et causées par deux éléments. 1. Un énorme historique de règles, objets, routes… 2. Une importante évolution des technologies, car nous passons généralement d’un firewall traitant le trafic de niveau 3 à 4 du modèle OSI à des firewalls de niveau 7. Pour écrire cet article, je me suis appuyé des retours d’expérience de certains de mes collègues. Grâce à eux, je vais vous faire partager quelques conseils sur la façon de migrer votre pare-feu tout en vous épargnant des maux de tête. Les conseils sont découpés en 7 étapes
1. Maîtriser la nouvelle technologie 2. Nettoyer vos règles et objets inutiles 3. Automatiser votre migration 4. Déclarer un gel des configurations 5. Préparer votre procédure de rollback 6. Prévoyez une large fenêtre de maintenance 7. Post migration dans les starting blocks Analysons chacune des étapes
1. Maitriser la nouvelle technologie Il parait évident que vous ne pourrez jamais faire une migration ou utiliser correctement votre nouveau firewall sans bien connaitre cette nouvelle technologie. Sans cette bonne connaissance, vous pourrez difficilement résoudre les futurs incidents et vous serez obligé de faire un rollback sur l’ancien équipement si vous ne voulez pas vous faire virer. Pour éviter cela, vous devez vous familiariser avec cette nouvelle technologie. Pour cela vous avez plusieurs cordes à votre arc :
- Vous pouvez suivre une formation
- Si vous vous sentez assez bon vous pouvez vous auto former avec les guides administrateurs et les différents sites / forums du constructeur.
2. Nettoyer vos règles et objets inutiles Lorsque nous intervenons pour une migration, il est très rare de voir un firewall existant tout propre et bien configuré. Les équipes sécurités ajoutent les règles quotidiennement les unes après les autres, les objets et les services de la même façon et cela ne fait qu’alourdir la configuration du firewall. Quels sont les principaux impacts ?
- Politique de sécurité de l’entreprise compromise
- Perte de temps lors de la résolution des incidents
- Temps de traitement du firewall très long
Avant de faire la migration, nous recommandons fortement d’auditer et nettoyer votre configuration actuelle, sinon vous risquez un désastre post migration. Pour faire ce nettoyage, les éditeurs de firewalls mettent à dispositions certains outils pour nettoyer votre firewall. Bien que ces outils soient souvent gratuits, ils peuvent parfois être efficaces. Nous constatons que sans la connaissance d’un administrateur réseau présent depuis des décennies avec une mémoire d'éléphant et qui peut raconter l'histoire de tous les IP dans le réseau, vous rencontrerez de nombreuses difficultés. D’autres entreprises n’ont aucune idée des raisons pour lesquelles ces règles sont et si celles-ci sont en cours d'utilisation. Chez Nomios nous recommandons aux clients d’acheter une licence d’audit de la solution Tufin SecureTrack. Bien que vous pensiez que cette licence coute cher, nous vous invitons à nous contacter, car le prix n’est pas du tout élevé. Que va vous apporter Tufin SecureTrack ?
- Supprimer les objets, groupes d’objets et services inutilisés ou redondants
- Afficher les hits sur chacune des règles et objets permettant notamment d’afficher les éléments non matchés.
- Afficher les règles et objets shadow (déjà matchés par une règle précédente)
- Audit de votre politique par rapport à des best practice ou recommandations constructeurs.
- Et d’autres fonctionnalités intéressantes.
Bref, l’idée de cet article n’est pas de vendre du Tufin, mais de vous expliquer que cette solution peut parfois être indispensable pour réussir une bonne migration. Pour info, certains de nos clients ont supprimé plus de 70% de leurs règles grâce à cette solution et, par conséquent vous l’aurez deviné la migration a été bien mieux maitrisée et a surtout été plus rapide à effectuer.
Cependant, petit point de vigilance :- Soyez attentifs lors de l’activation des logs sur vos firewalls, car cela aura un impact sur le CPU du firewall
- Certaines règles sont matchées une fois par mois ou par trimestre comme les logiciels de sauvegarde ou de paye, donc attention au nombre de hits des règles et objets ;-)
3. Automatiser votre migration Cette étape est probablement la plus compliquée, car la configuration de votre pare-feu doit être réécrite en utilisant la syntaxe du nouvel équipement et cela n’est pas si simple. Combien de temps cela peut prendre ? Avez-vous besoin d'outils d’automatisation ? Ces solutions sont-elles fiables ? Pour répondre à ces questions, je vous recommande de planifier du temps pour tester la migration de la configuration. Il est préférable de trouver tout cela dans un stade précoce de votre projet de migration. Nous vous recommandons de configurer manuellement les éléments de base:
- Paramètres de l'interface (physique, logique et IP)
- Configuration haute disponibilité (clustering)
- Paramètres de gestion (utilisateurs, accès à distance, AAA, SNMP, et Syslog)
Ensuite, il restera les objets, les services, les routes, les règles de sécurité, NAT, VPN… Pour ces derniers éléments, il peut être très intéressant d’automatiser cette partie de la migration. La décision dépend surtout du nombre de règles que vous avez. Dans un pare-feu qui comporte 1500 règles, la migration manuelle n’est pas une option envisageable, car si vous y arrivez, il y aura très probablement des erreurs humaines. Certains éditeurs de firewalls mettent à disposition des outils permettant d’automatiser les migrations. Sur le papier cela semble super. Mais en réalité, nous rencontrons de nombreux problèmes. Ces outils traduiront parfaitement 90% de la configuration, mais inévitablement, il restera 10% d’erreurs que vous aurez à trouver et à corriger! J’ai également rencontré des problèmes avec l’utilisation de ces outils quand le client utilisait une vieille version software sur l’ancien firewall. Mon expérience sur les migrations m’a poussé à utiliser dans de nombreux cas Excel. En récupérant un export de la conf au format csv, xml ou autre, puis à l’aide de quelques formules ou fonctions simples, nous pouvons transformer ce fichier en un format exploitable pour le firewall cible.
Petit point de vigilance :- Lors de la conversion, méfiez-vous des différences entre les firewalls, exemple les policies appliquées aux règles de NAT entre un firewall Juniper et Palo Alto n’auront pas les mêmes zones.
- Sur les éléments de configuration critiques, vérifiez bien que la conversion est correcte en vous relisant.
Avant de passer à l’étape suivante, dernier conseil, pensez à valider vos commandes d’insertion. Pour cela je vous recommande de prendre un échantillon d’objets, règles, routes… présents dans votre tableau Excel ou script de migration, et de les taper en CLI à l’aide d’un copier /coller. Vous verrez que vous aurez à faire face à des erreurs que vous devrez corriger. Cette étape est intéressante car elle permet de se familiariser avec le fonctionnement du nouveau firewall.
4. Déclarer un gel des configurations Entre l’extraction des configurations du firewall actuel jusqu’à la mise en production du futur firewall, nous avons une période où les équipes sécurité continuent d’implémenter des changements sur le firewall qui ne seront très probablement pas pris en compte dans la migration. Pour pallier à ce problème, il est impératif de convenir d’une période de gel de configuration sur le firewall. Si vous devez impérativement faire une modification sur le firewall, alors notez celle-ci pour l’inclure dans la migration.
5. Préparer votre procédure de rollback Cette phase n’est pas la plus intéressante, mais elle est très critique. Le premier objectif est de s’assurer une dernière fois que la nouvelle configuration est écrite correctement, pour que la migration se fasse en douceur! Ceci est aussi un bon moment pour planifier et écrire une procédure de rollback. Imaginez ce mauvais scénario : les choses tournent mal lors de la migration. Vous vous apprêtez à dépasser la fenêtre de maintenance. Vous êtes mort de fatigue et vous commencez à avoir des maux de tête. Une procédure de rollback bien maitrisée vous permettra de garder la tête froide et les idées claires. Vous appliquerez ce rollback si vous ne vous en sortez pas pour que l’ancien firewall reprenne le trafic de production.
6. Prévoyez une large fenêtre de maintenance Le premier conseil que je vous donnerai est de prévoir une fenêtre de maintenance plus longue que ce que vous pourrez avoir besoin, afin de prendre le temps de respecter calmement chacune des étapes de la migration, et également prendre du temps pour résoudre les derniers problèmes qui viendraient à apparaitre. Une autre suggestion est de ne pas annoncer aux utilisateurs finaux qu’une migration de firewall est prévue, mais d’annoncer une maintenance réseau. Ceci évitera à l'utilisateur lambda d’associer le pare-feu avec ce logiciel ennuyeux sur son PC, qui apparaît demandant de cliquer sur quelque chose pour continuer. Pour tout problème qui surviendra le lendemain matin, ils blâmeront par ignorance le pare-feu. Qui a vraiment besoin de savoir qu’une migration est prévue ? Ce sont les équipes applicatives. Les gens responsables des services (e-mail, Web, bases de données, etc.) doivent vérifier que tout se passe bien. Mon meilleur conseil est de leur demander de tester les applications avant et après la migration de pare-feu.
7. Post migration dans les starting blocks Il est très rare de voir des migrations sans effets de bord. Il est essentiel de planifier une phase de suivi avec le personnel technique alerté et être prêt à corriger tout problème. Il est également important de définir un ordre de priorité sur les éventuels incidents. Par exemple, un problème FTP sera normalement moins problématique qu’un problème de mail empêchant l’ensemble des employés de communiquer. Préparez les documents de troubleshooting car l’incident devra être résolu très rapidement. Les problèmes importants pouvant nécessiter un rollback auront lieu généralement dès le début du suivi de migration. Comme mentionné dans le point 1 de cet article, une connaissance avancée du firewall permettra de corriger rapidement les incidents. Cet article est terminé. J’espère ce certains de ces conseils vous aideront dans votre prochaine migration. N’hésitez pas à laisser vos commentaires si vous avez remarques à apporter.
