Outils pour utilisateurs

Outils du site


reseau:stormshield:fiche5

Différences

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

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
reseau:stormshield:fiche5 [2021/10/05 13:50]
techer.charles_educ-valadon-limoges.fr [Mise en place des règles de filtrage]
reseau:stormshield:fiche5 [2022/10/10 23:04] (Version actuelle)
techer.charles_educ-valadon-limoges.fr [Mise en place des règles de filtrage]
Ligne 34: Ligne 34:
  
 <WRAP center round important> <WRAP center round important>
-Par défaut, tout trafic qui n’est pas autorisé explicitement par une règle de filtrage est **bloqué**.+Par défaut, tout trafic qui n’est pas autorisé explicitement par une règle de filtrage est **bloqué** (règle n° 3 de la politique de sécurité « Block all »).
 </WRAP> </WRAP>
  
 +Dans les recommandations pour la définition d’une politique de filtrage réseau d’un pare-feu publiées par l’ANSSI le 30 mars 2013, il est précisé que la règle finale qui consiste à bloquer et journaliser tout ce qui n’est pas autorisé par les règles précédentes doit apparaître explicitement à la fin de la politique de filtrage appliquée. L’ajout de cette règle explicite 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 s’assurer que la trace des flux non légitimes est conservée.
 +{{ :reseau:stormshield:sns_92.png |}}
  
 Les firewalls SNS utilisent la technologie **SPI (Stateful Packet Inspection)** qui leur permet de garder en mémoire l’état des connexions TCP et des pseudo-connexions UDP et ICMP afin d’en assurer le suivi et de détecter d’éventuelles anomalies ou attaques.  Les firewalls SNS utilisent la technologie **SPI (Stateful Packet Inspection)** qui leur permet de garder en mémoire l’état des connexions TCP et des pseudo-connexions UDP et ICMP afin d’en assurer le suivi et de détecter d’éventuelles anomalies ou attaques. 
Ligne 44: Ligne 46:
 Les réponses faisant partie de la même connexion sont implicitement autorisées. Ainsi, nous n’avons nul besoin d’une règle de filtrage supplémentaire pour autoriser les paquets réponse d’une connexion établie au travers du firewall. Les réponses faisant partie de la même connexion sont implicitement autorisées. Ainsi, nous n’avons nul besoin d’une règle de filtrage supplémentaire pour autoriser les paquets réponse d’une connexion établie au travers du firewall.
  
-La figure suivante présente l’ordre d’application des règles de filtrage et de NAT, il est important de noter que les paquets sont filtrés avant d’être **natés** c’est pourquoi nous avons mis au point les règles de NAT avec une politique **Pass all**+La figure suivante présente l’ordre d’application des règles de filtrage et de NAT, il est important de noter que les paquets sont filtrés **avant** la phase de traduction (NAPT)
-{{ :reseau:stormshield:sns_81.png |}}+{{ :reseau:stormshield:sns_93.png |}}
  
  
-Le premier paquet reçu est confronté aux règles de filtrage des différents slots suivant l’ordre présenté dans la figure ci-dessus.  
  
-Dès que les éléments du paquet correspondent à une règle dans un slot, l’action de la règle (bloquer ou autoriser) est appliquée et le paquet n’est plus confronté aux règles suivantes+Le premier paquet reçu est confronté aux règles de filtrage des différents niveaux suivant l’ordre présenté dans la figure ci-dessus
  
-Si aucune règle de filtrage ne correspond, le paquet est bloqué par défaut. +Dès que les éléments du paquet correspondent à une règle dans un niveau, l’action de la règle (bloquer ou autoriser) est appliquée et le paquet n’est plus confronté aux règles suivantes.  
 + 
 +Si aucune règle de filtrage ne correspond, **le paquet est bloqué par défaut**.  
 + 
 +Dans le cas où le paquet est autorisé, il est confronté aux règles de **NAT** des différents niveaux toujours suivant l’ordre présenté ci-dessus. 
 +  * **Le filtrage implicite** regroupe les règles de filtrage pré-configurées ou ajoutées dynamiquement par le pare-feu pour autoriser ou bloquer certains flux après l’activation d’un service. Par exemple, une règle implicite autorise les connexions à destination des interfaces internes du pare-feu SNS sur le port HTTPS (443/TCP) afin d’assurer un accès continu à l’interface d’administration Web. Autre exemple, dès l’activation du service SSH, un ensemble de règles implicites sera ajouté pour autoriser ces connexions depuis toutes les machines des réseaux internes. 
 +  * **Le filtrage global** regroupe les règles de filtrage injectées au pare-feu depuis l’outil d’administration « Stormshield Management Server » (SMC) ou après affichage des politiques globales. 
 +  * **Le filtrage local** représente les règles de filtrage ajoutées par l’administrateur depuis l’interface d’administration du pare-feu SNS.
  
-Dans le cas où le paquet est autorisé, il est confronté aux règles de NAT des différents slots toujours suivant l’ordre présenté ci-dessus. 
  
 Les règles implicites sont accessibles depuis le menu **CONFIGURATION / POLITIQUE DE SÉCURITÉ Les règles implicites sont accessibles depuis le menu **CONFIGURATION / POLITIQUE DE SÉCURITÉ
 / Règles implicites**.  / Règles implicites**. 
 +{{ :reseau:stormshield:sns_94.png |}}
 Chaque règle peut être activée/désactivée. Chaque règle peut être activée/désactivée.
  
Ligne 64: Ligne 71:
 La modification de l’état de ces règles a un impact direct sur le fonctionnement des services du firewall. Pour que le service concerné fonctionne toujours, il faut s’assurer au préalable que le flux est autorisé par les règles de priorité moindre telles que globales ou locales. La modification de l’état de ces règles a un impact direct sur le fonctionnement des services du firewall. Pour que le service concerné fonctionne toujours, il faut s’assurer au préalable que le flux est autorisé par les règles de priorité moindre telles que globales ou locales.
 </WRAP> </WRAP>
 +
 +====== Analyse des politiques prédéfinies de filtrage ======
 +La découverte des règles déjà définies dans les deux premières politiques prédéfinies de filtrage, permet de comprendre le fonctionnement des règles de filtrage sur un pare-feu Stormshield.
 +
 +  * Ouvrir le menu **Configuration / Politique de sécurité / Filtrage et NAT / Filtrage**
 +  * Dans la liste déroulante des politiques de sécurité, choisir **(1) Block all**.
 + 
 +{{ :reseau:stormshield:sns_95.png |}}
 +Cette politique bloque presque tous les flux (règle N°3) sauf ceux définis par les règles 1 et 2.
 +
 +**La règle numéro 1** autorise l’accès en https et sur le port prédéfini **1300 pare-feu_srv** à toutes les interfaces du pare-feu, elle permet donc l’administration à distance depuis n’importe quel réseau.
 +
 +**La règle numéro 2** autorise les requêtes **ICMP Echo** vers toutes les interfaces du pare-feu, afin de pouvoir vérifier la présence du pare-feu à l’aide des commandes ICMP.
 +
 +  * Dans la liste déroulante des politiques de sécurité, choisir **(2) High**.
 +
 +{{ :reseau:stormshield:sns_96.png |}}
 +Cette politique est un peu moins restrictive que la précédente, elle autorise plus de chose à partir des réseaux internes.
 +
 +**La règle numéro 1** autorise l’accès à des services web en **http, https, dns** ⇒ elle permet l’accès à des sites web.
 +
 +**La règle numéro 2** autorise l’accès à des services **ftp**.
 +
 +**La règle numéro 3** autorise l’accès à des services de messagerie en **imap, smtp, pop3** elle permet l’envoi et la réception de messages.
 +
 +**La règle numéro 4** autorise les requêtes **ICMP Echo** vers n’importe quelle destination des réseaux internes, afin de pouvoir vérifier la présence du pare-feu et des services en DMZ à l’aide des commandes ICMP. 
 +
 +<WRAP center round info >
 +Vous remarquerez que pour toutes ces règles la colonne « Inspection de sécurité » stipule **IPS(Intrusion Prevention System)** qui est le niveau le plus élevé de filtrage avec inspection du contenu et le cas échéant blocage si l’on suspecte un comportement anormal ou une tentative d’intrusion.
 +</WRAP>
 +
 +
 +
  
 Les règles de filtrage font partie d’une politique présentée précédemment dans la partie **Traduction Les règles de filtrage font partie d’une politique présentée précédemment dans la partie **Traduction
Ligne 79: Ligne 119:
 ===== Mise en place des règles de filtrage ===== ===== Mise en place des règles de filtrage =====
 Vous allez mettre en place une nouvelle politique de sécurité, il faudra commencer par désactiver la règle de filtrage **Pass all** et ajouter les règles de filtrage qui respecteront le cahier des charges décrit ci-après. Vous allez mettre en place une nouvelle politique de sécurité, il faudra commencer par désactiver la règle de filtrage **Pass all** et ajouter les règles de filtrage qui respecteront le cahier des charges décrit ci-après.
- 
-Au besoin ajoutez les adresses IP privées de vos serveurs et les IP publiques des serveurs de vos voisins dans les **Objets Réseaux** (cf Partie 3 Objets réseau). 
-|**srv_dns_priv** : 172.16.x.x0|**srv_dns_pub_X** : 192.36.253.x0| 
-|**srv_web_priv** : 172.16.x.x1|**srv_web_pub_X** : 192.36.253.x1| 
-|**srv_ftp_priv** : 172.16.x.x2|**srv_ftp_pub_X** : 192.36.253.x2| 
-|**srv_mail_priv** : 172.16.x.x3|**srv_mail_pub_X** : 192.36.253.x3| 
  
  
Ligne 156: Ligne 190:
     * **Port dest** : Port destination, ici **smtp**.     * **Port dest** : Port destination, ici **smtp**.
 {{ :reseau:stormshield:sns_89.png |}} {{ :reseau:stormshield:sns_89.png |}}
 +
 +c) Seul votre serveur DNS interne (172.16.x.10) sera autorisé à résoudre vers l’extérieur, et plus précisément vers l’IP publique du DNS de Google (8.8.8.8).
 +  * Cliquez **Nouvelle règle /règle simple** 
 +    * **Action** : **Passer** ;
 +    * **Source** : **srv_dns_priv** ; 
 +    * **Destination** : DNS_Google ;
 +    * **Port dest** : Port destination, ici **dns_udp**.
 +{{ :reseau:stormshield:sns_90.png |}}
 +Double cliquez sur le symbole **off** des règles pour les passer à l’état **on**, puis cliquez **Appliquer et Oui, activer la politique**.
 +
 +Les règles actuellement mises en place sont les suivantes :
 +{{ :reseau:stormshield:sns_91.png |}}
 +
 +<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).
 +
 +</WRAP>
 +
 +==== Trafics sortants : ====
 +
 +  * Votre réseau interne (DMZ incluse) doit pouvoir joindre les serveurs FTP et Web de vos voisins.
 +  * Un stagiaire, nouvellement arrivé dans l’entreprise, a l’interdiction d’effectuer la moindre requête FTP. L’adresse IP de sa machine est 192.168.x.200.
 +  * Votre serveur de messagerie peut envoyer des mails vers les serveurs publiés par vos voisins.
 +  * Votre réseau interne, à l’exception de vos serveurs en DMZ, doit pouvoir naviguer sur les sites web d’Internet en HTTP et HTTPS, sauf sur les sites de la République de Corée (test avec www.visitkorea.or.kr).
 +  * L’accès au site https://www.cnn.com doit être bloqué depuis le réseau interne, en utilisant un objet FQDN.
 +
 +
 +==== Trafics entrants : ====
 +  * Les utilisateurs de l'autre agence peuvent joindre vos serveurs Web et FTP ; ces événements doivent être tracés.
 +  * Le serveur mails de l'autre agence est autorisés à transmettre des e-mails à votre serveur de  messagerie
 +  * Les utilisateurs de l'autre agence sont autorisés à pinger l’interface externe de votre SNS ; cet événement  devra lever une alarme mineure.
 +  * Le formateur est autorisé à pinger l’interface externe de votre SNS. 
 +  * Les utilisateurs de l'autre agence peuvent se connecter à votre SNS : via l’interface web et en SSH. Ces événements devront lever des alarmes majeures.
 +
  
 ===== Retour Accueil Stormshield ===== ===== Retour Accueil Stormshield =====
  
   * [[:reseau:stormshield:accueil|Stormshield]]   * [[:reseau:stormshield:accueil|Stormshield]]
reseau/stormshield/fiche5.1633434633.txt.gz · Dernière modification: 2021/10/05 13:50 de techer.charles_educ-valadon-limoges.fr