When I try to scan a network using this command:
nmap -Pn -f -A ( specific ip adress)
I cannot find out which ports are open but I get this result:
All 1000 scanned ports on 10.10.10.3 are filtered
Too many fingerprints match this host to give specific OS details
When I use nmap -Pn -f -a (name of box) (specific ip adress)
I am able to see one port but I know there are other ports that are open that I cannot see.What is the problem?
I’m not sure really.
But when i try to scan all ports of a machine, i will command like below
nmap -sC -sV -p- -T2 -o Port-1000.txt ip
Like this part.
If you use -T and reduce your timing limit you may have better results.
More the time nmap takes to scan, better the scan results will be.
When I try to scan a network using this command:
nmap -Pn -f -A ( specific ip adress)
First off - is there a reason why you are using -f here?
I cannot find out which ports are open but I get this result:
All 1000 scanned ports on 10.10.10.3 are filtered
This response implies nmap isn’t seeing anything back from the server. There are lots of reasons for this - for example it could be because the fragmentation you are using is causing the packets to be dropped.
On HTB I would normally say it means that either the server isn’t up, or you aren’t connected to the right network but I dont think that is the case here.
Too many fingerprints match this host to give specific OS details
When I use nmap -Pn -f -a (name of box) (specific ip adress)
I am not sure what you mean here, I dont see how putting the name of the box should work but I dont recognise the -a (lowercase a that is) switch.
As a test, can you try nmap -Pn -A -p- --reason -vvvvvv 10.10.10.3 and let me know what response you get, please?
Hey @TazWake His command is right (there on top he used aggression switch -A) only. But while typing to explain he forgot it to make it capital.
I’m really unaware of that problem.
One of the things which often catches people out is little typos - which is why I wanted to clarify what the commands actually used are. If there is a typo in what is being put here, chances are there is a typo in some of the strings being used - this isn’t a criticism of anyone’s language or typing skills, its just a fact that computers tend to be unforgiving.
I dont see how nmap could work with a nmap -Pn -f -A boxname 1.2.3.4 type argument either.
From what I can recall, -f is used to try and avoid firewalls / filters by fragmenting the packets, which seems an odd choice - but as a huge caveat, I don’t know the box in question so it might make sense.
@TazWake I used -f as I thought the firewall was the problem but it isn’t.Sorry for the typo -a, I meant -A.The scan is running and I will tell you the results but it will take a while
@TazWake Main Results:
Too many fingerprints match this host to give specific OS details
TCP/IP fingerprint:
SCAN(V=7.80%E=4%D=5/21%OT=%CT=%CU=%PV=Y%G=N%TM=5EC61F4B%P=x86_64-pc-linux-gnu)
U1(R=N)
IE(R=N)
TRACEROUTE (using proto 1/icmp)
HOP RTT ADDRESS
1 25.91 ms 10.10.14.1
2 2013.15 ms 10.10.14.1
3 2013.29 ms 10.10.14.1
4 2013.34 ms 10.10.14.1
5 … 17
18 2013.45 ms 10.10.14.1
19 2013.43 ms 10.10.14.1
20 2013.39 ms 10.10.14.1
21 … 30
@TazWake Main Results:
Too many fingerprints match this host to give specific OS details
TCP/IP fingerprint:
Just to confirm - that was the response from nmap -Pn -A -p- --reason -vvvvvv 10.10.10.3 ? If so try nmap --reason -vvvvvvvv -T4 10.10.10.3 to see if says anything different.
Did it say something like “all 65535 ports were filtered / no response” or anything?
Your trace route output implies the traffic isn’t leaving your machine, so no nmap scans should work. It might be worth checking you dont have a firewall or something else blocking packets.
@TazWake Yes,that was the result of the scan. nmap --reason -vvvvvvvv -T4 10.10.10.3 yielded the same results.The only firewall I installed was the ufw firewall which is disabled,I cannot think what else would block packets though.
@TazWake What is odd is I am able to do a syn scan,service version scan,agressive scan and a script vunerability scan on a completely different ip not connected to HTB
@ProtonCyber I can imagine this is frustrating but I am not sure what else I can suggest.
Your trace route information implies that the traffic is going to 10.10.14.1 and then dying. If the nmap scans (with --reason) aren’t adding any additional data around why the ports appear closed then its difficult to know where to look.
If you can only nmap scan non-HTB IP addresses then its likely there is a connection problem and you either need a new connection pack or may have to raise a JIRA ticket.
However, if you can scan HTB IP addresses with different switches (as implied in the first post), then it makes no sense given the output you’ve shown here.
You may need to manually troubleshoot this - run commands and make a careful note of the output so you can work out what is different between each one.
In terminal do ifconfig make sure tun0 is up, has happened to me more often than I care to admit that I either forgot to connect to the VPN or it crashed…
hello while using namp on cap machine i am getting this error- Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn Nmap done: 1 IP address (0 hosts up) scanned in 4.96 seconds what should i do ?