Open Fxyer opened 5 years ago
We also encountered the same issue when using udp as some ip results were not part of our target list.
I have the same issue
I've noticed this even on TCP scans. My system's DNS server sometimes pops up in the results, even though it's not in the target list:
{ "ip": "8.8.8.8", "timestamp": "1716789975", "ports": [ {"port": 53, "proto": "udp", "status": "open", "reason": "none", "ttl": 56} ] }
I assume this is a side effect of masscan having its own TCP stack.
For me, this happened when running the following command:
masscan --rate 300 --wait 5 --open-only -oJ - -iL targets.txt --top-ports 100
Where targets.txt
contained:
23.220.132.93/32
104.85.4.91/32
23.218.192.46/32
96.16.108.43/32
104.80.228.227/32
First of all, thank you for your wonderful work, a little bug here..
Phenomenon: in host 10.10.10.10 when I scan 20.20.20.20 running a task like:
/bin/masscan --rate 10000 -pU:1-65535 20.20.20.20
at the some time,in host 30.30.30.30 I scan 10.10.10.10 by this command:/bin/masscan --rate 10000 -pU:1-65535 10.10.10.10
in host 10.10.10.10, I get a result that "30.30.30.30's udp port 7777 is up",like this:Discovered open port 7777/udp on 30.30.30.30
but in host 10.10.10.10,my target is 20.20.20.20 not 30.30.30.30Analysis: in host 10.10.10.10, host need choose a random local port as source port for packets that sniff 20.20.20.20's all udp ports , for example local port is 5555 in host 30.30.30.30, host scan all the udp ports of host 10.10.10.10, including port 5555, in host 10.10.10.10, there is a packet like:
10.10.10.10:5555 --> 20.20.20.20:1234
at the some time, host 10.10.10.10 recevie a udp packet like :30.30.30.30:7777 --> 10.10.10.10:5555
10.10.10.10 think target response a udp packet towards it's port 5555, so report tasget's 7777 is up,but In fact 30.30.30.30 is not in targets.because of tcp's three-way handshake model,tcp is not affected.
Solution: When find an udp port up,check if it is in the target
Wish you a happy life~~