# NTP bursts from FortiGate firewalls **URL:** \ **Category:** Uncategorized\ **Created:** [May 19, 2020, 2:49am UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661 "2020-05-19T02:49:29Z")\ **Posts on this page:** 18\ **Page:** 2
**Author:** ![NTPman](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/ntpman/32/450_2.png) [@NTPman](https://community.ntppool.org/u/NTPman)\ **Post date:** [February 6, 2025, 4:00pm UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/21 "2025-02-06T16:00:49Z")
Also, are the incoming packets or the outgoing packets triggering the “protection”? Is this a feature (triggered by the inbound packets) that protects your system from an attack coming from the Internet, or is this a protection of the Internet from your system because you are flooding with NTP reply packets some specific external systems (protection triggered by the outgoing packets). > [@mlichvar](#): > > Several years ago they claimed they adjusted the limits, but it never worked for me. Then, put your money where you get reliable service. ---
**Author:** ![mlichvar](https://avatars.discourse-cdn.com/v4/letter/m/e79b87/32.png) [@mlichvar](https://community.ntppool.org/u/mlichvar)\ **Post date:** [February 6, 2025, 4:05pm UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/22 "2025-02-06T16:05:59Z")
It’s the incoming packets. There seems to be some per-flow rate limiting in the network (I see much higher packet rates on other VPSes) and I suspect when the number of limited flows exceeds a threshold, the whole port is blocked for 15 minutes. OVH is, or at least was when I checked the last time, the most popular VPS provided in the pool. ---
**Author:** ![NTPman](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/ntpman/32/450_2.png) [@NTPman](https://community.ntppool.org/u/NTPman)\ **Post date:** [February 6, 2025, 4:15pm UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/23 "2025-02-06T16:15:57Z")
They should be blocking only the flow that is problematic. If they block all inbound NTP traffic because of one problematic source IP, then rather OVH provides an easy option for denial of service. OpenAI told this me for the question “Could you tell me how does OVH’s DDoS protection work?”: ```auto 5. Customer Transparency Notifications and Reports: Customers are typically notified of ongoing DDoS attacks and can access reports detailing the nature of the attack and the mitigation actions taken by OVH. ``` I believe you have notifications and reports too. ---
**Author:** ![mlichvar](https://avatars.discourse-cdn.com/v4/letter/m/e79b87/32.png) [@mlichvar](https://community.ntppool.org/u/mlichvar)\ **Post date:** [February 6, 2025, 5:07pm UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/24 "2025-02-06T17:07:22Z")
Yes, I get the reports. Not much I can do about it except block the addresses. It’s not just one flow, more like 20. When I blast the server from one address, nothing happens except the rate is reduced. I looked at the individual addresses during a burst that triggered the block and there are some interesting patterns. It looks like it’s an on/off thing randomly switching between the addresses (each row is one second): ![](https://us1.discourse-cdn.com/flex016/uploads/ntppool/original/2X/6/621ed5223c74e8c9bb51c0013723e0dadd74f60d.png) ![](https://us1.discourse-cdn.com/flex016/uploads/ntppool/original/2X/a/a9c8ba7ea9c953a82f21b18fee40036cdbe1837b.png) ![](https://us1.discourse-cdn.com/flex016/uploads/ntppool/original/2X/a/a6547c2e62a42453e139558108e05c00f0bb26e0.png) ---
**Author:** ![MagicNTP](https://avatars.discourse-cdn.com/v4/letter/m/858c86/32.png) [@MagicNTP](https://community.ntppool.org/u/MagicNTP)\ **Post date:** [February 6, 2025, 9:03pm UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/25 "2025-02-06T21:03:55Z")
> [@mlichvar](#): > > suspect when the number of limited flows exceeds a threshold I also never really figured out what exactly was triggering this, as it happened at varying bitrates (I didn’t monitor packet rates at the time). Their DDoS protection seems really antiquated (to put it mildly), as OVH then send messages saying that… > Your IP is used in a NTP Amplification attack. You should update your NTP server, or fix its configuration, so that it won’t respond to ‘monlist’ queries. > You can check your server’s configuration here : [https://www.ovh.co.uk/cgi-bin/tools/ntp\_security.cgi](https://www.ovh.co.uk/cgi-bin/tools/ntp_security.cgi) > Attack detail : 31Kpps/19Mbps > dateTime srcIp:srcPort dstIp:dstPort protocol flags bytes reason > 2024.04.23 16:08:04 CEST x.y.z.a:123 x.29.73.188:17328 UDP — 76 ATTACK:NTP > 2024.04.23 16:08:04 CEST x.y.z.a:123 x.212.243.33:11748 UDP — 76 ATTACK:NTP > 2024.04.23 16:08:04 CEST x.y.z.a:123 x.144.170.6:48843 UDP — 76 ATTACK:NTP > […] (Address obfuscation by me.) Had this been an actual _amplification_ attack, the outbound traffic should have been _noticeably_ higher than the inbound one. Which it wasn’t, rather _slightly_ lower due to packet drops on the server side. Also, the packet size doesn’t _seem_ like `monlist` queries (but still could be some trickery). Then, had they used their own configuration check tool, they would have seen that that isn’t an issue. And lastly, looking at the actual traffic showed that there was nowhere a mode 6 or other control-type packet in sight when those “NTP Amplification” attacks based on `monlist` queries supposedly happened… ---
**Author:** ![davehart](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/davehart/32/1411_2.png) [@davehart](https://community.ntppool.org/u/davehart)\ **Post date:** [February 6, 2025, 9:35pm UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/26 "2025-02-06T21:35:59Z")
> [@MagicNTP](#): > > And lastly, looking at the actual traffic showed that there was nowhere a mode 6 or other control-type packet in sight when those “NTP Amplification” attacks based on `monlist` queries supposedly happened… A pedantic correction: `monlist` queries were mode 7 (ntpdc). `ntpd` removed support for `monlist` as of 4.2.8’s release in December 2014. The ntp-dev branch removed that support in April 2010, and disabled all mode 7 responses by default in November 2011. The replacement functionality, `ntpq -c mrulist`, uses a nonce mechanism to ensure the requesting IP address isn’t forged (spoofed), as it was with `monlist` amplification attacks. ---
**Author:** ![stevesommars](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/stevesommars/32/2075_2.png) [@stevesommars](https://community.ntppool.org/u/stevesommars)\ **Post date:** [February 7, 2025, 3:12am UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/27 "2025-02-07T03:12:02Z")
Terminology: The company is [Fortinet](https://www.fortinet.com/). One of their products is the FortiGate firewall. I had confirmation from Fortinet of the unfortunate FortiGate behavior, which began in December 2019 with a faulty software release. A correction was issued mid-2020. Hal and I monitored several NTP Pool NTP servers and watches as the FortiGate problem dwindled over the next couple of years. Except in Lithuania. Some NTP servers located in Europe, especially in the Lithuania zone, still show the same signature seen with the FortiGates. I queried Fortinet about this, but they no longer respond to my emails. I don’t think these are from FortiGate firewalls. My belief is that these are another Fortinet product, possibly a VPN. I could be wrong, but I’ll call these “Fortinet VPNs” The FortiGate firewalls had static IP addresses, as expected. Many of the Fortinet VPNs appear to have dynamic IP addresses, others have static IP addresses. The top ASNs with abusive clients are 1257, 8764, 13194, and 43627. At times many Lithuanian NTP clients simultaneously (sometimes over 40!) send bursts to the same NTP server. I haven’t determined a pattern. The simultaneous bursts may trigger the DDoS alerts. ---
**Author:** ![mlichvar](https://avatars.discourse-cdn.com/v4/letter/m/e79b87/32.png) [@mlichvar](https://community.ntppool.org/u/mlichvar)\ **Post date:** [February 7, 2025, 8:46am UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/28 "2025-02-07T08:46:25Z")
The Lithuanian clients are seen in whole Europe, but some countries have their own prominent local forti\* bursters. For example in Germany the top 3 bursters I see are from Germany, in France it’s the top one. I think it depends on how the clients are configured, e.g. if they use [europe.pool.ntp.org](http://europe.pool.ntp.org) or [pool.ntp.org](http://pool.ntp.org). For best results the ntpguard rules should be made in each country separately. I’m collecting data in 12 countries. ---
**Author:** ![mlichvar](https://avatars.discourse-cdn.com/v4/letter/m/e79b87/32.png) [@mlichvar](https://community.ntppool.org/u/mlichvar)\ **Post date:** [February 7, 2025, 8:56am UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/29 "2025-02-07T08:56:01Z")
> [@MagicNTP](#): > > Your IP is used in a NTP Amplification attack. You should update your NTP server, or fix its configuration, so that it won’t respond to ‘monlist’ queries. > You can check your server’s configuration here : [https://www.ovh.co.uk/cgi-bin/tools/ntp\_security.cgi](https://www.ovh.co.uk/cgi-bin/tools/ntp_security.cgi) Yes, this is very annoying. I made a suggestion to the OVH support to add a verification using their own tool before claiming “amplification attack”, but they didn’t seem to be interested. ---
**Author:** ![MagicNTP](https://avatars.discourse-cdn.com/v4/letter/m/858c86/32.png) [@MagicNTP](https://community.ntppool.org/u/MagicNTP)\ **Post date:** [February 11, 2025, 5:38pm UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/30 "2025-02-11T17:38:30Z")
> [@mlichvar](#): > > optimized detector in C and python scripts to prepare and load the firewall rules Sweet! On Linux, I expect that to go nicely with a `hash:ip,port`-type `ipset`, or even just a `hash:ip` or other type, depending on the desired granularity. Thanks! ---
**Author:** ![marco.davids](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/marco.davids/32/767_2.png) [@marco.davids](https://community.ntppool.org/u/marco.davids)\ **Post date:** [February 12, 2025, 8:36am UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/31 "2025-02-12T08:36:41Z")
> [@mlichvar](#): > > I wrote an optimized detector in C Nice tool thanks! But I have a clarifying question; in the output there’s an Pv4 address 46.36.88.170, being identified as ‘fortigate’. However, when I check it out, it appears to be a MikroTik device running RouterOS v6.45.9. How should I interpret this? ---
**Author:** ![mlichvar](https://avatars.discourse-cdn.com/v4/letter/m/e79b87/32.png) [@mlichvar](https://community.ntppool.org/u/mlichvar)\ **Post date:** [February 12, 2025, 9:30am UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/32 "2025-02-12T09:30:53Z")
I think that means the Fortigate (or a different FortiOS-based device as Steven pointed out) is in a local network behind NAT. A firewall or VPN doesn’t have to have a public address, right? The Mikrotik router could be provided by the ISP and their customers have their own device protecting their network. ---
**Author:** ![stevesommars](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/stevesommars/32/2075_2.png) [@stevesommars](https://community.ntppool.org/u/stevesommars)\ **Post date:** [February 12, 2025, 3:51pm UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/33 "2025-02-12T15:51:18Z")
I’ve seen several MikroTik devices among the Lithuania bursters. ---
**Author:** ![davehart](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/davehart/32/1411_2.png) [@davehart](https://community.ntppool.org/u/davehart)\ **Post date:** [February 14, 2025, 12:22am UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/34 "2025-02-14T00:22:56Z")
FortOS in the news: [https://www.akamai.com/blog/security-research/2025-february-fortinet-critical-vulnerabilities](https://www.akamai.com/blog/security-research/2025-february-fortinet-critical-vulnerabilities) ---
**Author:** ![MagicNTP](https://avatars.discourse-cdn.com/v4/letter/m/858c86/32.png) [@MagicNTP](https://community.ntppool.org/u/MagicNTP)\ **Post date:** [February 17, 2025, 5:40pm UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/35 "2025-02-17T17:40:51Z")
> [@mlichvar](#): > > I wrote an optimized detector in C I had a misbehaving client in the US zone today that evaded detection by the `detector` tool despite reaching peaks of 5000pps and more. I guess the traffic signature does not match those currently known for Fortinet products or timesyncd. The pattern was six distinct bursts per minute, for a 5-minute average rate of near 1Mbit/s continuously ever since it started at about 9AM UTC today. I have a PCAP with a few minutes worth of traffic. As it seems I can’t attach files of that type here, it can be downloaded (hopefully) from [here](https://limewire.com/d/fbaa74dc-d967-4e9e-8286-cca57efc2c27#WV5exXgKgcFehX1seU2P9owOH1nfovOBKoh_tVi7nvE) for the next seven days. I wrote an email to the apparent user of that IP address. Until I hear back from them, I have now blocked that traffic on the infrastructure side as it was more than doubling my usual traffic volume. ---
**Author:** ![stevesommars](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/stevesommars/32/2075_2.png) [@stevesommars](https://community.ntppool.org/u/stevesommars)\ **Post date:** [February 17, 2025, 7:14pm UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/36 "2025-02-17T19:14:09Z")
I looked at the pcap & agree this is not the Forti\* problem. I’ve never seen a similar pattern. ---
**Author:** ![MagicNTP](https://avatars.discourse-cdn.com/v4/letter/m/858c86/32.png) [@MagicNTP](https://community.ntppool.org/u/MagicNTP)\ **Post date:** [May 23, 2025, 1:48pm UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/37 "2025-05-23T13:48:30Z")
I’d been wondering for a while as to whether typical misbehaving clients such as Forti\* devices or timesyncd clients only occur with IPv4, or whether IPv6 would be affected as well. Since a few days, I know that there are also strangely behaving clients on IPv6. I have a server in the HK zone that had been in monitoring only mode for a few days already so that traffic had died down to a few kbit/s, when suddenly, traffic jumped back up to about 175 kbit/s, with short gaps in between. And all while the server was still in monitoring only mode. That happened around the time of the most recent hiccup with the pool back-end infrastructure, so I initially thought maybe some DNS server was handing out stale data temporarily. But when finally taking a closer look, I realized it was a single client that was causing this traffic. I started blocking the incoming traffic after a few days when it didn’t go away on its own. The client seemed pretty much unfazed by that, just slightly increasing the peak rate to about 245 kbit/s, but it still didn’t go away. Removing the block makes it drop the rate to about 175 kbit/s again. So it is certainly getting _some_ kind of message, but not the one to actually stop the traffic. Anyway, in case anyone is interested, a PCAP of the incoming client traffic can be downloaded from [here](https://limewire.com/d/NmS4g#difMBsQu5o) for the next seven days. (Note that my server’s IP address is obfuscated.) ---
**Author:** ![stevesommars](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/stevesommars/32/2075_2.png) [@stevesommars](https://community.ntppool.org/u/stevesommars)\ **Post date:** [May 23, 2025, 2:32pm UTC](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661/38 "2025-05-23T14:32:42Z")
Most of the abusive clients I’ve seen are IPv4. As you indicate, this example is IPv6. The fractional portion of the client Tx timestamp is distributed between 0 and 0.232, this is likely a systemd.timesyncd bug. ![image](https://us1.discourse-cdn.com/flex016/uploads/ntppool/original/2X/c/c2f52b0f7d8a613f272228d327cdd17828c955e2.png) [Previous page](https://community.ntppool.org/t/ntp-bursts-from-fortigate-firewalls/1661.md?page=1)