PIX as an NTP server for inside network(s)

[bsisco]

I currently have my PIX receiving NTP from an trusted outside source. I would like to set my switches to pick up their time from the PIX. I don't see anywhere that this is possible. I have tried using my inside interface as the source server for the clients, but they never receive the NTP messages and remain unsynchronized.

Our PIX's are the common internal points for each of our offices (they create our web of office connections via internet VPN tunnels) and are the logical choice to ditribute NTP traffic throughout our org.

Can anyone answer for sure that PIX's will act as NTP servers when called upon by clients configured for instance:

NTP server (PIX1_IP) source insside

This works when PIX1_IP is actually any other(non-PIX) internal NTP source.

[thisisshanky · Accepted solution]

For security reasons, PIX is only a NTP client. It cannot be a NTP server and responding to queries from NTP clients. PIX does not respond to NTP queries. If you turn logging on the PIX you can see a syslog message

%PIX-3-610001: NTP daemon interface int_name: Packet denied from

IP_addr

OR similar.

Hope that helps!

[bsisco]

Well, it's not the answer I was hoping for (although it is the answer I expected :o)

I haven't spent much time with NTP security either on the server side or client side. Aside from knowing the requirements for certain versions (which I feel probably plays a part here) I don't yet have a solid grasp of why it would be less secure as a client than a server as most clients just listen which makes them susceptible to false messages, but I'm willing to deal with it :)

Thanks for the great post thisisshanky!

[mostiguy]

server side means that you have a service/daemon running 24x7 with an open port - this fundamentally introduces more risk

historically, ntp daemons have been horrific security wise. There also are tons of variations on the standard protocols, so implemented all of these = complexity = more chances for bugs = a possible explanation for the terrible history of ntp daemons historically. Also, ntp supports multiple master servers (in the client server model), and using them to account for drift, etc, so again, more complexity.

http://www.eecis.udel.edu/~mills/ntp.html

will give you an idea of the complexity of all the variations of ntp that have been around