2

I have tried running nmap 192.168.0.97 to port-scan my computer, and I noticed it only lists TCP ports.

For both TCP and UDP ports, I would start by asking the OS on my computer. I.e. How do I list all sockets which are open to remote machines?

But port scanning is still useful as a confirmation. Port scanning your computer from a different computer is a particularly good idea if you have set up a firewall, to confirm that the firewall is doing what you want. In contrast, ss -l and netstat -l will report listening sockets without regard to any local firewall.


I hear that UDP scanning has some specific issues, that do not apply to TCP scanning. What command can I use to port scan UDP? For example I tried running sudo nmap -p0-65535 -sU 192.168.1.97, but it has been running for a while now without showing any results...

  • 1
    @JeffSchaller I think it was clear if you could assume good faith, but I think you make a reasonable request. The site shows the author of a question for various good reasons. Rephrased to take ownership. I've also adapted one additional statement from the other question. I hope the wording is now clear, although it does not add any more specific details. – sourcejedi Mar 24 at 21:55
1

That is one of the issues that might apply to UDP scanning. To be honest I have not bothered much with it. I think you can bump up the timing when you are on your nice fast local wired network. The -T5 option seems to work OK when I am scanning the computer I run nmap on :-). In this case, it completed a full UDP scan in less than 3 minutes.

Another hint: press enter while nmap is running. It will show a progress indicator.

Another way to speed it up is to not scan all 65535 ports :-). If you only want to double-check that your firewall protects the ports you think it does, you can just pass a list of listening ports that you saw in netstat -l / ss -l. I do not tend to have many weird network services that are listening on physical interfaces but that I need to firewall, so I can just type them in manually :-P.

A second issue is that UDP scans may also show programs which are not listening, only making requests, e.g. a program which sent a DNS request and is waiting for a reply. So some judgement is required. This is easiest when using netstat -l -p / ss -l -p so they show the program name, and then you can start guessing how they are using UDP :-).

The paranoia value of a real scan from a different computer, is that it would help people start noticing things like the Intel ME stupidity.

  • Thanks. How would you extract tcp and udp ports from ss or netstat, and pass them to nmap for tcp and udp scan? It is not easy to write such a shell script. – Tim Mar 22 at 23:21
  • @Tim I added a sentence saying that I would not need to. I would follow rules similar to those in the "Omitting localhost" section, then I have only a few services that would show up, so I can type them in manually. If possible, I would tend to configure services to listen on localhost, then I don't have to worry about the firewall for that service. Do you have many services which are not listening on localhost, for some reason? – sourcejedi Mar 22 at 23:24
  • Thanks. (1) I am not sure what rules in the "Omitting localhost" section in unix.stackexchange.com/questions/309083/…, probably because I don't quite follow the post and your reply there. (2) " If possible, I would tend to configure services to listen on localhost". When is it not possible? – Tim Mar 22 at 23:49
  • @Tim memory says that ntpd did not let you actually configure it to listen on localhost. Instead you could only configure ntpd to discard packets which did not come from localhost. My memory might be wrong, but at least that was a common default configuration. googleprojectzero.blogspot.com/2015/01/… – sourcejedi Mar 23 at 0:07
  • @Tim " Access to private and control mode queries can be restricted in ntp.conf based on the source IP. Default installations usually prohibit these queries for every source IP except for 127.0.0.1 and ::1. This is what e.g. Ubuntu, Debian and OS X do [did?]." - this is ntpd checking the source address of each connection itself. It was not being bound to localhost. – sourcejedi Mar 23 at 0:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.