Hello everybody, I use ip’s block lists, my question is if it is possible to know the ip’s of the ntp monitors? Knowing the ip’s I can create a suppression list and eventually they won’t be blocked, so they won’t condition the score of the ntp server. Thanks.

If a monitor briefly gets caught up in a temporary rate limit it will handle that. As @erayd and others said, if your abuse prevention blocks the monitors you are blocking too broadly to be useful as a public server in the pool system.

Correct we would not give you the monitoring station IP’s for this reason. There is no reason for you to know what is a client and what is a monitor. If you have a server in the pool it should answer the same for both the clients and the monitor. If you are using whitelist then you are not provid…

Hi everybody, thank you all for the explanation.

As a server operator, i do rate limit all clients by default. I rate limit those clients not using the NTP port more aggressively, since it’s more likely that user ports are used in case of abuse. Then, depending on the specific case, knowing the addresses of the monitors can be helpful. Only the se…

I do ratelimit also, if they hit harder then 2^2 seconds (bursting above 6 times will not be answered) all the time they are blocked. But there is no IP blocking, for nobody. You should not do such when being a part of the pool, as when you do, people will get your server via the DNS and you block…

I still use the following strategy. There are always a few IPs on the blocklist as a result - at the moment of this post, there are currently four. That’s on the lower end of what is typical for my server. [image] What is a reasonable limit? I personally add anything tha…

Note. There are at least two philosophies for dealing with huge bursts. ntpd from Network Time Foundation can strictly limit the response rate sent to a client. Miroslav pointed out that such rate limiting opened a denial of service channel. Thus chrony’s model for dealing with huge bursts is d…

This is the case where I think IP blocking potentially makes sense—when you can drop the traffic further upstream. For a while I would periodically review NTP’s monlist and manually add iptables rules to drop egregiously broken clients, but I realized that (maybe outside a trip through userspace?) …

So many bad clients? See my article that describes misbehaving FortiGate(Fortinet Firewalls) acting as NTP clients. Over three years later we still see a small number of these sending NTP bursts. Each client sends a short burst of 500+ NTP requests / second for a short interval. Worse, on occasi…

And in IPv4, there’s a sliding scale of how abusive individual clients are vs. how many clients are using NAT behind one IP address. If someone boots 100 VMs at the same time, you might receive a large burst of packets and then a query on average every 0.64 seconds.

Ip monitor list

Server operators

erayd April 3, 2023, 10:47pm 11

In my opinion it’s worthwhile having some sort of automated throttling of clients, even if just as a defense against bugs. As an example, 20,000 packets / sec for each problematic client is not insignificant - see the Fortigate bug below. Rules that chop the peaks off that kind of load can be quite helpful.

Topic		Replies	Views
List of trackers Uncategorized monitoring	32	903	May 21, 2025
Howto deal with bad NTP-Client / Attacker? Server operators	50	2310	December 1, 2023
A (preliminary) list of client IPs requesting time milions of times constantly Server operators	6	2644	May 2, 2017
IPv4 -v- IPv6 monitoring Server operators	25	1532	February 19, 2020
Add server produces: ""Could not check NTP status Server operators	36	1840	November 5, 2020

Ip monitor list

Related topics