masscan icon indicating copy to clipboard operation
masscan copied to clipboard

UDP Port scanning not working

Open petakcm8 opened this issue 9 years ago • 12 comments

Hello,

I am facing a rather strange issue while trying to do any protocol UDP port scanning with Masscan.

Every time I specify an udp port with the arguments -pU:port or --ports U: the scan returns 0 results, while everything works normally for TCP .

Any logical explanation for this ?

petakcm8 avatar Jul 30 '15 20:07 petakcm8

I am also seeing this issue.

$ masscan 0.0.0.0/0 -pU:53 --banners --output-filename dns.xml --echo | grep port
ports = 65589

vs.

$ masscan 0.0.0.0/0 -p53 --banners --output-filename dns.xml --echo | grep port
ports = 53

ghost avatar Sep 03 '15 17:09 ghost

I am seeing this issue as well. UDP Scans are failing to find open UDP 53 ports. NMAP UDP works. There is no issue with TCP.

Johnny5113 avatar Oct 16 '15 18:10 Johnny5113

I am alse seeing this issue, udp port scan can't work by masscan program

ddyy0308 avatar Apr 18 '16 06:04 ddyy0308

Workaround found, "masscan 0.0.0.0/4 -pU:123 -oL scan.output" wont give any results

instead use:

masscan 0.0.0.0/4 -pU:123 > myFile

IT will record the output to terminal e.g.: Discovered open port 123/udp on 1.2.3.4

What is really interesting about this, is that while we 'discover' an open port, we are not able to record it with --pcap record.pcap - which usually works fine.

ghost avatar May 28 '16 21:05 ghost

Doesn't seem like masscan works with UDP ports. Have read the manual and ran the arguments mentioned in the manual with no luck. Check this out:

# masscan 1.1.1.1 -pU:161,U:1024-1100                                                                                                      

Starting masscan 1.0.5 (http://bit.ly/14GZzcT) at 2019-11-19 17:03:40 GMT
 -- forced options: -sS -Pn -n --randomize-hosts -v --send-eth
Initiating SYN Stealth Scan
Scanning 1 hosts [78 ports/host]

As evident in the output above, it forces the -sS option and completely ignores UDP.

altjx avatar Nov 19 '19 17:11 altjx

Doesn't seem like masscan works with UDP ports. Have read the manual and ran the arguments mentioned in the manual with no luck. Check this out:

# masscan 1.1.1.1 -pU:161,U:1024-1100                                                                                                      

Starting masscan 1.0.5 (http://bit.ly/14GZzcT) at 2019-11-19 17:03:40 GMT
 -- forced options: -sS -Pn -n --randomize-hosts -v --send-eth
Initiating SYN Stealth Scan
Scanning 1 hosts [78 ports/host]

As evident in the output above, it forces the -sS option and completely ignores UDP.

I noticed the same thing with version 1.3.0. Doesn't seem to have been fixed... Are maintainers aware of this??

aayla-secura avatar May 19 '21 20:05 aayla-secura

I noticed this on 1.3.2 as well. Still not working?

Doesn't seem like masscan works with UDP ports. Have read the manual and ran the arguments mentioned in the manual with no luck. Check this out:

# masscan 1.1.1.1 -pU:161,U:1024-1100                                                                                                      

Starting masscan 1.0.5 (http://bit.ly/14GZzcT) at 2019-11-19 17:03:40 GMT
 -- forced options: -sS -Pn -n --randomize-hosts -v --send-eth
Initiating SYN Stealth Scan
Scanning 1 hosts [78 ports/host]

As evident in the output above, it forces the -sS option and completely ignores UDP.

I noticed the same thing with version 1.3.0. Doesn't seem to have been fixed... Are maintainers aware of this??

huynguy97 avatar Sep 18 '21 13:09 huynguy97

Masscan outputs Initiating SYN Stealth Scan even for UDP scans. See comment below or click link for full context. (Only ICMP scans get a special "Initiating" line).

https://github.com/robertdavidgraham/masscan/blob/144c527ed55275ee9fbb80bb14fbb5e3fcff3b7e/src/main.c#L1358-L1365

mikeryan avatar Dec 16 '21 20:12 mikeryan

Bump for attention from @robertdavidgraham - this still affects the latest revision as of today. UDP scanning causes the outbound packets and I can see the replies (for DNS in particular) but they're not recorded to output files, nor do they increment the found= number on the STDERR status text.

The workaround listed above (https://github.com/robertdavidgraham/masscan/issues/182#issuecomment-222330773) did work for me, however.

jeffmcjunkin avatar May 30 '22 18:05 jeffmcjunkin

Well, I just found this issue. The udp scan was working in a very old version. Now it does not work oppositely, I will try the solution above and edit this comment later.

but if I use output redirection, parsing it in program is a problem…

Update 1: I use it and found a 53/udp ystd, weird. Same environment today, but nothing found now.

Update 2: Solution in previous reply is not working here.

kmahyyg avatar May 07 '23 05:05 kmahyyg

Same issue. UDP scan doesnt work

AloneAndUnknown avatar Aug 03 '23 19:08 AloneAndUnknown

Masscan outputs Initiating SYN Stealth Scan even for UDP scans. See comment below or click link for full context. (Only ICMP scans get a special "Initiating" line).

https://github.com/robertdavidgraham/masscan/blob/144c527ed55275ee9fbb80bb14fbb5e3fcff3b7e/src/main.c#L1358-L1365

If I remember correctly, this is a PR I sent because it bothered me and I had a use-case for ICMP-only scans

If you want the status to look “correct”, you can model a PR off of that and add UDP

at the time, I realized there were 2 choices:

  1. Add status ouput when the scan is icmp only
  2. “Fix” the entire status reporting code. This includes OR’ing the different scan modes, since you can mix tcp and UDP into a single scan- so there are three status lines- “udp”, “tcp” and “udp and tcp”

in the end, it’s all aesthetics so I didn’t opt for handling the udp or udp+tcp case

EDIT: #109 , #240 and #244 are the PRs I sent regarding the general issue of “UDP and ICMP as an afterthought” in the code. Only one (#244, the icmp buckets+dedup) has an actual impact on the scanning, the others are aesthetic as I mentioned

EDIT: If you want to send PRs, I recommend using https://github.com/IVRE/masscan as your upstream. @robertdavidgraham seems too busy to deal with PRs, Pierre/@p-I- (who maintains IVRE) is VERY active and responsive and will merge balid PRs. Doesn’t mean PRs can’t be sent to this repo as well, but there are several important PRs here sitting without any attention that the IVRE fork has merged- #646 is a very good example of this

mzpqnxow avatar Aug 06 '23 14:08 mzpqnxow