Nmap signalant que presque tous les ports sont ouverts
J'ai remarqué lors de certaines évaluations lors d'une analyse de port TCP, Nmap signalera presque tous les ports ouverts pour une machine).
En utilisant par exemple nmap -sS -PN -T4 target -p0-65535, plus de 20 000 ports seront retournés ouverts. Après enquête, la plupart de ces ports ne sont pas ouverts ni même filtrés.
Qu'est-ce qui pousse Nmap à considérer les ports ouverts, et existe-t-il un type d'analyse différent qui peut contrer cela et donner des résultats plus précis?
Vous frappez très probablement une appliance IDS/IPS bien configurée.
snort peut facilement détecter votre analyse de port en cours avec le filtre sfPortscan (le -sS est pratiquement une signature "analyse de port en cours"), et en plus de consigner votre attaque, il peut être configuré pour effectuer une réponse active . Ces réponses peuvent être aussi simples que vous envoyer un RST, ou aussi riches que la règle " react ". Le comportement par défaut de la réponse "réagir" consiste à répondre par un HTTP 403 Forbidden message, mais ils peuvent également le configurer pour envoyer toutes les données arbitraires souhaitées. Le comportement de réaction n'est pas limité aux demandes de port 80 non plus. snort enverra la réponse quel que soit le numéro de port .
Pour tester cette théorie, tout en effectuant une analyse de port de la cible, à partir de la même machine qui effectue l'analyse, essayez d'ouvrir n'importe quel ancien port sur cette cible avec un navigateur ou un netcat. Si vous recevez la réponse HTTP 403 Interdit d'un port non HTTP, c'est probablement ce qui se passe.
Je suppose que nmap n'interprète pas la réponse, il signale uniquement que la connexion socket a été établie, il vous le signale donc comme un port ouvert. Plutôt que de deviner, cependant, vous pouvez définir le --packet-trace option sur nmap pour voir ce que vous récupérez réellement.
Vous pouvez lire le snort manual here .
Vous avez quelques options. Ma première pensée serait qu'il pourrait y avoir un système intermédiaire qui répond avec des paquets SYN/ACK aux ports interdits (pare-feu). Si tel est le cas, vous pourrez peut-être distinguer les ports vraiment ouverts par le TTL de la réponse. Si vous avez enregistré la sortie XML de votre scan (-oX ou -oA), vous pouvez vérifier le //port/state/@reason_ttl attribut. Ceci est similaire à la technique du "firewalking". Vous pouvez trouver des informations connexes ici: Firewalking avec nmap .
Une autre alternative serait d'utiliser un type de scan différent . Scan SYN de Nmap (-sS ou par défaut lors de la numérisation en tant que root) peut être détecté par les options TCP, MSS et taille de la fenêtre, donc un IDS/IPS pourrait y répondre. Essayez d'utiliser le TCP Scan de connexion (-sT) au lieu. D'autres types de scan (ACK, FIN, Maimon, etc.) pourraient être utilisés pour filtrer vos résultats; ils ne montreront pas les ports ouverts par eux-mêmes, mais ils pourraient signaler certains de ces ports "ouverts" comme pare-feu, ou du moins montrer qu'ils se comportent différemment. Faites preuve de prudence ici, cependant, car ceux-ci envoient de "mauvais" paquets très visibles et reposent sur des comportements qui ne sont pas souvent présents dans les systèmes d'exploitation modernes.
Enfin, vous pouvez utiliser la détection de version de service de Nmap (-sV) pour identifier les services derrière les ports "ouverts". Il est probable que les faux positifs expirent simplement ou envoient un RST pour fermer la connexion peu de temps après son ouverture. Cela ralentira considérablement votre analyse, mais il est parfois important d'être précis. Je recommanderais de commencer par --version-intensity 0, qui fera simplement une capture de bannière et éventuellement des sondes qui sont marquées sur le port spécifique en cours d'analyse, par opposition à la valeur par défaut, qui le fait et jusqu'à 8 autres tests.
Il existe une technique d'obscurcissement dans laquelle un serveur simule presque tous les ports à ouvrir, simulant idéalement une signature de service valide sur la plupart de ces ports.
Portspoof , par exemple, implémente cette approche et gère plus de 8000 signatures de service.
Il m'est arrivé la même chose. C'est Snort qui l'a causé. Ajout du -f et --badsum le passage à nmap m'a permis de contourner l'IDS/IPS. La commande complète était la suivante:
nmap -sS -p 1-65535 -f --badsum -vv -Pn -oA target_nmap target
J'ai fait face au même problème que toi. Dans mon cas, l'IDS/IPS enverrait un SYN, ACK pour tous les ports, ce qui a amené nmap à conclure que tous les ports étaient ouverts.
Cependant, alors que les paquets doivent être retransmis lorsqu'ils ne sont pas acquittés conformément à la spécification TCP , l'IDS/IPS n'a PAS retransmis de paquets qui n'ont pas été acquittés (ce qui est le cas dans un TCP SYN scan),.
Par conséquent, j'ai pu distinguer les ports ouverts de ceux inaccessibles en regardant les paquets retransmis dans Wireshark. Si un SYN, ACK a été retransmis, cela signifiait que le port était ouvert.
Le filtre Wirehark que vous pouvez utiliser pour cela est:
tcp.analysis.retransmission
Il pourrait y avoir un certain nombre de choses qui se passent ici.
John a mentionné que le reniflement ou un autre type d'IDS/IPS était un piège potentiel qui attrape votre scan de synchronisation. Vous pouvez essayer de passer de -sS à -sT et de spécifier une période de temps à attendre avant d'essayer d'analyser un autre port - sfportscan est piloté par le temps, s'il est activé. (Source: ancien employé de Sourcefire)
D'autres possibilités incluent des pare-feu d'inspection avec état. J'ai vu des cas où s'il y a un pare-feu/NAT/dispositif de filtrage entre vous et votre cible d'analyse, le pare-feu peut renvoyer un SYN/ACK, alors qu'en fait le port vers votre cible réelle peut ne pas être accessible. Encore une fois, essayez une analyse -sT et déterminez le nombre de ports que vous essayez d'analyser simultanément.
La mise en garde à l'aide de -sT par opposition à -sS ou à d'autres types d'analyse est que, si un service écoute sur un port et que vous obtenez une réponse, il y a de fortes chances que vous finissiez par vous connecter. Pour un exemple de ceci, lancez une analyse -sT sur n'importe quel démon ssh et vérifiez/var/log/secure par la suite.
J'ai eu des choses étranges avec nmap dans le passé lorsque j'essaie de numériser trop rapidement, et -T4 est après tout défini comme "agressif". Essayez de régler votre vitesse de numérisation sur 3 et voyez si vous obtenez les mêmes résultats.
Vous pouvez également rencontrer des bogues dans le système d'exploitation ou nmap ou des problèmes d'interopérabilité de quelque sorte. Si vous avez un autre système, essayez de l'exécuter et voyez si vous obtenez le même résultat.
Il peut y avoir une technologie de pare-feu qui perturbe votre trafic, voyez si vous pouvez éliminer quoi que ce soit sur le chemin.