Bonjour à tous, nmap propose de nombreuses options et certaines sont capable de déterminer le service exacte tournant sur un port. Par ex lorsque je fait un scan de ma machine sur laquelle ssh tourne sur le port 2022 : # nmap -sV pcadmin1
Starting Nmap 4.62 ( http://nmap.org ) at 2009-03-05 10:07 CET Interesting ports on pcadmin1.local (192.168.12.3): Not shown: 1706 closed ports PORT STATE SERVICE VERSION 80/tcp open http Apache httpd 2.2.9 ((Ubuntu) PHP/5.2.6-2ubuntu4.1 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g) 111/tcp open rpcbind 139/tcp open netbios-ssn Samba smbd 3.X (workgroup: WORKGROUP) 443/tcp open ssl/http Apache httpd 2.2.9 ((Ubuntu) PHP/5.2.6-2ubuntu4.1 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g) 445/tcp open netbios-ssn Samba smbd 3.X (workgroup: WORKGROUP) 901/tcp open http Samba SWAT administration server 2022/tcp open ssh (protocol 2.0) 2049/tcp open rpcbind 8081/tcp open tcpwrapped 1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at http://www.insecure.org/cgi-bin/servicefp-submit.cgi : SF-Port2022-TCP:V=4.62%I=7%D=3/5%Time=49AF9642%P=i686-pc-linux-gnu%r(NULL, SF:27,"SSH-2\.0-OpenSSH_5\.1p1\x20Debian-3ubuntu1\r\n"); MAC Address: 00:19:B9:XX:XX:XX (Dell) Host script results: |_ Discover OS Version over NetBIOS and SMB: OS version cannot be determined. Service detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 13.296 seconds # On remarque ainsi que le service ssh a bien été détecté sur le port 2022 mais qu'il n'a pas été capable de déterminer la version exact dont il donne la signature en fin d'analyse. On retrouve facilement dans la signature la version du service ssh :OpenSSH_5.1p1 Debian-3ubuntu1 On peux meme en déduire la version de l'OS (bien que l'option -A soit un peu plus indiquée) Sinon concernant le changement de port du service ssh, je considère que ce n'est pas une nécessité si l'on utilise un système tel que denyhost qui va bannir les IP qui ont fait trop de tentatives de connection en échec (3 par défaut). Mais en considérant que les attaques sont réalisées par des robot qui ne vont pas chercher ssh sur un autre port que le port 22 on peut estimer que cela réduit tout de meme les risques liés à une éventuelle faille de ssh par ex. J'espere avoir éclairé un peu la chose. Cordialement, Matthieu CHAUVEAU _____ From: Alain Vaugham [mailto:[email protected]] To: [email protected] Sent: Wed, 04 Mar 2009 19:00:50 +0100 Subject: Re: accès ssh Le samedi 31 janvier 2009 13:30, Jerome Kieffer a écrit : | On Fri, 30 Jan 2009 22:47:38 +0100 | Alain Vaugham <[email protected]> wrote: | | > Le mardi 20 janvier 2009 16:30, Paul Marques Mota a écrit : | > | Le 20 janvier 2009 08:26, Jerome Kieffer | > | <[email protected]> a écrit : | > | > On Tue, 20 Jan 2009 01:48:42 +0100 | > | > Alain Vaugham <[email protected]> wrote: | > | > | > | >> J'ai listé toutes les réponses reçues : | > | >> - le changement du port du sshd | > | > | > | > C'est con, un coup de nmap et on le retrouve ton port. | > | | > | Oui. Le but de cette partie de la manip n'est pas vraiment de rajouter | > | plus de sécurité, mais de diminuer le volume des attaques. | > | | > | > Pour info : | > Il y a une semaine j'ai pu faire changer le port 22 sur la box. | > | > C'est passé brusquement de 20-22 tentatives à la minute à 0. | > Je ne consulte que les /var/log/auth.log.* | | cette méthode ne tient pas 1 minute face à un utilisateur avec nmap | en main. Encore une fois, je ne mets pas en doute cette possibilité avec nmap. Aussi, j'ai voulu me mettre à la place d'un utilisateur avec nmap en main pour comprendre ce qui se passe. J'ai essayé différents ports d'écoute pour ssh (/etc/ssh/sshd_config) autres que le 22 sans oublier de redémarrer le service à chaque fois. J'ai vérifié mon authentification sans mot de passe avec une paire de clefs. moi_ici:$ ssh -p4443 [email protected] moi_labas:$ J'ai ensuite vérifié ce que donnait cette commande nmap : moi_ici: $ nmap -P0 192.168.3.111 Voici les résultats pour les 4 ports sur lesquels j'avais mis ssh : 4443 aucun port ni service ne sont affichés 4444/tcp open krb524 7234 aucun port ni service ne sont affichés 9527 aucun port ni service ne sont affichés D'après ce que j'ai compris le nom du service affiché est un nom normalisé pour les ports inférieur à 1000 ou un nom enregistré mais en attente de normalisation ou toléré (?) jusqu'à 3000 et totalement libre au délà jusqu'aux 65000 environ. Dans la syntaxe de nmap que j'ai utilisée, je constate que le résultat retourné est le nom "normalisé" du service et non le nom du service qui est réellement à l'écoute sur le port. ssh tournait sur le port 4444 bien que le nom affiché par nmap soit krb524. Au passage, j'imagine que j'ai pris un risque en choisissant 4444 au hasard. C'est visible que je ne suis pas un cador en nmap donc avec ces quatres résultats je pourrai en déduire que la victime n'a pas d'accès ssh ouvert. Inversement je pourrai me contenter de croire qu'il suffit d'utiliser un port non "répertorié/normalisé" pour masquer la présente d'un service ssh sur la victime et rendre ainsi plus difficile la tâche aux attaquants. Bien que ce soit contraire à ce qui est conseillé un peu partout de ne pas utiliser les ports normalisés, peut-on envisager de masquer la présence d'un service ssh par exemple en 80 ou en 25 (si pas de http ou de smtp)? Y a-t-il une autre syntaxe de nmap qui permette de découvrir (en moins d'une minute ;-) ) que dans mon exemple sur le port 4444, c'est bien ssh qui tourne même si c'est krb524 qui est affiché? J'ai parcouru le man de nmap mais il y a tellement de possibilités obscures pour moi que j'ai compris que je n'ai pas encore la capacité à le comprendre. -- Cordialement Alain Vaugham -------------------------------------------------------- [PUB] Signature numérique GPG de ce courrier: 0xD26D18BC
_________________________________ Linux mailing list [email protected] http://lists.parinux.org/mailman/listinfo/linux
