Authenicated NTP
-
i was fully onboard until i realized access requires the requestor to furnish the following:
- Name and postal street address of the organization or individual
- Name and contact information for the system operator and an alternate name if possible. These should include the e-mail addresses and the preferred contact method.
- Network IP address of the client system that will be used to query the NIST server. A network name is desirable but not required, since the system will authenticate the request using IP addresses only. Users may request up to 4 contiguous IP addresses that will share the same key.
you can't claim tinfoil hat and then furnish a full government and USPS street address to the Feds!
all seriousness though, these patches could easily be modified to configure a private authenticated NTP provider. good stuff, OP. i agree they should be added to base install.
-
@cyberconsultants The patches are not specific to NIST's authenticated NTP service, as NIST just implements authentication per the NTP RFCs. In fact, I tested these with my own NTP server which sources time from GPS and provides authenticated NTP service. The difference is, if you control your own NTP server, you can get by with only using key ID 1 (currently hard coded in the pfSense source) whereas using NIST's (or likely anyone's) public service, you have to be able to set a different key ID.
Side note: For anyone who doesn't want to go to the trouble of sending a letter or finding a fax machine, unlike what the NIST website says, they now do the key process all via email (and their file transfer site).
-
@cyberconsultants I can tell you projects that seek to improve aging protocols (NTP) take time (no pun intended) and trusted testers. I personally had issues with NTP getting hacked and having 10-15 jumps durring college tests without use of authentication (checked with analog gear clocks). I have not had that issue once it was moved to NIST authenticated time. It's a great project that seeks to fix issues like this. So far I have not had issues with use of these services. Again I was taking cyber security tests so I would expect the class wanted to drip students toes into some of the major issues, and gage how they resolved it. For me I flat moved to authenticated time. I trust it, it works it's secure. They even renewed my keys for me. Thank you NIST. I have not had time jumps now and I pray it stays that way.
From a university network perspective, the use of authenticated NTP with NIST is an improvement over the non authenticated version. Deployment of it requires it be tested, and a GUI that is easily accessible. Again the key should be hidden from prying eyes
. It's that important. Make a new username hide the key from everyone that access the firewall important.With that thought
@stephenw10 can NTP options be specifically assigned in user manager and be blocked for others? With reflections on this GUI patch I just tested maybe it is also a good time to check with you. I do not think many admin have had the ability to use it without custom patches. Maybe the user manager does not list it yet.
@MatthewA1 maybe your GUI option should also be included in a user manager feature.
You know that song
one thing leads to another... -
https://redmine.pfsense.org/issues/15073
I just submitted a feature request for new user NTP keys privileges profile to be added. It should specifically list NTP keys so super admin can hide them from settings.
-
@JonathanLee I'm thinking maybe this should be done as part of a larger update such as this:
- The NTP key management should be it's own tab on the Services > NTP page
- New permissions are for accessing this page
- Multiple keys may be specified
- An optional field for key ID field is added to the NTP Settings page on a per server/pool/peer basis. This would let users manage what key is used with which server so that
- Different keys can be used for different servers (including no key for some servers)
- A user with permission to configure NTP servers can use the keys without actually knowing the key values
-
@MatthewA1 I couldn't agree with you more. YES
-
Are there authenticated NTP servers for public use other than the NIST ones? I wanted to test this and see what the generated ntp conf files look like, but not if the only option is to fax/snailmail a request. To be honest, it seems to me that time would be better spent implementing NTS instead.
-
@marcosm NIST actually does it completely by email now, but the website is out of date. I just got a key last week actually, and it was about a 3 day turnaround. You just email internet-time-service@nist.gov with the same information they previously wanted by mail or fax.
As far as I know, there is not anyone else (aside from one-off NTP servers) that provides authenticated NTP services, or at least not for free. NTP.org does not support it for sure. It looks like Canada's NRC does but for a significant fee. -
Did the GitHub package get merged with the updates? I saw you submitted them this morning. EPIC!!!
-
Did this github ever get merged?
847e417b5612f28bc1e84ca028a980df9c5c57a7
I can pull it in patches now
-
J JonathanLee referenced this topic on
-
@JonathanLee It has not, and I have not seen any further feedback.
I agree these aren't all the changes that it would be nice if were implemented, but it at least takes it from an almost useless feature (because you are never going to get the key ID 1 from a shared system) to something with some problems.
I'm willing to add some of the missing pieces (e.g., per server authentication) but I'm not inclined to do so if it isn't going to be reviewed. As I mentioned in the Redmine issue, if someone can tell me what the most important changes needed for this to be accepted are, I'd take care of them.
@marcosm Sure, I think NTS would be great, but for now, at least as far as I can tell, none of the major time providers support NTS, and I doubt many GPS based time systems will support it for some time (at least the lower-end systems) -
@MatthewA1 Netgate I have been told has a very small staff and strict budget, they will get to it eventually. Don't be discouraged.
-
I made an update where authentication can be enabled or disabled per server/peer (and it actually validates that you didn't enable authentication for a pool).
The latest version can be applied using the package patch using this URL if anyone wants to test:
https://github.com/pfsense/pfsense/pull/4658.diffSide note: I would like to further improve this by allowing multiple keys to be configured and then have a dropdown for each server to select the key (or no authentication), but I don't see any way to do that without making some significant changes to the config.xml format. I don't think I should go down that road without input from Netgate first though.
I think this needs to be done anyways to resolve some other issues such as:- Like @marcosm pointed out on Redmine, there are two places to configure NTP servers, but they edit the same config option while implying they are separate settings
- Disabling the NTP server from Services > NTP results in ignoring time servers set in System > General Setup, but there is no indication of that on the General Setup page
I'll add a couple more notes on this to the Redmine. I'm not sure if this should be a separate ticket or not either, but I think I don't want them in the same branch/PR for now.
-
-
@MatthewA1 Open a redline and put the patch and the GitHub into it, Netgate will see it in 2 seconds after that, I bet it will be added to the development version if you do that route.
-
-
@JonathanLee Hmm, I'm not sure what is causing that. However, I checked an unmodified pfSense CE 2.7.2 and pfSense Plus 23.09.1 and this shows up in the logs on both of those appliances after a reboot. Also interesting is that it does not occur on a service restart, only on a system reboot.
-
@MatthewA1 when I removed the patch it goes away, I think it has to do with the status page adjustments.
-
J JonathanLee referenced this topic on
-
Anybody else using authenticated NTP?
We got our config info from that very nice gentleman Judah at NIST over a year ago, and I just now--as in, an hour ago- finally found the time to get ours working right with pfSense. :) I try to be a security nut, and, from what I understand, NIST's authenticated NTP service feels like the most secure inexpensive option for time sync.
As far as how I got it configured, I really appreciate your work above, @LamaZ, as it helped me quickly find where I needed to make changes in pfSense to get it all working. Ultimately, I just ended up commenting out the code in that system_ntp_configure() function you mentioned that overwrites the NTPD .keys and .conf files, and just populated the files myself, by hand. That seemed like a pretty quick and easy way to get it working.
It definitely would be nice if the pfSense UI supported this, but in the meantime, I guess we can just keep hacking the system_ntp_configure() function whenever it's modified, to keep it from overwriting the config files.
I definitely encourage everyone who is using pfSense as their corporate firewall to get their firewall(s) set up as secure/authenticated NTP servers, though. It's just one more way to reduce would-be hackers' attack vectors, right? -
@LamaZ Folks, just upgraded to pfSense+ 24.03-RELEASE and this still works.
I fumbled and didn't quite get @MatthewA1's sweet patch method working yet. That would of carried over across the upgrade right?
