Skip to main content
ppatel
Staff & Editor
Staff & Editor
January 25, 2022

Technical Tip: Block ICMP timestamp on FortiGate interface while keeping ping enabled

  • January 25, 2022
  • 0 replies
  • 56754 views

Description

This article describes the Block ICMP timestamp on a Fortigate interface while keeping ping enabled.

The ICMP timestamp response from Fortigate contains the device's date and time. This information could be used as a vulnerability with high visibility.
Both ICMP Type 13 (Timestamp Request) and Type 14 (Timestamp Reply) are largely obsolete - they have been replaced by NTP (Network Time Protocol) for time synchronization.

Blocking the requests will not have any effect on legitimate traffic, although some 3rd party legacy diagnostic tools might use it.

To block an ICMP timestamp request on wan1 interface IP, follow the following steps:

config system interface
 edit "wan1"
        set vdom "root"
        set ip 1.1.1.1 255.255.255.0
        set allowaccess ping
        set type physical
        set snmp-index 1
    next
end

Scope

FortiGate.

Solution

  1. Create a firewall service for ICMP type 13 (timestamp request) and type 14 (timestamp replies) if it is not available on the list of services:

df418fe6.jpg

 

e0ef8398.jpg0050f56c.jpg
config firewall service custom
    edit "TIMESTAMP"
        set protocol ICMP
        set icmptype 13
    next

    edit "TIMESTAMP_Replies"
        set protocol ICMP
        set icmptype 14
        unset icmpcode
    next
end


  1. Create an address entry for the WAN1 interface IP:

 

config firewall address
    edit "wan1-IP"
        set subnet 1.1.1.1 255.255.255.255
    next
end

 

  1. Create local-in-policy to block timestamp requests on the wan1 interface IP:

 

config firewall local-in-policy
     edit 1
        set intf "wan1"
        set srcaddr "all"
        set dstaddr "wan1-IP"
        set service "TIMESTAMP" "TIMESTAMP_Replies"
        set schedule "always"
        set action deny
    next
end


Starting from FortiGate v7.6.0, the Local-in-Policy can also be configured in the GUI. Refer to this document for reference:
Technical Tip: Creating a Local-In policy (IPv4 and IPv6) on GUI

 

Refer to the guide below to configure the local-in policy for the dedicated reserved management interface: 
Technical Tip: How to configure a local-in policy on a HA reserved management interface

 

Testing the Policy Is Working:

 

To test whether the local-in policy is working as expected, use a tool such as hping3 to generate test traffic:
hping3

 

Example command:


sudo hping3 1.2.3.4 --icmp --icmp-ts 


'icmp-ts' flag creates the type 13 Traffic.

 

Verify the local-in policy exists and note the policy index number:

 

diagnose firewall iprope list 100001 

policy index=1 uuid_idx=16080 action=drop 
flag (8010001): log master pol_stats 
schedule(always) 
cos_fwd=0 cos_rev=0 
group=00100001 av=00000000 au=00000000 split=00000000 
host=0 chk_client_info=0x0 app_list=0 ips_view=0 
misc=0 
zone(1): 3 -> zone(1): 0 
source(1): 0.0.0.0-255.255.255.255, uuid_idx=15741, 
dest(1): 0.0.0.0-255.255.255.255, uuid_idx=15741, 
service(1): 
[1:0x0:0/(0,65535)->(13,13)] flags:0 helper:auto 

diag firewall iprope show 100001 1 <- The final 1 of this line is the policy index number.
idx:1 
pkts:0 (0 0 0 0 0 0 0 0) 
bytes:0 (0 0 0 0 0 0 0 0) 
asic_pkts:0 (0 0 0 0 0 0 0 0) 
asic_bytes:0 (0 0 0 0 0 0 0 0) 
flag:0x0

 

Example Output of hping3 test:

Without local-in policy:

 

$ sudo hping3 1.2.3.4 --icmp --icmp-ts 
using eth0, addr: 10.10.10.10, MTU: 1500 
HPING 1.2.3.4 (eth0 1.2.3.4): icmp mode set, 28 headers + 0 data bytes 
len=46 ip=1.2.3.4 ttl=246 id=65378 tos=0 iplen=40 
icmp_seq=0 rtt=18.7 ms 
ICMP timestamp: Originate=41865392 Receive=41865390 Transmit=41865390 
ICMP timestamp RTT tsrtt=20

 

With local-in policy enabled:

 

$ sudo hping3 1.2.3.4 --icmp --icmp-ts 
using eth0, addr: 10.10.10.10, MTU: 1500 
HPING 1.2.3.4 (eth0 1.2.3.4): icmp mode set, 28 headers + 0 data bytes 
^C 
--- 1.2.3.4 hping statistic --- 
19 packets transmitted, 0 packets received, 100% packet loss <- 19 packets transmitted - all blocked.

 

Check Traffic Statistics:

 

diag firewall iprope show 100001 1 
idx:1 
pkts:19 (19 0 0 0 0 0 0 0) <- 19 packets matching the block policy.
bytes:760 (760 0 0 0 0 0 0 0) 
asic_pkts:0 (0 0 0 0 0 0 0 0) 
asic_bytes:0 (0 0 0 0 0 0 0 0) 
flag:0x0 
hit count:19 (19 0 0 0 0 0 0 0) 
first hit:2024-10-29 12:39:07 last hit:2024-10-29 12:39:25

 

Related articles:

Technical Tip: How to verify the block ICMP timestamp on FortiGate interface 

Technical Tip: Blocking ICMP Unreachable Messages by using interface-policy

Technical Tip: Block ICMP request originated from the firewall

    Thought Leadership. Security Summit. Thursday, November 12th, PGA National Resort, Palm Beach Gardens, FL.
    Thought Leadership. Security Summit. Thursday, October 8th. Disney's Grand Californian Hotel & SPA, Anaheim, CA.