RE: SYN vs Connect scans

["Rob Nicholls" <robert () robnicholls co uk>]

Hi Gregg,

 

I’m going to assume that the results from your TCP Connect scan are accurate for the host. Those results contain a 
large number of open ports (a Windows domain controller, if I had to guess), but no closed ports (all other ports are 
filtered).

 

The SYN Scan only reports closed ports (where Nmap received a RST from something), with the rest marked as filtered. 
Noticeably, there are no open ports.

 

There also does not appear to be any overlap between the ports marked as open and closed. If I didn’t know better, I’d 
assume you’d scanned two completely different hosts! But assuming you’ve tried to scan the same host both times, it 
looks like something has gone wrong.

 

My best guess is there’s something specific to your system that’s causing this behaviour. Are you trying to scan over a 
VPN connection? Do any of your network interfaces have multiple IPs and netmasks assigned to them?

 

On Linux, I believe Nmap should use libpcap for both SYN and Connect scans (unless you use the --unprivileged flag, to 
avoid using raw sockets). I’d generally expect to see the same routing and scan reports.

 

However, if you’re running Nmap on Windows, you might only be using WinPcap or more likely npcap to perform the SYN 
scan. The Connect scan on Windows will be performed by the host, without using WinPcap/npcap.

 

One possibility might be incorrect routing by WinPcap/npcap. WinPcap (and probably npcap too, but I’ve not double 
checked) uses as a service, and when it’s started it enumerates your network adapters and their settings. Any 
subsequent changes to IPs or routes (e.g. when a VPN is started, which may create a new virtual adapter and route) may 
not be picked up correctly by Nmap. If that happens, your SYN scan may send packets out of the wrong adapter. Depending 
on where your system is trying to route these packets, you may find the gateway responds with TCP resets for certain 
ports (which might explain the closed ports you’re seeing) while dropping the rest (which is why the open ports come 
back as filtered) due to things like firewall rules configured on that different gateway. Based on the closed ports, 
that may be a Check Point firewall returning closed ports, instead of the destination host you’re trying to scan.

 

You’ll likely need to use something like Wireshark or turn up Nmap’s debug or packet tracing (--packet-trace) to see 
how/where the packets are being sent, and more importantly what IPs/device(s) are returning the open and closed ports. 
My best guess is that completely different devices are returning the SYN/ACK and RST packets you’re receiving on the 
different scans.

 

Endpoint protection software (e.g. local firewall) can cause issues with some scans, although in that case you might be 
more likely to see incorrect results on the Connect scan (via Windows and whatever gets in its way) and correct results 
with the SYN scan (as it uses raw sockets).

 

If you’re trying to scan over a VPN, you may find you need to restart WinPcap or npcap for it to detect your virtual 
adapter and new route. Different VPNs do things in different ways, and if you’re very unlucky you may find you can’t 
use Nmap to scan over the VPN (although you may be able to get some useful results using the --unprivileged flag). You 
can manually restart WinPcap (npf service) or npcap (npcap service) from an elevated Command Prompt using:

 

net stop npf

net start npf

 

or

 

net stop npcap

net start npcap

 

You should also be able to tell which network interfaces Nmap can currently see (and the routing table) using:

 

nmap --iflist

 

If you can’t see the MAC address or IP address of the local network adapter you think Nmap should be using as a source 
to perform the scan, that may explain why Nmap isn’t working as expected.

 

Regards,

 

Rob

 

 

From: dev <dev-bounces () nmap org> On Behalf Of Gregg Doherty
Sent: Friday, May 12, 2023 4:44 PM
To: dev () nmap org
Subject: SYN vs Connect scans

 

Can someone explain why SYN Scan isn't finding all the open ports?   But TCP connect scan does.   Both would require 
the ACK from the target.  

 

---------- SYNSCAN.GNMAP (-T3)

# Nmap 7.93 scan initiated Thu May 11 13:22:34 2023 as: nmap -sS -p - -v -v -n -oA output.file-Pn xxx.xxx.xxx.xxx

Host: xxx.xxx.xxx.xxx ()  Status: Up

Host: xxx.xxx.xxx.xxx ()  Ports: 17/closed/tcp//qotd///, 20/closed/tcp//ftp-data///, 21/closed/tcp//ftp///, 
22/closed/tcp//ssh///, 256/closed/tcp//fw1-secureremote///, 264/closed/tcp//bgmp///, 443/closed/tcp//https///, 
586/closed/tcp//password-chg///, 990/closed/tcp//ftps///, 1080/closed/tcp//socks///, 1723/closed/tcp//pptp///, 
18231/closed/tcp//unknown///, 18234/closed/tcp///// Ignored State: filtered (65522)

 

---------- TCPCONNECT.GNMAP

# Nmap 7.93 scan initiated Thu May 11 13:25:07 2023 as: nmap -sT -p - -v -v -n -oA output.file -Pn xxx.xxx.xxx.xxx

Host: xxx.xxx.xxx.xxx ()  Ports: 53/open/tcp//domain///, 88/open/tcp//kerberos-sec///, 135/open/tcp//msrpc///, 
139/open/tcp//netbios-ssn///, 389/open/tcp//ldap///, 445/open/tcp//microsoft-ds///, 464/open/tcp//kpasswd5///, 
636/open/tcp//ldapssl///, 3268/open/tcp//globalcatLDAP///, 3269/open/tcp//globalcatLDAPssl///, 9389/open/tcp//adws///, 
17472/open/tcp/////, 47001/open/tcp//winrm///, 48089/open/tcp/////, 49664/open/tcp/////, 49665/open/tcp/////, 
50666/open/tcp/////, 58584/open/tcp/////, 58654/open/tcp/////, 58681/open/tcp/////, 58816/open/tcp/////, 
58846/open/tcp/////, 65173/open/tcp/////, 65218/open/tcp/////, 65221/open/tcp/////, 65223/open/tcp/////, 
65236/open/tcp/////, 65241/open/tcp/////, 65242/open/tcp/////        Ignored State: filtered (65506)

 

_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at https://seclists.org/nmap-dev/