Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement raw socket support for Version-, script-, and OS-Scanning #1512

Closed
bka-dev opened this Issue Mar 12, 2019 · 1 comment

Comments

Projects
None yet
2 participants
@bka-dev
Copy link

bka-dev commented Mar 12, 2019

Hi,

by design nmap is using raw sockets mainly during the SYN-Scan phase, which allows the user to modify various parameters like Source-IP, Source-Port, TTL, etc.

However for version detection, script scanning and OS detection nmap uses the usual connect() method, which means that many parameters like -g/--source-port can't be used together with -sV, -sC or -O.

It would be great to have raw socket support for some other scan types. Probably it makes most sense for UDP scans, due to it's stateless nature.

The use case for which this would be helpful could be the following:

  1. Consider an open UDP port 4124, which only sends a response once a valid service probe is sent (-sV).
  2. The firewall only allows incoming packets that originate from UDP port 53 (-g 53).

To get a valid response, you would need to invoke nmap like this:
sudo nmap -vvv -n -sU -Pn -p4124 -sV -g 53 <IP address>

However, because sV uses connect(), the source port can't be set to 53 for service probes, and the service could never be identified.

What do you think? Would such a modification make sense, or would this require way too much effort?

Cheers,
bka

@dmiller-nmap

This comment has been minimized.

Copy link

dmiller-nmap commented Mar 19, 2019

Thanks for the suggestion. This is a very tricky thing to do, though, because the source port is an important part of TCP and UDP that is used to identify which conversation the packet belongs to. Nmap is able to set the source port for certain operations because it does not intend on carrying out an extended conversation with the target. It uses the parts of the packet that are intended for that (TCP initial sequence number, etc.) to identify which probe the response was sent to for timing purposes, so they can't be used for their intended purpose. Essentially, there's not enough state left in the packet to keep conversations separate if we force the source port to be the same.

Port scanning and OS detection do use the source port set with -g, because they are each only concerned with the most immediate response from a particular target port. Version detection and script scanning, on the other hand, must carry on bidirectional conversation with the target. Additionally, they must be able to carry on multiple separate conversations at a time, which is what the source port is designed for. There's really not a way to keep multiple bidirectional streams separate from each other if they all use the same source port.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.