packet filter [...] un comportement par défaut plus simple et sûr
La dépêche ne détaille pas ce point, alors j'y vais ;).
La directive "keep state" du firewall pf(4) est maintenant activée par défaut pour les règles "pass" ainsi que le contrôle des en-tetes TCP "flasg S/SA". Cela peut surprendre : « pourquoi ont-ils choisi de faire une modification de ce type, pas rétro-compatible, qui risque de poser des pbs à certains parmi ceux qui ne RTFM pas avant d'upgrader ? ».
Et bien c'est précisément ce type de décisions courageuses que j'admire : elles font que pf(4) se bonifie et que son utilisation se simplifie avec le temps au lieu de devenir kludgy au fur et à mesure que les fonctionnalités s'empilent.
Un exemple : nous voulons autoriser l'accès ssh depuis l'extérieur.
Il y a un an ou deux, nous écrivions :
ext_if="re0"
pass in on $ext_if from any to any port 22 keep state flags S/SA
Mais les choses ont évoluées :
- Depuis un moment déjà, il n'est plus nécessaire d'écrire "from any", "to any" et encore moins "from any to any"- "keep state" servait à rendre la règle statefull (en quelque sorte, « bidirectionnelle » : on autorise le traffic sortant du port 22 en réponse à une requête externe). Il est désormais activé par défaut pour les "pass".
- "flags S/SA" était généralement ajouté aux règles "pass" : cela signifie "accepte les paquets TCP initiant de nouvelles connexions uniquement s'ils ont le flag SYN et pas le flag ACK". C'est maintenant activé par défaut pour les règles "pass".
- On utilisait typiquement une macro comme $ext_if pour désigner notre interface externe. Maintenant on peut utiliser le groupe "egress" : le nom de l'interface par laquelle passe la route par défaut est automatiquement et dynamiquement substitué. Dynamiquement = même si on change à chaud la cnx/route ou la carte réseau (ou bien à froid/au reboot : si on met le disque dans une autre machine, par ex, le ruleset reste valable).
Désormais, pour le même résultat, il suffit donc de :
pass in on egress to port 22
Bien que le nombre de fonctionnalités explose, les rulesets deviennent de plus en plus compacts, portables, simples et lisibles.
# pf(4), de plus en plus simple
Posté par herodiade . En réponse à la dépêche Sortie de OpenBSD 4.1. Évalué à 10.
La dépêche ne détaille pas ce point, alors j'y vais ;).
La directive "keep state" du firewall pf(4) est maintenant activée par défaut pour les règles "pass" ainsi que le contrôle des en-tetes TCP "flasg S/SA". Cela peut surprendre : « pourquoi ont-ils choisi de faire une modification de ce type, pas rétro-compatible, qui risque de poser des pbs à certains parmi ceux qui ne RTFM pas avant d'upgrader ? ».
Et bien c'est précisément ce type de décisions courageuses que j'admire : elles font que pf(4) se bonifie et que son utilisation se simplifie avec le temps au lieu de devenir kludgy au fur et à mesure que les fonctionnalités s'empilent.
Un exemple : nous voulons autoriser l'accès ssh depuis l'extérieur.
Il y a un an ou deux, nous écrivions :
ext_if="re0"
pass in on $ext_if from any to any port 22 keep state flags S/SA
Mais les choses ont évoluées :
- Depuis un moment déjà, il n'est plus nécessaire d'écrire "from any", "to any" et encore moins "from any to any"- "keep state" servait à rendre la règle statefull (en quelque sorte, « bidirectionnelle » : on autorise le traffic sortant du port 22 en réponse à une requête externe). Il est désormais activé par défaut pour les "pass".
- "flags S/SA" était généralement ajouté aux règles "pass" : cela signifie "accepte les paquets TCP initiant de nouvelles connexions uniquement s'ils ont le flag SYN et pas le flag ACK". C'est maintenant activé par défaut pour les règles "pass".
- On utilisait typiquement une macro comme $ext_if pour désigner notre interface externe. Maintenant on peut utiliser le groupe "egress" : le nom de l'interface par laquelle passe la route par défaut est automatiquement et dynamiquement substitué. Dynamiquement = même si on change à chaud la cnx/route ou la carte réseau (ou bien à froid/au reboot : si on met le disque dans une autre machine, par ex, le ruleset reste valable).
Désormais, pour le même résultat, il suffit donc de :
pass in on egress to port 22
Bien que le nombre de fonctionnalités explose, les rulesets deviennent de plus en plus compacts, portables, simples et lisibles.