Is limiting LAN access to NTP Pool even possible?
-
Is there a practical way to restrict LAN devices to only access time servers on the WAN that are in the Network Time Protocol server pool? (pool.ntp.org)
I recognize that pool.ntp.org hands out random addresses from a list of hundreds of servers, and the list keeps changing, so trying to make a LAN to WAN firewall exception list that spans all of them, and stays up to date, is either impossible or very high maintenance.
But, if I merely enable "Any LAN port/address to port 123 / any-address"
… I might as well just turn off the organizational firewall that tries to force everyone to access the web through a proxy filter.
With such a permissive rule in place, anyone could set up a port 123 remote desktop or proxy bypass, or Tor onion router, or whatever...
I suppose one way to handle this is to only enable unrestricted NTP pool access for pfSense itself, and then only permit the LAN devices to get NTP sync updates from pfSense.
-
Might as well turn off your firewall? Little bit of an exaggeration ;)
Just so you know - you prob have users bouncing off your proxy to their home openvpn server to bypass your restrictions ;)
But yeah I would say that providing your own time service would be a good idea! What kind of org is it that would not have their own times services. If your running AD its pretty much a requirement that your DCs are going to provide time sync to members.
-
Public schools are required to filter, for CIPA compliance, to get e-Rate federal funding, acting in loco parentis.
I really don't have much control over this requirement, but I have try to comply as much as possible.
I can really only leave it to the filtering provider to deal with people VPN'ing through them.
But yes, I see what you mean. So really, just need to allow open NTP access from the domain controllers and servers.
-
Something is trying really hard to get the time from Apple.
NetRange 17.0.0.0 - 17.255.255.255
CIDR 17.0.0.0/8
Name APPLE-WWNET
Organization Apple Inc. (APPLEC-1-Z)block
Mar 23 06:13:03 LAN 10.0.8.69:65498 17.171.4.15:123 UDP
block
Mar 23 06:13:08 LAN 10.0.8.69:65498 17.171.4.33:123 UDP
block
Mar 23 06:13:13 LAN 10.0.8.69:65498 17.171.4.34:123 UDP
block
Mar 23 06:13:18 LAN 10.0.8.69:65498 17.171.4.35:123 UDP
block
Mar 23 06:13:23 LAN 10.0.8.69:65498 17.171.4.36:123 UDP
block
Mar 23 06:13:28 LAN 10.0.8.69:65498 17.171.4.37:123 UDP
block
Mar 23 06:13:33 LAN 10.0.8.69:65498 17.151.16.12:123 UDP
block
Mar 23 06:13:38 LAN 10.0.8.69:65498 17.151.16.14:123 UDP
block
Mar 23 06:13:43 LAN 10.0.8.69:65498 17.151.16.20:123 UDP
block
Mar 23 06:13:48 LAN 10.0.8.69:65498 17.151.16.21:123 UDP
block
Mar 23 06:13:53 LAN 10.0.8.69:65498 17.151.16.22:123 UDP
block
Mar 23 06:13:58 LAN 10.0.8.69:65498 17.151.16.23:123 UDP
block
Mar 23 06:14:03 LAN 10.0.8.69:65498 17.151.16.38:123 UDP
block
Mar 23 06:14:08 LAN 10.0.8.69:65498 17.171.4.13:123 UDP
block
Mar 23 06:14:13 LAN 10.0.8.69:65498 17.171.4.14:123 UDP
block
Mar 23 06:14:18 LAN 10.0.8.69:65498 17.171.4.33:123 UDP
block
Mar 23 06:14:23 LAN 10.0.8.69:65498 17.171.4.34:123 UDP
block
Mar 23 06:14:28 LAN 10.0.8.69:65498 17.171.4.35:123 UDP
block
Mar 23 06:14:33 LAN 10.0.8.69:65498 17.171.4.36:123 UDP
block
Mar 23 06:14:38 LAN 10.0.8.69:65498 17.171.4.37:123 UDP
block
Mar 23 06:14:43 LAN 10.0.8.69:65498 17.151.16.12:123 UDP
block
Mar 23 06:14:48 LAN 10.0.8.69:65498 17.151.16.14:123 UDP
block
Mar 23 06:14:53 LAN 10.0.8.69:65498 17.151.16.20:123 UDP
block
Mar 23 06:14:58 LAN 10.0.8.69:65498 17.151.16.21:123 UDP
block
Mar 23 06:15:03 LAN 10.0.8.69:65498 17.151.16.22:123 UDP
block
Mar 23 06:15:08 LAN 10.0.8.69:65498 17.151.16.23:123 UDP
block
Mar 23 06:15:13 LAN 10.0.8.69:65498 17.151.16.38:123 UDP
block
Mar 23 06:15:18 LAN 10.0.8.69:65498 17.171.4.13:123 UDP
block
Mar 23 06:15:23 LAN 10.0.8.69:65498 17.171.4.14:123 UDP
block
Mar 23 06:15:28 LAN 10.0.8.69:65498 17.171.4.15:123 UDPSTOPPIT. THWAP!
.
-
yeah
;; ANSWER SECTION:
15.4.171.17.in-addr.arpa. 1832 IN PTR time.apple.com.
15.4.171.17.in-addr.arpa. 1832 IN PTR time3-st1.apple.com.I would look to see what box that is, and correct it to use your local ntp. If your org is running AD - there is a whole process for setting authoritative time source in your AD structure - only that source would need to get out to other time sources. And does not have to be pool, I would check into what they are are using and only allow that. I would think if org big enough they have an their network a stratum 1 time source to use vs over the internet. But over the internet lock it down to the few different servers they are setup for.
-
The more evil answer is to make time.apple.com resolve to your local NTP server via DNS overrides… :-)
-
Lots of Apple devices go out to time.apple.com, especially the WAPs and their servers by default. You can change this in the device / server settings.
As others have pointed out, you can set up your own internal NTP server and create a firewall rule that only allows that time server access through port 123 to sync itself with the rest of the planet.
I love the DNS resolution idea. I do the same thing. It's easier than editing a host file. You could route pool.ntp.org to your internal time server so you don't have to go around and edit every device. So your time server will essentially function as a time proxy server or a time relay server.
-
You could route pool.ntp.org to your internal time server so you don't have to go around and edit every device. So your time server will essentially function as a time proxy server or a time relay server.
Actually this would be my first choice (i.e. redirecting all 123/UDP traffic to 127.0.0.1), however I haven't tested it extensively to see if it might create issues …
-
Well you can not set dns to point to 127.0.0.1 –- because the client would then ask itself. Just point it to the lan IP of your ntp (pfsense) server.
-
You may also be able to use NAT on the LAN interface to redirect all outbound traffic to 123/UDP to your pfSense's LAN interface, with it running an NTP server - much like it's done for a transparent web proxy.
That saves messing with DNS ;)
-
Well you can not set dns to point to 127.0.0.1 –- because the client would then ask itself. Just point it to the lan IP of your ntp (pfsense) server.
I meant what Cry Havok described … I've done this for DNS traffic in the past.
-
Actually this would be my first choice (i.e. redirecting all 123/UDP traffic to 127.0.0.1), however I haven't tested it extensively to see if it might create issues …
works pretty good… i found an article at http://www.interspective.net/2012/07/pfsense-ntp-and-network-sneakery.html#more, i've done just like that… i'm using a single server, clock.nyc.he.net
