So clearly there is some list somewhere that ntp pool assigns to each country that is in each zone… For example my server is in the north american zone, and in the us.
What I am looking for is an easy cidr listing of this NA zone so I can use it to limit who can query my server. I for sure could create my own from multiple sources and can see what countries are included in the NA zone from here. http://www.pool.ntp.org/zone/north-america
But it would be so much easier if there was already list that was available. I would think there has to be if they are creating the zones in the first place. Have to know and setup what netblocks are in these zones, etc…
A url that is updated every now and then that points to a text file with IP/cidr would be freaking fantastic
There’s no guarentee that the clients are on the same continent or in the same country; it’s a “best efforts” based on the clients DNS server and the GeoIP database from MaxMind.
I would like to take this list and on my firewall limit inbound to my ntp server. So that users that are not in NA can not query…
Be it your listing your using is 100% accurate or not really an issue.
Or could just setup the rules to allow but log those that are not in the list, and not log the traffic that comes from NA listed IPs, etc. There are plenty of places I could create my own listing from… Was just curious since you have created pools specific for say north america zone, that you would already have an easy to get to list of these IP blocks?
I recall back when was playing around and just did short sniff of like 1 hour of traffic, that the top IPs doing queries where not even in NA… A simple listing of what ntp considers NA would allow me to just log those that are not in that list, etc.
That sounds like a bad idea. Foreign traffic exists, but is usually limited – the Snapchat incident is a notable exception, but its worst harm was to servers in other countries from clients in the US anyway – and no IP geolocation database is perfectly accurate. Indeed, in some ways, they’re getting worse over time as desperate ISPs acquire IPv4 ranges from anywhere they can find them.
Trying to block such traffic will save you a small amount of bandwidth and harm a small portion of Pool users.
Are you sure they really weren’t in North America? And even if they weren’t, how harmful were they? A high traffic US server has hundreds of thousands or millions of clients, and receives thousands of queries per second. A small number of abusive clients are a disproportionate but still small percentage of total traffic.
Also, you can block or rate-limit them, with NTP’s built-in rate-limiting facilities or in other ways, based on their behavior instead of their location.
In any case, the geo IP database is provided by a third party, and anyone can download it from them.
LIke I said I know I can download lists of IP blocks for different countries - what I was asking if it was provided somewhere on ntp.org
Why do people keep bringing up accuracy?? That has nothing to do with what I am asking…
Nevermind I will just create my own list… Who said anything about worried about bandwidth?? Who said anything about worried about them doing something bad?
Just on principle sake - I am in the NA zone, maybe I don’t want non NA users hitting me… For starters if they are not in NA using a NA ntp is prob not a good choice in the first place, etc.
Okay. That’s a reasonable enough question. And the answer is that it’s a widely available third-party list, and it probably never occurred to @ask to redistribute it.
This principle will slightly harm a small portion of users, and won’t significantly benefit anyone.
Geolocation errors would be a real problem if a large portion of servers blocked foreign traffic.
That’s really neat. One of my long-term-roadmap things is to have a small program operators can run that’ll use pcap (for example) to capture ntp packets and do analytics on them.
Optionally it could also send summary data or sampled data to a central service that could process the data similarly to what you did with Grafana.
How are you storing the data to do the visualization?
The data were stored in a ElasticSearch Cluster.
The data was generated by iptables.
I’ve created a rule for ntp packets. Normally it is written to syslog but i’ve configured the rsyslog daemon to send the message to Logstash.
And Logstash insert it into ElasticSearch.
The message contains the source ip of the packet. So Grafana can use the ip for visualization.
But you can use also json or something else.
Out of my own experience at my company, ElasticSearch needs a lot of memory for indexing.
And a lot of nodes for indexing when you have a large amount of data.
