Je recherche des exemples ou de la doc sur comment concevoir
correctement un firewall. Par cela, j'entends :
- spécification papier de la politique de sécurité
- transformation en firewall (netfilter ou pf par exemple)
- vérification que la spec correspond au firewall réel
J'ai déjà pas mal d'idées sur comment faire ça correctement, mais je
suppose qu'il y a des gens qui ont déjà dû coller des exemples sur le
net ou poster des documents sur "designing a good firewall".
Attention, je ne cherche pas un nième tutorial sur netfilter ou pf, je
sais les utiliser (enfin, je crois). Il s'agit plutot d'un truc style
diagrammes de classes en programmation, mais pour les firewalls.
--
panic("aha1740.c"); /* Goodbye */
2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
loic.tortay
Vincent Bernat wrote:
Je recherche des exemples ou de la doc sur comment concevoir correctement un firewall. Par cela, j'entends : - spécification papier de la politique de sécurité - transformation en firewall (netfilter ou pf par exemple) - vérification que la spec correspond au firewall réel
Il y a
<http://www.madison-gurkha.com/publications/tcp_filtering/tcp_filtering.ps> qui décrit le design de IPFilter.
Je ne l'ai pas relu récemment, mais il me semble me souvenir que s'était un très bon descriptif.
Loïc.
Vincent Bernat wrote:
Je recherche des exemples ou de la doc sur comment concevoir
correctement un firewall. Par cela, j'entends :
- spécification papier de la politique de sécurité
- transformation en firewall (netfilter ou pf par exemple)
- vérification que la spec correspond au firewall réel
Il y a
<http://www.madison-gurkha.com/publications/tcp_filtering/tcp_filtering.ps>
qui décrit le design de IPFilter.
Je ne l'ai pas relu récemment, mais il me semble me souvenir que
s'était un très bon descriptif.
Je recherche des exemples ou de la doc sur comment concevoir correctement un firewall. Par cela, j'entends : - spécification papier de la politique de sécurité - transformation en firewall (netfilter ou pf par exemple) - vérification que la spec correspond au firewall réel
Il y a
<http://www.madison-gurkha.com/publications/tcp_filtering/tcp_filtering.ps> qui décrit le design de IPFilter.
Je ne l'ai pas relu récemment, mais il me semble me souvenir que s'était un très bon descriptif.
Loïc.
Vincent Bernat
OoO La nuit ayant déjà recouvert d'encre ce jour du vendredi 23 décembre 2005, vers 23:04, disait:
Je recherche des exemples ou de la doc sur comment concevoir correctement un firewall. Par cela, j'entends : - spécification papier de la politique de sécurité - transformation en firewall (netfilter ou pf par exemple) - vérification que la spec correspond au firewall réel
Il y a
<http://www.madison-gurkha.com/publications/tcp_filtering/tcp_filtering.ps> qui décrit le design de IPFilter.
Je me suis mal exprimé : je voulais parler du design d'un ruleset, pas de l'applicatif en lui-même. :) -- BOFH excuse #354: Chewing gum on /dev/sd3c
OoO La nuit ayant déjà recouvert d'encre ce jour du vendredi 23
décembre 2005, vers 23:04, loic.tortay@gmail.com disait:
Je recherche des exemples ou de la doc sur comment concevoir
correctement un firewall. Par cela, j'entends :
- spécification papier de la politique de sécurité
- transformation en firewall (netfilter ou pf par exemple)
- vérification que la spec correspond au firewall réel
Il y a
<http://www.madison-gurkha.com/publications/tcp_filtering/tcp_filtering.ps>
qui décrit le design de IPFilter.
Je me suis mal exprimé : je voulais parler du design d'un ruleset, pas
de l'applicatif en lui-même. :)
--
BOFH excuse #354:
Chewing gum on /dev/sd3c
OoO La nuit ayant déjà recouvert d'encre ce jour du vendredi 23 décembre 2005, vers 23:04, disait:
Je recherche des exemples ou de la doc sur comment concevoir correctement un firewall. Par cela, j'entends : - spécification papier de la politique de sécurité - transformation en firewall (netfilter ou pf par exemple) - vérification que la spec correspond au firewall réel
Il y a
<http://www.madison-gurkha.com/publications/tcp_filtering/tcp_filtering.ps> qui décrit le design de IPFilter.
Je me suis mal exprimé : je voulais parler du design d'un ruleset, pas de l'applicatif en lui-même. :) -- BOFH excuse #354: Chewing gum on /dev/sd3c
Manou
Vincent Bernat devait dire quelque chose comme ceci :
Je me suis mal exprimé : je voulais parler du design d'un ruleset, pas de l'applicatif en lui-même. :)
Si je devais écrire une spec' comme celle-ci, en gros ce serait (dans le désordre) :
- spécification papier de la politique de sécurité
1) Toujours travailler (groupe de) poste(s) par (groupe de) poste(s). 2) Toujours définir explicitement, pour chaque (groupe de) poste(s) les service autorisé et la portée de cette autorisation. 3) Toujours regrouper les postes ayant les même droits générique sur un même subnet. 4) Lorsqu'au sein d'un groupe certains postes ont en plus des droits spécifiques, s'arranger pour que les adresses IP se suivent, quitte à laisser des trous pour pouvoir inserer de nouvelles machines.
Ce qui donnerait [avec des données purement fantaisistes] quelque chose comme :
Personnellement je trouve que ça coule de source si la première partie est bien pensée. Surtout lorsque la transformation se fait vers pf dont les tables et macro permettent de suivre les spécifications à la lettre. Juste penser que l'autorisation est l'exception et non la règle, et qu'il est préférable de grouper les destinations, puis les services
pass out quick on $if_wild proto tcp from $devel_cidr to any port $devel_portwild block out quick on $if_wild from $devel_cidr to any
pass out quick on $if_dmz proto tcp from $devel_admin to $devel_adminhost port 22 pass out quick on $if_dmz proto tcp from $devel_web to $dmz_http port 22 block out quick on $if_dmz proto tcp from $devel_cidr to any port 22
pass out quick on $if_dmz proto tcp from $devel_web to $dmz_http port 21 pass out quick on $if_dmz proto tcp from $devel_cidr to $dmz_ftp port 21 pass out quick on $if_dmz proto tcp from $devel_cidr to $dmz_pop port 110 pass out quick on $if_dmz proto tcp from $devel_cidr to $dmz_smtp port 25 pass out quick on $if_dmz proto tcp from $devel_cidr to $dmz_nntp port 119 block out quick on $if_dmz proto tcp from $devel_cidr to any
- vérification que la spec correspond au firewall réel
Bah, là c'est assez simple, tout tester ;-) Et quand je dis tout, c'est tout. Il faut essayer de se connecter sur chaque machine de la DMZ depuis chaque machine du réseau (LAN *et* DMZ), et essayer de ce connecter vers un échantillon de services/serveurs présent dans le vaste monde, depuis chaque machine là aussi. Pour les tests fait vers le vaste monde, toujours essayer plusieurs serveurs pour un même service, de façon à être sûr que l'absence de connexion n'est pas dû à un problème sur le réseau ou à un filtrage sur le serveur lui-même. De même, il ne faut jamais oublier qu'une absence de connexion ne veut pas dire que la règle fonctionne correctement, mais qu'il y a une règle qui bloque soit la demande de connexion, soit la réponse du serveur. Il faut donc doubler les tests d'une étude des logs. Toujours regarder les logs après avoir testé une machine, et toujours recommencer les tests depuis la première machine si l'on corrige un problème dans les règles. Le plus simple étant de tester les machines dans l'ordre croissant de leur adresse IP, cela garantie que l'on en oublie pas une en route.
Ah oui, aussi, si je devais écrire une spec' comme celle-ci, elle serait beaucoup plus détaillée ;-)
Vincent Bernat devait dire quelque chose comme ceci :
Je me suis mal exprimé : je voulais parler du design d'un ruleset, pas
de l'applicatif en lui-même. :)
Si je devais écrire une spec' comme celle-ci, en gros ce serait (dans
le désordre) :
- spécification papier de la politique de sécurité
1) Toujours travailler (groupe de) poste(s) par (groupe de) poste(s).
2) Toujours définir explicitement, pour chaque (groupe de) poste(s) les
service autorisé et la portée de cette autorisation.
3) Toujours regrouper les postes ayant les même droits générique sur un
même subnet.
4) Lorsqu'au sein d'un groupe certains postes ont en plus des droits
spécifiques, s'arranger pour que les adresses IP se suivent, quitte à
laisser des trous pour pouvoir inserer de nouvelles machines.
Ce qui donnerait [avec des données purement fantaisistes] quelque chose
comme :
Personnellement je trouve que ça coule de source si la première partie
est bien pensée. Surtout lorsque la transformation se fait vers pf dont
les tables et macro permettent de suivre les spécifications à la lettre.
Juste penser que l'autorisation est l'exception et non la règle, et
qu'il est préférable de grouper les destinations, puis les services
pass out quick on $if_wild proto tcp from $devel_cidr to any port $devel_portwild
block out quick on $if_wild from $devel_cidr to any
pass out quick on $if_dmz proto tcp from $devel_admin to $devel_adminhost port 22
pass out quick on $if_dmz proto tcp from $devel_web to $dmz_http port 22
block out quick on $if_dmz proto tcp from $devel_cidr to any port 22
pass out quick on $if_dmz proto tcp from $devel_web to $dmz_http port 21
pass out quick on $if_dmz proto tcp from $devel_cidr to $dmz_ftp port 21
pass out quick on $if_dmz proto tcp from $devel_cidr to $dmz_pop port 110
pass out quick on $if_dmz proto tcp from $devel_cidr to $dmz_smtp port 25
pass out quick on $if_dmz proto tcp from $devel_cidr to $dmz_nntp port 119
block out quick on $if_dmz proto tcp from $devel_cidr to any
- vérification que la spec correspond au firewall réel
Bah, là c'est assez simple, tout tester ;-) Et quand je dis tout, c'est
tout. Il faut essayer de se connecter sur chaque machine de la DMZ
depuis chaque machine du réseau (LAN *et* DMZ), et essayer de ce
connecter vers un échantillon de services/serveurs présent dans le vaste
monde, depuis chaque machine là aussi. Pour les tests fait vers le vaste
monde, toujours essayer plusieurs serveurs pour un même service, de
façon à être sûr que l'absence de connexion n'est pas dû à un problème
sur le réseau ou à un filtrage sur le serveur lui-même.
De même, il ne faut jamais oublier qu'une absence de connexion ne veut
pas dire que la règle fonctionne correctement, mais qu'il y a une règle
qui bloque soit la demande de connexion, soit la réponse du serveur. Il
faut donc doubler les tests d'une étude des logs.
Toujours regarder les logs après avoir testé une machine, et toujours
recommencer les tests depuis la première machine si l'on corrige un
problème dans les règles. Le plus simple étant de tester les machines
dans l'ordre croissant de leur adresse IP, cela garantie que l'on en
oublie pas une en route.
Ah oui, aussi, si je devais écrire une spec' comme celle-ci, elle
serait beaucoup plus détaillée ;-)
Vincent Bernat devait dire quelque chose comme ceci :
Je me suis mal exprimé : je voulais parler du design d'un ruleset, pas de l'applicatif en lui-même. :)
Si je devais écrire une spec' comme celle-ci, en gros ce serait (dans le désordre) :
- spécification papier de la politique de sécurité
1) Toujours travailler (groupe de) poste(s) par (groupe de) poste(s). 2) Toujours définir explicitement, pour chaque (groupe de) poste(s) les service autorisé et la portée de cette autorisation. 3) Toujours regrouper les postes ayant les même droits générique sur un même subnet. 4) Lorsqu'au sein d'un groupe certains postes ont en plus des droits spécifiques, s'arranger pour que les adresses IP se suivent, quitte à laisser des trous pour pouvoir inserer de nouvelles machines.
Ce qui donnerait [avec des données purement fantaisistes] quelque chose comme :
Personnellement je trouve que ça coule de source si la première partie est bien pensée. Surtout lorsque la transformation se fait vers pf dont les tables et macro permettent de suivre les spécifications à la lettre. Juste penser que l'autorisation est l'exception et non la règle, et qu'il est préférable de grouper les destinations, puis les services
pass out quick on $if_wild proto tcp from $devel_cidr to any port $devel_portwild block out quick on $if_wild from $devel_cidr to any
pass out quick on $if_dmz proto tcp from $devel_admin to $devel_adminhost port 22 pass out quick on $if_dmz proto tcp from $devel_web to $dmz_http port 22 block out quick on $if_dmz proto tcp from $devel_cidr to any port 22
pass out quick on $if_dmz proto tcp from $devel_web to $dmz_http port 21 pass out quick on $if_dmz proto tcp from $devel_cidr to $dmz_ftp port 21 pass out quick on $if_dmz proto tcp from $devel_cidr to $dmz_pop port 110 pass out quick on $if_dmz proto tcp from $devel_cidr to $dmz_smtp port 25 pass out quick on $if_dmz proto tcp from $devel_cidr to $dmz_nntp port 119 block out quick on $if_dmz proto tcp from $devel_cidr to any
- vérification que la spec correspond au firewall réel
Bah, là c'est assez simple, tout tester ;-) Et quand je dis tout, c'est tout. Il faut essayer de se connecter sur chaque machine de la DMZ depuis chaque machine du réseau (LAN *et* DMZ), et essayer de ce connecter vers un échantillon de services/serveurs présent dans le vaste monde, depuis chaque machine là aussi. Pour les tests fait vers le vaste monde, toujours essayer plusieurs serveurs pour un même service, de façon à être sûr que l'absence de connexion n'est pas dû à un problème sur le réseau ou à un filtrage sur le serveur lui-même. De même, il ne faut jamais oublier qu'une absence de connexion ne veut pas dire que la règle fonctionne correctement, mais qu'il y a une règle qui bloque soit la demande de connexion, soit la réponse du serveur. Il faut donc doubler les tests d'une étude des logs. Toujours regarder les logs après avoir testé une machine, et toujours recommencer les tests depuis la première machine si l'on corrige un problème dans les règles. Le plus simple étant de tester les machines dans l'ordre croissant de leur adresse IP, cela garantie que l'on en oublie pas une en route.
Ah oui, aussi, si je devais écrire une spec' comme celle-ci, elle serait beaucoup plus détaillée ;-)
Jeremy JUST
On 23 Dec 2005 18:25:53 GMT Vincent Bernat wrote:
Je recherche des exemples ou de la doc sur comment concevoir correctement un firewall. Par cela, j'entends : - spécification papier de la politique de sécurité - transformation en firewall (netfilter ou pf par exemple) - vérification que la spec correspond au firewall réel
Ça fait quelques mois que j'essaie de trouver le temps de lire ce livre:
Building Internet Firewalls, 2nd edition Zwicky, Cooper, Chapman O'Reilly, 2000 http://www.amazon.fr/exec/obidos/ASIN/1565928717
-- Jérémy JUST
On 23 Dec 2005 18:25:53 GMT
Vincent Bernat <bernat@luffy.cx> wrote:
Je recherche des exemples ou de la doc sur comment concevoir
correctement un firewall. Par cela, j'entends :
- spécification papier de la politique de sécurité
- transformation en firewall (netfilter ou pf par exemple)
- vérification que la spec correspond au firewall réel
Ça fait quelques mois que j'essaie de trouver le temps de lire ce
livre:
Building Internet Firewalls, 2nd edition
Zwicky, Cooper, Chapman
O'Reilly, 2000
http://www.amazon.fr/exec/obidos/ASIN/1565928717
Je recherche des exemples ou de la doc sur comment concevoir correctement un firewall. Par cela, j'entends : - spécification papier de la politique de sécurité - transformation en firewall (netfilter ou pf par exemple) - vérification que la spec correspond au firewall réel
Ça fait quelques mois que j'essaie de trouver le temps de lire ce livre:
Building Internet Firewalls, 2nd edition Zwicky, Cooper, Chapman O'Reilly, 2000 http://www.amazon.fr/exec/obidos/ASIN/1565928717
