Error #487: Your port specifications are illegal.

Hi. I am new to this and have followed the newbies instruction implicitly. However, when I use this command:
nmap -sC -sV -p 10.10.10.27, i get the following:

tarting Nmap 7.80 ( https://nmap.org ) at 2020-07-08 17:20 AEST
Error #487: Your port specifications are illegal. Example of proper form: “-100,200-1024,T:3000-4000,U:60000-”

What am I doing wrong???

if you want to scan all the ports, use -p-
Or if you want to scan a range e.g 1-2000, use -p1-2000
https://nmap.org/book/port-scanning-options.html

1 Like

@fartbar said:

Hi. I am new to this and have followed the newbies instruction implicitly. However, when I use this command:
nmap -sC -sV -p 10.10.10.27, i get the following:

tarting Nmap 7.80 ( https://nmap.org ) at 2020-07-08 17:20 AEST
Error #487: Your port specifications are illegal. Example of proper form: “-100,200-1024,T:3000-4000,U:60000-”

What am I doing wrong???

As @yupm has said, the port specification needs to be there.

Another common issue is if people use the script mentioned in the starting points where you run a scan to find open ports then run a detailed scan, this is pretty buggy.

Its a lot better to just do a single scan - then you can troubleshoot it if it still fails.

@TazWake said:

Another common issue is if people use the script mentioned in the starting points where you run a scan to find open ports then run a detailed scan, this is pretty buggy.

Its a lot better to just do a single scan - then you can troubleshoot it if it still fails.

I beg to disagree on that part (at least for RL engagements). For larger networks (e.g. several class C subnets), it is more efficient to first find what is active and open on all the ranges (using staggered parallel instances for sub-ranges), before picking the larger hammer and smashing on what is there. Because that way, you will first get a picture of what actually is there, and don’t need to start from the very beginning, just because nmap decided to choke on whatever it didn’t like (yes, I indeed experienced several SEGFAULTs in the not so distant past).

@HomeSen said:

I beg to disagree on that part (at least for RL engagements). For larger networks (e.g. several class C subnets), it is more efficient to first find what is active and open on all the ranges (using staggered parallel instances for sub-ranges), before picking the larger hammer and smashing on what is there.

I sort of agree, but with a caveat and on the basis that you know the tool well enough to resolve any issues and have a good enough idea what you are passing as variables from one part of the script to the other.

The caveat is you lose visibility of why the response is the response. I find the --reason switch very useful in RL but if you just look for ports that nmap thinks are open, you might lose this additional context. But this is very much a personal choice and the nature of the engagement will dictate the decisions.

(but also masscan :smile: )

However, in the context of HTB, I dont even find masscan faster than simply running nmap. (And UDP scanning is whole different PITA :smile: )

Because that way, you will first get a picture of what actually is there, and don’t need to start from the very beginning, just because nmap decided to choke on whatever it didn’t like (yes, I indeed experienced several SEGFAULTs in the not so distant past).

Yeah - interestingly I’ve had nmap segfault on quite a few HTB boxes recently.

Tips to fix-

To see how much space you have used and free.
To see where files are taking up space.
Disk Cleanup.
System Restore.
Repair the Recycle Bin.
Repair Temporary Internet Files.
Delete Files in the System Temp Folder.
Check Size of Swap File.

Regards,
Rachel Gomez