Disable ICMP Timestamp Responses in Linux

Security scanners often flag ICMP timestamp support (CVE-1999-0524 and similar findings) because a host that answers type 13 (timestamp-request) returns type 14 (timestamp-reply) with clock values. That leak is minor compared with an unpatched service, but compliance workflows still expect you to stop responding.

Linux answers timestamp requests in software when the packet reaches the network stack. There is no supported sysctl like net.ipv4.icmp_echo_ignore_all for timestamps—you filter at the firewall. The sections below are grouped by firewall method (firewalld, nftables, iptables, UFW), not by distribution.

Quick answer

Pick one method per host. Stacking firewalld rules and manual nftables tables without planning can duplicate drops or fight for hook priority.

What ICMP timestamp types mean

ICMP carries control messages beside TCP and UDP. Two IPv4 types matter for hardening (RFC 792). ICMPv6 defines a separate message registry and has no timestamp request or reply equivalents.

Modern time sync uses NTP or PTP, not ICMP timestamps. Blocking type 13 on INPUT stops remote hosts from eliciting replies. Dropping type 14 on OUTPUT is optional—useful if you want explicit egress control or tools that generate replies locally.

Verify before and after changes

Run tests from a second machine when possible. Loopback checks miss the INPUT path your scanner uses.

On the target host (vm1.lab.example in our lab), confirm the kernel responds before any firewall change:

nping --icmp --icmp-type 13 -c 1 -H 127.0.0.1

Sample output:

Max rtt: 0.017ms | Min rtt: 0.017ms | Avg rtt: 0.017ms
Raw packets sent: 1 (40B) | Rcvd: 1 (40B) | Lost: 0 (0.00%)

From the probe host (vm2.lab.example), aim at the target address:

nping --icmp --icmp-type 13 -c 2 -H 192.168.56.116

Sample output before filtering:

Raw packets sent: 2 (80B) | Rcvd: 2 (92B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 1.02 seconds

After you apply one of the firewall methods below, run the same remote nping command again. A successful block shows 100% packet loss and Rcvd: 0 in the summary line.

Install nmap on the probe host if nping is missing (dnf install nmap on RHEL-family systems). hping3 with --icmp --icmptype 13 is an alternative where packaged.

Block with firewalld

Use this path when firewall-cmd --state reports running and you already manage zones through firewalld. All rules here target IPv4 only (family="ipv4"), which matches the ICMP types scanners test.

Rich rule (explicit drop)

Add a rich rule that drops IPv4 timestamp requests in the default zone:

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" icmp-type name="timestamp-request" drop'

Load the permanent configuration into the running firewall:

sudo firewall-cmd --reload

Confirm the rule is present:

sudo firewall-cmd --list-rich-rules | grep timestamp

Sample output:

rule family="ipv4" icmp-type name="timestamp-request" drop

Re-run the remote nping probe from your second host. On our RHEL 10.2 lab, that alone moved the result from 0% loss to 100% loss without a separate OUTPUT rule—dropped requests never reach the code that would emit type 14.

Do not combine protocol value="icmp" and icmp-type in one rich rule; firewalld 2.4 rejects that combination as INVALID_RULE.

A rich rule uses an explicit drop action. That differs from firewall-cmd --add-icmp-block, which applies a zone reject for the ICMP type—both stop remote timestamp replies when the block is on the zone that owns your tested interface.

ICMP block (zone reject)

firewalld also supports blocking timestamp requests through the zone ICMP-block list:

sudo firewall-cmd --permanent --add-icmp-block=timestamp-request

Load the permanent configuration into the running firewall:

sudo firewall-cmd --reload

Confirm which zone owns the interface you tested:

sudo firewall-cmd --get-active-zones

List ICMP blocks for that zone:

sudo firewall-cmd --list-icmp-blocks

Sample output:

public (default)
  interfaces: enp0s8
timestamp-request

If the tested NIC sits in a non-default zone, pass --zone= when you add the block. After reload, run the same remote nping probe from your second host.

To roll back an ICMP block, remove it from the permanent configuration:

sudo firewall-cmd --permanent --remove-icmp-block=timestamp-request

Apply the change to the running firewall:

sudo firewall-cmd --reload

To roll back the rich-rule method, remove the permanent rule and reload firewalld:

sudo firewall-cmd --permanent --remove-rich-rule='rule family="ipv4" icmp-type name="timestamp-request" drop'

The remove command exits silently on success. Apply the change to the running firewall:

sudo firewall-cmd --reload

Block with nftables

Use native nftables when no front end manages the ruleset, or when you attach a dedicated table with a clear priority on top of existing hooks.

Create a table and chains (one-time setup):

sudo nft add table inet filter

Register an input hook on that table:

sudo nft 'add chain inet filter input { type filter hook input priority 0; policy accept; }'

The input chain is registered when that command exits without an error. Add the matching output hook on the same table:

sudo nft 'add chain inet filter output { type filter hook output priority 0; policy accept; }'

Drop incoming timestamp requests:

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

Optionally drop outbound timestamp replies on OUTPUT:

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

Remote nping from vm2 showed 100% loss on vm1 with a temporary inet glc_test table at priority -300 using the same match syntax.

Persist rules under /etc/nftables.conf or a file in /etc/nftables/ included from there, then enable the unit:

sudo systemctl enable --now nftables

On firewalld-managed hosts, prefer firewalld instead of a parallel inet filter table unless you understand hook ordering.

List the table when you need rule handles for deletion:

sudo nft list table inet filter

Delete the input rule by handle number from that listing:

sudo nft delete rule inet filter input handle <num>

Remove the output rule the same way when you added one:

sudo nft delete rule inet filter output handle <num>

Block with iptables

iptables-nft remains the CLI many scripts expect. It works on hosts without firewalld owning the tables.

Block incoming timestamp requests at the top of INPUT:

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

Add a matching drop for outbound replies on OUTPUT:

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

Confirm the INPUT rule is present:

sudo iptables -L INPUT -n | grep -i timestamp

Check the OUTPUT chain the same way:

sudo iptables -L OUTPUT -n | grep -i timestamp

Sample output:

DROP       icmp --  0.0.0.0/0            0.0.0.0/0            icmptype 13
DROP       icmp --  0.0.0.0/0            0.0.0.0/0            icmptype 14

Save according to your distribution (iptables-save to /etc/sysconfig/iptables on RHEL-family systems with legacy persistence, or a netfilter-persistent package on Debian/Ubuntu).

On vm1 with active firewalld, raw iptables -I failed with iptables-restore … RULE_INSERT failed (No such file or directory)—another sign to use firewalld or nftables instead of fighting the active ruleset.

Remove the rules by exact specification when you roll back:

sudo iptables -D INPUT -p icmp --icmp-type timestamp-request -j DROP

Drop the matching OUTPUT rule with the same syntax:

sudo iptables -D OUTPUT -p icmp --icmp-type timestamp-reply -j DROP

Block with UFW before.rules

UFW does not expose per-ICMP-type CLI toggles. Edit the before rules file so drops apply before UFW evaluates its allow/deny policy.

Open /etc/ufw/before.rules and add these lines inside the *filter section, before the final COMMIT:

-A ufw-before-input -p icmp --icmp-type timestamp-request -j DROP
-A ufw-before-output -p icmp --icmp-type timestamp-reply -j DROP

Reload UFW so the file is applied:

sudo ufw reload

Check status:

sudo ufw status verbose

UFW still uses iptables/nftables underneath; the exact file layout matches Debian and Ubuntu packaging. See UFW command for enable order—allow SSH before ufw enable on remote servers.

To revert, remove the two lines from /etc/ufw/before.rules and run sudo ufw reload again.

Troubleshooting

References

• RFC 792 — ICMP
• IANA ICMP parameters
• firewalld rich rules — Red Hat documentation
• firewalld ICMP types — firewalld.org
• nftables wiki — Official wiki
• UFW community documentation — Ubuntu

Summary

ICMP timestamp findings are fixed at the firewall, not with a kernel sysctl. Block timestamp-request (type 13) on the path scanners use—usually the host INPUT hook or firewalld zone—and confirm from a second host with nping or your scanner’s plugin.

When firewalld already runs the machine, a permanent rich rule with family="ipv4" dropping timestamp-request is the most explicit path; --add-icmp-block=timestamp-request on the active zone is another supported firewalld method. Use nftables on hosts you manage with nft directly, iptables when no front end conflicts, and UFW before.rules on Ubuntu-style UFW deployments.

After you deploy a method, keep the verification command in your change record. Compliance rescans only care that a remote IPv4 type 13 request no longer produces a type 14 reply on the network path they test.