Nmap Development mailing list archives
RE: SYN vs Connect scans
From: "Rob Nicholls" <robert () robnicholls co uk>
Date: Sat, 13 May 2023 12:25:19 +0100
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/
Current thread:
- SYN vs Connect scans Gregg Doherty (May 12)
- RE: SYN vs Connect scans Rob Nicholls (May 13)