[ntp:questions] xntp both serve and client

fenwayfool peterson.russell at gmail.com
Thu Nov 6 03:40:39 UTC 2008


On Nov 5, 4:30 pm, "Maarten Wiltink" <maar... at kittensandcats.net>
wrote:
> "fenwayfool" <peterson.russ... at gmail.com> wrote in message
>
> news:9fa0247a-eb93-4ae2-a0ac-af96cc20329f at w1g2000prk.googlegroups.com...
>
> > Is it possible to turn off xntp server functionality?
>
> Effectively, yes. Strictly, no.
>
> > 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.
>
> 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

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.




More information about the questions mailing list