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
Réponses:
Si vous voulez voir si vous pouvez établir une connexion TCP à partir d'une machine distante, installez OpenCSW sur celle-ci et la machine cible, et installez netcat sur les deux. Voici la syntaxe d'utilisation de netcat pour tester les connexions 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
Les pare-feu doivent 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 ce bel article ).
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 demande 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 message 1 dépendent de la configuration du pare-feu, 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 message TCP RST / ACK en retour. Je suppose que le protocole TCP 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 qu'un outil rapporte, car il peut dire la même chose dans les deux cas (cependant, il est très probable qu'il le distingue comme "connexion refusée" vs n ° 1, "réseau inaccessible"). ). Observés 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 soit autorisé par le pare-feu et que quelque chose écoute, donc vous obtenez 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.
Vous pouvez utiliser la commande netstatpour voir si un port est ouvert et en écoute.
$ 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 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 les adresses locales et étrangères . Local serait votre système tandis qu'étranger serait toutes les adresses se connectant à votre port TCP ou vous connectant à l'un de leurs ports TCP.
Donc, dans le cas du port 22, c'est le démon ssh qui s'exécute sur mon système, c'est ÉCOUTER les connexions. Une fois que quelqu'un tente de se connecter au sshdémon, il copie une copie de lui-même et pousse cette connexion vers un autre port, en gardant le port TCP 22 ouvert pour des connexions supplémentaires à mesure qu'elles entrent.
netstat -a -P tcp -f inet | awk '/LISTEN$/ {print $0}'
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 je questionne 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.
ncsignale "Connexion refusée" lorsque le port est accessible, mais il n'y a pas d'écouteur, et "Le réseau est inaccessible" lorsque la demande a été renvoyée par un pare-feu via icmp (ce qui signifie qu'il peut y avoir ou non un service sur le port ). Si le pare-feu supprime le paquet au lieu de le rejeter, ilncse bloquera pendant un certain temps.