Différences

Ci-dessous, les différences entre deux révisions de la page.

--- activite3filtrage [2022/10/12 11:00] – [Propositions de modification] techer.charles_educ-valadon-limoges.fr
+++ activite3filtrage [2024/11/03 15:58] (Version actuelle) – [Document 2 : comparaison entre une table de filtrage « papier » et une table de filtrage sur SNS] techer.charles_educ-valadon-limoges.fr
@@ Ligne 1: / Ligne 1: @@
-====== Mise en œuvre du filtrage ======
+====== Activité : Mise en œuvre du filtrage ======
 ===== Ressources =====
@@ Ligne 5: / Ligne 5: @@
   * {{ :fiche5_configurationobjetsreseaux_sns.pdf |Fiche 5 – Configuration des objets réseaux}}
+  * {{ :fiche6_configurationnat_sns.pdf |Fiche 6 - configuration du NAT}}
   * {{ :fiche7_filtrage_protocolaire_sns.pdf |Fiche 7 – Filtrage protocolaire}}
 ===== Présentation de l'activité =====
@@ Ligne 23: / Ligne 24: @@
 Vous devez mettre en place des règles de règles de filtrage pour sécuriser votre infrastrcture en tenant compte des informations suivantes  :
   * vous ne devez autoriser que les flux nécessaires entre les différents réseaux. Tous les autres flux doivent  être bloqués.
-  * le serveur DNS (VLAN serveur) a l'adrese IP 192.168.228.125/26
+  * le serveur DNS (VLAN serveur) a l'adresse IP 192.168.228.125/26
 Voici un extrait de la table de filtrage à implémenter sur votre pare-feu.
@@ Ligne 35: / Ligne 36: @@
 **Question 1 :** expliquez chacune des quatres règles puis proposer éventuellement une modification.
-**Question 2 :** quelles sont les deux règles générales qui manquent ?
+**Question 2 :** en vous aidant du document 3 qui explicite une liste de recommandations de l’ANSSI, indiquez quelles sont les deux règles générales qui manquent ?
 </WRAP>
@@ Ligne 47: / Ligne 48: @@
 ==== Document 2 : comparaison entre une table de filtrage « papier » et une table de filtrage sur SNS====
-Voici à titre d'exemple la **traduction** d'une **proposition** de table de filtrage et sa mise en oeuver avec le SN Stormshield
+Voici à titre d'exemple la **traduction** d'une **proposition** de table de filtrage et sa mise en oeuvre avec le SNS Stormshield
 ^  N°  ^  Adresse IP Source  ^  Port S  ^  Adresse IP Destination  ^  Port D  ^  Proto  ^  Action  ^
 |1	|  *  |  >1023  |  192.168.0.1  |  25  |  TCP  |  Autoriser  |
-|2  |  192.168.192.16  |  >1023  |  192.168.192.254  |  22, 443	TCP  |  Autoriser  |
+|2  |  192.168.192.16  |  >1023  |  192.168.192.254  |  22, 443	|  TCP  |  Autoriser  |
-|3  |  *  |  *  |192.168.0.254 \\ 192.168.192.16854 \\ 192.168.20.254 \\ 192.168.30.254 \\ 194.0.0.1  |  *  |  *  |  	Bloquer  |
+|3  |  *  |  *  |192.168.0.254 \\ 192.168.192.254 \\ 192.168.20.254 \\ 192.168.30.254 \\ 194.0.0.1  |  *  |  *  |  	Bloquer  |
 |4 |  192.168.20.0/24  |  >1023  |  *  |  80, 443  |  TCP  |  Autoriser  |
-|5|  192.168.20.0/24  |  >1023  |  192.168.30.1	53  |  UDP  |  Autoriser  |
+|5|  192.168.20.0/24  |  >1023  |  192.168.30.1 | 	53  |  UDP  |  Autoriser  |
 |6|  192.168.30.1  |  *  |  *  |  53  |  TCP/UDP  |  Autoriser  |
 |7|  *  |  *  |  *  |  *  |  *  |  Bloquer  |
@@ Ligne 87: / Ligne 88: @@
-Pour cela, aidez-vous du **document 3** qui explicite une liste de recommandations de l’ANSSI que vous allez mettre en œuvre dans voter pare-feu.
+Pour cela, aidez-vous du **document 3** qui explicite une liste de recommandations de l’ANSSI que vous allez mettre en œuvre dans votre pare-feu.
 ^  N°  ^  Adresse IP Source  ^  Port Source  ^  Adresse IP Destination  ^  Port Destination  ^  Proto(cole)  ^  Action  ^
@@ Ligne 93: / Ligne 94: @@
 | . |  .  |  .  |  .  |  .  |  .  |  .  |
 | . |  .  |  .  |  .  |  .  |  .  |  .  |
-|  Section 2 – Règles de protection du pare-feu  |||||||
+|  Section 2 – Règles d’autorisation des flux émis par le pare-feu  |||||||
 | . |  .  |  .  |  .  |  .  |  .  |  .  |
 | . |  .  |  .  |  .  |  .  |  .  |  .  |
-|  Section 3 – Règles d’autorisation des flux métiers  |||||||
+|  Section 3 – Règles de protection du pare-feu  |||||||
 | . |  .  |  .  |  .  |  .  |  .  |  .  |
 | . |  .  |  .  |  .  |  .  |  .  |  .  |
-|  Section 4 – Règles d’autorisation pour la DMZ  |||||||
+|  Section 4 – Règles d’autorisation des flux métiers  |||||||
 | . |  .  |  .  |  .  |  .  |  .  |  .  |
 | . |  .  |  .  |  .  |  .  |  .  |  .  |
-|  Section 5 – Règle d’interdiction finale  |||||||
+|  Section 5 – Règles “antiparasites” (facultatif)  |||||||
+| . |  .  |  .  |  .  |  .  |  .  |  .  |
+| . |  .  |  .  |  .  |  .  |  .  |  .  |
+|  Section 6 – Règle d’interdiction finale  |||||||
+| . |  .  |  .  |  .  |  .  |  .  |  .  |
 ==== Document 3 : extrait « des recommandations pour la définition d’une politique de filtrage réseau d’un pare-feu » publiées par l’ANSSI ====
@@ Ligne 172: / Ligne 176: @@
   * Il est recommandé de renommer la politique de filtrage de production
   * Il est recommandé de définir une politique de journalisation locale et une politique de journalisation centralisée
-====Document 3 : extrait « des recommandations pour la définition d’une politique de filtrage réseau d’un pare-feu » publiées par l’ANSSI====
-L’organisation proposée est construite selon un modèle de sécurité positif (tout ce qui n’est pas explicitement autorisé est interdit), il est possible de la décomposer en 6 sections rigoureusement ordonnées de la façon suivante :
-^  Ordre  ^  Contenu  ^
-|Section n°1	|Règles d’autorisation des flux à destination du pare-feu|
-|Section n°2	|Règles d’autorisation des flux émis par le pare-feu|
-|Section n°3	|Règle de protection du pare-feu|
-|Section n°4	|Règles d’autorisation des flux métiers|
-|Section n°5	|Règles "antiparasites" (facultatif)|
-|Section n°6	|Règle d’interdiction finale|
-=== Section n°1 ===
-Les règles de sécurité qui autorisent l’accès aux services proposés par un pare-feu doivent être regroupées dans la politique de filtrage. Ces règles sont peu nombreuses et doivent être définies précisément, en particulier au niveau de leurs adresses sources et de leurs services (HTTPS pour l’accès à l’interface d’administration, SNMPv3 pour la supervision).
-=== Section n°2 ===
-Les règles de sécurité qui autorisent les flux ayant pour origine le pare-feu doivent être regroupées dans la politique de filtrage. Ces règles sont peu nombreuses et doivent être définies précisément : service d’envoi de journaux, service d’alerte (trap SNMP), service de sauvegarde (SSH ou HTTPS).
-===
-Section n°3 ===
-Cette section ne comporte qu’une seule règle dite de protection de la passerelle :
-^  Source  ^  Destination  ^  Service  ^  Action  ^  Journalisation  ^
-|Toutes	|Toutes les interfaces du pare-feu	|Tous	|Interdire	|Oui|
-La mise en place d’une règle de protection du pare-feu est impérative pour prévenir l’ouverture de flux non légitimes à destination de la passerelle ; la journalisation de cette règle permet de conserver la trace de ces flux illégitimes.
-=== Section n°4 ===
-Les règles qui autorisent les flux métiers doivent être regroupées et organisées selon une logique établie et adaptée au contexte. Ces règles constituent l’essentiel de la politique de filtrage, elles doivent être définies précisément au niveau de leurs adresses sources, de leurs adresses de destination et de leurs services.
-Il faut être le plus restrictif possible en n’autorisant que le strict nécessaire permettant de respecter les besoins métiers liés à chaque zone du réseau. Éviter lorsque cela est possible des plages d’adresse IP trop larges, des plages de ports trop étendues.
-=== Section n°5 (facultatif) ===
-Les règles "antiparasites" peuvent être utilisées pour alléger les journaux de la passerelle, mais doivent être établies en accord avec la politique globale de journalisation de l’architecture. Elles permettent de rendre les fichiers journaux plus exploitables en évitant de garder des traces (exemple : flux de diffusion netbios, dhcp) inutiles.
-=== Section n°6 ===
-L’ajout d’une règle explicite d’interdiction finale journalisée garantit l’application du modèle de sécurité positif (tout ce qui n’a pas été autorisé précédemment est interdit) et permet de conserver la trace des flux non légitimes.
-NB : La règle de blocage par défaut explicite avec journalisation préconisée par l’ANSSI est sujette à interprétation. L’entreprise Stormshield recommande généralement d’éviter cette règle car mal configurée, elle peut générer un bruit conséquent à l’intérieur des fichiers journaux et les rendre ainsi difficilement exploitables. Ainsi cette règle n’est pertinente que si l’ensemble des protocoles bloqués générant du bruit inutile n’est pas journalisé au préalable (NETBIOS par exemple). C’est d’ailleurs ce que recommande clairement l’ANSSI dans son guide de configuration.
-Conseils généraux
-  * Définir une convention de nommage à respecter ;
-  * Définir une convention de coloration pour avoir une meilleure analyse visuelle ;
-  * Expliciter à l’aide de commentaires les règles de filtrage créées ;
-  * Dans la mesure du possible, limiter l’utilisation de règles implicites ;
-  * Les consignes de filtrage doivent être documentées ;
-  * La politique de filtrage doit être testée et passée en revue deux fois par an.
-==== Document 4 : extrait « des recommandations pour la sécurisation d’un pare-feu Stormshield SNS » publiées par l’ANSSI====
-=== Précisions sur la gestion du réseau d’Administration ===
-Idéalement, un équipement SNS doit être raccordé à un réseau d’administration sur une interface Ethernet dédiée (une sous-interface virtuelle peut être envisagée si aucune interface Ethernet physique n’est disponible). Il ne doit être administrable que depuis ce réseau et cette interface. La politique de filtrage doit être configurée afin de n’autoriser l’accès aux services d’administration de l’équipement (HTTPS et non SSH) qu’aux adresses IP des postes d’administration déclarées dans le groupe défini pour cet usage.
-L’administrateur réseau doit séparer ses usages d’administration et de bureautique. Ainsi, son poste dédié à l’administration ne doit pas avoir accès à Internet (où un accès restreint aux serveurs de mises à jour de l’OS uniquement). Il est également d’usage de se connecter avec un compte utilisateur restreint. Lorsqu’il souhaite avoir des usages bureautiques, il doit utiliser un autre poste présent en dehors du réseau d’Administration. Il est envisageable de pouvoir se connecter au poste « bureautique » depuis le poste d’Administration à l’aide d’un protocole de « bureau à distance » comme RDP. La mise en place d’un poste unique mais avec des conteneurs ou VM qui séparent et isolent les usages peut être aussi envisagée (cf QubesOS ou Clip OS).
-=== La technologie Anti-usurpation ===
-Il est important d’activer l’anti-spoofing sur les interfaces réseaux internes. Cette technologie permet au firewall de s’assurer que les adresses IP sources des paquets reçus sont bien légitimes. Sur SNS, lorsque vous définissez une interface comme une interface protégée. Le mécanisme anti-spoofing est effectif.
-== Recommandations générales ==
-   * Il est recommandé de désactiver les interfaces réseau non utilisées.
-   * Il est recommandé d’interdire explicitement les plages d’adresses du groupe RFC 5735 provenant d’Internet.
-   * Il est recommandé de renommer la politique de filtrage de production
-   * Il est recommandé de définir une politique de journalisation locale et une politique de journalisation centralisée