Ci-dessous, les différences entre deux révisions de la page.
Prochaine révision | Révision précédente | ||
activite5filtrage [2022/10/16 21:24] techer.charles_educ-valadon-limoges.fr créée |
activite5filtrage [2023/10/08 22:56] (Version actuelle) techer.charles_educ-valadon-limoges.fr [Mise en place des règles de filtrage] |
||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
- | ====== Premières règles de filtrae | + | ====== |
===== Ressources ===== | ===== Ressources ===== | ||
Ligne 5: | Ligne 5: | ||
* {{ : | * {{ : | ||
* {{ : | * {{ : | ||
- | ===== Présentation de l' | + | |
- | Le pare-feu Stormshield utilise la notion d’**objet** qui permet par exemple de représenter un **serveur (Host)** ou un **réseau (Network)** en respectant une convention de nommage sur l’interface d’administration. Des précisions sur le objets sont données dans le **document 1**. | + | |
- | Sur l’interface d’administration SNS de Stormshield, | ||
- | {{ : | ||
- | ==== Document 1 : la notion d’objets réseaux dans l’interface d’administration SNS==== | ||
- | Les objets réseaux sont un concept très important à appréhender pour être à l’aise avec l’administration d’un pare-feu Stormshield. En effet, au lieu de déclarer un hôte, un réseau, un port sous forme d’adresse IP ou de numéro, cela passera par la création et l’utilisation d’un objet qui respectera une convention de nommage propre à chaque structure. | ||
- | L’intérêt d’utiliser | + | ===== Mise en place des règles |
- | * une **convention | + | Vous allez mettre |
- | | + | |
- | | + | |
- | ===== Analyse du filtrage proposé ===== | ||
- | Vous devez mettre en place des règles de règles | + | <WRAP center round todo > |
- | | + | **Étape 1 :** Copiez la politique |
- | * le serveur DNS (VLAN serveur) a l' | + | </ |
+ | * Dans la liste déroulante des politiques de sécurité, choisissez **(1) Block all**. | ||
+ | {{ : | ||
- | Voici un extrait de la table de filtrage à implémenter sur votre pare-feu. | + | Cette politique bloque presque tous les flux (règle N°3) sauf ceux définis par les règles |
- | ^ N° ^ Adresse IP Source | + | |
- | |1 | * | > | + | |
- | |2 | adresse réseau Wifi | > | + | |
- | |3 | adresse réseau utilisateur | + | |
- | |4 | adresse réseau utilisateur | + | |
+ | La règle numéro 1 autorise l’accès en **https** et sur le port prédéfini **1300 firewall_srv** à toutes les interfaces du firewall, elle permet donc l’administration à distance. | ||
+ | |||
+ | La règle numéro 2 autorise les requêtes **ICMP Echo** vers toutes les interfaces du firewall, afin de pouvoir vérifier la présence du firewall à l’aide des commandes ICMP. | ||
+ | * Cliquez **Éditer** puis **copier vers** et choisir une politique vide (par exemple **Filter 06**). | ||
+ | * Cliquez **Sauvegarder les modifications…** | ||
+ | * Dans la liste déroulante des politiques de sécurité, choisissez la politique copiée **(06) Block all**. Cliquez **Éditer** puis **Renommer** et renommez-là en **Utilisateurs_Block all & NAT**, puis **Mettre à jour**. | ||
+ | * Cliquez sur le bouton **Appliquer** puis **Activer la politique** " | ||
+ | * Dans la liste des politiques de sécurité, choisissez la politique précédente, | ||
+ | * Dans la liste des politiques de sécurité, choisissez la politique **(06) Utilisateurs_Block all & NAT** / onglet **NAT** puis cliquez sur **Coller**. La règle de NAT/PAT est copiée. | ||
<WRAP center round todo> | <WRAP center round todo> | ||
- | **Question 1 :** expliquez chacune des quatres règles puis proposer éventuellement | + | **Étape 2** : Nous allons mettre en place une première série de règles sur le Trafic sortant. Utilisez les bandeaux séparateurs en indiquant le rôle de chaque règle pour plus de lisibilité. |
- | **Question 2 :** quelles sont les deux règles générales qui manquent ? | ||
</ | </ | ||
+ | a) Votre réseau interne doit pouvoir émettre un **ping vers n’importe quelle destination**. | ||
+ | * Cliquez la règle numéro 2 qui passe en surbrillance et choisissez **Nouvelle règle / séparateur – Regroupement de règle**. | ||
+ | {{ : | ||
+ | * Cliquez le symbole du crayon et modifiez le nom du séparateur en **ping vers n’importe quelle destination**. | ||
+ | * Cliquez **Nouvelle règle / règle simple** | ||
+ | * **Action** : **Passer** ; | ||
+ | * **Source** : L’adresse IP ou le réseau source, ici **Network_internals** ; | ||
+ | * **Protocole dest** : laisser **Any**. | ||
+ | * Double-cliquez sur **Protocole** et remplir les champs comme ci-dessous : | ||
+ | * **Type de protocole** : **Protocole IP** ; | ||
+ | * **Protocole IP** : **icmp** ; | ||
+ | * **Message ICMP** : choisir au milieu de la liste **requête Echo (Ping, type 8, code 0)** | ||
+ | {{ : | ||
+ | La nouvelle règle se présente ainsi : | ||
+ | {{ : | ||
- | Le **document 2** compare une table de filtrage « papier » et une table de filtrage sur SNS. | + | |
- | <WRAP center round todo> | + | |
- | **Question 3 :** quel est, selon vous, l' | + | |
- | </ | + | |
+ | b) Votre réseau interne doit pouvoir accéder aux serveurs privés de la DMZ (DNS, WEB pour l' | ||
+ | * Ajoutez un séparateur nommé **Accès aux serveurs DMZ**, choisissez **Nouvelle règle / séparateur – Regroupement de règle** puis éditez-le. | ||
+ | * Cliquez sur **Nouvelle règle /règle simple** : | ||
+ | * **Action** : **Passer** ; | ||
+ | * **Source** : **Network_in** ; | ||
+ | * **Destination** : **srv_http_priv** | ||
+ | * **Port dest** : Port destination, | ||
+ | {{ : | ||
- | ==== Document 2 : comparaison entre une table de filtrage « papier » et une table de filtrage sur SNS==== | + | c) Seul votre résolveur DNS interne sera autorisé à résoudre vers l’extérieur, |
- | Voici à titre d' | + | |
- | ^ N° ^ Adresse IP Source | + | |
- | |1 | | + | * **Source** : **srv_dns_priv** ; |
- | |2 | 192.168.192.16 | + | * **Destination** : DNS_Google ; |
- | |3 | | + | * **Port dest** : Port destination, |
- | |4 | 192.168.20.0/ | + | {{ : |
- | |5| 192.168.20.0/ | + | |
- | |6| 192.168.30.1 | + | |
- | |7| | + | |
- | Cette table de filtrage est celle d’un pare-feu « stateful » ainsi les règles correspondantes | + | Double cliquez sur le symbole **off** des règles pour les passer |
- | Légende aidant à la compréhension du tableau suivant | + | Les règles actuellement mises en place sont les suivantes |
- | * VLAN 10 Administration = 192.168.10.0/ | + | {{ : |
- | * VLAN 20 Production = 192.168.20.0/ | + | |
- | * VLAN 30 Serveurs = 192.168.30.0/ | + | |
- | * DMZ = 192.168.0.0/ | + | |
- | * PC d’administration = 192.168.192.16/ | + | |
- | * Serveur DNS récursif = 192.168.30.1/ | + | |
- | * Serveur Mail en DMZ = 192.168.0.1/ | + | |
- | * Interfaces du pare-feu = 192.168.0.254, | + | |
- | * N’importe quelles adresses IP = * (Any, Toutes ou 0.0.0.0/ | + | |
- | * SSH = port 22/TCP, SMTP = port 25/TCP, DNS = port 53, HTTP = port 80/TCP, HTTPS = port 443/TCP, Tous les ports = *, Ports clients = >1023. | + | |
+ | <WRAP center round todo> | ||
+ | **Étape 3 :** Vous allez mettre en place une deuxième série de règles sur les trafics entrants et sortants qui respecteront le cahier des charges ci-dessous (utilisez les séparateurs en indiquant le rôle de chaque règle). | ||
- | Stormshield permet d’organiser les règles de filtrage à l’aide de séparateurs colorés afin de gagner en lisibilité. Il est également possible de donner un nom à chaque règle. Pour cela, il suffit de demander à afficher la colonne « nom » dans la table de filtrage. | ||
- | |||
- | {{ :sns_01.png |}} | ||
- | |||
- | * Le serveur mail disposant d’une adresse IP privée, son accès depuis l’extérieur se fait par l’interface externe du pare-feu. La première règle combine à la fois une autorisation au niveau du filtrage et une redirection de port. | ||
- | * L’objet Internet correspond à toutes les adresses IP différentes des adresses IP internes alors que l’objet Any englobe absolument toutes les adresses IP. | ||
- | * L’objet Firewall_all est un groupe contenant l’ensemble des interfaces du pare-feu. | ||
- | * Les ports sources ne sont, par défaut, pas représentés. Il est toutefois possible de forcer l’utilisation d’une plage de ports particulière si on le souhaite. | ||
- | |||
- | ==== Propositions de modification ==== | ||
- | <WRAP center round todo> | ||
- | Question 4 : Proposez des modifications et améliorations à apporter aux règles de filtrage en les classant dans les 5 sections préconisées. | ||
</ | </ | ||
+ | ==== Trafics sortants : ==== | ||
- | 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. | + | |
- | + | ||
- | ^ N° ^ Adresse IP Source | + | |
- | | Section 1 – Règles d’autorisation à destination du pare-feu | + | |
- | | . | . | . | . | . | . | . | | + | |
- | | . | . | . | . | . | . | . | | + | |
- | | Section 2 – Règles de protection du pare-feu | + | |
- | | . | . | . | . | . | . | . | | + | |
- | | . | . | . | . | . | . | . | | + | |
- | | Section 3 – Règles d’autorisation des flux métiers | + | |
- | | . | . | . | . | . | . | . | | + | |
- | | . | . | . | . | . | . | . | | + | |
- | | Section 4 – Règles d’autorisation pour la DMZ ||||||| | + | |
- | | . | . | . | . | . | . | . | | + | |
- | | . | . | . | . | . | . | . | | + | |
- | | Section 5 – 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 ==== | + | |
- | 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 " | + | |
- | |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, | + | |
- | + | ||
- | === 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 | + | |
- | |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 " | + | |
- | + | ||
- | === 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, | + | |
- | + | ||
- | === 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 | + | |
- | + | ||
- | ==== 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, | + | |
- | + | ||
- | L’administrateur réseau doit séparer ses usages d’administration | + | |
- | + | ||
- | === 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 | + | |
+ | ==== Trafics entrants : ==== | ||
+ | * Les utilisateurs de l' | ||
+ | * Les utilisateurs de l' | ||