tl;dr “Received UDP packet with IP ID of zero” is not a vulnerability nor a misconfiguration worth reporting even as an informational issue. A number of network-level vulnerability scanners would report an issue called “Received UDP packet with IP ID of zero” which essentially means the 16-bit ID (Identification) field in the IP header is zeroed. Per CVE-2002-0510:
The UDP implementation in Linux 2.4.x kernels keeps the IP Identification field at 0 for all non-fragmented packets, which could allow remote attackers to determine that a target system is running Linux.
This is usually accompanied by such a packet dump, where the zero is visible as ID[0] (example courtesy of StackExchange):
IPv4 SRC[10.0.0.5] TGT[127.0.0.1]
TOS[192] TTL[64] Flags[40] Proto[17] ID[0] FragOff[0]
HDR-LENGTH[20] TOTAL-LENGTH[76] CKSUM[45199]
UDP SRC-PORT[123] TGT-PORT[47454] CKSUM[35227]
RAW DATA [48]:
1A030AE800000C9E00001A9A6BAAE008 ...�...�...�k��.
DA15B7A195FE52CDC6F15EDB78000000 �.����R���^�x...
DA15BC9BBD4C60B5DA15BC9BBD511C4F �.���L`��.���Q.O
To reduce the time spent globally on attempting (in vain) to fix it or at least provide a reasonable “risk acceptance” response, here’s a few points that should beyond any doubt explain that this is not a security issue.
Probably the most important fact about CVE-2002-0510 is that the fingerprinting is possible because every IP implementation sets different values and not because Linux sets it to zero.
This controversy comes from the fact that the original Internet Protocol (IP) RFC 791 wasn’t very specific in explaining all the edge cases for setting the Identification field:
Identification: 16 bits: An identifying value assigned by the sender to aid in assembling the fragments of a datagram.
There’s more on the field but all it says is only applicable when IP fragmentation is required and never goes into details on what should be the value of the field for unfragmented packets. This left, as with many other early RFCs, a widely open gates for everyone implementing the IP stack to arbitrarily choose their own approach. Someone would set this field to zero, someone to an incremental value as if the packet was fragmented, someone would set random etc.
This inconsistency was partially cleared in RFC 6864 “Updated Specification of the IPv4 ID Field”:
This document updates the specification of the IPv4 ID field in three distinct ways, as discussed in subsequent subsections: Using the IPv4 ID field only for fragmentation (...)
Which implies that setting it to a predictable value is the expected behaviour if no fragmentation is involved. This is reinforced in the Security Considerations section which implies that having IP ID set to an apparently random values can be used as a covert channel to exfiltrate data, which is yet another reason to set it to zero:
When the IPv4 ID is ignored on receipt (e.g., for atomic datagrams), its value becomes unconstrained; therefore, that field can more easily be used as a covert channel. For some atomic datagrams it is now possible, and may be desirable, to rewrite the IPv4 ID field to avoid its use as such a channel.
Because of that back in 2002 RedHat provided the following response when this was first reported as CVE-2002-0510:
Red Hat do not consider this to be a security issue and there are many ways that you can identify or fingerprint a Linux machine.
Enough said!