I have a requirement to allow the internal NTP servers to sync with ONLY US.pool.ntp.org. I have tried creating the rule 2 different ways.
How best can I create this security policy to limit NTP updates to the us.pool.ntp.org?
Hi @jlieberman ,
Lets begin with you second approach. As you know NTP protocol doesn't use any kind of URL, so basically URL category can be used only with http based applications that actually have URL in the data. If you put URL category to your rule (not as URL filtering profile), this become additional matching criteria. Since the URL is part of the application data, your rule will most likely allow the the initial connection to be established (in order for the FW to gather enough information to identify the URL), once it detect the URL it will again evaluate your rule and if it is different from the defined it will no longer match with this rule and search for new rule match eventually hitting your deny all.
But as I mentioned at the beginning NTP doesn't use any URL and it is using UDP, so the rule will allow the ntp request and responde to pass through since it is trying to gather enough information to detect the url you defined, but since it is UDP and the actual reply is in the second packet you have fully working ntp.
Now for your first approach. When you create FQDN object and use it in a rule the firewall will start periodically asking its DNS to resolve the FQDN to IP address. The IP address/es from the reply are the one that firewall will use as destination IP for matching criteria for your rule. When DNS reply the FW will cache the response for configurable amount of time and periodically will check for update.
According to this document event if DNS return all 500+ addresses, the FW will use only the first 32 - https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClVqCAK
As you can imagine when host or another device want to sync with NTP it will first resolve the fqdn to ip address and send ntp request to one of the first ip addresses.
So for me it sounds that FQDN object as destination address is exactly what you need. Can you elaborate a bit more what do you mean by "This doesn't work as there are like 500+ ips behind that pool"
- You want to allow all 500+ IPs at the same time? Do you really need all of them?
- Or you are concerned that you allow too many addresses?
Thank you for the prompt reply.
I have already tested both methods and neither work. I thought the FQDN approach might work but it did not. That is when I tried the 2nd approach and then quickly saw that no URL is being identified. Your explanation makes perfect sense.
The problem with the FQDN approach is simple. If you go and resolve us.pool.ntp.org you will get maybe 4 IP addresses back. But really there are 549 active servers in that zone. https://www.pool.ntp.org/zone/us . When you use pool.ntp.org, it will determine which is the closest server to you and use that one. These change daily and there is no way for me to specify a single IP as it might not be valid tomorrow.
We have done something similar and we use Objects/Addresses/FQDN.
This seems to work for us as those are hardly ever down and there are several with a FQDN as the last option.
@OtakarKlier I tried that method for us.pool.ntp.org but it isn't catching the IPs that end up being used. I think this pool uses a different method because they pick a random address from a pool of 600+. The pool can change from 1 day to the next.
I think I might just push them to use nist instead since that is a more reliable source that I can lock down.
Hi @jlieberman ,
I finally understand what is the problem with the FQDN object. It seems that DNS return different IP addresses every time a request is sent.
I was going to suggest to use some script that is reading all 500+ server and providing EDL, but I didn't manage to find the full list of addresses so I am not sure of the effort will worth it.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!