[EN] Filtering ICMP Timestamp Packets on Ubuntu: A Practical Mitigation Method for Pentest Findings

One of the common findings encountered during security scans or penetration tests on Linux servers is that ICMP Timestamp Request/Reply packets are allowed. This issue is usually reported under names such as “ICMP Timestamp Request Remote Date Disclosure” or similar titles.

Although this finding may not seem critical at first glance, filtering these packets is recommended, especially in corporate environments, security hardening processes, and compliance-focused infrastructures. ICMP Timestamp messages can reveal timing-related information about a remote system. While this information alone may not directly lead to system compromise, it can still help attackers during reconnaissance, system profiling, or planning further attack steps.

In ICMP, Type 13 represents a Timestamp Request, while Type 14 represents a Timestamp Reply.

In this article, we will explain how to block ICMP Timestamp packets on Ubuntu, what the automation script does, why it is made persistent with systemd, and how to verify the configuration after implementation.

What Is ICMP Timestamp?

ICMP, or Internet Control Message Protocol, is a core network protocol used by operating systems and network devices to exchange error messages and control information.

The most common example of ICMP usage is the ping command, which uses ICMP Echo Request and Echo Reply messages.

ICMP Timestamp is an older ICMP mechanism that allows a remote device to request time-related information from another system. In modern environments, this feature is generally not required. Time synchronization is usually handled through NTP or other dedicated time synchronization services.

ICMP Timestamp uses two main ICMP message types:

ICMP Type 13 - Timestamp Request
ICMP Type 14 - Timestamp Reply

When a client sends an ICMP Type 13 packet to a target system, the target may respond with an ICMP Type 14 packet. This response may expose time-related information about the system, which is why security scanners often report it as a finding.

Why Should This Finding Be Mitigated?

Allowing ICMP Timestamp responses usually does not create a direct exploitation path. However, a good security approach is based on reducing unnecessary information disclosure and disabling unused protocol behaviors.

Blocking ICMP Timestamp packets is useful for several reasons:

It prevents unnecessary findings in penetration test reports.

It reduces the amount of system information exposed externally.

It limits the data available to attackers during reconnaissance.

It improves compliance with hardening and security standards.

It disables an outdated ICMP behavior that is not required in most modern environments.

This is especially useful for internet-facing Ubuntu servers running services such as DNS, web applications, mail services, VPN gateways, or management interfaces.

Solution Approach

The main goal is to block incoming and outgoing ICMP Timestamp packets on the Ubuntu server.

The following ICMP types will be filtered:

ICMP Type 13 - Timestamp Request
ICMP Type 14 - Timestamp Reply

The automation script blocks these packets in both the INPUT and OUTPUT chains.

With this configuration, the server:

Does not accept incoming ICMP Timestamp Request packets.

Does not send ICMP Timestamp Reply packets.

Does not initiate ICMP Timestamp Request packets.

Does not accept incoming ICMP Timestamp Reply packets.

This provides a stricter and cleaner security posture.

Automation Script

The following script can be used to block ICMP Timestamp packets on Ubuntu servers. It creates the required iptables rules and defines a systemd service to make sure the rules are reapplied after a reboot.

sudo bash -c '
echo ">>> ICMP Timestamp (13/14) Mitigation Script is starting..."

# 1. Create the rule script
cat << "EOF" > /usr/local/bin/block-icmp-timestamp.sh
#!/bin/bash
iptables -C INPUT -p icmp --icmp-type 13 -j DROP 2>/dev/null || iptables -I INPUT -p icmp --icmp-type 13 -j DROP
iptables -C INPUT -p icmp --icmp-type 14 -j DROP 2>/dev/null || iptables -I INPUT -p icmp --icmp-type 14 -j DROP
iptables -C OUTPUT -p icmp --icmp-type 13 -j DROP 2>/dev/null || iptables -I OUTPUT -p icmp --icmp-type 13 -j DROP
iptables -C OUTPUT -p icmp --icmp-type 14 -j DROP 2>/dev/null || iptables -I OUTPUT -p icmp --icmp-type 14 -j DROP
EOF

chmod +x /usr/local/bin/block-icmp-timestamp.sh

# 2. Create the systemd service configuration
cat << "EOF" > /etc/systemd/system/icmp-timestamp-block.service
[Unit]
Description=Block ICMP Timestamp (Type 13/14) for Pentest Compliance
After=network.target ufw.service iptables.service firewalld.service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/block-icmp-timestamp.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF

# 3. Enable and apply the service
systemctl daemon-reload
systemctl enable icmp-timestamp-block.service
systemctl restart icmp-timestamp-block.service

echo ">>> [OK] Installation completed. Active netfilter rules:"
iptables -nvL INPUT | grep -E "icmptype 13|icmptype 14"
iptables -nvL OUTPUT | grep -E "icmptype 13|icmptype 14"
'

What Does the Script Do?

The script consists of three main parts.

In the first part, it creates a separate bash script named:

/usr/local/bin/block-icmp-timestamp.sh

This script adds the required DROP rules to iptables.

A key point in this section is the following command structure:

iptables -C ...

The -C parameter checks whether the rule already exists. If the rule is already present, it is not added again.

If the rule does not exist, the following command is executed:

iptables -I ...

The -I parameter inserts the rule at the beginning of the chain.

This prevents duplicate rules from being created when the script is executed multiple times. In other words, the script is designed to be safe and idempotent.

Why Are Both INPUT and OUTPUT Chains Used?

In many cases, blocking ICMP Type 13 packets in the INPUT chain may seem sufficient. If the server does not accept Timestamp Request packets, it will not generate a reply.

However, from a stricter hardening perspective, filtering both INPUT and OUTPUT traffic is a better approach.

With this configuration:

The server drops incoming Timestamp Request packets.

The server cannot send Timestamp Reply packets.

The server cannot initiate Timestamp Request packets.

The server drops incoming Timestamp Reply packets.

This provides a more complete mitigation and is especially useful when the goal is to achieve a clean result in security scans and penetration tests.

Why Is a systemd Service Created?

iptables rules added manually may be lost after a reboot on some systems. Therefore, the rules need to be reapplied automatically when the system starts.

This script creates a custom systemd service for that purpose:

[Unit]
Description=Block ICMP Timestamp (Type 13/14) for Pentest Compliance
After=network.target ufw.service iptables.service firewalld.service

This section ensures that the service runs after the network and firewall-related services are available.

[Service]
Type=oneshot
ExecStart=/usr/local/bin/block-icmp-timestamp.sh
RemainAfterExit=yes

Type=oneshot means the service runs a command once and then exits. This type of service is commonly used for applying configuration changes during system startup.

RemainAfterExit=yes allows systemd to consider the service active even after the command has completed.

The final section enables the service to run during normal multi-user system startup:

[Install]
WantedBy=multi-user.target

Verifying the Configuration

After running the script, you can check the service status with the following command:

systemctl status icmp-timestamp-block.service

The service should show as successfully executed.

To verify the iptables rules, run:

iptables -nvL INPUT | grep -E "icmptype 13|icmptype 14"
iptables -nvL OUTPUT | grep -E "icmptype 13|icmptype 14"

You can also use the following command for a simpler overview:

iptables -S | grep icmp

The expected rules should look similar to the following:

-A INPUT -p icmp -m icmp --icmp-type 13 -j DROP
-A INPUT -p icmp -m icmp --icmp-type 14 -j DROP
-A OUTPUT -p icmp -m icmp --icmp-type 13 -j DROP
-A OUTPUT -p icmp -m icmp --icmp-type 14 -j DROP

Notes for Ubuntu 22.04 and Ubuntu 24.04

On newer Ubuntu versions, iptables commands may use the nftables backend in the background. This is normal.

You can check the active backend with:

iptables --version

You may see an output similar to:

iptables v1.x.x (nf_tables)

This means that iptables commands are being handled through the nftables backend.

To view nftables rules directly, you can use:

sudo nft list ruleset

If your organization uses nftables as the standard firewall management method, the same mitigation can also be implemented directly with nftables rules.

However, the script in this article uses iptables because it is simple, practical, and easy to deploy across multiple Ubuntu servers.

Important Notes for Systems Using UFW

If UFW is active on the Ubuntu server, you should check how the custom iptables rules interact with existing UFW rules.

You can check UFW status with:

sudo ufw status verbose

Even when UFW is enabled, the iptables rules added by this script can still work. However, in strictly managed environments, firewall policies should ideally be managed from a single control point.

The recommended approach in enterprise environments is:

Use one clear firewall management method.

Avoid unmanaged combinations of UFW, firewalld, iptables, and nftables.

Document all automation scripts.

Track pentest-related changes through change management.

Verify the result after reboot.

Does This Affect Ping?

No, this script does not block normal ping traffic.

Ping uses different ICMP types:

ICMP Type 8 - Echo Request
ICMP Type 0 - Echo Reply

This script only blocks:

ICMP Type 13 - Timestamp Request
ICMP Type 14 - Timestamp Reply

Therefore, a standard ping command can continue to work:

ping 8.8.8.8

However, if there are other firewall rules on the server that block ICMP more broadly, ping behavior may still be affected by those separate rules.

How to Roll Back the Configuration

If you need to remove the rules manually, you can use the following commands:

sudo iptables -D INPUT -p icmp --icmp-type 13 -j DROP
sudo iptables -D INPUT -p icmp --icmp-type 14 -j DROP
sudo iptables -D OUTPUT -p icmp --icmp-type 13 -j DROP
sudo iptables -D OUTPUT -p icmp --icmp-type 14 -j DROP

To disable the systemd service:

sudo systemctl disable icmp-timestamp-block.service
sudo systemctl stop icmp-timestamp-block.service

To completely remove the created files:

sudo rm -f /usr/local/bin/block-icmp-timestamp.sh
sudo rm -f /etc/systemd/system/icmp-timestamp-block.service
sudo systemctl daemon-reload

Security and Operational Recommendations

Before applying firewall hardening changes on production systems, they should always be tested in a controlled environment.

When working with firewall rules, pay attention to the following points:

Make sure SSH access is not interrupted.

Verify application traffic after the change.

Clearly define whether UFW, firewalld, iptables, or nftables is the firewall standard.

Check the rules again after reboot.

Run a validation scan with the pentest or security team.

Document the implemented change.

Since this script only targets ICMP Timestamp packets, it is generally a low-risk hardening action. However, every firewall change should still be applied carefully, especially on production systems.

ICMP Timestamp Request and Timestamp Reply packets are common findings in security scans on Ubuntu servers. Although this issue is usually not critical by itself, it is a good practice to mitigate it as part of system hardening.

With the automation script provided in this article, ICMP Type 13 and Type 14 packets are blocked in both incoming and outgoing directions. The systemd service also ensures that the rules are reapplied automatically after a reboot.

In summary, this configuration helps to:

Mitigate ICMP Timestamp findings.

Improve pentest compliance.

Prevent unnecessary time-related information disclosure.

Strengthen the server firewall posture.

Keep the rules persistent after reboot.

Small hardening steps like this can make a meaningful difference, especially on internet-facing Linux servers.