Printable View
Hello,
Is it possible to turn off xntp server functionality?
That is, xntpd seems to always have port 123 open. This shows up on a
port scan even though the system I have really only requires client
functionality. Seems like I could restrict server access via the
ntp.conf file but port 123 would still be open... I don't want random
port scans to show the port as open.
On 2008-11-05, fenwayfool <peterson.russell@gmail.com> wrote:
[color=blue]
> Is it possible to turn off xntp server functionality?[/color]
No.
The only difference between an ntpd which is a "server" and an ntpd
which is a "client" is that the former replies to polls from other ntpds
(or other [s]ntp clients).
BTW: xntp is the name that was used for ntp version 3.*'; it is now
known as "ntp".
[color=blue]
> That is, xntpd seems to always have port 123 open.[/color]
ntpd binds port 123 on all interfaces. Whether or not this port is
"open" depends on your host firewall, upstream firewalls, and the ntpd
access restrictions.
[color=blue]
> This shows up on a port scan even though the system I have really only
> requires client functionality. Seems like I could restrict server
> access via the ntp.conf file but port 123 would still be open... I
> don't want random port scans to show the port as open.[/color]
Please see [url]http://support.ntp.org/Support/AccessRestrictions[/url] to learn
about setting ntpd access restrictions.
--
Steve Kostecke <kostecke@ntp.org>
NTP Public Services Project - [url]http://support.ntp.org/[/url]
fenwayfool wrote:[color=blue]
> Hello,
>
> Is it possible to turn off xntp server functionality?[/color]
As noted, the real xntpd is obsolete, although some distributors refused
to change to the new name. Historically, it started as ntpd, then got
renamed to xntpd to distinguish version 3 from the older version. It
was renamed back to ntpd for the, current, version 4.
[color=blue]
>
> That is, xntpd seems to always have port 123 open. This shows up on a[/color]
ntpd needs port 123 UDP open in order to receive the replies to its
polls, or broadcast packets.
"fenwayfool" <peterson.russell@gmail.com> wrote in message
news:9fa0247a-eb93-4ae2-a0ac-af96cc20329f@w1g2000prk.googlegroups.com...
[color=blue]
> Is it possible to turn off xntp server functionality?[/color]
Effectively, yes. Strictly, no.
[color=blue]
> That is, xntpd seems to always have port 123 open. This shows up on a
> port scan even though the system I have really only requires client
> functionality. Seems like I could restrict server access via the
> ntp.conf file but port 123 would still be open... I don't want random
> port scans to show the port as open.[/color]
It's _UDP_ port 123. UDP being stateless, if you want to hear replies
to your queries, you need to listen some of the time. The easiest way
to do that, is to listen all of the time. NTP takes that way.
If you have a very smart firewall, you could configure it to only let
the port show as open for a few seconds after a request came out of it.
Don't come asking me how to do that, though, it's way over my head.
As a benefit, NTP will provide diagnostic information when asked on
that same port. You may not care for it, but it allows for easy
checking that an NTP client is actually running well and where it's
getting its time from and so on.
Groetjes,
Maarten Wiltink
On Nov 5, 4:30*pm, "Maarten Wiltink" <maar...@kittensandcats.net>
wrote:[color=blue]
> "fenwayfool" <peterson.russ...@gmail.com> wrote in message
>
> news:9fa0247a-eb93-4ae2-a0ac-af96cc20329f@w1g2000prk.googlegroups.com...
>[color=green]
> > Is it possible to turn off xntp server functionality?[/color]
>
> Effectively, yes. Strictly, no.
>[color=green]
> > That is, xntpd seems to always have port 123 open. *This shows up on a
> > port scan even though the system I have really only requires client
> > functionality. *Seems like I could restrict server access via the
> > ntp.conf file but port 123 would still be open... I don't want random
> > port scans to show the port as open.[/color]
>
> It's _UDP_ port 123. UDP being stateless, if you want to hear replies
> to your queries, you need to listen some of the time. The easiest way
> to do that, is to listen all of the time. NTP takes that way.
>
> If you have a very smart firewall, you could configure it to only let
> the port show as open for a few seconds after a request came out of it.
> Don't come asking me how to do that, though, it's way over my head.
>
> As a benefit, NTP will provide diagnostic information when asked on
> that same port. You may not care for it, but it allows for easy
> checking that an NTP client is actually running well and where it's
> getting its time from and so on.
>
> Groetjes,
> Maarten Wiltink[/color]
Thanks for the replies everyone. The system I have is an embedded
system and the NTP software was ported (to a non-Linux OS) a while
back so I guess it was called xntp when that work was done. In this
environment, we only use NTP as a client.
I have modified the ntp.config to restrict access... but the port
still shows up on port scans. I believe this is because the UDP port
scans simply send a packet to the port number... if no reply is seen,
it is assumed the port is open. If the port is closed, an ICMP packet
is returned by the network stack. Still, restricting access is a good
thing. My problem is, customers... not me... don't like port 123
showing up as open. I suspect this is because they are thinking more
along the lines of a simple SNTP sequence that goes like:
1. open socket (using a random port > 1023 as the source port)
2. send message (port 123 is dest port)
3. wait for reply
4. close socket
Step #3 has a timeout period associated with it. True, a source port !
= 123 violates the RFC strictly speaking... but it works.
NTP seems a bit more involved. It even seems like if I configure a
server... and the code has trouble reaching the server... that it may
revert into a "listen to NTP broadcast messages" like mode??? Not
sure about that but some comments suggest it at first glance. That
would be another reason to keep port 123 open, I guess.
Anyway, I very much appreciate the responses everyone. Thanks.
[color=blue]
>ntpd needs port 123 UDP open in order to receive the replies to its
>polls, or broadcast packets.[/color]
That's the way the current code operates.
If you are running in client only mode, you don't really need
to use port 123 on the local system. It could use any port number,
but it might take a while to modify the current source code to
do that.
If you are just trying to hide from bad guys, using iptables
or whatever to only allow packets from the selected servers might work.
That gets complicated if you are using the pool.
--
These are my opinions, not necessarily my employer's. I hate spam.
On 2008-11-06, fenwayfool <peterson.russell@gmail.com> wrote:
[color=blue]
> Thanks for the replies everyone. The system I have is an embedded
> system and the NTP software was ported (to a non-Linux OS) a while
> back so I guess it was called xntp when that work was done. In this
> environment, we only use NTP as a client.[/color]
The current stable version of the NTP Reference Implementation is
4.2.4p5
[color=blue]
> I have modified the ntp.config to restrict access... but the port
> still shows up on port scans.[/color]
ntpd binds UDP port 123 on all interfaces.
The access restrictions don't change this binding.
[color=blue]
> My problem is, customers... not me... don't like port 123 showing up
> as open.[/color]
It is up to you to convince your customers that this is not a problem.
The port scan shows that ntpd is listening on 123/UDP. But the port scan
does not show that the Access Restrictions are causing ntpd to drop all
packets except those explicitly allowed.
[color=blue]
> I suspect this is because they are thinking more along the
> lines of a simple SNTP sequence that goes like:
>
> 1. open socket (using a random port > 1023 as the source port)
> 2. send message (port 123 is dest port)
> 3. wait for reply 4. close socket[/color]
ntpd is continuously disciplining the clock and, since it is
continuously running port 123/UDP is continuously bound.
[color=blue]
> Step #3 has a timeout period associated with it. True, a source port !
>= 123 violates the RFC strictly speaking... but it works.[/color]
Some time servers will not accept connections when the source port is
not 123.
[color=blue]
> NTP seems a bit more involved. It even seems like if I configure a
> server... and the code has trouble reaching the server... that it may
> revert into a "listen to NTP broadcast messages" like mode???[/color]
If you tell ntpd to poll certain servers that is what it will do.
If you tell ntpd to listen for broadcast packets that is what it will
do.
There is no facility for the sort of reversion you are suggesting.
--
Steve Kostecke <kostecke@ntp.org>
NTP Public Services Project - [url]http://support.ntp.org/[/url]
On 2008-11-06, Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote:
[color=blue]
> If you are running in client only mode, you don't really need
> to use port 123 on the local system. It could use any port number,
> but it might take a while to modify the current source code to
> do that.[/color]
The NTP port is set in ./include/ntp.h:
/*
* NTP protocol parameters. See section 3.2.6 of the specification.
*/
#define NTP_VERSION ((u_char)4) /* current version number */
#define NTP_OLDVERSION ((u_char)1) /* oldest credible version */
#define NTP_PORT 123 /* included for non-unix machines */
Changing the port that ntpd uses is trivial.
Changing ntpq/ntpdc to work with your modified ntpd is a different
story.
--
Steve Kostecke <kostecke@ntp.org>
NTP Public Services Project - [url]http://support.ntp.org/[/url]
In article <slrngh4v5j.gaf.kostecke@stasis.kostecke.net>,
Steve Kostecke <kostecke@ntp.org> writes:[color=blue]
>On 2008-11-06, fenwayfool <peterson.russell@gmail.com> wrote[/color]
[color=blue]
>Some time servers will not accept connections when the source port is
>not 123.[/color]
Which ones?
I think that would complicate debugging. For example, I couldn't run
ntpdate in user mode to compare my local clock with a servers.
--
These are my opinions, not necessarily my employer's. I hate spam.
Hal Murray wrote:
[color=blue]
> Steve Kostecke writes:
>[color=green]
>>Some time servers will not accept connections when the source port is
>>not 123.[/color]
>
> Which ones?
>
> I think that would complicate debugging. For example, I couldn't run
> ntpdate in user mode to compare my local clock with a servers.[/color]
I'm not aware of any specific servers which enforce the ntpport. But it
is a restriction.
--
Steve Kostecke <kostecke@ntp.org>
NTP Public Services Project - [url]http://support.ntp.org/[/url]
fenwayfool wrote:
[color=blue]
> NTP seems a bit more involved. It even seems like if I configure a
> server... and the code has trouble reaching the server... that it may
> revert into a "listen to NTP broadcast messages" like mode??? Not
> sure about that but some comments suggest it at first glance. That
> would be another reason to keep port 123 open, I guess.[/color]
broadcastclient mode has to be explicitly configured, but that is
something that is quite commonly done by people who are operating ntpd
in a pure client mode.
The problem with only temporarily opening the socket during a poll is
that it has to be treated as a special case which can only be enabled if
none of acting as a server, broadcastclient, or management
capabilities are in use. (A lot of pure client users also want remote
access to management statistics.)
Also there will still be a proportion of the time in which the port is
open, so it could still show up on scans.