TÉLÉCHARGER - Renforcement des dispositifs Juniper

Introduction

Raisonnement

Une implémentation de pare-feu « hors boîte » n’est pas entièrement sécurisée et doit être renforcée. Ce document détaille les différents aspects de sécurité des pare-feux Juniper et des normes mises en œuvre pour sécuriser les pare-feux Juniper.

Objectif

Ce document a pour objectif de définir une norme de base de sécurité pour les implémentations de pare-feux Juniper par les administrateurs de pare-feux.

Portée

Ces normes de sécurité couvrent l’implémentation Screen OS du pare-feu Juniper.

Toutefois, pour certaines configurations, ces exigences minimales et certaines fonctionnalités de ces normes peuvent ne pas être pratiques à mettre en œuvre. Pour les exceptions, les administrateurs système doivent documenter les raisons pour lesquelles elles ne respectent pas pleinement ces normes et demander une exemption au département de sécurité.

Public cible

Les administrateurs de pare-feux ont la responsabilité principale de mettre en œuvre ces normes. Lors de leurs revues et inspections, les auditeurs doivent utiliser ce document pour vérifier le respect des normes.

Les gestionnaires commerciaux peuvent lire les raisons derrière chaque point des normes afin de mieux comprendre l’importance de les appliquer à leurs environnements.

Mise en œuvre

Les administrateurs de pare-feux Juniper doivent utiliser ces normes pour établir les procédures d’installation et d’exploitation.

Aperçu de la sécurité des pare-feux Juniper

Cette section donne un bref aperçu des différents aspects de la sécurité des pare-feux Juniper. Les détails du renforcement pour chaque aspect sont présents dans les sections suivantes du document.

L’environnement de sécurité opérationnel du pare-feu Juniper comprend divers aspects :

• Configuration initiale du dispositif et de Screen OS

• Configuration du dispositif

• Gestion du dispositif

• Gestion des utilisateurs

• Services

• Accès au système

• Journalisation et surveillance du système

• Journalisation et surveillance des politiques

Configuration du dispositif et de Screen OS

La sécurité du pare-feu Juniper Screen OS débute par une configuration sécurisée. Les facteurs influant sur cela incluent l’utilisation de la version correcte de Screen OS.

Identifier correctement le dispositif pour prévenir les manipulations physiques

L’emballage extérieur ne doit pas présenter de dommages, ni de preuve que des personnes non autorisées l’ont ouvert. Si le carton présente des dommages qui permettraient au dispositif d’être déballé ou échangé, cela pourrait être une preuve de manipulation.

Chaque boîte emballée arrive avec un ruban personnalisé pour indiquer que Juniper ou un fabricant autorisé a emballé le dispositif. Le ruban est unique ; le mot « Juniper » est imprimé répétitivement tout au long du ruban. Si le ruban n’est pas présent, cela pourrait être une preuve de manipulation.

L’emballage intérieur ne doit pas présenter de dommages ou de preuve de manipulation. Le sac en plastique ne doit pas avoir de grand trou et l’étiquette qui scelle le sac en plastique ne doit pas être détachée ou manquante. Tout dommage au sac ou à l’étiquette pourrait être une preuve de manipulation.

Vérifier la version correcte du matériel et du logiciel

Pour vérifier que le produit reçu est la version correcte du matériel et du logiciel, exécutez la commande suivante depuis l’interface CLI :

get system

La sortie de cette commande inclut deux éléments clés : la version du matériel et la version du logiciel. Les versions du matériel et du logiciel doivent correspondre à la cible de sécurité commune pour être pleinement conformes à la configuration évaluée selon les critères communs.

Les pare-feux sont livrés avec le logiciel Screen OS pré-installé. Toutefois, les versions du logiciel Screen OS installées sur les dispositifs peuvent varier en fonction de l’époque de fabrication des appareils de sécurité.

Mise à jour d’un pare-feu Juniper

Il faut charger l’image correcte du logiciel Screen OS sur l’appareil de sécurité.

Avant de pouvoir charger l’image du logiciel Screen OS, configurez l’interface de gestion par laquelle les images peuvent être téléchargées depuis le serveur FTP vers les appareils de sécurité. Les commandes suivantes permettent de configurer la zone et l’adresse IP pour l’interface de gestion.

set interface interface-name zone trust

set interface interface-name ip ip-address

Note : Le nom de l’interface doit être le nom de l’interface réelle connectée à l’ordinateur servant de pare-feu FTP ; à travers cette interface, les appareils de sécurité peuvent communiquer avec le pare-feu FTP. Pour les appareils de série 5, l’interface trust – liée par défaut à la zone de sécurité trust peut être utilisée. Pour les appareils Juniper NetScreen-204 et 208, vous pouvez utiliser l’interface ethernet1. Pour les appareils Juniper NetScreen-500, l’interface ethernet1/1 dans la zone de sécurité trust peut remplacer l’interface-name. Sur les appareils de sécurité haut de gamme, y compris Juniper NetScreen-ISG2000 et ISG1000, l’interface peut utiliser ethernet1/1. Juniper NetScreen-5200 et NetScreen 5400 peuvent utiliser l’interface ethernet2/1.

L’adresse ip-address doit être une adresse IP valide, qui peut être dans le même sous-réseau ou dans un sous-réseau différent du pare-feu TFTP.

Une fois configuré, utilisez les commandes suivantes pour télécharger l’image Screen OS depuis le pare-feu FTP vers l’appareil de sécurité :

save software from tftp tftp-firewall-ip Screen OS-image to flash

où tftp-firewall-ip est l’adresse IP de l’ordinateur servant de pare-feu TFTP où se trouvent les images logicielles Screen OS et Screen OS-image est le chemin relatif vers le fichier d’image logicielle Screen OS et le nom du fichier lui-même.

Par exemple, si l’image Screen OS pour l’appareil Juniper NetScreen-5GT est « ns5gt.5.4.0r4.0 » et se trouve sur le pare-feu FTP (avec l’adresse IP 10.155.95.253), dans le répertoire /tftpboot/screen OS-image/5.4/, la commande doit être la suivante :

save software from tftp 10.155.95.253 /tftpboot/screen OS-image/5.4/ns5gt.5.4.0r4.0 to flash

Le processus de téléchargement prendra quelques minutes. Une fois le processus de téléchargement terminé, l’appareil de sécurité reviendra à l’invite CLI et nécessitera un redémarrage. Émettez la commande reset et fournissez les réponses aux questions ci-dessous pour charger complètement l’image sur l’appareil de sécurité et restaurer les configurations d’usine par défaut.

reset

Configuration modifiée, sauvegarder ? [y]/n n

Redémarrage du système, êtes-vous sûr ? y/[n] y

L’appareil de sécurité reviendra à l’invite de connexion. À ce stade, l’appareil de sécurité a été complètement chargé avec la version correcte du logiciel Screen OS.

Mises à jour de Screen OS

Mettez à jour les pare-feux Screen OS avec les mises à jour recommandées par le fournisseur, dans le cadre de chaque trimestre.

Configuration du dispositif

Restaurer les paramètres par défaut

Restaurez le pare-feu à son mode opérationnel et configurations d’usine par défaut avant de mettre l’appareil dans un mode opérationnel différent, y compris le mode authentifié transparent (aussi appelé mode VPN transparent) ou le mode NAT/Route authentifié (aussi appelé mode VPN NAT/Route) ou avant d’effectuer toute configuration pour un test spécifique.

Utilisez les commandes unset all et reset avec les réponses suivantes pour restaurer le mode opérationnel et les configurations par défaut pour l’appareil.

unset all

Erase all system config, are you sure y/ [n]? Y

reset

Configuration modified, save? [y]/n n

System reset, are you sure? y/[n] y

set clock mm/dd/yyyy hh:mm

get system

"System in NAT/Route mode" indique qu’il fonctionne en mode NAT/Route

"System in transparent mode" indique qu’il fonctionne en mode transparent

Tous les appareils de sécurité sont, par défaut, configurés en mode NAT/Route sans VPN.

Pour garantir que l’appareil de sécurité est en mode conforme aux critères communs EAL4 évalués, suivez l’une des trois séquences suivantes selon la configuration souhaitée :

Mode NAT/Route non authentifié

Mode NAT/Route authentifié

VPN basé sur le routage

VPN basé sur la politique

Mode transparent authentifié

Mode NAT/Route authentifié

Configurez le pare-feu en mode NAT/Route authentifié en utilisant un VPN basé sur le routage ou un VPN basé sur la politique. Vous pouvez configurer les deux, un VPN basé sur le routage et un VPN basé sur la politique, en mode NAT/Route authentifié.

Seul la clé manuelle est prise en charge dans la configuration évaluée, c’est-à-dire que la clé automatique ne peut pas être utilisée. Faites attention à sélectionner les valeurs de clé manuelle de manière à ce qu’elles suivent les mêmes règles que les mots de passe administrateurs. Distribuez les clés manuelles en utilisant une méthode sécurisée afin de garantir qu’elles ne sont pas accessibles publiquement.

VPN basé sur le routage

Configurez l’appareil de sécurité correspondant avec un VPN basé sur le routage en mode NAT/Route authentifié.

VPN basé sur la politique

Configurez l’appareil de sécurité correspondant avec un VPN basé sur la politique en mode NAT/Route authentifié.

Convention de nommage du pare-feu

Pare-feux de branche : (Convention de nommage non définie)

Pare-feux du centre de données : (Convention de nommage non définie)

Configuration des options d’écran

Les appareils de sécurité doivent empêcher tous les types d’attaques de type déni de service (DoS) et de signatures d’attaques sur chaque zone de sécurité pour éviter que ces types d’attaques se produisent sur le réseau.

Pour afficher les options d’écran par défaut pour une zone de sécurité spécifique, exécutez la commande suivante :

get zone zone-name screen

Par défaut, les options d’écran activées pour la zone de sécurité Untrust/V1-Untrust (et les interfaces dans la zone Untrust/V1-Untrust) dans Screen OS 5.0 :

Protection contre les attaques de type Tear-drop : activée

Protection contre les attaques de type SYN Flood (200) : activée

Seuil d’alarme : alarm-threshold

Taille de file d’attente : Q-size

Valeur d’expiration : 20

Seuil source : src-threshold

Seuil de destination : dst-threshold

Supprimer MAC inconnu (mode transparent uniquement) : désactivé

Protection contre les attaques Ping-of-Death : activée

Filtre des options IP de route source : activé

Protection contre les attaques Land : activée

Les seuils d’alarme, Q-size, src-threshold et dst-threshold sont dépendants de la plateforme, comme indiqué dans le tableau ci-dessous.

Pour les zones de sécurité Trust/V1-Trust et DMZ/V1-DMZ (et les interfaces dans les zones Trust et DMZ), aucune option d’écran n’est activée par défaut.

Fonction d’écran ne générant que des alarmes sans supprimer les paquets : désactivée

Pour désactiver toutes les options d’écran par défaut pour la zone Untrust/V1-Untrust, les commandes suivantes sont utilisées :

unset zone untrust screen tear-drop

unset zone untrust screen syn-flood

unset zone untrust screen ping-death

unset zone untrust screen ip-filter-src

Lorsque la zone de sécurité n’a pas d’options d’écran activées, le message suivant s’affiche :

"Screen function only generate alarm without dropping packet: OFF"

La commande CLI suivante active tous les écrans par zone (et est appliquée à toutes les interfaces de cette zone) :

set zone zone-name screen block-frag

set zone zone-name screen component-block

set zone zone-name screen fin-no-ack

set zone zone-name screen icmp-flood

set zone zone-name screen icmp-fragment

set zone zone-name screen icmp-large

set zone zone-name screen ip-bad-option

set zone zone-name screen ip-filter-src

set zone zone-name screen ip-loose-src-route

set zone zone-name screen ip-record-route

set zone zone-name screen ip-security-opt

set zone zone-name screen ip-spoofing

set zone zone-name screen ip-stream-opt

set zone zone-name screen ip-strict-src-route

set zone zone-name screen ip-sweep

set zone zone-name screen ip-timestamp-opt

set zone zone-name screen land

set zone zone-name screen limit-session

set zone zone-name screen mal-url code-red

set zone zone-name screen ping-death

set zone zone-name screen port-scan

set zone zone-name screen syn-ack-ack-proxy

set zone zone-name screen syn-fin

set zone zone-name screen syn-flood

set zone zone-name screen syn-frag

set zone zone-name screen tcp-no-flag

set zone zone-name screen tear-drop

set zone zone-name screen udp-flood

set zone zone-name screen unknown-protocol

set zone zone-name screen winnuke

Les commandes ci-dessus doivent être exécutées pour les zones internes et externes (c’est-à-dire Trust et Untrust) afin de protéger les réseaux internes et externes. Lorsque l’appareil de sécurité fonctionne en mode NAT/Route, exécutez les commandes ci-dessus pour les zones de sécurité Trust et Untrust.

Lorsque l’appareil de sécurité fonctionne en mode « transparent », (y compris le mode transparent authentifié), exécutez les commandes ci-dessus pour les zones de sécurité V1-Trust et V1-Untrust.

Vous devez exécuter les mêmes commandes (comme indiqué ci-dessus) pour chaque zone de sécurité supplémentaire.

Lorsque l’appareil de sécurité fonctionne en mode NAT/Route (y compris le mode NAT/Route non authentifié et le mode NAT/Route authentifié), activez le rejet des paquets sans adresse IP source ou ayant une adresse IP source non routable en utilisant la commande suivante :

set zone zone-name screen ip-spoofing drop-no-rpf-route

« zone-name » est le nom de la zone de sécurité telle que Trust ou Untrust.

Par exemple, lorsque le pare-feu fonctionne en mode NAT/Route, pour activer la fonctionnalité de rejet des paquets pour la zone de sécurité trust et untrust, émettez les commandes suivantes :

set zone trust screen ip-spoofing drop-no-rpf-route

set zone untrust screen ip-spoofing drop-no-rpf-route

Assurez-vous d’exécuter la même commande (comme indiqué ci-dessus) pour toute zone de sécurité de couche 3 utilisée. Lorsque vous modifiez l’option de blocage HTTP, les modifications ne s’appliquent qu’aux sessions créées après la mise en œuvre de cette option de blocage.

Configuration de la protection contre les falsifications IP

Configurez la protection contre les falsifications IP en utilisant l’option d’écran « ip-spoofing » comme indiqué ci-dessus dans la section « Configuration des options d’écran ». Cela inclut les configurations intrazone où le trafic VPN se trouve dans la même zone que le trafic déchiffré. Toutefois, selon la configuration mise en œuvre (en particulier les configurations interzone), les étapes suivantes sont nécessaires pour être adéquatement protégé contre les attaques de falsification IP.

Les directives suivantes pour les modes Authentifié NAT/Route et Authentifié Transparent doivent compléter les directives fournies dans la section précédente « Définition d’une politique pour autoriser le trafic ».

L’option d’écran « IP-Spoofing » est ignorée – un ensemble d’adresses et de politiques doit être défini pour autoriser uniquement le trafic autorisé, en excluant les adresses IP falsifiées.

Lorsque le pare-feu fonctionne en mode Authentifié NAT/Route ou Authentifié Transparent, l’option d’écran « IP-Spoofing » est « ignorée ». Par conséquent, définissez un ensemble d’adresses et de politiques pour autoriser le trafic, en excluant les adresses IP falsifiées.

Gestion du dispositif

Cette section fournit des détails sur la sécurisation des aspects de gestion du dispositif de pare-feu.

Sécurisation du trafic administrateur sur le dispositif

Quatre étapes sont nécessaires pour sécuriser le trafic administrateur du dispositif :

a) Définir l’adresse IP autorisée pour l’adresse IP du client administrateur

b) Définir les options spécifiques à l’interface

i) Définir l’adresse IP de gestion pour les interfaces

ii) Désactiver les services de gestion inutiles

c) Changer les numéros de port pour les services administrateurs

Désactiver les commandes internes

L’administrateur du pare-feu doit désactiver les commandes internes. L’utilisation des commandes internes s’applique uniquement à des fins de dépannage et de débogage.

Pour désactiver les commandes internes, vous devez exécuter la commande suivante :

set common-criteria no-internal-commands

Pour utiliser les commandes internes (par exemple, « debug flow basic » et « get dbuf stream », « debug ids sat ») à des fins de dépannage et de débogage, utilisez la commande suivante :

unset common-criteria no-internal-commands

Note : Utilisez les commandes internes « debug ids sat » pour ISG-1000, ISG-2000, NS-5200 et NS-5400.

Désactiver Telnet pour la gestion du dispositif

L’utilisation de Telnet est déconseillée sur les pare-feux Juniper. Utilisez SSH, version 2.0, pour gérer le pare-feu Juniper :

Pour ce faire :

Désactiver Telnet sur l’interface de gestion

Activer SSH

Contrôle des réinitialisations matérielles non autorisées

Pour désactiver la récupération via la connexion, utilisez la commande suivante :

unset admin device-reset

Pour désactiver la récupération via le trou, utilisez la commande suivante :

unset admin hw-reset

Lorsqu’elles sont désactivées, les administrateurs du pare-feu doivent activer la réinitialisation correspondante afin d’effectuer toute activité nécessitant un redémarrage du pare-feu.

Restriction de l’accès à distance

L’accès à la gestion doit être limité au port de console connecté localement, plutôt que aux paramètres par défaut d’usine.

Pour limiter l’accès à la gestion au port de console, l’interface qui est par défaut dans la zone de sécurité V1-Trust ou Trust doit avoir l’accès à la gestion désactivé.

Toutes les autres interfaces ont l’accès à la gestion désactivé par défaut.

Pour désactiver la gestion de l’interface, émettez la commande CLI suivante :

unset interface interface-name manage

Gestion des utilisateurs

Les administrateurs des appareils de sécurité doivent choisir des noms d’utilisateur et des mots de passe qui non seulement ont une longueur d’au moins huit caractères et utilisent autant de types de caractères que possible. Il est nécessaire de mélanger les lettres minuscules et majuscules pour assurer une protection adéquate. En outre, les noms d’utilisateur et les mots de passe faciles à deviner ne sont pas sécurisés.

Les appareils de sécurité sont livrés avec un nom d’utilisateur et un mot de passe par défaut de « netscreen ». Changez le mot de passe par défaut dès que possible pour empêcher l’accès non autorisé.

La durée recommandée entre les changements de mot de passe est de 30 jours maximum pour atténuer les effets d’une identité d’administrateur compromise.

Définition/Changement des restrictions de longueur du mot de passe

Pour garantir que les mots de passe de huit caractères ou plus sont toujours utilisés, vous devez d’abord définir la commande suivante :

set admin password restrict length password-length

où password-length est une valeur décimale égale ou supérieure à 8 et inférieure ou égale à 31. Elle doit également suivre la politique de mot de passe.

Définition/Changement du nom d’administrateur et du mot de passe

Les commandes CLI suivantes, dans l’ordre, sont nécessaires pour définir un nouveau nom d’administrateur et un mot de passe :

set admin name name-string

set admin password password-string

où name-string et password-string doivent être remplacés par le nom d’utilisateur réel et le mot de passe de l’administrateur.

Gestion des politiques

Supprimer la politique par défaut autorisant

Le pare-feu pourrait avoir une politique par défaut autorisant le trafic traversant le dispositif depuis l’interface dans la zone Trust vers l’interface dans la zone Untrust. Supprimez cette politique par défaut pour éviter une autorisation involontaire de l’information traversant le dispositif. Utilisez la commande CLI :

unset policy id 1

Journalisation du trafic refusé

Par défaut, l’appareil de sécurité rejette tout trafic qui ne correspond à aucune politique « autorisée ». Par conséquent, ajoutez une politique à la fin de la liste des politiques afin de journaliser le trafic refusé qui ne correspond à aucune politique :

set policy id pol-id from scr-zone to dst-zone any any any deny log

... où pol-id est l’ID de la politique, scr-zone et dst-zone sont respectivement la zone source d’où le trafic provient et la zone de destination vers laquelle le trafic arrive.

Pour chaque zone de sécurité qui a une interface réseau attribuée, ajoutez les politiques ci-dessus à la fin des tables de politique afin de garantir que le journal des paquets rejetés est conservé.

set policy id pol-id from trust to untrust any any any deny log count

set policy id pol-id from untrust to trust any any any deny log count

set policy id pol-id from trust to dmz any any any deny log count

set policy id pol-id from dmz to trust any any any deny log count

Définition d’une politique pour autoriser le trafic

Deux étapes importantes à suivre lors de la création d’une politique de sécurité :

• Activer le comptage et la journalisation pour maintenir les informations de journal d’audit pour le trafic passant à travers le dispositif.

• Doit être spécifique pour garantir que le trafic autorisé est intentionnel et non inclus dans une politique générale.

Utilisez une adresse IP source spécifique (src-addr), une adresse IP de destination (dst-addr), une zone source (src-zone), une zone de destination (dst-zone), un protocole et un service (servicename) si possible. Un exemple où il peut ne pas être pertinent d’être spécifique est pour le trafic destiné à un réseau externe pour un accès web général.

Après avoir créé et configuré les adresses source et de destination, configurez la politique avec le comptage et la journalisation en utilisant la commande suivante :

set policy id id-num from src-zone to dst-zone src-addr dst-addr servicename

action log count

... où « id-num » est le nombre décimal représentant l’ID de la politique et « action » peut être « permit » pour autoriser un service spécifique à passer de l’adresse source à travers l’appareil de sécurité vers l’adresse de destination ; ou « deny » pour bloquer le service qui passe à travers l’appareil de sécurité.

Ordre des politiques

L’ordre des politiques est important, car les politiques correspondent dans l’ordre en commençant par la première dans la liste des politiques et en se déplaçant à travers la liste. La première politique correspondante s’applique au trafic réseau pour déterminer l’action à effectuer. Par défaut, une nouvelle politique créée apparaît à la fin de la liste des politiques.

Il existe une option qui permet de positionner une politique au sommet de la liste plutôt que de laisser la politique apparaître à la fin. Dans l’interface CLI, ajoutez le mot-clé « top » à la commande « set policy » :

For example,

set policy id 6 top from trust to untrust trust-HostA untr-NetworkB http

permit log

La politique nouvellement créée peut également être positionnée à n’importe quel emplacement dans la liste des politiques en utilisant l’option de mot-clé « before » à la commande CLI « set policy » :

For example:

set policy id 4 before 98 from untrust to trust untr-NetworkB trust-HostA ftp

permit log

Si des politiques globales sont utilisées, remplacez la politique ci-dessus qui s’exécute avant toute politique globale. Une politique globale de refus peut être utilisée qui doit être ajoutée à la fin de la liste des politiques globales :

set policy global id pol-id any any any deny log count

Journalisation et surveillance du système

Configurer Syslog

Vous devez configurer un pare-feu Syslog comme sauvegarde pour les informations d’audit et le stockage à long terme des journaux d’audit. Cela aidera à prévenir la perte d’informations d’audit.

Les commandes spécifiques nécessaires pour configurer un pare-feu Syslog sont :

set syslog config ip-address facilities local0 local0

set syslog config ip-address port 514

set syslog config ip-address log traffic

set syslog enable

set log module system level level-name destination syslog

où ip-address est l’adresse IP réelle du pare-feu Syslog et level-name est le niveau de gravité du journal.

Note : Vous devez entrer la commande set log une fois pour chaque niveau de message.

Les options pour level-name sont les suivantes :

emergency

alert

critical

error

warning

notification

information

debugging

Événements à journaliser

Les journaux du système contiennent les événements historiques du pare-feu et les informations d’utilisation, utilisées pour le débogage des dysfonctionnements du système et les enquêtes pénales. Par conséquent, journalisez toutes les informations critiques.

Configurez Syslog pour journaliser les éléments suivants sur chaque pare-feu :

• Chaque connexion et déconnexion

• Démarrage et arrêt du pare-feu

• Session complète

• Administration des comptes utilisateurs et groupes

• Défaillances matérielles

Rétention et archivage des journaux

Il arrive souvent qu’il soit nécessaire d’obtenir une traçabilité complète d’un processus pour des investigations de sécurité ou des buts de dépannage. Par conséquent, conservez localement les journaux du pare-feu pendant un nombre défini de jours. Il doit y avoir suffisamment d’espace de stockage alloué pour gérer cela. En outre, il doit y avoir un contrôle d’accès très strict mis en œuvre sur les journaux stockés.

Les fichiers de journal doivent être archivés hors ligne. Protégez adéquatement les journaux archivés afin que les utilisateurs non autorisés n’y aient pas accès.

Protection des fichiers de journal

Si un utilisateur malveillant parvient à modifier les fichiers de journal et à supprimer les traces d’attaque, aucune enquête ne pourra être concluante. En outre, le journal étendu pour la traçabilité d’audit. Par conséquent, protégez les fichiers de journal contre toute manipulation et stockez-les en toute sécurité.

Journaux d’activité des utilisateurs privilégiés

Les utilisateurs privilégiés ont un contrôle total sur le pare-feu. Journalisez chaque activité effectuée sur le pare-feu par ces utilisateurs.

Surveillance périodique

Pour maintenir les niveaux de sécurité sur les pare-feux Juniper, surveillez les pare-feux régulièrement. Effectuez ces tâches de surveillance à intervalles réguliers.

Configuration de la mitigation des pertes d’audit Il existe des cas où plus d’événements auditables peuvent se produire que le dispositif de sécurité n’est pas capable d’écrire sur un pare-feu Syslog. Le dispositif de sécurité doit arrêter tout événement auditable supplémentaire jusqu’à ce que la traçabilité d’audit puisse gérer plus de trafic. Un administrateur autorisé doit activer la commande suivante :

set log audit-loss-mitigation

Pour journaliser les paquets autorisés traversant le dispositif, activez l'option de journalisation sur toutes les politiques de trafic authentifiées et/ou non authentifiées.

Dans ce document, toutes les politiques autorisées incluent le mot-clé log, afin de créer des entrées de journalisation du trafic pour le trafic autorisé.

À la fin de la session d’application, les journaux du trafic autorisé sont créés.

Vous pouvez utiliser la commande suivante pour visualiser les journaux de trafic globaux, ou les journaux de trafic spécifiques à une politique :

get log traffic

get log traffic policy id

Pour journaliser les paquets rejetés, définissez la commande suivante pour terminer on l'une des interfaces du dispositif :

set firewall log-self

Pour journaliser les paquets rejetés authentifiés ; vous devez ajouter le mot-clé log à la première politique associée à un tunnel VPN. Les paquets qui ne correspondent à aucune des politiques associées au tunnel sont « rejetés ». Les entrées de journal pour ces paquets rejetés sont liées à la politique de plus haut niveau (première dans la liste « get policy all ») associée au tunnel et à la direction du flux de trafic.

Délai d'expiration inactif de la gestion du pare-feu

Interface de ligne de commande

Protégez la gestion depuis le port console en définissant un délai d'inactivité. Par défaut, les sessions console et Telnet expireront après 10 minutes d'inactivité. Il est recommandé de ne jamais définir la valeur du délai d'expiration à zéro.

Pour vérifier, exécutez la commande :

get console

Interface utilisateur Web (WebUI)

Le délai d'expiration de l'interface utilisateur Web, tout comme celui de la console, est par défaut de 10 minutes. Lors du changement du délai d'expiration de l'interface utilisateur Web, précisez un nombre de minutes (entre 1 et 999) de temps d'inactivité avant la fermeture du navigateur. Activez l'option « Activer le délai d'expiration inactif de la gestion Web » et ne la désactivez pas.

Administrateur de sécurité

Modifier le dispositif > Administration du dispositif > Gestion Web

Adresses IP autorisées

Configurez les dispositifs Juniper pour accepter les demandes de gestion uniquement à partir de sources fiables. Définissez une liste d'adresses IP autorisées. Les adresses IP autorisées incluent un paramètre de masque spécifié sous forme décimale. Les adresses IP autorisées peuvent être des hôtes / sous-réseaux. NOTE : Vous êtes limité à six entrées.

CLI

set admin manager-ip address [mask]

Tâches quotidiennes de surveillance

• Trois tentatives de connexion échouées consécutives

• Événements Syslog avec niveaux – critique, alerte ou urgence

• Ajout ou suppression non autorisée aux comptes utilisateurs et groupes

• Modifications / modifications non autorisées effectuées

• Tentatives d'accès non autorisées

  Tâches hebdomadaires de surveillance

• Fonctionnement correct du démon Syslog

• Utilisation de toutes les ressources (CPU, mémoire) dépassant les seuils prédéfinis (basés sur les chiffres de planification de capacité)

  Tâches mensuelles de surveillance

• Niveau des correctifs du pare-feu

• Redémarrages du pare-feu

• Utilisation de l'espace disque

• Changements de membres du groupe de comptes

• Vérification des sauvegardes

  Tâches biannuelles de surveillance

• Effectuer une vérification physique

  Les administrateurs du pare-feu Juniper doivent effectuer ces tâches de surveillance. Signalez tout écart observé par rapport au fonctionnement normal au service concerné.