Performed credentialed Vulnerability scan on linux/Unix servers by Nessus and thousand of vulnerability came out of port tcp/0. How could a IANA reserved port(tcp/0) handle traffic? Are those vulnerability truly countable or those came out as false positive? How should we proceed for the remediation process of the vulnerabilities showed under port tcp/0?
Asked
Active
Viewed 5,090 times
12
-
3Which scanner are you using? Is the number even remotely realistic? Take samples and check your system for the vulnerabilities. If your scanner shows so many and your system isn't 10 years old and completely unpatched, it's probably mostly false positives. – Tom K. Feb 03 '18 at 12:35
-
I am using Nessus Manger (7.0). In average, the count of vulnerability at tcp/0 of an red hat 6 server is nearly 1100-1200. I am not sure how much time they are left unpatched, but i can assume from the OS server version. I knew credential scan or agent based scan reduce the number of false positive and hence I performed the scan with credential or agent. I wonder, how it will be possible to filter the false positive from these large number of vulnerabilities from tcp/0! – Shakir Feb 03 '18 at 12:55
-
Those are not necessarily false positives. I've updated my answer, see below. – ximaera Feb 03 '18 at 13:05
2 Answers
16
How could a IANA reserved port(tcp/0) handle traffic?
It can. Generally, TCP (or UDP) port 0 being in a reserved state doesn't mean it can't be used in practice. Though the way Berkeley sockets are designed it's not that easy to bind on port zero, it's nevertheless possible to use it.
However, it's highly unlikely that this is actually happening in your case. You're just using the Nessus scanner which lists activities not closely related to a specific port under port 0/TCP or 0/UDP (see: "Vulnerabilities by Host"). This is simply an (inconvenient?) convention to display port-less warnings under port 0 -- ironically, to avoid confusion.
Note that those a) are not necessarily vulnerabilities, just warnings or suggestions (e.g. not adhering to the best Microsoft practices while running a scanner); b) are not necessarily false positives. Try to ignore port zero itself, read the report carefully and act accordingly.
ximaera
- 3,395
- 8
- 23
-
So, the mentioned port are actually the port Nessus Manager used for running the scan? If this is the case, Tenable should have mentioned it in their manual. By the way, In my case, many high/medium severity vulnerability is under tcp/0 (normally those vuln are real in my old servers i guess since they are not patched for long times). Since i installed nessus agents in those servers and performed scan using agents, those vuln might be listed under tcp/0. – Shakir Feb 03 '18 at 13:25
-
"The second section is a list of the plugins, organized by the port used for the scan activities. Activities not closely related to a specific port are listed under port 0/TCP." This line is lifesaver from your given link. – Shakir Feb 03 '18 at 13:26
-
6@Shakir this is **NOT** the source port used for scanning. This is simply an (unconvenient) convention to display *port-less* warnings under port 0 -- ironically, to avoid confusion. – ximaera Feb 03 '18 at 13:34
-
Your claim that it's possible to bind to port zero isn't supported by the link. What the link say they did was to bind on a different port and manipulate the packets with iptables. – kasperd Feb 03 '18 at 23:38
-
@kasperd I didn't say it's possible to *bind*. Although it's possible, but requires some OS-level patching. My point is, it's possible to *use* it. Clarified that in my answer, thanks! – ximaera Feb 04 '18 at 06:03
3
How could a IANA reserved port(tcp/0) handle traffic?
While the accepted answer explains how port 0 is still a real port, it may be helpful to understand how ports work in TCP. Below is a 32-bit-wide diagram of the a TCP packet, to scale. UDP is similar, although a lot simpler (after the ports, it has just a length field and a checksum field before the data).
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | Source Port | Destination Port | +-------------------------------+-------------------------------+ | Sequence Number | +---------------------------------------------------------------+ | Acknowledgment Number | +-------+-----------+-+-+-+-+-+-+-------------------------------+ | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | +-------+-----------+-+-+-+-+-+-+-------------------------------+ | Checksum | Urgent Pointer | +-------------------------------+-------------------------------+ | Options | Padding | +-----------------------------------------------+---------------+ | | / ... Data (optional) ... / | | +---------------------------------------------------------------+
As you can see, the source port and destination port fields are both 16 bits wide. This means it can represent 65536 different possible states, from 0 to 65535. This is incidentally why there are no negative ports, as the value is treated as unsigned. The only thing stopping any of the ports from being all null bytes (representing port 0) is an IANA standard saying not to do that. It is perfectly possible for a packet to be sent out with any of the ports set to 0. The purpose of keeping port 0 reserved is to allow "just give me any port" to be represented by a 16-bit integer. When an attempt is made to bind to TCP/0, rather than listening for packets with the destination port set to all zeros, the system is supposed to bind to any available port.
forest
- 64,616
- 20
- 206
- 257