Il est parfois utile de savoir si un ordinateur ou un serveur est joignable sur un port précis ; cela sert à tester la santé d'un service (Apache, MySQL), à vérifier qu'un firewall est bien configuré, etc.
Telnet... pas si net !
Une première solution serait d'utiliser telnet pour ouvrir une session sur le port en question ; exemple ci-dessous avec le port 80 servant bien souvent au protocole HTTP :
$ telnet my.server.com 80
Problème : on entre alors en mode interactif et si l'on a pas l'habitude du protocole en question ou de l'outil telnet, sortir de ce mode peut se révéler être un vrai parcours du combattant !
Netcat forever ?
netcat (nc) propose une vérification quasi instantanée grâce aux options -zv ; on sait alors de suite si le port est ouvert et surtout, l'application nous rend de suite la main :
$ nc -zv my.server.com 80
Oui mais...
Depuis quelques temps, je me suis rendu compte que certaines implémentations de netcat (RedHat / CentOS à partir de la version 7) ne permettaient pas (ou plus) cela mais affichaient tout bonnement :
nc: invalid option -- 'z'
Ncat: Try `--help' or man(1) ncat for more information, usage options and help. QUITTING.
Quelle alternative ?
Une méthode universelle sous UNIX (y compris Linux, BSD et Mac OS X) est de passer par /dev/tcp et de jouer avec les sorties. Si l'on reprend notre précédent exemple cela donne :
$ 2>/dev/null >/dev/tcp/my.server.com/80
Ici pas de message puisque nous avons redirigé les sorties c'est donc la variable $? qui nous indique le bon fonctionnement de la manoeuvre ; cette dernière devant être égale à 0 en cas de réussite.
$ echo $?
0
On peut ensuite éventuellement utiliser les opérateurs && et || pour lancer un script uniquement si le port est respectivement ouvert ou fermé.
Exemple d'affichage d'un message si le port 80 est ouvert :
$ 2>/dev/null >/dev/tcp/my.server.com/80 && echo "Server on port 80 OK"
Exemple d'envoi de mail si le port 80 est fermé :
$ 2>/dev/null >/dev/tcp/my.server.com/80 || echo "Reboot or reconfigure your firewall" | mail -s "Server on port 80 KO" bob@example.com
http://bash.over-blog.com/2015/05/verifier-si-un-port-est-ouvert-sur-une-machine-distante.html
Telnet... pas si net !
Une première solution serait d'utiliser telnet pour ouvrir une session sur le port en question ; exemple ci-dessous avec le port 80 servant bien souvent au protocole HTTP :
$ telnet my.server.com 80
Problème : on entre alors en mode interactif et si l'on a pas l'habitude du protocole en question ou de l'outil telnet, sortir de ce mode peut se révéler être un vrai parcours du combattant !
Netcat forever ?
netcat (nc) propose une vérification quasi instantanée grâce aux options -zv ; on sait alors de suite si le port est ouvert et surtout, l'application nous rend de suite la main :
$ nc -zv my.server.com 80
Oui mais...
Depuis quelques temps, je me suis rendu compte que certaines implémentations de netcat (RedHat / CentOS à partir de la version 7) ne permettaient pas (ou plus) cela mais affichaient tout bonnement :
nc: invalid option -- 'z'
Ncat: Try `--help' or man(1) ncat for more information, usage options and help. QUITTING.
Quelle alternative ?
Une méthode universelle sous UNIX (y compris Linux, BSD et Mac OS X) est de passer par /dev/tcp et de jouer avec les sorties. Si l'on reprend notre précédent exemple cela donne :
$ 2>/dev/null >/dev/tcp/my.server.com/80
Ici pas de message puisque nous avons redirigé les sorties c'est donc la variable $? qui nous indique le bon fonctionnement de la manoeuvre ; cette dernière devant être égale à 0 en cas de réussite.
$ echo $?
0
On peut ensuite éventuellement utiliser les opérateurs && et || pour lancer un script uniquement si le port est respectivement ouvert ou fermé.
Exemple d'affichage d'un message si le port 80 est ouvert :
$ 2>/dev/null >/dev/tcp/my.server.com/80 && echo "Server on port 80 OK"
Exemple d'envoi de mail si le port 80 est fermé :
$ 2>/dev/null >/dev/tcp/my.server.com/80 || echo "Reboot or reconfigure your firewall" | mail -s "Server on port 80 KO" bob@example.com
http://bash.over-blog.com/2015/05/verifier-si-un-port-est-ouvert-sur-une-machine-distante.html
No comments:
Post a Comment