[RESOLU] Problème : délai de mise en oeuvre des régles du firewall
-
bonjour tous le monde,
voilà, je suis en 2e année de BTS info, pour mon examen pratique j'ai choisi de montrer une plateforme de firewall basée sur PFsense et, pour faire simple, mon problème est le temps que met PFsense à appliquer RÉELLEMENT les règles de firewall (j'aimerai pouvoir le réduire afin de rendre possible son utilisation lors de examen). en effet pour le moment ce délai est trop long et laisserai trop de blanc durant l'examen , ce qui me serait préjudiciable (si vous avez un moyen de réduire ce délai ou de savoir quand les règles de firewall sont réellement appliquées, je suis preneur ^^)
ps : j'avais une autre question, pour laisser passer uniquement le ping (proto ICMP, type echo request et echo reply), les règles à mettre sont bien d'autoriser sur les deux interfaces l'echo request et l'echo reply dans les deux sens , non ??
merci beaucoup !!!
-
Sur l'ensemble des Pfsense que j'ai en production, l'application des règles lors d'une modification ne prend pas plus 3 ou 4 secondes. C'est un maximum. Vous avez un délai plus important ?
-
De même !
(C'est d'ailleurs très aisé à tester : créer une règle qui interdit le ping, faire un ping -t, et valider la règle).
(Attention, une session tcp ou udp en cours n'est normalement pas interrompue par un changement de règle !)Je peux penser que ce temps est lié au nombre de "state" configuré (10000 par défaut).
Pour un ping, je n'autorise que icmp/echo (=8). Règle ajouté systématiquement pour Rules / Wan !
-
@ccnet : j'ai un délai plus important en effet :o
@jdh :ça veut dire que vous avez laisser la règle par défaut sur la Lan et interdisez QUE sur le wan ?? ^^
après test sur les states (en faisant un clear states en fait ^^), le délai d'application des règles est devenu plus acceptable ça devait en effet être due à ça en tt cas merci pour le coup de main
edit 2 : par curiosité , existerait il une commande en shell pour faire un reset states (je suis sur que oui mais comme le BSD c vraiment l'inconnue pour moi, je préfère demander aux experts ^^)
-
Je ne vois pas ce qui vous permet de pensez que je n'ajoute pas une règle LAN subnet -> any pour icmp/echo (=8 ).
Je peux penser que le suivi de connexion s'applique à icmp, et donc pas besoin d'une règle retour icmp/echo-reply.Si ccnet demande "si c'est plus long", c'est qu'il attend une valeur numérique !
(J'ai même proposé une démarche de test qui donne de suite une valeur en secondes !)Au delà de 5-6 secondes, il y aurait lieu de regarder le problème …
Lié à la puissance cpu ?Je ne vois aucun intérêt à "batcher" un clear state : il n'y a lieu de réaliser un filter reload (d'ailleurs intégré avec le bouton "apply") qu'au moment où on ajoute ou modifie une règle.
-
concernant la règle Lan subnet -> any pour icmp/echo, c'était plutôt une question (j'ai présumé, à tord vu les résultats que j'ai eu après ^^)
concernant le délai chiffré , il est vrai qu'en situation de production, il aurait été nécessaire si ce n'est impératif d'effectuer un test précis (la méthode que vous décrivez dans votre premier post en est une très simple) néanmoins, n'étant pas en situation de production mais en situation de test, la "propreté" de la solution apportée importe assez peu a vrai dire (l'important est de pouvoir montrer ce que je souhaite montrer sans que les blancs d'attente ne soient trop long, la solution doit juste me permettre d'atteindre cet objectif), même si il est vrai que si je souhaite continuer mon travail sur pfSense , il me faudra réfléchir à une solution propre.
un problème de puissance Cpu ??? peut être , la machine utilisé en test contient un vieux P4 2.00GHz et 1GO de DDR (si mes souvenirs sont bon)
pour ce qui est de batcher un clear state, c vrai qu'avec le recul je me rend compte que c'est assez inutile (il faut préciser que j'ai demandé cela car ma prof d'informatique voulais absolumet que je trouve la commande en shell , ce qui m'aurait plus embéter qu'autre chose à placer dans ma présentation mais bon …)
en tous cas, merci de vos réponses jdh et ccnet ;)
-
Faire un clear state à l'application des règles est tout simplement "idiot" car cela reset toutes les connexions traversant le firewall !
Le problème provient de la façon dont vous voulez montrer que la règle est appliquée je pense. Si vous avez une connexion ouverte et que vous appliquez une règle pour bloquer cette connexion alors celle-ci ne sera pas coupée immédiatement en raison de la politique de mise à jour des états du filtre de paquets. Dans tous les autres cas l'application doit être instantanée.
Vous pouvez jouer sur la gestion des états en la passant en mode "agressive".