Il faut bien comprendre ce que Les "listes" de Pf sont. Ils ne font pas partie des règles qui sont chargées dans le noyau en fait, mais les macros à la place. Cela signifie qu'ils sont développés pendant la phase de prétraitement du chargement des règles - contrairement aux tableaux . En gardant cela à l'esprit, on évite de se "tirer dans le pied".
Voyons maintenant ce que vous essayez de faire :
block out quick proto { tcp, udp } from any to ! <my_table> port != { 66 80 }
- Bloc immédiatement Si
- c'est TCP ou c'est UDP
-
ET il est destiné à
- Les IP qui ne sont pas dans
my_table
-
ET ports, qui ne sont pas dans la liste
Comme je vous l'ai dit Les éléments des listes seraient développés dans une règle distincte pour chaque élément de la liste. . Et cela casserait la logique que je viens d'expliquer : seul le premier port de la liste serait traité correctement, si vous bloquez immédiatement ( quick ), cela signifie évidemment qu'il n'y a pas de deuxième vérification - "port non autorisé, ok, le bloquer".
Pour maîtriser le jeu de règles du pare-feu, il vaut mieux garder les choses aussi simples que possible. En fait, ce n'est pas seulement pour les pare-feu - c'est du bon sens général et de la programmation. Les doubles négations, les exceptions des exceptions ne sont pas si simples à suivre.
Quelles sont vos options alors ? - Vous pouvez examiner les différents angles : que voulez-vous passer et quand voulez-vous le faire ?
# If it's destined to IP in <my_table> -- pass:
pass out quick proto { tcp, udp } from any to <my_table>
# ElseIf it's to allowed ports -- pass:
pass out quick proto { tcp, udp } to port { 66 80 }
# And this point would be reached only if it wasn't to <my_table>
# and to some ports other than allowed ones:
block out quick proto { tcp, udp }
Ce jeu de règles est en effet beaucoup plus lisible. De plus, l'expansion des macros ne gâche pas sa logique.
Bien sûr, Pf a d'autres moyens de résoudre cette tâche, mais les décrire tous correctement rendrait cette réponse beaucoup trop longue.
