Reject, Block et les négatons dans les règles

yro

Bonjour à tous…
J'ai deux questions,

J'aimerai connaître la différence exacte qu'il y a entre "Reject et Block" et dans quelles circonstances employer l'un ou l'autre. J'ai lu d'autres postes à ce sujet, mais les réponses ne me semblent pas assez précises.
Si j'ai bien compris le principe de PFsense, la négation (ou l'exclusion) dans une règle d'autorisation ou de block concerne uniquement les sources où les destinations, en aucun cas elle ne s'applique sur les ports utilisés. Comment faire pour limiter ou interdire le passage des paquets à l'exception d'une série de ports contenu dans un alias?
Je m'explique, voici une série de règles qui s'applique sur des Vlans ou départ d'une config devenue classique maintenant:
interface Wan (règle classique générée par défaut)
interface Lan (règles d'accès illimité, c'est une interface de management)
interface optionnelle avec 10 Vlans répertoriés de 1 à 10

Voici les règles que j'ai appliqué sur l'interface virt. du Vlan 4

J'aimerai maintenant inséré une règle (reject ou block) à mon avis qui se situerait sous la règle d'interdiction à l'interface de management, pour limiter le trafic vers Internet à certains ports (80, 443, 21, 25, 110, etc. …)
Ma seule option était de lister tous les ports que je ne veux pas voir traverser en prenant soins de laisser passer ceux énumérés par exemple, mais imaginez-vous le travail et puis ce ne serait pas élégant voir complètement ingérable si je dois y faire des modifications.
J'ai bien pensé intégrer un alias regroupant les ports en question dans la règle 3 "Allow internet Only", mais sans doute à cause de la négation devant l'alias il semble que les paquets ne passent plus.

Qui aurait une idée sur la question ?
Merci par avance! ;)

Ah! Oui, pour info l'alias 4VlanAcces comporte l'adresse de tous les Vlans sauf celui source (ici le Vlan 4)

ccnet

J'aimerai connaître la différence exacte qu'il y a entre "Reject et Block"

Le texte figurant sous le champ me semble pourtant assez … limpide :

Hint: the difference between block and reject is that with reject, a packet (TCP RST or ICMP port unreachable for UDP) is returned to the sender, whereas with block the packet is dropped silently. In either case, the original packet is discarded. Reject only works when the protocol is set to either TCP or UDP (but not "TCP/UDP") below.

Block : le paquet est ignoré et n'entre pas. Aucune réponse n'est envoyé à l'émetteur.
Reject : Pour un paquet TCP on répond par un reset, pour les autres par un icmp port inaccessible.

On utilisera Block le plus souvent pour rester silencieux.

Comment faire pour limiter ou interdire le passage des paquets à l'exception d'une série de ports contenu dans un alias?

Votre dernière règle rejette tout ce qui n'a pas été accepté explicitement avant (ce qui est bien), il suffit d'autoriser cette série de ports avant la règle reject. Non ?

yro

Merci CCNET pour ces explications éclairées… ;)
En lisant ton poste la lumière m'est apparue, je pense que je me dirigeais vers la mauvaise pente.
Pour Isoler mes Vlans, pourquoi créer une règle "pass" puis nier les destinations vers les quelles je ne veux pas que mes paquets atteignent, alors qu'il suffit de mettre une règle "Block" au bon endroit, ces paquets une fois éliminés ne pourrons plus être acceptés dans les règles suivantes, qu'en pensez-vous ?
Voici ce que j'obtiens:

J'ajoute une petite règle qui permet explicitement l'accès au Vlan 3 sur http:80
L'Alias PortAllowed contient les ports que je veux laisser passer vers Internet.
Je pourrais ajouter a la suite, juste avant la dernière règle de rejet d'autres port autorisés sépicifiques à des services utilisés sur mon Vlan!

Il me semble que cette méthode m'offre beaucoup plus de souplesse que la précédente, y voyez-vous des erreurs ?
Merci

yro

??? … :-\

J’aurais espéré une petite réponse pour valider ces règles,
Quelqu’un d’avisé pourrait-il me dire si il utilise ce type de règles pour isoler ses Vlans dans le même cas d’utilisation que présenté plus haut ?

Ce serait sympa de commenter mon idée car je n’ai pas d’exemple similaire à celui-ci dans les descriptions fournies dans les autres topics du forum !

Merci ;)

titofe

Bonjour,

Je débute sur PfSense et je n'ai pas encore fait réellement de règle de filtrage avec (qui ne veux pas dire que je ne sais pas en faire), mais en lisant le Post de ccnet, il me semble que la réponse est simple, personnellement j'aurai fait comme il à dit, la règle qui refuse tout en dernier et les règles qui accepte en premier.

Je m'explique si la règle qui refuse tout est lu en premier, il n'ira jamais voir si il y a une règle plus bas qui le contredit …. et c'est aussi plus facile à lire sur PfSense par la suite.

Cdt,

yro

Oui, mais si j’ai bien compris la philosophie de Pfsense, quand un règle restrictive est introduite ce qui n’est pas concerné est autorisé et second souci que j’explique plus haut c’est les ports ou suite de ports inclus dans un alias ne peuvent pas conjointement être niés avec une destination.

Donc dans le premier tableau la règle qui autorise le Vlan4 à sortir partout sauf vers Vlan4access (alias qui reprend les adresses réseau des autres Vlan) et qui en gros configure là mon accès internet fonctionne très bien en soit. Là où cela se complique c’est que si je veux aussi restreindre les ports qui ont accès au net, fort de certains principes de firewalling, j’ajoute un alias avec les ports de destination dans cette même règle, Et là que ce passe-t-il ?

Admettons que je veuille bloquer le port 443, je fais donc comme décrit et j’ajoute un port de destination à ma règle, cela devient en français :
J’autorise depuis Vlan4 depuis tous les ports pas vers alias (autres Vlans) vers le port 443.
Implicitement cela veut dire que par contre tout ce qui n’est pas en direction du port 443 depuis le Vlan4 pourra contacter les autres Vlans malgré la négation.

Et au même titre qu’un paquet refusé et dropper n’ira pas plus loin dans le jeu de règles, un paquet accepté n’ira pas voir non plus si une règle restreint celle qu’il l’a autorisé plus haut.

Conclusion, derrière une négation il est presque (presque car je ne connais pas la solution) impossible de créer une restriction qui porte sur la même origine.

La solution que je mets en œuvre est une trappe, en effet sachant que par défaut tout est bloqué et qu’il me faut un accès vers le net depuis mes vlans en prenant soin d’isoler les autres vlans de celui avec lequel je communique ma première règle Reject (Reject hosts to management) va implicitement accepter tout les paquets vers toutes les autres destinations différentes de celle de mon interface de management. Les petits paquets commencent à courir dans mon filtre et se précipitent vers toutes les bèches que la règle Reject à laissé, mais seul les paquets à destination du net m’intéresse donc je tue alors tout ceux qui cherche à aller vers les autre Vlans par la règle block, une fois ces paquets éliminés je peux alors traiter toutes les autres requêtes de façon conventionnelles sans me soucier de mes Vlans et restreindre les ports, les destinations et autres sans inquiétude.

De façon pratique, toutes nouvelles règles que je veux instaurer vers les vlans, je les place avant la règle Block et ce que je veux traiter vers internet après la règle Block.

ccnet

Il faut garder à l'esprit trois choses assez simples :

1. Les règles sont évaluées de haut en bas pour chaque interface.
2. Dès qu'une règle est évaluée à vrai pour un paquet, le règle est appliquée et les règles suivantes ne sont pas évaluées.
3. Les règles de nat sont appliquées avant celle de filtrage.

En pratique lors de la mise en route, surtout si vous n'avez pas une grande expérience, je conseille d'activer les logs sur chaque règle (refus comme acceptation) pour vérifier ce que se passe vraiment. Ensuite vous adaptez la gestion des logs à votre politique de sécurité.

yro

Merci, il m'a fallut un peut de temps pour m'y faire il est vrai, venant d'autres philosophies de firewalling j'espère avoir pris cette mesure!

j'ai les logs des différentes règles mises en place, à première vue j'obtiens ce que je cherche, il me semble même que mon raisonnement se tient (je précise, juste au sujet de la petite règle mise en place plus haut car je n'ai pas d'autres prétentions) le doute vient de mon entourage colaboratif qui trouve cette logique intéressante, mais qui n'a pas de référence sur ce que j'ai mis en place et redoute un piège dans l'utilisation définitive comme bastion d'un réseau important. ;)

C'est un peut dans ce sens que je cherche à avaliser ce que j'ai fait… sans impliquer votre intervention outres mesure!

Merci!

ccnet

Vous pouvez toujours faire un test depuis l'extérieur avec un outil comme Nmap. Ce ne sera pas une analyse exhaustive des problèmes potentiels, loin s'en faut, mais vous verrez au moins l'effet des règles en place.

yro

Merci, bonne idée! ;)
Je vais mettre ça en place, je donnerai les résultats sur ce post!