Bonnes pratiques d’implémentation de règles CheckPoint

Voici quelques conseils de bonnes pratiques pour l’implémentation de règles sur un CheckPoint

  1. Faire des règles simples. Plus les règles sont simples, moins il y a d’erreurs et plus elles sont efficaces
  2. Eviter d’utiliser « ANY » en services. Toujours analysé les ports nécessaires en amont de l’implémentation
    • Même si des ports doivent être ouvert au fur et à mesure des blocages.
  3. Privilégier les objets NETWORK au lieu de plusieurs objets HOST
  4. Utiliser des groupes pour regroupes les sources/destinations/services
  5. Toujours activer l’antispoofing sur l’ensemble des interfaces du firewall
  6. Placez les règles les plus fréquemment consultés sur le dessus de la base de règles. Cela permettra d’améliorer les performances et le pare-feu est plus efficace.
    • Le firewall recherches la base de règles dans l’ordre séquentiel.
    • La première règle correspondante à une connexion est appliqué, non pas la règle qui correspond le mieux.
  7. Utiliser de bonnes conventions de nommage pour représenter les objets du réseau et les services.
  8. Mettre en œuvre la «règle Stealth » pour bloquer et de suivre les tentatives de connexion au module pare-feu.Mettre en œuvre une règle au bas de la base de règles et en fin de bandeau pour bloquer et enregistrer tout le trafic (clean-up). Firewall-1 par défaut ne trace pas le trafic qui est arrêté.
  9. Ne pas utiliser d’objet de domaine dans la base de règles. Les objets de domaine peuvent entraîner des goulots d’étranglement sur les performances.
  10. Eviter de mettre trop de niveau d’arborescence pour les bandeaux (nous conseillons de ne pas dépasser 3 niveaux pour que cela reste simple en lecture)
  11. Pour éviter d’être inondés par le trafic de diffusion broadcast tels que bootp et le NBT, créer une règle pour « droper » les paquets sans les tracer. Ident est un service utilisé par le protocole SMTP pour essayer d’identifier les clients de messagerie. En «rejectant» le service, et non en le « dropant », l’application SMTP gagne en performance car il n’a pas à attendre que la connexion ident parte en timeout.
  12. Vous préférez « Reject » à « Drop » pour certains services. Les services tels que «ident» devrait être rejeté afin de permettre une meilleure performance d’application.
    • Quand une action Drop est prise, l’expéditeur n’est pas informé.
    • Une action Reject se comporte de cette façon :
Services Actions
TCP L’expéditeur est notifié.
UDP Envoie une erreur ICMP port inaccessible à l’expéditeur.
d’autres Idem que Drop .

Au niveau de l’organisations de la base de règle, je peux vous conseiller ceci :

  1. Bandeau Firewalls
    • Contient toutes les règles ce qui provient du firewall ou à sa destination
    • Stealth Rules
  2. Bandeau Global
    • Contient toutes les règles d’autorisations globale tels que le DNS/NTP/etc…
      • Ces règles dont dites globales car elles s’appliques à plusieures zones
    • Contient toutes les règles globale d’interdiction tels que le NBT ou le Broadcast
  3. Des bandeaux par Zone (ex. LAN ou DMZ)
    • Bandeau Flux entrant
      • Contient les flux entrant
      • Drop all (src : Zone XXX (ex. LAN)/ dst : any / port : any / log)
    • Bandeau Flux sortant
      • Contient les sortant vers la Zone XXX
      • Drop all (src : Any / dst : Zone XXX / port : any / log)
  1. Bandeau Clean-UP
    • Dans ce bandeau de trouve la règle de clean-up
      • Src : Any / dst : Any / port : Any / Log

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s