Certes mais c'est un choix stratégique que tu fais la:
"j'ouvre tous les protocoles sortants".
Comme tout choix, c'est certainement le résultat d'une réflexion poussée qui doit alors apparaitre dans ton document pour permettre aux lecteurs de faire le meme raisonnement (validation) ou de le contredire (et a ce moment la il faudra leur donner les moyens d'implementer d'autres politiques de filtrage).
Avec le filtrage décrit ci dessus:
- Quid des spyware qui tournent sur tes postes clients ?
ils etablissent des connections sortantes et ont donc tout loisir d'exporter toutes les informations qu'ils souhaitent.
- Quid des serveur FTP malicieux qui peuvent negocier des ouvertures de ports ENTRANT (grace au tracking de connection destinée au départ pour le ftp-data)
Si ils sont consultés ils peuvent établir des connections entrantes sur les ports TCP qu'ils veulent (negocier avec le client FTP donc on doit faire confiance au client pour etre restrictif ? je me demande si netfilter sait prendre cela en considération ... a voir).
N'importe quel nimbda tournant chez toi peut infecter l'exterieur (connection sortante port 80)
N'importe quel trojan va pourvoir passer, se connecter (connection sortante) sur un canal IRC et y attendre des ordres ... qu'il va executer depuis l'intérieur. Un remote shell en quelques sortes.
Pour moi, hors de question, les protocoles qui sont autorisés en sortie sont sur ma liste de choses impossibles a supprimer et passent par un proxy applicatif le plus possible, par un proxy "bete" (comme un socks) sinon de facon a delocaliser les flux et a valider qu'ils sont connus/maitrisés autant que faire se peu.
C'est pour cela que certaines personnes ont besoin de la relation Appli/Port ,
evidement si tu ouvres en grand, pas besoin de connaitre le détail.
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par PLuG . En réponse à la dépêche Documentation: Firewall et sécurité d'un réseau personnel sous Linux. Évalué à 1.
"j'ouvre tous les protocoles sortants".
Comme tout choix, c'est certainement le résultat d'une réflexion poussée qui doit alors apparaitre dans ton document pour permettre aux lecteurs de faire le meme raisonnement (validation) ou de le contredire (et a ce moment la il faudra leur donner les moyens d'implementer d'autres politiques de filtrage).
Avec le filtrage décrit ci dessus:
- Quid des spyware qui tournent sur tes postes clients ?
ils etablissent des connections sortantes et ont donc tout loisir d'exporter toutes les informations qu'ils souhaitent.
- Quid des serveur FTP malicieux qui peuvent negocier des ouvertures de ports ENTRANT (grace au tracking de connection destinée au départ pour le ftp-data)
Si ils sont consultés ils peuvent établir des connections entrantes sur les ports TCP qu'ils veulent (negocier avec le client FTP donc on doit faire confiance au client pour etre restrictif ? je me demande si netfilter sait prendre cela en considération ... a voir).
N'importe quel nimbda tournant chez toi peut infecter l'exterieur (connection sortante port 80)
N'importe quel trojan va pourvoir passer, se connecter (connection sortante) sur un canal IRC et y attendre des ordres ... qu'il va executer depuis l'intérieur. Un remote shell en quelques sortes.
Pour moi, hors de question, les protocoles qui sont autorisés en sortie sont sur ma liste de choses impossibles a supprimer et passent par un proxy applicatif le plus possible, par un proxy "bete" (comme un socks) sinon de facon a delocaliser les flux et a valider qu'ils sont connus/maitrisés autant que faire se peu.
C'est pour cela que certaines personnes ont besoin de la relation Appli/Port ,
evidement si tu ouvres en grand, pas besoin de connaitre le détail.