Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 07/04/2021, à 15:58

gaffeur

Ouverture d'un port ...

Salut les gens !

Je me posais la question suivante :

Est-il possible d'ouvrir un port quelconque (donc, éditer une règle de par-feu pour ufw) pour un service (logiciel) en particulier ? Et, est-il possible de provoquer l'ouverture automatique d'un port, lors du démarrage d'un logiciel et en provoquer le blocage, lors de la fermeture du même logiciel ? ...


Celui qui pose des questions apprend. Celui qui croit tout savoir n'apprend rien ! ...

Hors ligne

#2 Le 07/04/2021, à 16:03

Zakhar

Re : Ouverture d'un port ...

Si ton service a prévu l'UPnP pour fonctionner sur une machine en NAT, tu as une petite chance, parce que c'est ce que fait UPnP vis à vis du routeur NAT pour que des ports soient "forwardés" à la volée.

Sinon, il faut rajouter l'ouverture/fermeture dans les scripts de lancement du service.

Mais en pratique, tu peux simplement ouvrir les ports du service en question dans ton firewall, tant qu'aucun service écoutant ces ports n'est lancé, les paquets entrants iront à la poubelle puisque personne n'en fait rien...

Dernière modification par Zakhar (Le 07/04/2021, à 16:06)


"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

Hors ligne

#3 Le 07/04/2021, à 16:18

bruno

Re : Ouverture d'un port ...

Petite précision, en l’absence de toute règle de pare-feu un port n'est « ouvert » que si un service est en écoute dessus.
Par exemple, le serveur web apache se met en écoute sur les ports 80 est 443 lorsqu'il est lancé.

Hors ligne

#4 Le 07/04/2021, à 16:35

gaffeur

Re : Ouverture d'un port ...

Merci pour vos réponses ! ...

Zakhar a écrit :

Mais en pratique, tu peux simplement ouvrir les ports du service en question dans ton firewall, tant qu'aucun service écoutant ces ports n'est lancé, les paquets entrants iront à la poubelle puisque personne n'en fait rien...

Mais, alors dans ce cas, je prends un risque (d'intrusion), si ce port reste ouvert, non ?


Celui qui pose des questions apprend. Celui qui croit tout savoir n'apprend rien ! ...

Hors ligne

#5 Le 07/04/2021, à 17:20

Zakhar

Re : Ouverture d'un port ...

gaffeur a écrit :

Mais, alors dans ce cas, je prends un risque (d'intrusion), si ce port reste ouvert, non ?

Deux réponses à cela.

S'il s'agit d'un PC derrière une box (ce que tu ne précises pas), le "risque" ne peut provenir que d'un PC local puisque ton PC est par défaut inaccessible de l'extérieur.

Deuxièmement, même depuis l'intérieur (ou si le PC n'est pas derrière une box) comme l'explique autrement Bruno, tant tu n'as pas de service sur un port, il n'y a pas de risque puisque les paquets n'iront nulle part puisque le port n'est alors pas ouvert.

La seule différence potentielle est selon si tu veux faire un "drop" ou un "reject".
Il me semble que le comportement standard d'un port sans service lancé est de faire un "drop".

C'est ce qu'il est conseillé de faire vis à vis de l'extérieur. Vis à vis des machines dans ton LAN, il est conseillé de faire un "reject" pour les informer de la différence, mais là ça nécessiterait effectivement de savoir dynamiquement si le port est servi ou pas.

Dernière modification par Zakhar (Le 07/04/2021, à 17:26)


"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

Hors ligne

#6 Le 07/04/2021, à 19:19

gaffeur

Re : Ouverture d'un port ...

Azakha a écrit :

S'il s'agit d'un PC derrière une box (ce que tu ne précises pas), le "risque" ne peut provenir que d'un PC local puisque ton PC est par défaut inaccessible de l'extérieur.

Oui, c'est le cas ; le PC se trouve derrière la Box !  Effectivement, j'ai lu qq part qu'une Box implémentait un par-feu ; donc tu confirmes ...

Donc, j'ai noté que le risque peut éventuellement exister au niveau du réseau local (maison, entreprise, asso, etc ...) Mais, pour ce qui me concerne c'est surtout ce qui provient de l'extérieur du réseau.

Dernière modification par gaffeur (Le 07/04/2021, à 19:22)


Celui qui pose des questions apprend. Celui qui croit tout savoir n'apprend rien ! ...

Hors ligne

#7 Le 07/04/2021, à 19:40

bruno

Re : Ouverture d'un port ...

Il me semble que le comportement standard d'un port sans service lancé est de faire un "drop".

Plus exactement lorsque un paquet arrive à destination d'un port sur lequel aucun service n'est en écoute, le paquet est simplement ignoré par le noyau.
C'est pourquoi je dis régulièrement que le pare-feu est généralement inutile sur un ordinateur de bureau, voire sur un serveur. Un pare-feu a essentiellement pour rôle de filtrer les flux entre deux réseaux, l'Internet et un réseau local par exemple.

Hors ligne

#8 Le 07/04/2021, à 22:08

Zakhar

Re : Ouverture d'un port ...

bruno a écrit :

Il me semble que le comportement standard d'un port sans service lancé est de faire un "drop".

Plus exactement lorsque un paquet arrive à destination d'un port sur lequel aucun service n'est en écoute, le paquet est simplement ignoré par le noyau.

Et donc c'est fonctionnellement un "drop" non ?

Il y a une différence vu de l'extérieur ?


"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

Hors ligne

#9 Le 08/04/2021, à 15:14

bruno

Re : Ouverture d'un port ...

Non, ça c'est du jargon de pare-feu et cela ne correspond pas au « DROP » d'iptables.
En l’absence de pare-feu si j'envoie un paquet TCP sur le port 30 sur lequel aucun service n'est en écoute le noyau ignore le paquet et renvoie un RST . Avec nmap le port va apparaître comme fermé (closed) :

PORT   STATE  SERVICE
30/tcp closed unknown

Si une règle iptables qui ignore le paquet (DROP) rien n'est renvoyé. Avec nmap le port va apparaître comme filtré (filtered) :

PORT   STATE    SERVICE
30/tcp filtered unknown

Avec ce résultat on est a peu près sûr que le port 30 est bloqué par un pare-feu, ce qui en soit peut être une information intéressante.
Si on veut que la réaction soit la même que sans pare-feu, et sans service en écoute sur le port 30, on va utiliser une règle iptable avec REJECT --reject-with tcp-reset : le paquet est rejeté et on renvoie un RST.

Hors ligne