5

I am scanning a host in our network with Nexpose and one of the vulnerabilities reported is

Received UDP packet with IP ID of zero:

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

I don't see anything to resolve this. How can I resolve this and close it out? I don't see a great deal of information for mitigation on this and ironically, this is the only host that I've seen reporting this. It's not end of the world serious, but it would allow an attacker to fingerprint my host.

LUser
  • 824
  • 6
  • 12
  • I'd want to ask, "do you need to resolve this?" It's an info-level issue, and each Linux distro can have different ways to tinker with the IP ID. Look up the issue on their forums. – schroeder Dec 11 '15 at 22:24

2 Answers2

0

I don't think you can resolve that. This is a matter of how the TCP/IP stack is working in the Operating System.

Also have in mind that this allows the Operating System to avoid being used in Zombie attacks: How does nmap do a zombie and decoy scan?

  • Actually, there is guidance from Linux distros on how to tweak the stack to not always start with an ID of 0 on the first packet. – schroeder Dec 12 '15 at 18:27
  • Well, I am supposing that for him this ID is always 0, not just the first time. If you know how to change the policy of IP IDs in Linux it could be nice to know it and I think that could solve his problem! –  Dec 12 '15 at 18:56
  • Ok well , if I can't change this then this will have to suffice.... Unless someone can provide better answer, I will let you have this. – LUser Dec 14 '15 at 22:17
0

The official response of RedHat per 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.

RFC 6864 "Updated Specification of the IPv4 ID Field" further clarifies that:

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 if no fragmentation is involved is the expected behaviour. 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 zero it:

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.

kravietz
  • 412
  • 2
  • 7