Nmap - Intense vs résultat rapide

Question

J'ai hérité d'un petit réseau et j'améliore actuellement ses performances de sécurité.

J'ai démarré le port d'un hôte (appelez-le weirdo) dans ce petit réseau et de mon point de vue, il semble que cet hôte spécifique ait une sorte de Détecteur de balayage de ports et/ou Obfustructeur de résultat de balayage chose avec IPTABLES Se passe, car le résultat revenant de Intense Scan Diffère tellement de celui du rapide un.

Donc, ici le rapide Résultat de balayage me@mypc:~# nmap -T4 -F 12.34.56.78:

Starting Nmap 7.01 ( https://nmap.org ) at 2017-04-18 11:48 CEST Nmap scan report for 12.34.56.78 Host is up (0.57s latency). Not shown: 93 closed ports PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 53/tcp open domain 80/tcp open http 3306/tcp open mysql 8080/tcp open http-proxy 8443/tcp open https-alt Nmap done: 1 IP address (1 Host up) scanned in 4.15 seconds

Cela montre en fait la même sortie que l'analyse rapide de Weirdo localhost root@Weirdo:~# nmap -T4 -F localhost.

Mais c'est le intense Scan me@mypc:~# nmap -T4 -A -v 12.34.56.78:

1/tcp open tcpmux? ...(every port is shown as open, except a few) 49155/tcp open unknown ... 9102/tcp open jetdirect? ... 65389/tcp open tcpwrapped ... Completed SYN Stealth Scan at 11:49, 18.22s elapsed (1000 total ports) ... Not shown: 120 closed ports

Remarque: ... signifie répétition de la ligne précédente avec un numéro de port différent

Donc, fondamentalement, le intense Scan découvre que beaucoup d'autres ports sont ouverts, mais c'est le paradoxe, car le scan intense sur le weirdo localhost root@Weirdo:~# nmap -T4 -A -v localhost donne également exactement la même liste de ports ouvertes que l'analyse rapide.

Quand je regarde le Traceroute Ensuite, je vois ce qui suit:

TRACEROUTE (using port 199/tcp) HOP RTT ADDRESS 1 1.52 ms 12.99.34.255 2 1.37 ms 12.99.0.3 3 1.09 ms 12.34.56.78

PORT Numérisation des deux IP avec me@mypc:~# nmap -sV -T4 -O -F --version-light 12.99.34.255 12.99.0.3 Je vois ça 12.99.34.255 est un pare-feu Netgear FVS336GV2 accessible avec le navigateur (le port 80, est donc ouvert).

Une analyse rapide (1 secondes après), une analyse rapide (après la numérisation intense) entraîne la même sortie que l'analyse intense.

Après avoir attendu quelques secondes, puis effectuez la numérisation rapide, il en résulte la même sortie que la numérisation rapide initiale.

Ce pare-feu joue-t-il probablement sur le scan intense ?

Un autre petit ajout:

Sur le weirdo hôte je vérifie le pare-feu iptables et obtenez ceci:

root@Weirdo:~# iptables -vL -t filter Chain INPUT (policy DROP 25288 packets, 1768K bytes) pkts bytes target prot opt in out source destination 101K 54M ACCEPT all -- lo any anywhere anywhere 189K 12M ACCEPT all -- eth1 any anywhere anywhere 285 9686 ACCEPT icmp -- eth0 any anywhere anywhere icmp echo-request 297 30354 garbage all -- eth0 any anywhere anywhere state INVALID 0 0 garbage tcp -- eth0 any anywhere anywhere tcpflags: FIN,SYN,RST,PSH,ACK,URG/NONE 0 0 garbage tcp -- eth0 any anywhere anywhere tcpflags: FIN,SYN/FIN,SYN 0 0 garbage tcp -- eth0 any anywhere anywhere tcpflags: SYN,RST/SYN,RST 0 0 garbage tcp -- eth0 any anywhere anywhere tcpflags: FIN,RST/FIN,RST 0 0 garbage tcp -- eth0 any anywhere anywhere tcpflags: FIN,ACK/FIN 0 0 garbage tcp -- eth0 any anywhere anywhere tcpflags: PSH,ACK/PSH 0 0 garbage tcp -- eth0 any anywhere anywhere tcpflags: ACK,URG/URG 1968K 2742M ACCEPT all -- eth0 any anywhere anywhere state RELATED,ESTABLISHED 9564 391K ACCEPT tcp -- eth0 any anywhere anywhere tcp dpt:http 463 27508 ACCEPT tcp -- eth0 any anywhere anywhere tcp dpt:domain 45 2392 ACCEPT tcp -- eth0 any anywhere anywhere tcp dpt:8443 0 0 ACCEPT tcp -- eth0 any anywhere anywhere tcp dpt:9422 25288 1768K garbage all -- eth0 any anywhere anywhere Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 1361K packets, 501M bytes) pkts bytes target prot opt in out source destination Chain garbage (9 references) pkts bytes target prot opt in out source destination

Ces filtres jouent-ils les astuces sur le scan intense ?

Qu'est-ce que cela signifie avoir une règle avec la cible garbage ?

bonsaiviking · Answer

Tout d'abord, corrigeons certaines hypothèses et terminologie qui feront comprendre les résultats beaucoup plus facilement:

Les -F L'option est une analyse "rapide" car elle analyse seulement 100 ports. C'est l'équivalent de --top-ports 100. Sans cette option, Nmap scanne 1000 TCP ports.
Les -A L'option n'est pas "intense" mais plutôt "toutes les fonctionnalités". C'est l'équivalent de -sV -sC -O --traceroute.

Vous avez donc exécuté un balayage de ports de 100 ports et comparez-le à un balayage de port avec la détection de la version et l'empreinte d'exploitation de système d'exploitation de 1000 ports. C'est compréhensible que vous auriez plus de résultats dans la deuxième analyse. Mais laissez-vous supposer que vous vouliez littéralement "chaque port est ouvert" dans le deuxième scan. Quelle pourrait être la cause et comment pouvons-nous savoir à coup sûr?

Premièrement, il serait intéressant de savoir si le -F Scan génère des résultats différents si exécuté après le -A analyse. Je soupçonne que ce serait. Cela montrerait alors que quelque chose (probablement le pare-feu) a changé la manière dont les paquets sont passés entre le système de numérisation et la cible. Voici les indices que je vois dans la deuxième analyse:

ports plus ouverts
Services non identifiés (tcpmux?) et tcpwrapped services
ouvrir des ports indiqués qui ne sont pas dans une analyse locale de la cible

IPTABLES n'est pas assez intelligent seul pour adapter le comportement comme celui-ci, et rien dans vos règles ne le montre non plus. Donc, l'interférence provient probablement d'un système différent sur le chemin réseau entre le scanner et la cible. Si vous aviez enregistré une sortie XML (-oX ou -oA) ou avait utilisé le --reason Option (également activée par -vv ou -d), alors vous seriez capable de voir des détails sur pourquoi Nmap considéré chaque port ouvert ou fermé. le La partie la plus intéressante de ceci est la reason_ttl Attribut, qui enregistre la valeur de champ time-dirige IP reçue, qui est normalement décrémentée une fois pour chaque hop IP sur le chemin réseau. Donc, pour une cible Linux, les réponses commencent à TTL 64 et avec 2 sauts entre les deux devraient être réduites à 62. Tout ce que vous voyez dans la version la plus précise du scan (c'est-à-dire l'-F Scannez avec principalement des ports fermés) est votre base de référence. Si vous commencez à voir des valeurs plus élevées que cela, cela signifie probablement que quelque chose entre vous et la cible envoie des réponses au lieu de la cible. Exemple (le port 27 est "faux-ouvert"):

[.____ HTTP SYN-ACK TTL 60 [.____]

Éviter cela impliquera probablement de ralentir votre analyse pour éviter de trébucher le seuil d'alerte "Scan". Évasion de mesures adaptatives telles que celle-ci est compliquée . Mais une fois que vous avez trébuché le seuil, vous pouvez faire des choses intéressantes pour cartographier les règles de pare-feu.

Si vous êtes en train d'être "bloqué" de cette manière avec de nombreux ports ouverts, mais vous pouvez toujours accéder aux services réels derrière l'ensemble d'original de ports (SSH, SMTP, HTTP, etc.), vous pouvez essayer de définir un très faible =TTL Valeur dans vos paquets Outbound. Lorsqu'un routeur diminue le TTL sur 0, il enverra un message expiré ICMP TIME, entraînant étiqueté le port filtered. Si nous pouvons choisir un TTL affluant après le pare-feu, mais avant la cible, nous pouvons obtenir une liste de ports "ouverts" causés par le pare-feu et un ensemble de ports "filtrés" qui sont probablement autorisés. Dans Votre exemple, basé sur la sortie Traceroute, j'utiliserais le --ttl 2 option, puisque --ttl 3 atteindrait réellement la cible. Donc, la scan ressemblerait: nmap -sS --ttl 2 -Pn example.com. À l'aide de -Pn n'est généralement pas recommandé, mais dans ce cas est nécessaire, car les sondes n'atteignent jamais la cible. Rappel: Cette analyse ne produira que de la sortie utile si vous êtes actuellement bloqué par le pare-feu et si le bloc n'est pas sur tous les ports, mais il faut du trafic:

 Raison du service d'état du port [.____] 25/TCP filtré SMTP dépassé de 12,99,34,255 TTL 252 [.____] 27/TCP Ouvrir NSW-Fe Syn-ack TTL 61 [. 80/TCP HTTP Temps HTTP dépassé de 12.99.34.255 TTL 252 [.____]

Dans cette sortie, le port 27 a reçu un rayon de syn-ack à ressembler à celui de la cible, même si nous savons de notre --ttl 2 que notre sonde n'aurait jamais atteint la cible. Les deux autres ports sont autorisés à traverser, car nous obtenons les messages dépassés de temps après leur expiration. Si le pare-feu n'autorise pas les messages dépassés du temps sortant, ils montreraient comme filtered avec un no-response raison.