2 votes

Comment interpréter le résultat de nmap, l'hôte est actif mais aucun port n'est ouvert ?

J'ai utilisé nmap pour cartographier un réseau, en effectuant un balayage à l'aide de la commande suivante

nmap -v -sS --no-stylesheet -T3 -sU -sV -O -oX <filename.xml> 192.168.69.0/24

Certains des hôtes reviennent avec un résultat étrange. Nmap pense qu'ils sont en place à cause de syn-ack . J'ai supposé que cela signifiait qu'une connexion tcp avait été établie sur un certain port et que le processus de poignée de main à trois était terminé. Cependant, aucun port n'est répertorié comme ouvert. (il y a cependant des ports ouverts|filtrés, filtrés et fermés). Quelqu'un peut-il m'expliquer comment je dois interpréter cela ? La négociation d'une connexion tcp avec un hôte ne signifie-t-elle pas qu'il doit y avoir au moins un port ouvert ?

La sortie XML de l'analyse pour cet hôte est présentée ci-dessous :

<host starttime="1435615239" endtime="1435901758">
  <status state="up" reason="syn-ack" reason_ttl="115"/>
  <address addr="192.168.69.23" addrtype="ipv4"/>
  <hostnames>
    <hostname name="example.com" type="PTR"/>
  </hostnames>
  <ports>
    <extraports state="open|filtered" count="1000">
    <extrareasons reason="no-responses" count="1000"/>
    </extraports>
    <extraports state="filtered" count="996">
    <extrareasons reason="no-responses" count="996"/>
    </extraports>
    <port protocol="tcp" portid="111">
    <state state="closed" reason="reset" reason_ttl="115"/>
    <service name="rpcbind" method="table" conf="3"/>
    </port>
    <!-- more closed ports -->
  </ports>
  <os><!-- ... --></os>
  <times srtt="3165" rttvar="109" to="100000"/>
</host>

3voto

Yamaho Points 4053

Nmap estime qu'ils sont en hausse à cause de syn-ack. J'ai supposé que cela signifiait qu'une connexion tcp avait été établie sur un certain port et que le processus de poignée de main à trois était terminé.

En fait, Nmap n'effectue pas d'échange à trois pour la découverte d'un hôte (ni pour le balayage TCP SYN avec la fonction -sS ). Il envoie un paquet TCP SYN brut au port 443 ( entre autres sondes ), et considère l'hôte comme opérationnel s'il reçoit l'une des différentes réponses possibles. Dans votre cas, la cible a envoyé une réponse SYN-ACK, indiquant un port ouvert. Nmap laisse alors le soin au système d'exploitation de votre hôte d'envoyer un paquet RST en réponse, puisque le système d'exploitation n'est pas au courant du SYN sortant et n'attend pas la réponse SYN-ACK. Si votre pare-feu est configuré pour DROP les paquets invalides ou inattendus, le RST ne sera jamais envoyé.

Certaines piles TCP, en particulier sur les appareils embarqués, ne gèrent pas très bien les anomalies TCP. Votre cible pourrait être assise avec une connexion TCP semi-ouverte sur le port 443, attendant un paquet RST ou ACK qui n'arrive jamais, ce qui provoquerait la sonde SYN suivante pendant le processus de connexion. phase de balayage des ports de ne pas obtenir de réponse.

Mais il ne s'agit que d'hypothèses. Il est tout aussi probable que la cible dispose d'une sorte de pare-feu adaptatif qui a détecté le scan de port et a commencé à bloquer le trafic de Nmap avant qu'il n'atteigne le port ouvert 443.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X