Fixing CVE-1999-0524 on Red Hat Enterprise Linux

CVE-1999-0524 is an information-disclosure finding: the host responds to ICMP timestamp requests (type 13) with timestamp replies (type 14), which can leak the system clock and (historically) help an attacker with time-based attacks. The fix is simply to drop both message types at the firewall.

On RHEL the right tool depends on the version:

• RHEL 7 → iptables (or firewalld with direct rules)
• RHEL 8 / 9 → firewalld (nftables backend) is the supported path; raw nftables works too

Below are the recipes that actually pass a re-scan.

1. Verify the Finding First

Before changing anything, confirm the host really answers timestamp requests. From another machine:

# hping3 is the cleanest test
sudo hping3 --icmp --icmptype 13 -c 2 <target-ip>

# or with nmap
sudo nmap -sU -PE --script=icmp-timestamp <target-ip>

If you get a type-14 reply, the finding is real. If you get nothing, the scanner result was stale and you only need to re-scan.

2. RHEL 8 / 9 — firewalld (Recommended)

firewalld ships with nftables underneath. Add two permanent rich rules that drop ICMP types 13 and 14 in the active zone (usually public):

# Find the active zone
sudo firewall-cmd --get-active-zones

# Drop incoming timestamp requests (type 13)
sudo firewall-cmd --permanent --add-rich-rule='
  rule protocol value="icmp" icmp-type name="timestamp-request" drop'

# Drop outgoing timestamp replies (type 14)
# firewalld has no direct egress filter via icmp-type name, so use a direct rule:
sudo firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 \
  -p icmp --icmp-type timestamp-reply -j DROP

# Apply
sudo firewall-cmd --reload

Verify:

sudo firewall-cmd --list-rich-rules
sudo firewall-cmd --direct --get-all-rules

Note: firewall-cmd --get-icmptypes on RHEL 8/9 lists timestamp-request but not timestamp-reply as a blockable inbound type, which is why the reply side uses a direct rule on OUTPUT. Both halves are required to satisfy the scanner.

3. RHEL 7 — iptables

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

# Persist across reboots
sudo yum install -y iptables-services
sudo service iptables save
sudo systemctl enable --now iptables

If the box runs firewalld on RHEL 7 instead, use the same two firewall-cmd --permanent --direct rules shown above (one on INPUT, one on OUTPUT).

4. Pure nftables (RHEL 8/9, if you don’t use firewalld)

sudo nft add rule inet filter input  icmp type timestamp-request drop
sudo nft add rule inet filter output icmp type timestamp-reply   drop

# Persist
sudo nft list ruleset | sudo tee /etc/sysconfig/nftables.conf >/dev/null
sudo systemctl enable --now nftables

5. IPv6 Note

CVE-1999-0524 is IPv4-only — ICMPv6 has no equivalent timestamp message type, so no ip6tables / inet rule is needed for this CVE specifically. Scanners won’t flag IPv6 here.

See also: Mastering the Linux Command Line — Your Complete Free Training Guide

6. Don’t Bother With net.ipv4.icmp_* sysctls

There is no kernel sysctl to disable timestamp replies (unlike icmp_echo_ignore_all for ping). The kernel always answers type 13 if it reaches the IP stack. Filtering at the firewall is the only supported fix on RHEL.

7. Re-test

sudo hping3 --icmp --icmptype 13 -c 3 <target-ip>
# Expect: 100% packet loss

Then re-run your vulnerability scanner (Nessus / Qualys / Tenable). The finding should clear on the next scan.

Quick Copy-Paste Summary (RHEL 8/9 + firewalld)

sudo firewall-cmd --permanent --add-rich-rule='rule protocol value="icmp" icmp-type name="timestamp-request" drop'
sudo firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 -p icmp --icmp-type timestamp-reply -j DROP
sudo firewall-cmd --reload

That’s the whole fix — two rules, no reboot, no service impact on anything other than ICMP types 13/14.