J'ai chez moi un pécé (sous linux) qui fait un peu serveur (ssh, web, mail,
imaps, ntp). Jusqu'à présent je ne m'étais pas trop soucié de configurer le
pare-feu, me reposant sur le fait que la machine en question n'a pas d'IP
publique (elle est derrière une freebox en mode routeur), mais d'après ce
que j'ai lu sur ce groupe, ce n'est pas à considérer comme une protection
suffisante.
Pour les conseils techniques, je lirai la page de man d'iptables ou me
renseignerai sur un autre groupe. Mon premier problème est que je dois
déterminer une politique de filtrage, choisir des règles; et que j'ai un
peu de mal (même après avoir lu la FAQ firewalls ici). Parmi les questions
que je me pose :
- Je ne suis pas sûr de comprendre pourquoi il est utile de bloquer les
ports non utilisés en entrée : vu qu'il n'y de toute façon aucune
application qui écoute dessus...
- Il me semble que certains protocoles utilisent des ports choisis
dynamiquement au moment de la connexion. Cela ne risque-t-il pas de poser
des problèmes ? Dois-je prévoir certains ports pour cela et configurer mes
services en conséquence ?
- (Peut-être lié à la question précédente.) D'après ce que j'ai compris, il
y a plusieurs « états » pour une connexion (nouvelle ou déjà établie).
Quand on parle de bloquer les connexions, il s'agit uniquement des
nouvelles ? Qu'appelle-t-on au juste une connexion établie : si quelqu'un
parle à mon port 22 (ouvert), la connexion est-elle toujours établie s'il
essaye ensuite de parler à un autre port ?
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
m3rlin
Salut Manuel,
- Je ne suis pas sûr de comprendre pourquoi il est utile de bloquer les ports non utilisés en entrée : vu qu'il n'y de toute façon aucune application qui écoute dessus...
Aucune application visible.. mais en cas de rootkit tu n'est jamais sur, il est donc preferable de bloquer par default tout les ports en entrée, et juste d'authoriser ceux voulu!
- Il me semble que certains protocoles utilisent des ports choisis dynamiquement au moment de la connexion. Cela ne risque-t-il pas de poser des problèmes ? Dois-je prévoir certains ports pour cela et configurer mes services en conséquence ?
Je pense pas, ton serveur web (par exemple) ecoutera toujours sur le port voulu. Par contre si tu souhaite filtrer tes ports en sortie le probleme peu ce poser. Il te faudra donc plus que filtrer les ports de sortie, filtrer les ports de destination.
- (Peut-être lié à la question précédente.) D'après ce que j'ai compris, il y a plusieurs « états » pour une connexion (nouvelle ou déjà établie). Quand on parle de bloquer les connexions, il s'agit uniquement des nouvelles ? Qu'appelle-t-on au juste une connexion établie : si quelqu'un parle à mon port 22 (ouvert), la connexion est-elle toujours établie s'il essaye ensuite de parler à un autre port ?
Je pense que le terme "connexion nouvelle" designe la "poignet de main" entre les deux machines, et bloquer les nouvelles connexion permet de bloquer certaine attaque (comme le SYNFlood)
Voilà j'espere avoir pu t'aider un peu
Michael
Salut Manuel,
- Je ne suis pas sûr de comprendre pourquoi il est utile de bloquer les
ports non utilisés en entrée : vu qu'il n'y de toute façon aucune
application qui écoute dessus...
Aucune application visible.. mais en cas de rootkit tu n'est jamais
sur, il est donc preferable de bloquer par default tout les ports en
entrée, et juste d'authoriser ceux voulu!
- Il me semble que certains protocoles utilisent des ports choisis
dynamiquement au moment de la connexion. Cela ne risque-t-il pas de poser
des problèmes ? Dois-je prévoir certains ports pour cela et configurer mes
services en conséquence ?
Je pense pas, ton serveur web (par exemple) ecoutera toujours sur le
port voulu.
Par contre si tu souhaite filtrer tes ports en sortie le probleme peu
ce poser.
Il te faudra donc plus que filtrer les ports de sortie, filtrer les
ports de destination.
- (Peut-être lié à la question précédente.) D'après ce que j'ai compris, il
y a plusieurs « états » pour une connexion (nouvelle ou déjà établie).
Quand on parle de bloquer les connexions, il s'agit uniquement des
nouvelles ? Qu'appelle-t-on au juste une connexion établie : si quelqu'un
parle à mon port 22 (ouvert), la connexion est-elle toujours établie s'il
essaye ensuite de parler à un autre port ?
Je pense que le terme "connexion nouvelle" designe la "poignet de
main" entre les deux machines, et bloquer les nouvelles connexion
permet de bloquer certaine attaque (comme le SYNFlood)
- Je ne suis pas sûr de comprendre pourquoi il est utile de bloquer les ports non utilisés en entrée : vu qu'il n'y de toute façon aucune application qui écoute dessus...
Aucune application visible.. mais en cas de rootkit tu n'est jamais sur, il est donc preferable de bloquer par default tout les ports en entrée, et juste d'authoriser ceux voulu!
- Il me semble que certains protocoles utilisent des ports choisis dynamiquement au moment de la connexion. Cela ne risque-t-il pas de poser des problèmes ? Dois-je prévoir certains ports pour cela et configurer mes services en conséquence ?
Je pense pas, ton serveur web (par exemple) ecoutera toujours sur le port voulu. Par contre si tu souhaite filtrer tes ports en sortie le probleme peu ce poser. Il te faudra donc plus que filtrer les ports de sortie, filtrer les ports de destination.
- (Peut-être lié à la question précédente.) D'après ce que j'ai compris, il y a plusieurs « états » pour une connexion (nouvelle ou déjà établie). Quand on parle de bloquer les connexions, il s'agit uniquement des nouvelles ? Qu'appelle-t-on au juste une connexion établie : si quelqu'un parle à mon port 22 (ouvert), la connexion est-elle toujours établie s'il essaye ensuite de parler à un autre port ?
Je pense que le terme "connexion nouvelle" designe la "poignet de main" entre les deux machines, et bloquer les nouvelles connexion permet de bloquer certaine attaque (comme le SYNFlood)
Voilà j'espere avoir pu t'aider un peu
Michael
Fabien LE LEZ
On 09 Sep 2007 16:24:19 GMT, mpg :
- Je ne suis pas sûr de comprendre pourquoi il est utile de bloquer les ports non utilisés en entrée : vu qu'il n'y de toute façon aucune application qui écoute dessus...
Aujourd'hui, 16:24, tu penses qu'aucune application n'écoute sur ces ports. Peut-être te trompes-tu ; peut-être la situation évoluera-t-elle sans que tu t'en rendes forcément compte.
- D'après ce que j'ai compris, il y a plusieurs « états » pour une connexion (nouvelle ou déjà établie).
Une application serveur écoute sur un port donné (par exemple, 80 pour Apache). Si une machine tente de se connecter sur ce port, la connexion peut être bloquée (par le firewall), refusée (par l'application en question, pour celles qui permettent ce genre de configuration), ou acceptée. Une fois qu'elle est acceptée, il peut effectivement y avoir un changement de port, mais tout ça est très bien géré automatiquement, tu n'as pas à t'en préoccuper, que ce soit dans la configuration du firewall (et/ou du routeur -- ici, la freebox), ou dans la config de l'application.
- Il me semble que certains protocoles utilisent des ports choisis dynamiquement au moment de la connexion. Cela ne risque-t-il pas de poser des problèmes ?
Il y a le protocole FTP, qui est une chiotte à gérer ; mais heureusement, comme il est bien connu, un bon firewall doit être capable de reconnaître le protocole et de faire passer les connexions qui vont bien. Tu peux te contenter d'ouvrir le port 21 en entrée.
Certaines applications peuvent décider d'écouter sur un port différent à chaque démarrage (ou sur plusieurs ports). Exemple : utorrent. Il faut alors désactiver cette fonctionnalité.
D'autres protocoles moins connus peuvent avoir des comportements bizarres ; il faut bien lire la documentation, et gérer au cas par cas. Mais comme il s'agit d'un serveur local, sans connexion entrante depuis Internet, je ne pense pas que tu rencontres le cas.
On 09 Sep 2007 16:24:19 GMT, mpg <manuel.pg@free.fr>:
- Je ne suis pas sûr de comprendre pourquoi il est utile de bloquer les
ports non utilisés en entrée : vu qu'il n'y de toute façon aucune
application qui écoute dessus...
Aujourd'hui, 16:24, tu penses qu'aucune application n'écoute sur ces
ports. Peut-être te trompes-tu ; peut-être la situation
évoluera-t-elle sans que tu t'en rendes forcément compte.
- D'après ce que j'ai compris, il
y a plusieurs « états » pour une connexion (nouvelle ou déjà établie).
Une application serveur écoute sur un port donné (par exemple, 80 pour
Apache). Si une machine tente de se connecter sur ce port, la
connexion peut être bloquée (par le firewall), refusée (par
l'application en question, pour celles qui permettent ce genre de
configuration), ou acceptée.
Une fois qu'elle est acceptée, il peut effectivement y avoir un
changement de port, mais tout ça est très bien géré automatiquement,
tu n'as pas à t'en préoccuper, que ce soit dans la configuration du
firewall (et/ou du routeur -- ici, la freebox), ou dans la config de
l'application.
- Il me semble que certains protocoles utilisent des ports choisis
dynamiquement au moment de la connexion. Cela ne risque-t-il pas de poser
des problèmes ?
Il y a le protocole FTP, qui est une chiotte à gérer ; mais
heureusement, comme il est bien connu, un bon firewall doit être
capable de reconnaître le protocole et de faire passer les connexions
qui vont bien. Tu peux te contenter d'ouvrir le port 21 en entrée.
Certaines applications peuvent décider d'écouter sur un port différent
à chaque démarrage (ou sur plusieurs ports). Exemple : utorrent. Il
faut alors désactiver cette fonctionnalité.
D'autres protocoles moins connus peuvent avoir des comportements
bizarres ; il faut bien lire la documentation, et gérer au cas par
cas. Mais comme il s'agit d'un serveur local, sans connexion entrante
depuis Internet, je ne pense pas que tu rencontres le cas.
- Je ne suis pas sûr de comprendre pourquoi il est utile de bloquer les ports non utilisés en entrée : vu qu'il n'y de toute façon aucune application qui écoute dessus...
Aujourd'hui, 16:24, tu penses qu'aucune application n'écoute sur ces ports. Peut-être te trompes-tu ; peut-être la situation évoluera-t-elle sans que tu t'en rendes forcément compte.
- D'après ce que j'ai compris, il y a plusieurs « états » pour une connexion (nouvelle ou déjà établie).
Une application serveur écoute sur un port donné (par exemple, 80 pour Apache). Si une machine tente de se connecter sur ce port, la connexion peut être bloquée (par le firewall), refusée (par l'application en question, pour celles qui permettent ce genre de configuration), ou acceptée. Une fois qu'elle est acceptée, il peut effectivement y avoir un changement de port, mais tout ça est très bien géré automatiquement, tu n'as pas à t'en préoccuper, que ce soit dans la configuration du firewall (et/ou du routeur -- ici, la freebox), ou dans la config de l'application.
- Il me semble que certains protocoles utilisent des ports choisis dynamiquement au moment de la connexion. Cela ne risque-t-il pas de poser des problèmes ?
Il y a le protocole FTP, qui est une chiotte à gérer ; mais heureusement, comme il est bien connu, un bon firewall doit être capable de reconnaître le protocole et de faire passer les connexions qui vont bien. Tu peux te contenter d'ouvrir le port 21 en entrée.
Certaines applications peuvent décider d'écouter sur un port différent à chaque démarrage (ou sur plusieurs ports). Exemple : utorrent. Il faut alors désactiver cette fonctionnalité.
D'autres protocoles moins connus peuvent avoir des comportements bizarres ; il faut bien lire la documentation, et gérer au cas par cas. Mais comme il s'agit d'un serveur local, sans connexion entrante depuis Internet, je ne pense pas que tu rencontres le cas.
Eric PETIT
Dans le message :fc16n7$1jrl$, mpg a écrit:
Bonjour,
J'ai chez moi un pécé (sous linux) qui fait un peu serveur (ssh, web, mail, imaps, ntp). Jusqu'à présent je ne m'étais pas trop soucié de configurer le pare-feu, me reposant sur le fait que la machine en question n'a pas d'IP publique (elle est derrière une freebox en mode routeur), mais d'après ce que j'ai lu sur ce groupe, ce n'est pas à considérer comme une protection suffisante.
"freebox en mode routeur"
- Je ne suis pas sûr de comprendre pourquoi il est utile de bloquer les ports non utilisés en entrée : vu qu'il n'y de toute façon aucune application qui écoute dessus...
Tu a au moins un problème de terminologie ;-) Plutôt qu' "entrée" tu devrais utiliser le terme "écoute" . Je te conseille de chercher de la prose sur les réseaux en général et les firewall en particulier notamment ce qui peut toucher à la sécurité. On en trouve généralement assez facilement. Tu perdra peut être moins de temps à lire et comprendre qu'a tenter de mettre en place un iptable pas forcément utile. Et ensuite tu saura quoi faire ;-)
.....
- (Peut-être lié à la question précédente.) D'après ce que j'ai compris, il y a plusieurs « états » pour une connexion (nouvelle ou déjà établie). Quand on parle de bloquer les connexions, il s'agit uniquement des nouvelles ? Qu'appelle-t-on au juste une connexion établie : si quelqu'un parle à mon port 22 (ouvert), la connexion est-elle toujours établie s'il essaye ensuite de parler à un autre port ?
cette question est en contradiction avec la première citation, as tu redirigé des ports vers ton serveur ? Si oui alors il est bon de se préoccuper de la sécurité, y compris si ton serveur n'a pas d'IP publique.
-- Eric Reply-to valide, laissez tel quel ! Texte brut vivement conseillé !!
Dans le message :fc16n7$1jrl$1@talisker.lacave.net,
mpg a écrit:
Bonjour,
J'ai chez moi un pécé (sous linux) qui fait un peu serveur (ssh, web,
mail, imaps, ntp). Jusqu'à présent je ne m'étais pas trop soucié de
configurer le pare-feu, me reposant sur le fait que la machine en
question n'a pas d'IP publique (elle est derrière une freebox en mode
routeur), mais d'après ce que j'ai lu sur ce groupe, ce n'est pas à
considérer comme une protection suffisante.
"freebox en mode routeur"
- Je ne suis pas sûr de comprendre pourquoi il est utile de bloquer
les ports non utilisés en entrée : vu qu'il n'y de toute façon aucune
application qui écoute dessus...
Tu a au moins un problème de terminologie ;-)
Plutôt qu' "entrée" tu devrais utiliser le terme "écoute" .
Je te conseille de chercher de la prose sur les réseaux en général et les
firewall en particulier notamment ce qui peut toucher à la sécurité. On en
trouve généralement assez facilement. Tu perdra peut être moins de temps à
lire et comprendre qu'a tenter de mettre en place un iptable pas forcément
utile. Et ensuite tu saura quoi faire ;-)
.....
- (Peut-être lié à la question précédente.) D'après ce que j'ai
compris, il y a plusieurs « états » pour une connexion (nouvelle ou
déjà établie). Quand on parle de bloquer les connexions, il s'agit
uniquement des nouvelles ? Qu'appelle-t-on au juste une connexion
établie : si quelqu'un parle à mon port 22 (ouvert), la connexion
est-elle toujours établie s'il essaye ensuite de parler à un autre
port ?
cette question est en contradiction avec la première citation, as tu
redirigé des ports vers ton serveur ?
Si oui alors il est bon de se préoccuper de la sécurité, y compris si ton
serveur n'a pas d'IP publique.
--
Eric
Reply-to valide, laissez tel quel !
Texte brut vivement conseillé !!
J'ai chez moi un pécé (sous linux) qui fait un peu serveur (ssh, web, mail, imaps, ntp). Jusqu'à présent je ne m'étais pas trop soucié de configurer le pare-feu, me reposant sur le fait que la machine en question n'a pas d'IP publique (elle est derrière une freebox en mode routeur), mais d'après ce que j'ai lu sur ce groupe, ce n'est pas à considérer comme une protection suffisante.
"freebox en mode routeur"
- Je ne suis pas sûr de comprendre pourquoi il est utile de bloquer les ports non utilisés en entrée : vu qu'il n'y de toute façon aucune application qui écoute dessus...
Tu a au moins un problème de terminologie ;-) Plutôt qu' "entrée" tu devrais utiliser le terme "écoute" . Je te conseille de chercher de la prose sur les réseaux en général et les firewall en particulier notamment ce qui peut toucher à la sécurité. On en trouve généralement assez facilement. Tu perdra peut être moins de temps à lire et comprendre qu'a tenter de mettre en place un iptable pas forcément utile. Et ensuite tu saura quoi faire ;-)
.....
- (Peut-être lié à la question précédente.) D'après ce que j'ai compris, il y a plusieurs « états » pour une connexion (nouvelle ou déjà établie). Quand on parle de bloquer les connexions, il s'agit uniquement des nouvelles ? Qu'appelle-t-on au juste une connexion établie : si quelqu'un parle à mon port 22 (ouvert), la connexion est-elle toujours établie s'il essaye ensuite de parler à un autre port ?
cette question est en contradiction avec la première citation, as tu redirigé des ports vers ton serveur ? Si oui alors il est bon de se préoccuper de la sécurité, y compris si ton serveur n'a pas d'IP publique.
-- Eric Reply-to valide, laissez tel quel ! Texte brut vivement conseillé !!
