11-27-2018 12:53 PM - edited 02-21-2020 08:30 AM
Hello Experts,
I hope you all are doing great.
We have a Ntp server in a customer local network and we want to sync that Ntp server with Global Ntp server, the Ntp traffic will traverse through the Cisco ASA, So i just want to know what is the Best practice we ever used while we are creating rules for inbound or outbound traffic on ASA for Ntp.
Currently we are using below rules for Ntp traffic on ASA.
access-list Outside-to-Inside extended permit udp any host 10.x.x.x eq ntp
access-list Inside-to-Outside extended permit udp host 10.x.x.x any eq ntp
Thanks in advance.
Solved! Go to Solution.
11-28-2018 04:54 AM
The "any" doesn't affect who can originate traffic from outside. It only allows the trusted inside ntp server to use any public server.
Only the return flows from the public ntp servers that your trusted server has selected will be allowed from outside to inside.
11-28-2018 05:15 AM
Best practice varies according to your risk profile.
Ultra secure is a dedicated NTP appliance with antenna to GPS satellites. They encode precise timing and a dedicate appliance can derive NTP from that.
Anything Internet-based is less secure.
The next most secure would be a hardened Linux server running minimal services.
In the middle would be what many organizations do - distribute NTP from a core switch or other network device.
Less (least?) secure would be running a Windows server with NTP server enabled.
In all the Internet-based cases, if your trusted server is only configured to use a well-known (or few well-known) public ntp server(s) then your attack scenarios would have to be someone taking over thoise servers and targeting you (or the whole Internet) in an ntp-based attack. Most people would consider that a very unlikely scenario.
You could further lock it down by doing only authenticated ntp, however you have to register or subscribe for such services.
11-27-2018 01:24 PM
my opinion
access-list Outside-to-Inside extended permit udp any host 10.x.x.x eq ntp
however, if you know the ntp server ip address than create a object-group and match it with that.
for example.
Object-group NTP-SERVER
object-network host x.x.x.x.x
!
access-list Outside-to-Inside extended permit object-group NTP-SERVER host 10.x.x.x eq ntp
11-27-2018 06:21 PM
If the ntp requests originate from inside, you don't need the outside-to-inside acl.
The ASA is a stateful firewall and will recognize the return traffic as part of a udp flow that it has in the state table.
11-27-2018 08:14 PM
11-28-2018 04:29 AM
11-28-2018 04:35 AM
If you want to restrict the local ntp server to using one and only one public (global) ntp server then specify that public ntp server as the destination ip.
If the internal server points to an FQDN (like pool.ntp.org which resolves to multiple IP addresses) or you want to allow them to use any public ntp server without requiring further firewall ACL changes then use "any" as the destination ip.
11-28-2018 04:50 AM
11-28-2018 04:54 AM
The "any" doesn't affect who can originate traffic from outside. It only allows the trusted inside ntp server to use any public server.
Only the return flows from the public ntp servers that your trusted server has selected will be allowed from outside to inside.
11-28-2018 05:02 AM
11-28-2018 05:15 AM
Best practice varies according to your risk profile.
Ultra secure is a dedicated NTP appliance with antenna to GPS satellites. They encode precise timing and a dedicate appliance can derive NTP from that.
Anything Internet-based is less secure.
The next most secure would be a hardened Linux server running minimal services.
In the middle would be what many organizations do - distribute NTP from a core switch or other network device.
Less (least?) secure would be running a Windows server with NTP server enabled.
In all the Internet-based cases, if your trusted server is only configured to use a well-known (or few well-known) public ntp server(s) then your attack scenarios would have to be someone taking over thoise servers and targeting you (or the whole Internet) in an ntp-based attack. Most people would consider that a very unlikely scenario.
You could further lock it down by doing only authenticated ntp, however you have to register or subscribe for such services.
11-28-2018 06:08 AM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide