Documents de l'ANSSI
-
Un document récent (janvier 2018) rédigés par l'ANSSI, que je vous recommande de lire :
https://www.ssi.gouv.fr/uploads/2018/01/guide_preconisations-pare-feux-zone-exposee-internet_anssi_pa_044_v1.pdf
Cela représente les recommandations de l'état Français pour les entreprises.
Vous trouvez les bons schémas, des réponses à des questions qui reviennent sans cesse, …Bonne lecture.
-
Bonne lecture en effet. Je confirme sur le terrain, là où les besoins de sécurité sont un peu conséquents, la présence de ce type d'architecture de pare feu.
-
De bonnes informations en général même si personnellement le double pare-feu de technos différentes me fait légèrement sourire.
Dans la killchain, si l'un des deux est compromis, alors c'est game over, on pourrait en mettre 4 aussi..c'est bien 4 c'est mieux que 2 :-)Mon conseil, qui vaut ce qu'il vaut : le pare-feu frontal ne doit porter aucun service accessible de l'extérieur pour réduire au maximum la surface d’exposition, dès lors compromettre un système qui ne fait office que de point de passage et non de terminaison devient extrêmement difficile (des paquets magiques peut être).
Les recommandations de l'ANSSI sont valables pour les heureux possesseurs de plateformes UTM (boîtes à tout faire) portant tellement de services qu'elles offres une surface d'exposition importante, bien souvent exploitées par des personnes manquant de compétences dans ce domaine.De plus, tout système d'information moderne utilise principalement des flux chiffrés (SSL/TLS) dans ses communications internes, ils sont donc opaques au passages dans ces plateformes IDS/IPS réseau. A moins de détruire tous les efforts de sécurité en faisant de l'introspection SSL sur ces mêmes passerelles :-)
Perso, je réduis au strict minimum la surface d'exposition et je concentre mes efforts sur la surveillance et la protection des protocoles exposés (99% HTTP).
-
@Juve : merci de relancer ce fil et de ta, toujours instructive, réflexion et pratique.
Ce document est édité par l'ANSSI : agence gouvernementale de prescription de la sécurité à l'attention des entreprises notamment de secteurs stratégiques (ex. Défense).
Ce document relance le schéma (un peu ancien) de double firewall :
Internet <-> Fw 1 <-> DMZ <-> Fw 2 <-> Réseaux internes
NB : c'était le schéma proposé par les premières éditions O'Reilly sur Les Firewalls (à l'époque appelé 'bastion' par le traducteur !).
L'idée de ce schéma est que les seuls flux autorisés sont- Internet <-> Dmz, et
- Dmz <-> Réseaux internes.
Autrement dit - d'un, la DMZ rassemble les machines exposées à Internet,
- de deux, les Réseaux internes n'accèdent pas à Internet (sous-entendu autrement que via une machine en DMZ).
Donc on placera en Dmz, moulte proxies ('mandataires' dans la terminologie de l'époque).
Bien évidemment l'idée d'utiliser des firewalls différents suit, avec la contrainte de disposer du personnel compétent sur l'un et l'autre techno, ce qui est difficile et discutable.
De même, le conseil de se limiter à des firewalls dédiés au filtrage et excluant toute autre taches, s'oppose, justement, à l'utilisation de l'UTM, laissant le filtrage aux proxies.Il s'agit toutefois d'un texte intéressant, car il explique par les bons raisonnements chacune des recommandations.
C'est l'objectif idéal de la sécurité, avec tous les moyens que cela impose.
Libre ensuite d'agir en toute conscience …En particulier, il est intéressant de lire les passages sur la virtualisation : virtualisation du firewall, de serveurs dans des zones, ...
-
Dans mon activité pro j'échange régulièrement avec ce genre d'autorité de tutelle (dont l'ANSSI qui est en plein développement et qui commence à sortir de très bons guides)
La mise en place d'un bastion en back-to-back est utile du moment ou l'on gère correctement le sectionnement des domaines de routage. Dans une infra de ce type, dans les règles de l'art, les réseaux de confiance (interne) ne dispose pas de route par défaut vers l’extérieur, seul le firewall frontal est capable de joindre les réseaux publiques. Malheureusement, bien souvent ces architectures étaient perverties et leur objectif initial de cloisonnement du routage disparaissait.
Dans les règles de base que je vous conseille:
- les serveurs de production ne doivent jamais pouvoir sortir librement sur Internet ceci afin de limiter la casse en cas de compromission. En effet, en analyse killchain, dans 9 Cas sur 10 l'assaillant va compromettre le service cible en lui faisant télécharger un code malveillant (payload) puis en l'exécutant. Si votre serveur compromis ne peut télécharger le payload cela vous donne plus de chance de détecter l'attaque (ex : analyse des logs, détection de tentative de sortie etc.). Si les serveur consomment des ressources externes (API etc.), il faut ouvrir spécifiquement ces flux
- ne pas avoir de règles de NAT outbound pour les réseaux les plus sensibles, cela rajoute une sécurité additionnelle en cas de filtrage laxiste
- avoir un partenaire de protection contre les dénis de service par flood, ce problème se gère en amont
- par défaut tout fermer et ouvrir seulement ce qui est nécessaire
- centraliser les logs sur une plateforme d'analyse pour détecter, analyser et comprendre la situation (perso j'utilise Splunk, c'est payant certes mais c'est efficace, voir pj )
- comprendre ce que l'on fait.