Comment vérifier si le pare-feu s'est ouvert pour un port mais n'écoute pas sur le port
Nous allons déployer une nouvelle application sur un serveur et l'application écoutera sur le port 8443. Nous avons demandé à l'équipe Réseau d'ouvrir le pare-feu pour le port 8443 sur ce serveur avant de déployer l'application. Aucune application n'écoute actuellement sur ce port particulier du serveur.
Y a-t-il quand même que je peux m'assurer que le pare-feu est ouvert pour le port 8443
OS: Linux/Windows
Si vous voulez voir si vous pouvez former une connexion TCP depuis une machine distante, installez OpenCSW sur celle-ci et la machine cible, et installez netcat sur les deux. C'est la syntaxe pour utiliser netcat pour test TCP:
nc -vz targetServer portNum
Par exemple, pour vérifier SSH sur "homeServer1":
nc -vz homeserver1 22
Cela vous permet de tester la connectivité de niveau TCP à partir du système distant. Netcat peut également être configuré pour écouter sur un port plutôt que d'agir en tant que client. Pour l'écouter sur TCP/8443:
Sur le serveur qui hébergera l'application: nc -l homeserver1 8443
Sur une machine située en dehors du pare-feu: nc -vz homeserver.fqdn 8443
Voici un exemple d'une exécution réussie:
[jadavis6@ditirlns01 ~]$ nc -vz ditirlns01.ncat.edu 8443
Connection to ditirlns01.ncat.edu 8443 port [tcp/pcsync-https] succeeded!
Une exécution ratée:
[jadavis6@ditirlns01 ~]$ nc -vz ditirlns01.ncat.edu 8443
nc: connect to ditirlns01.ncat.edu port 8443 (tcp) failed: Connection refused
Pare-feu devrait répondre avec un message ICMP lorsqu'ils bloquent une demande. Cependant, ce n'est pas nécessairement le cas (vous serez intéressé par cet article de Nice ).
Vous pouvez tester de l'extérieur pour voir si un port est accessible via un pare-feu et, si oui, si quelque chose l'écoute. Voici trois scénarios différents impliquant une requête tcp que vous pouvez observer avec wireshark, ou un autre renifleur de paquets, et ce que vous verrez:
1) Le pare-feu rejette la demande
Vous obtenez un message ICMP, et l'outil effectuant la demande devrait immédiatement vous dire quelque chose à cet effet ("inaccessible, admin interdit", etc.). Par "outil", j'entends le client que vous utilisez pour envoyer la demande (j'ai utilisé telnet). Les détails du message1 dépendent de la façon dont le pare-feu est configuré, mais "port inaccessible" est probablement le plus courant.
"Aucune route vers l'hôte" peut indiquer cela, mais cela peut également indiquer des problèmes de routage plus subtils.
2) Le pare-feu supprime le paquet
Il n'y a pas de réponse, l'outil attend donc qu'il expire ou que vous vous ennuyiez.
3) Le pare-feu autorise les paquets (ou il n'y a pas de pare-feu), mais rien n'écoute sur le port.
Vous obtenez un TCP RST/ACK message en retour. Je suppose que le TCP protocole l'exige. En d'autres termes, si rien n'écoute sur le port, le système d'exploitation lui-même envoie cette réponse. Il peut être difficile de le distinguer du n ° 1 simplement en fonction de ce que rapporte un outil, car il peut-être dit la même chose dans les deux cas (cependant, très probablement, comme "connexion refusée" vs # 1, "réseau inaccessible"). Observé dans un renifleur de paquets sur la machine cliente, les scénarios # 1 (message de rejet ICMP) et # 3 (message TCP RST/ACK) sont clairement distincts.
La seule autre option ici est que le paquet est autorisé par le pare-feu et que quelque chose écoute, vous obtenez donc une connexion réussie.
En d'autres termes: en supposant que votre réseau fonctionne en général correctement, si vous obtenez # 1 ou # 2, cela signifie qu'un pare-feu empêche activement l'accès au port. # 3 se produira si votre serveur ne fonctionne pas mais que le port est accessible, et bien sûr (implicitement) # 4 est une connexion réussie.
- Par exemple, "port inaccessible", "Hôte interdit", diverses autres combinaisons de Hôte/port/admin et inaccessible/interdit; recherchez-les dans le message car elles sont une indication explicite d'un pare-feu IP en jeu.
Vous pouvez utiliser la commande netstat pour voir si un port est ouvert et en écoute.
Exemple
$ netstat -anp | less
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:41716 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:17500 0.0.0.0:* LISTEN 3034/dropbox
tcp 0 0 0.0.0.0:17501 0.0.0.0:* LISTEN 3033/dropbox
tcp 0 0 127.0.0.1:2143 0.0.0.0:* LISTEN 3191/ssh
tcp 0 0 127.0.0.1:2025 0.0.0.0:* LISTEN 3191/ssh
La sortie affiche les processus (colonne la plus à droite) qui écoutent sur les ports TCP. Les numéros de port sont les les numéros qui suivent les deux-points après les adresses IP (0.0.0.0:111 serait le port 111 par exemple).
Les adresses IP affichent Local et Adresses étrangères. Local serait votre système tandis que Foreign serait toutes les adresses se connectant à votre TCP ou vous vous connectant à l'un de leurs TCP ports.
Donc, dans le cas du port 22, c'est le démon ssh qui s'exécute sur mon système, c'est ÉCOUTE pour les connexions. Une fois que quelqu'un essaie de se connecter au démon ssh, il crée une copie de lui-même et pousse cette connexion vers un autre port, en gardant TCP port 22 ouvert pour les connexions supplémentaires à mesure qu'elles arrivent) .
La configuration et l'état de la configuration du pare-feu sont spécifiques au pare-feu/système d'exploitation.
Ce que vous pouvez faire, c'est l'essayer depuis server2:
nmap server1
Récemment, j'ai la même demande et suis venu au fil. J'ai pu scanner des ports ouverts sur le FW avec la commande nc, comme ceci pendant que j'interroge sa sortie:
nc -v -w 1 -z -s *srcIP destIP port* 2>&1 | grep timed > /dev/null && echo closed || echo open
Fondamentalement, si j'arrive à expiration, cela signifie que le port n'est pas ouvert sur le FW.
Vous pouvez utiliser un outil en ligne tel que www.firewallruletest.com pour voir si des hôtes externes peuvent établir des connexions TCP.