Masscan doesn't recognized opened port

[altjx]

Any assistance would be great. I've seen this issue a few times over the years, but just always flipped over to Nmap in those particular scenarios. However, I'm very curious to try nailing down what may be going on here.

In this particular scenario, I know this system has several ports opened -- 21/tcp, 23/tcp, 80/tcp, etc.; however, Masscan fails to ever identify any of these opened ports whereas I can confirm the ports are opened with other tools.

Masscan details:

Masscan version 1.3.2 ( https://github.com/robertdavidgraham/masscan ) Compiled on: Feb 2 2021 11:13:27 Compiler: gcc 10.2.1 20210110 OS: Linux CPU: unknown (64 bits) GIT version: unknown

Masscan output:

└─# masscan -vv 192.168.3.127 -Pn -p 23 --rate=3500 -sS -vv
[+] pcap: found library: libpcap.so
pfring: error: dlopen('libpfring.so'): Operation not permitted
if: route: '        eth0' dst=0.0.0.0 src=192.168.3.232 gw=192.168.1.5 priority=100
if: route: '        eth0' dst=192.168.0.0 src=192.168.3.232 gw=0.0.0.0 priority=0
if: route: '        eth0' dst=192.168.1.5 src=192.168.3.232 gw=0.0.0.0 priority=100
if: route: '     docker0' dst=172.17.0.0 src=172.17.0.1 gw=0.0.0.0 priority=0
[+] interface = eth0
[+] if(eth0): pcap: libpcap version 1.10.1 (with TPACKET_V3)
[+] if(eth0): opening...
[+] if(eth0): successfully opened
[+] interface-type = 1
if:eth0: not receiving transmits
if:eth0: type=ethernet(1)
[+] source-mac = 00-15-5d-01-67-0f
[+] source-ip = 192.168.3.232
[+] if(eth0): looking for default gateway
[+] router-ip = 192.168.1.5
[+] if(eth0):arp: resolving IPv4 address
[+] arp: 192.168.1.5 == d4-76-a0-78-f0-ae
[+] router-mac-ipv4 = d4-76-a0-78-f0-ae
[+] if(eth0): initialization done.
Starting masscan 1.3.2 (http://bit.ly/14GZzcT) at 2022-08-14 21:26:36 GMT
Initiating SYN Stealth Scan
Scanning 1 hosts [1 port/host]
[+] starting receive thread #0
[+] THREAD: recv: starting main loop
[+] starting transmit thread #0
[+] starting throttler: rate = 3500.00-pps
THREAD: xmit: starting main loop: [0..1]
[+] transmit thread #0 complete
[+] waiting for threads to finish
[+] exiting receive thread #0                    ound=0
[+] exiting transmit thread #0
[+] all threads have exited

Nmap:

└─# nmap 192.168.3.127 -sT -Pn -n -v -p 23
Starting Nmap 7.92 ( https://nmap.org ) at 2022-08-14 21:20 UTC
Initiating Connect Scan at 21:20
Scanning 192.168.3.127 [1 port]
Discovered open port 23/tcp on 192.168.3.127
Completed Connect Scan at 21:20, 0.01s elapsed (1 total ports)
Nmap scan report for 192.168.3.127
Host is up (0.00069s latency).

PORT   STATE SERVICE
23/tcp open  telnet

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.31 seconds

Telnet:

└─# telnet 192.168.3.127
Trying 192.168.3.127...
Connected to 192.168.3.127.
Escape character is '^]'.
HP JetDirect
Password is not set

Please type "menu" for the MENU system,
or "?" for help, or "/" for current settings.
>

Changing the scan type (syn/connect/etc) doesn't seem to make a difference. Have also tried increasing/decreasing the rate as well.

The only thing that stands out to me is this line:

pfring: error: dlopen('libpfring.so'): Operation not permitted

However, I'm not sure if this is truly what's causing it. Masscan is able to detect some ports opened on other systems, but misses majority of them. Anything else that stands out in the output that I should be diving deeper into, or is there anything else I may be missing? FWIW, this is being executed from within a docker container as well. Also, the systems that I'm scanning are on the same subnet as me.

[HrBingR]

Unfortunately I don't have a solution, experiencing the same issue so might go back to nmap for now, but the pfring error is probably related to https://github.com/robertdavidgraham/masscan#pf_ring

Most likely that error will exist if you haven't compiled with pfring support or support pfring in terms of hardware.

[mzpqnxow]

The pf_ring error is effectively informational and can be ignored, unless you installed PF_RING shared libraries and expected it to work- in which case you put them somewhere unusual and can fix by setting LD_LIBRARY_PATH to the location (e.g. /usr/local/lib)

Either way, it would not prevent masscan from functioning, it wouldn't just not be able to use direct memory access/zc

There's actually not any option to build with (or without) libpfring, in the same way there's not an option to include or exclude libpcap. It will always try to load them at runtime using dlopen(). So you'll always see this behavior

Sorry, can't help much other than to clear that up and rule out PF_RING as related

[mzpqnxow]

I see you're scanning a LAN - see #695

This won't work unless the gateway is willing to route the packet back in a "hairpin" style