[ntp:hackers] -I, -L, and the new nic/interface config stuff
tglassey at earthlink.net
Tue Sep 22 16:21:16 UTC 2009
Harlan Stenn wrote:
> Once upon a time folks wanted a way to "not listen" to certain IPs
> and/or interfaces.
This is to allow systems to have multiple interfaces and only provide
service on some of them rather than ALL of them as the only option which
is a good idea. It will allow for more controls of the addresses and the
Restricting Applications as a part of Security Design
Since its possible today to restrict certain apps to specific interfaces
and addresses used, the ability to better tune the operations models for
NTP deployments is a good addition. The question is where to control
those aspects and features from - i.e. is it NTP? or the Host OS
Firewall settings? or is it both and if so what portions of the controls
are relegated to NTP and what to the Host OS FW.
By comparison most of the port restrictions and the IP address
restrictions can be done in the platform's firewall settings which are
becoming a common and key part of commercial OS's so a larger question
has to be answered as to whether any of those control features are
needed or whether the platform's FW will handle them.
If the intent is to create a reference port of NTP which replaces the OS
as a stand-alone instance then it makes total sense to have all those
controls in the NTP instance, but today I dont know of a single instance
of an NTP appliance which operates in a manner which could take
advantage of those features and the question becomes one of whether
adding those will complicate managing systems NTP is one because of the
potential for policy control loops between the Application (NTP in this
case) and the policy interfaces on the Hosting OS platform.
As to use cases we should be aware that there are instances where a NTP
service would want to be run on an external port during 'scheduled
synchronization' instances only - i.e. time windows where a policy to
test or set that client-NTP instance's TOD. The problem is that NTP has
to be kept HOT to run properly meaning it needs to be running to keep
its proper accuracy especially without a reference source and as such to
periodically reach out and touch its reference server.
So the question is how to allow a security model which supports that -
do you open the address and port 123 permanently? do you only bind and
open the address and port when the daemon reaches out to the reference
source? Why this is the question to ask is that the same Client NTP
instance may in fact also be a permanent internal NTP instance which
allows connections from systems on the approved-for-use (internal)
network as well so this would appear as a NTP instance which was only
available on one side for the external cal procedures and always
available internally for sync's of the internal systems.
A typical implementation of this would be a corporate time service
gateway which was not a posted member of the NTP Pool or public servers
list as most NTP instances are today. This would allow that NTP instance
to only be 'visible' when the external sync was happening and no other
Likewise port scanners which are used by the Evil Masses to detect open
ports could be dealt with as well. One of the possible solutions (and
BLU you will get a kick out of this) would be to use the Sun SunScreen
'invisibility' model for NTP as a possibility too.
> As I recall (and corrections are welcome)...
> We knew this was gonna be difficult to get right in the config file and
> we knew it was gonna take a while before we had a useful plan.
> In the interim we came up with two partial workarounds.
> One was -L, that said "do not listen to virtual IPs". The definition of
> a virtual IP was one that had a ':' in the name, which meant it only
> worked on Linux and Solaris boxes.
> The other was -I, that said "listen on the <arg>".
> For better or worse, with -L under this scheme we would ignore any of
> the IPs that "matched", and for -I (in ntp-stable only *one* -I flag is
> allowed) anything that doesn't match is open-read-dropped.
> Now that we are about to release code in 4.2.6 that appears to offer a
> complete mechanism to offer what seems to be adequate to implement all
> of the policy choices of listen|open-read-drop|ignore for interfaces
> and/or IPs, we find there are some corner cases that need to be
> addressed. To see the scenarios and some discussion, please visit
> https://support.ntp.org/bin/view/Dev/NtpdAndNetworkSockets (and if you
> think you have a use-case that is not covered, please add it).
> First, given that -L only worked for 2 OSes and implemented "ignore"
> policy and -I only supported one instance and implemented "drop" policy,
> is there any reason we should let folks specify the complete interface
> control mechanism on the command line?
> If not, what about completely removing the -I and -L options instead?
> Second, we need to decide what to about interfaces and IPs that are
> *not* covered by any stated directives. I see the following choices in
> the case where the first "interface" ntp.conf file contans a
> "restrictive" listen directive:
> - use 'nic drop all' before the specified 'listen' directive
> - use 'nic ignore all' before the specified 'listen' directive
> - signal an error
> My belief is that if we use either of the first two we will find vocal
> opponents of whatever choice we make and if we decide our initial
> choicee wass wrong it will be Difficult to change that default later.
> If we use the 3rd choice, we are requiring people to (try to) understand
> the issues well enough to make a good decision. Granted, we can do our
> best to document this, but hey, documentation can always be better and
> sysadmins may or may not decide to read it.
> So let's discuss...
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.409 / Virus Database: 270.13.111/2386 - Release Date: 09/21/09 05:51:00
More information about the hackers