ICMP Timestamp Request Remote Date Disclosure (CVE-1999-0524, Nessus plugin 10114) means a host answers ICMP type 13 timestamp requests with its current clock time. It is a low-severity information leak. Fix it by dropping inbound type 13 requests and outbound type 14 replies at the host firewall or network ACL, then rescan to confirm.

What the scanner is actually detecting

ICMP timestamp is an old IPv4 query defined in RFC 792. A client sends a type 13 message, and the target answers with a type 14 reply carrying its own clock, expressed as milliseconds since midnight UTC. The scanner flags the host if a reply comes back. No login, port or service is involved: it is purely a network-layer test.

How the major scanners report it:

Nessus (Tenable): plugin 10114, “ICMP Timestamp Request Remote Date Disclosure”, in the General family, rated Low with a CVSS v2 base score of 2.1 and mapped to CVE-1999-0524.
Qualys: QID 82003.
Greenbone/OpenVAS and Rapid7 InsightVM/Nexpose: both ship their own check for the same condition, titled around an ICMP timestamp reply or response. The remediation below is identical regardless of which scanner raised it.

The CVE record itself is broad: it reads “ICMP information such as (1) netmask and (2) timestamp is allowed from arbitrary hosts”. That is why some reports list address mask replies (types 17 and 18) under the same CVE.

Real-world risk, stated honestly

This is a low-severity finding, and it should be prioritized that way. What an attacker learns is the target’s clock time. Tenable’s description notes that this can help defeat time-based authentication, which applies to weak schemes that derive tokens or random seeds from the system clock. Modern protocols such as Kerberos and TOTP already treat the current time as public, so the reply does not weaken them.

The more practical concern is reconnaissance. The Nmap documentation points out that timestamp queries can find live hosts on networks where administrators block echo requests (ping) but forget other ICMP query types. Clock values can also help with OS fingerprinting and with telling apart hosts that sit behind the same address. Tenable also notes that Windows Vista, 7, Server 2008 and 2008 R2 deliberately return slightly incorrect timestamps (typically within 1000 seconds), which limits the value of the leak but does not stop the scanner from flagging them.

How to confirm it on the host

Run these from a machine on the same network path as your scanner. Both tools need root or administrator rights to send raw ICMP.

# Nmap: send only a timestamp probe. --disable-arp-ping stops Nmap
# from marking a same-subnet host "up" through ARP alone.
nmap -sn -PP --disable-arp-ping --reason 192.0.2.10

# hping3: --icmp-ts sends ICMP type 13 timestamp requests
hping3 --icmp-ts -c 3 192.0.2.10

If Nmap reports the host as up with -PP as the only probe, or hping3 prints replies, the host is answering. To prove the reply comes from the host itself and not from a device in front of it, capture on the target:

tcpdump -ni any 'icmp[icmptype] == icmp-tstamp or icmp[icmptype] == icmp-tstampreply'

On Windows, check whether the firewall is actually enforcing on the active profile, since the default inbound action blocks unsolicited ICMP:

Get-NetFirewallProfile | Format-Table Name, Enabled, DefaultInboundAction

A Windows host that answers timestamp requests usually has the firewall disabled for its current profile or a broad rule that allows all inbound ICMPv4.

How to fix it

Block only types 13 and 14. Do not block all ICMP, which breaks Path MTU Discovery and makes troubleshooting harder.

Linux with iptables

Insert the rules at the top of the chain. Many default rulesets contain an earlier rule that accepts all ICMP, and an appended (-A) drop rule placed after it never matches.

iptables -I INPUT 1 -p icmp --icmp-type timestamp-request -j DROP
iptables -I OUTPUT 1 -p icmp --icmp-type timestamp-reply -j DROP

Numeric types (--icmp-type 13 and --icmp-type 14) work too; iptables -p icmp -h lists the names your build accepts. These rules are lost at reboot unless saved. On Debian and Ubuntu with the iptables-persistent package, for example:

iptables-save > /etc/iptables/rules.v4

Linux with nftables

List your ruleset first, because table and chain names vary by distribution. Use insert so the rule lands at the start of the chain:

nft list ruleset
nft insert rule inet filter input icmp type timestamp-request drop
nft insert rule inet filter output icmp type timestamp-reply drop

Add the same rules to the ruleset file your system loads at boot (for example /etc/nftables.conf on Debian) so they persist.

Linux with firewalld (RHEL, Rocky, Alma, Fedora)

Block inbound requests in the zone bound to the scanned interface. If the request never reaches the host, no reply is sent.

firewall-cmd --get-active-zones
firewall-cmd --permanent --zone=public --add-icmp-block=timestamp-request
firewall-cmd --reload
firewall-cmd --zone=public --list-icmp-blocks

There is no kernel sysctl that disables timestamp replies. net.ipv4.icmp_echo_ignore_all covers echo requests only, so firewall filtering is the fix on Linux.

Windows (Defender Firewall)

Microsoft’s own netsh migration guidance (KB 947709) uses exactly this case as its example of an ICMP block rule:

netsh advfirewall firewall add rule name="Block ICMP Timestamp" protocol=icmpv4:13,any dir=in action=block

The PowerShell equivalent:

New-NetFirewallRule -DisplayName "Block ICMP Timestamp" -Direction Inbound -Protocol ICMPv4 -IcmpType 13 -Action Block

Optionally, also block outbound replies:

netsh advfirewall firewall add rule name="Block ICMP Timestamp Reply" protocol=icmpv4:14,any dir=out action=block

Explicit block rules take precedence over conflicting allow rules in Windows Firewall, so this works even if an “allow all ICMPv4” rule exists. It does nothing if the firewall is off for the active profile. Turning the firewall back on is the real fix in that case, but it is a larger change that needs its own testing.

For fleets, create the same rule in Group Policy under Computer Configuration > Policies > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security > Inbound Rules: a Custom rule, protocol ICMPv4 restricted to type 13, action Block, applied to all profiles.

You may see a registry value called DisableIcmpTimestamp recommended in forums. In the Rapid7 community thread on this finding, a user reported that InsightVM kept flagging hosts after setting it. Use the firewall rule instead.

Routers and perimeter firewalls

Deny types 13 and 14 ahead of any rule that permits ICMP. On Cisco IOS, a named extended ACL with sequence numbers lets you place the entries before existing permits:

ip access-list extended EDGE-IN
 5 deny icmp any any 13
 6 deny icmp any any 14

IOS accepts the numeric types and may display them by name (type 14 as timestamp-reply). Other firewall platforms follow the same pattern: match ICMP type 13 (and 14 where outbound filtering applies) and order the rule above broader ICMP permits. A perimeter ACL only protects traffic that crosses it, so internal scans will still flag hosts unless they are filtered locally.

How to verify the fix and rescan

Repeat the Nmap and hping3 tests from the scanner’s network. Nmap should now report the host as down for the timestamp-only probe, and hping3 should show 100% packet loss.
Check that the rule is matching: iptables -L INPUT -v -n --line-numbers shows packet counters, and Get-NetFirewallRule -DisplayName "Block ICMP Timestamp" confirms the Windows rule exists and is enabled.
Reboot one host and test again to prove the rule persists.
Rescan the affected hosts with the same scanner and policy that raised the finding.

What can break and how to roll back

Very little depends on ICMP timestamps today. Time synchronization uses NTP over UDP port 123, not ICMP, and that includes the Windows Time service. The realistic side effects are:

Discovery or monitoring tools that use timestamp probes (such as Nmap’s -PP) will no longer see the host through that method.
Over-broad rules. If someone “simplifies” the change to block all ICMP, Path MTU Discovery breaks and connections can stall on large packets.

Rollback is a single command per platform:

iptables -D INPUT -p icmp --icmp-type timestamp-request -j DROP
iptables -D OUTPUT -p icmp --icmp-type timestamp-reply -j DROP

firewall-cmd --permanent --zone=public --remove-icmp-block=timestamp-request
firewall-cmd --reload

Remove-NetFirewallRule -DisplayName "Block ICMP Timestamp"

For nftables, find the rule handle with nft -a list ruleset and remove it with nft delete rule. Remember to update any saved ruleset file as well.

Common false positive reasons

Another device answered. A NAT gateway, load balancer or firewall that owns the scanned IP can reply on the host’s behalf. If tcpdump on the host shows no type 13 traffic, fix the device in front of it.
Different network path. The rule lives on the perimeter, but the scanner sits on an internal segment that never crosses it.
Rule ordering or scope. The drop rule sits below an ICMP accept rule, or a GPO rule is enabled for the Domain profile while the host is on Private or Public.
Rule not persisted. The fix worked until the next reboot.
Stale data. The report predates the change. Note that this is a network-level check, so results do not change between credentialed and uncredentialed scans.

For appliances where you cannot change filtering, such as some embedded devices, record a formal risk acceptance with network-level filtering as the compensating control, rather than excluding the host from scans.

FAQ

Is ICMP timestamp disclosure a real vulnerability?

It is a genuine information leak but a low-risk one (CVSS v2 2.1 in Nessus). It mainly helps reconnaissance. Fix it as part of standard hardening, not as an emergency.

Do I have to block ping to fix this?

No. Echo requests (type 8) and timestamp requests (type 13) are separate message types. Block 13 and 14 only and leave the rest of ICMP alone.

Does this finding apply to IPv6?

No. ICMPv6 has no timestamp message, so the finding is IPv4 only.

Why do Windows hosts report odd timestamps?

According to Tenable, some older Windows versions deliberately return inaccurate values. The host is still answering, so the finding remains valid until the request is blocked.

Tracking this finding across many hosts

On a large estate the hard part is knowing which hosts still answer after the change. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners and can generate host-specific remediation scripts that run only after human approval, deployed by its agents on Windows and Linux endpoints. For Nessus findings such as plugin 10114, it can re-test the individual finding to confirm closure.

Discovery and visibility

Scanning and collection

The AI layer

Action and closure

Team and governance

Reporting

ICMP Timestamp Request Remote Date Disclosure: How to Block ICMP Types 13 and 14