Reprise du message précédent :
question aux pros du réseau: est-ce qu'il existe des outils pour automatiser la gestion de parcs de parefeux ?
 
Je voudrais pouvoir définir dans l'outil grosso-modo la topologie utilisée, les flux qu'on veut ouvrir et pouf, l'outil générerait la conf pour chaque fw, l'appliquerait et me proposerait un café pour le regarder bosser.
 
Un exemple: soit 3 sites connectés ainsi: A <---> B <---> C
 
Si je dis qu'un subnet derrière A doit accéder à un hôte derrière C, il ouvre les flux comme il faut sur les trois parefeux avec les critères définis.
 
Si j'ajoute maintenant un site D dont, comme A, le routage passe aussi par B pour aller à C: D <---> B <---> C
Si j'ajoute un des subnets derrière D en tant que source dans la règle de flux précédente, il modifie les règles correspondantes sur B et C pour tenir compte de la nouvelle source, sans rien toucher à A.
 
Je n'arrive pas à savoir si ce genre de choses existent et comment ça s’appellerait (SDN ?).

genre algosec ?

ah oui, c'est exactement ça (la partie FireFlow).
 
Pour la petite histoire, on a un outil développé vite fait en interne qui nous fait ça très bien mais il est rudimentaire (fichiers plats pour tout définir, j'allais pas y passer 3 mois non plus) et minimaliste : il ne gère que la partie génération/conformité, au sens où il supprime tout ce qui dépasse partout où il passe sans chercher à comprendre.
 
Il y a un mode simulation pour vérifier ce qu'on va réellement faire sur le parc mais j'ai un peu peur que mon admin réseau nous pète tout un jour avec.
 
Je vais regarder en partant d'algosec. Merci

 
Dès que tu commences à avoir des investisseurs, pas mal de salariés, des filiales... C'est assez normal
 

 
C'est un métier où tu risques pas le chômage, surtout avocat d'affaires
 

 
Ah ah bien trouvé
 

En tout cas ça montre bien que pour monter et tenir bien sa boîte, les qualités sont bien autres que les connaissances techniques/avoir le meilleur logiciel/produit a vendre.

 
C'est ce qu'utilise un gros groupe français du gaz
Ca a l'air d'être une usine à gaz mais bon c'est fait pour

Voilà, faut de la thune et racheter ceux qui savent faire  
 
Et collecter la dîme aussi.

Ilumnio pour le côté "SDN" sur les hôtes, Tuffin pour les équipements dédiés.

 
une usine à gaz dans un grand groupe de gaz...
 
de notre côté c'est plutôt simple et efficace: tu déclares tes fw, leurs ips/subnets, leurs routes possibles avec quelques hints et l'outil se démerde pour reconstruire la topologie avec ça. Après c'est juste une histoire d'aliases et de règles. Tu peux aussi taguer tes réseaux, au hasard 'voip', pour écrire une règle selon laquelle tous les réseaux voip peuvent se parler entre eux en SIP (par exemple). Ca marche très bien, c'est rapide et très puissant, et c'est un peu ce qui me fait peur maintenant. Je vois qu'en 30s on peut éclater le réseau de toute la cogip si on n'est pas bien réveillé ou simplement qu'on se démerde pour faire des modifs qui vont bien en étant à plusieurs dessus en même temps (l'outil est pas 365 ready )

 
Je vais regarder ceux-là aussi. Merci

Algosec c'est ce qu'on a ici aussi, j'étais déjà pas super convaincu à la base mais plus le temps passe plus ce sentiment se confirme, c'est juste de l'automatisation d'ouverture de flux en fait, ça peut accélérer un process legacy qui suit à peu près ce schéma :
- un user fait une demande à une équipe réseau  
- se fait recaler parce que l'équipe sécu ne valide pas parce que certains critères ne sont pas remplis
- reformule se demande qui cette fois est acceptée
- la demande est implémentée, mais ça marche pas parce qu'elle a été imlpémentée à moitié ou mal formulée
- la demande est reformulée et réimplémentée, et enfin ça fonctionne
 
Ce genre d'outil permet donc d'accélérer le processus ci-dessus en automatisant les communications entre les équipes et en proposant certains checks automatiques qui vont permettre de zapper certaines étapes manuelles.
Mais ce qu'il faut bien comprendre c'est que la source de vérité reste la config des firewalls elle même, il n'y a pas de source de plus haut niveau/plus abstraite qu'on mixerait avec un certain nombre de variables/templates pour en déduire les configs des firewalls. On est toujours dans ce paradigme où on empile des règles dans les firewalls sans se poser de question sur le cycle de vie de tout le bousin.
 
Pour moi la vraie solution au problème c'est :
- une CMDB qui répertorie les firewalls et les éléments de configuration qui leurs sont propres (ou propres à leur site d'appartance, ou propre aux réseaux qu'ils portent etc). Typiquement Netbox est l'outil recommandé pour ce genre de chose.
- un système de stockage des policies sous forme abstraite, pour ça à ma connaissance de solution toute faite, une base SQL fait l'affaire, tout le boulot consiste à définir un schéma qui correspond à ton organisation. cf https://en.wikipedia.org/wiki/Object-relational_mapping
- un process automatisé qui prend en entrée les deux éléments ci-dessus, génère la config pour chaque firewall et la pousse sur chaque équipement. Attention même chez certains constructeurs très cher, pouvoir simplement pousser une configuration complète n'est pas forcément quelque chose de supporté. Et au contraire, puisqu'il n'y a plus besoin d'interface graphique sur les firewalls, nftables peut être une piste à explorer (on doit faire un poc là-dessus cette année justement, j'espère qu'on aura le temps)
- chaque user/service/BU/entité en mesure de gérer des changements dans la configuration des policies doit être responsabilisée dessus, chaque policy doit être identifiée d'une manière ou d'un autre avec l'entité qui en est responsable.
 
Voilà c'est l'idée générale, après en fonction de la taille de ton business (nombre de users, fréquence des changements, complexité du réseau etc) certaines étapes seront plus simple ou plus complexes bien sûr.

 
La solution pour ça c'est la simulation en lab avant de pousser une nouvelle version de la config.
- Génération d'un lab (sous gns3 ou autre) à l'image de la prod
- Déroulement d'un certain nombre de tests de connectivité (écrits manuellement et/ou déduits du jeu de policies implémenté)
- Si OK, on peut pousser la nouvelle conf sur la prod
 
+ prévoir un mécanisme de rollback automatique sur la conf n-1 en cas de perte de connectivité (critères à définir)

Je serais pas hyper serein d'avoir un outils pareil en main. Ou alors vraiment en faisant valider par 2/3 personnes chaque déploiement.
 Doit y avoir des incidents par moment?

C'est la base de l'informatique, qu'il y ait des incidents par moment l'outil doit être prévu pour les anticiper/ne pas les permettre, après suivant le temps qu'on veut y passer on peut faire un truc vite fait mais qui casse tout au moindre clic de travers, ou un système qui prévoit un maximum de garde-fous et de mesures de remédiation.
Si on veut pousser le bouchon loin en termes de fiabilité on pourrait même demander à ce que ce soient les users eux-même qui fournissent leur jeu de test en même temps que leur set de policies à implémenter, comme ça avec une simulation on peut garantir que la nouvelle version ne casse rien.

c'est des produits que tu vends a des DSI en disant que tu vas pouvoir automatiser le réseau et la sécu et virer la moitié de l'équipe    
Apres Snowden, y'a un directeur de la NSA qui a dit qu'on réglerait le probleme en ayant moins d'informaticiens "grâce à l'automatisation (sic)

Celui qui ne pète pas son réseau c'est celui qui ne fous rien.  

Tester c'est douter    
 
C'est pas faux

 
Merci Ivy
 
Ca fait beaucoup d'infos. La manière dont notre outil fonctionne actuellement est pas si loin de ce que tu préconises. Il génère la conf exacte que doivent avoir les parefeux et fait une espèce de diff intelligent pour chacun d'entre eux:
update alias machin set ...
delete rule bidule_qui_sert_plus
create rule voip_sortant avec tels paramètres
 
La procédure est de faire tourner l'outil en simulation (sans appliquer les changements) et d'analyser le diff avec les configuration des fws avant de le faire tourner en mode réel. Là, le risque est que quelqu'un d'autre modifie la conf entre les deux. On est une petite équipe (j'ai 2 mecs au support, un au système, un au réseau, pour ~250 users/1000 salariés dans une cogip très hétérogène et assez dispersée) donc c'est encore facile de se coordonner, théoriquement. Il faut que je vois pour au moins faire une espèce de staging de la conf à appliquer, refuser de l'appliquer sans simulation, et lorsque c'est appliqué en réel prendre la conf dans le staging s'il n'est pas trop vieux, disons 5 minutes au maximum, peut-être avec la vérification d'un md5 de la conf des fw histoire de s'assurer que eux aussi n'ont pas bougé entre la simulation et le réel. Ca me semble facile à faire pour au moins sécuriser un peu le merdier.
 
Je pourrais peut-être aussi coder en dur des espèces de golden rules qui quoi qu'il arrive seront générées pour nous permettre de reprendre la main dans l'hypothèse d'une erreur cataclysmique. Ca me semble moins facile car les règles à générer sont dépendantes de la topologie. Ou alors il faudrait les coder en dur pour chaque fw avec une espèce de flag disant "génère la règle sans te poser de question".
 
Pour le reste, il faut que je digère le tout. J'avais aussi pensé à un environnement de test et à une application via des runners gitlab, mais j'ai pas poussé.
 
Enfin un outil qui fait tout ça en mieux et plus intelligent avec mon patron qui fait le gros chèque qui va bien, ça m'irait bien quand même

Oui gérer le versioning c'est assez facile normalement, via git ou autre. Ton outil se base sur une version donnée et fait la validation puis pousse en prod cette version, peu importe que quelqu'un d'autre ait fait une autre merge request en même temps, elle sera prise en compte à l'itération suivante.

Si tu envisages de partir sur un outil commercial attention en tout cas, car il y en a une bonne partie (comme algosec) qui ne vont pas répondre à ton besoin, puisque leur mode de fonctionnement c'est plutôt d'utiliser les configurations actuelles des firewalls comme référence et d'empiler les règles sans intelligence, le but étant de pouvoir être vendable à des organisations qui fonctionnent en mode legacy et qui n'ont pas envie de changer (quitte à ce que le nouvel outil n'apporte pas grand chose au final, mais peu importe une fois que c'est vendu ). D'après ce que tu décris je pense que vous êtes déjà au delà de ça.

Ce genre d'outils c'est capable de fonctionner avec divers constructeurs de FW?

Algosec si  
On va peut être acheter le module Firewall analyser.
Et aussi Nessus pour la sécurité  

Va voir tuffin, tu sera surpris.

C'est leur grand intérêt.
Et vu que les recos sont d'avoir différents fournisseurs ça devient vite indispensable que ce genre d'outils en gère plusieurs

J'irais voir à l'occasion. C'est surtout de la curiosité, j'en ai aucun besoin

 
Tout le workflow interne à changé si tu veux, donc s'il y a du spécifique, il va falloir en recoder la moitié (pour être gentil).

À ce point autant installer un nouvel environnement à côté, démarrer les nouveaux workflows sur le nouveau système et achever les anciens sur l'autre.
Dans une filiale de ma cogip ils ont choisi cette solution pour une appli de workflow vieillissante et une solution SaaS censée être la panacée.

Le problème c'est que ça fait peser un double emploi pour les utilisateurs, c'est à mesurer en fonction de la facilité à migrer les données avec transformation (ou non)

 
ca doit pas du tout couter une couille ca

Algosec coûte déjà une blinde, le devis pour tuffin était 50% plus élevé si je me souviens bien

bon apres c'est tellement des trucs de niche....faut vendre cher pour compenser

Tu as plusieurs moyens de "réussir" ça dépend aussi des tes valeurs. Tu peux très bien avoir une boîte avec 90 commerciaux et 10 devs pour vendre ton soft de merde

Par contre ta intérêt a trouver du client à la pelle car ton taux de renouvellement va être énorme... Enfin sauf marché captif ou être le leader de loin

Ca existe, genre algosec, ca gère plusieurs firewall (et routeurs avec ACL de mémoire).
Par contre niveau optimisation il y a quelques années c'était pas trop ça.
/3ansaprèslabataille

Ca m'amène une question. Le multi vendors firewall à implémenté pour limiter les attaques réussis je suis de moins en moins convaincu de l'utilité étant donné que tous les vendeurs font la même chose avec une base linux et des composants comme openssl ou openvpn dessus. Les CVE et alertes sécu me donnent cet opinion, je me demande si j'ai assez de recul.

Bah justement t'a plein de vendeur en base BSD.
Et je parle même pas de vendeurs qualifiés par une agence de sécurité nationale pour attester de la sécurité des produits

Ça me fait rire ça d'ailleurs.
Le seul Fw qualifié par l'anssi c'est stormshield. Si c'est qualifié c'est juste parce que stormshield a fait la demande et parce que c'est français alors que bon soyons honnête c'est pas ce qui se fait de mieux...
Tous les grands en ont rien à branler d'être qualifié par l'anssi.
Sauf que pour avoir un système homologué DR ou les OIV etc. tu es obligé d'avoir un Fw qualifié en frontal internet...

  je préfère les produits régionaux comme l'Avèze

Le topic était dans ma tête dès le XXe siècle  

Je trouve ça limite comme concept. Tu multiplies les failles, les surface d'attaques, les problèmes d'interco...c'est une pratique qui rajoute de la complexité certes, mais de la sécurité ? Pas vraiment.

C'est un peu le problème des produits certifiés Anssi : ils sont avant tout certifiés parce qu'ils sont français, pas parce qu'ils sont bien sécurisés/fiables/etc...

Euh, c'est un peu plus compliqué que "juste être français" le process de qualification hein

Non biensûr mais aucun étranger se fait chier à demander à être qualifié, ils s'en battent les couilles, ils préfèrent les certifications internationales EAL* qu'un truc français à la con

Nan t'a raison. Y'a du Nokia de qualifié, du NXP, Siemens... Que des boîtes Françaises.

 
Je te sens aigri envers l'ANSSI (et une pointe de mauvaise foi ou de méconnaissance de comment ça marche) Racontes nous tout
 
Ah et sinon petit article sur The Register aujourd'hui, je flippe toujours d'être là bas car ils sont souvent assez assassin sur plein de trucs https://www.theregister.co.uk/2020/ [...] ure_plans/