Hosting an ntp server?

[ZiaTioN]

How would I go about setting up an ntp server on my Fedora Core 1 box?

[Void Main]

I assume you really mean ntp server (so your other machines can sync their time from that server). You probably already have the ntp server installed and running if you have that machine set up to sync it's time with another server. If you do you should also have an /etc/ntp.conf file. The file is pretty well commented. For instance, if you want to give access to all of your local machines just edit that file and under the "CLIENT NETWORK" section there is an example. Say your internal network is 192.168.0.0 with a netmask of 255.255.255.0 just add this line:

Code: Select all

restrict 192.168.0.0 mask 255.255.255.0 notrust nomodify notrap


Then restart ntpd (/sbin/service ntpd restart).

That's all there is to it. Of course you have to configure your clients to use that server which can be done in the graphical tool (redhat-config-date) or by putting your server's address in your client's /etc/ntp/step-tickers file.

[ZiaTioN]

Yeah I do really mean an ntp server which is why I asked about an ntp server .

I had already configured the ntp.conf file and started the service but my windows boxes cannot sync with it for some reason.

I left all the defaults the same and changed the "CLIENT NETWORK" section to reflect my home network subnet. Is there something else I am missing?

[Void Main]

Well, the NTP server also doubles as an NTP client which is why I asked. Do you have an NTP client on your Windows boxes? I'm afraid I can't help you any more with that since I don't do Windows. My Linux clients can sync so I would have to assume that your Windows NTP client is not configured properly or is just broken (which is more usually the case). If you have it set up properly you should be able to do an "ntpdc -c sysstats yourservername" and get some stats. If it's not set up right you would get a "connection refused" message. Of course I have no idea what the Windows command would be with whatever ntp client you are using.

[ZiaTioN]

Hmm, ok my other linux boxes and MAC cannot sync to it either.

[root@localhost root]# ntpdate -u 192.168.0.100
18 Mar 23:33:56 ntpdate[25070]: no server suitable for synchronization found
[root@localhost root]# ntpdate -u 192.168.0.100
18 Mar 23:34:02 ntpdate[25071]: no server suitable for synchronization found
[root@localhost root]# ntpdate -u 192.168.0.100
18 Mar 23:34:07 ntpdate[25072]: no server suitable for synchronization found

However I can sync to the server from my client locally:

[root@Hackbox root]# ntpdate -u 127.0.0.1
18 Mar 23:32:39 ntpdate[2410]: adjust time server 127.0.0.1 offset 0.000001 sec
[root@Hackbox root]# ntpdate -u 192.168.0.100
18 Mar 23:32:51 ntpdate[2411]: adjust time server 192.168.0.100 offset 0.000002 sec
[root@Hackbox root]# ntpdate -u 192.168.0.100
18 Mar 23:33:49 ntpdate[2412]: adjust time server 192.168.0.100 offset 0.000001 sec
[root@Hackbox root]# ntpdate -u 192.168.0.100
18 Mar 23:33:56 ntpdate[2413]: adjust time server 192.168.0.100 offset 0.000002 sec

As you cans ee I can sync to the local loop interface (127.0.0.1) and the eth0 interface (192.168.0.100).

Here is what my ntp.conf file looks like:

# Prohibit general access to this service.
# restrict default ignore

# Permit all access over the loopback interface. This could
# be tightened as well, but to do so would effect some of
# the administrative functions.
restrict 127.0.0.1


# -- CLIENT NETWORK -------
# Permit systems on this network to synchronize with this
# time service. Do not permit those systems to modify the
# configuration of this service. Also, do not use those
# systems as peers for synchronization.

restrict 192.168.0.0 mask 255.255.255.0 notrust nomodify notrap


# --- OUR TIMESERVERS -----
# or remove the default restrict line
# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.

restrict 192.43.244.18 mask 255.255.255.255 nomodify notrap noquery
restrict clock.redhat.com mask 255.255.255.255 nomodify notrap noquery
restrict clock2.redhat.com mask 255.255.255.255 nomodify notrap noquery
restrict time.cachenetworks.com mask 255.255.255.255 nomodify notrap noquery
restrict louie.udel.edu mask 255.255.255.255 nomodify notrap noquery
restrict ntp.ourconcord.net mask 255.255.255.255 nomodify notrap noquery
restrict clock.nyc.he.net mask 255.255.255.255 nomodify notrap noquery
server 192.43.244.18
server clock.redhat.com
server clock2.redhat.com
server time.cachenetworks.com
server louie.udel.edu
server ntp.ourconcord.net
server clock.nyc.he.net



# --- NTP MULTICASTCLIENT ---
#multicastclient # listen on default 224.0.1.1
# restrict 224.0.1.1 mask 255.255.255.255 notrust nomodify notrap
# restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap



# --- GENERAL CONFIGURATION ---
#
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available. The
# default stratum is usually 3, but in this case we elect to use stratum
# 0. Since the server line does not have the prefer keyword, this driver
# is never used for synchronization, unless no other other
# synchronization source is available. In case the local host is
# controlled by some external source, such as an external oscillator or
# another protocol, the prefer keyword would cause the local host to
# disregard all other synchronization sources, unless the kernel
# modifications are in use and declare an unsynchronized condition.
#
server 66.187.233.4
fudge 127.127.1.0 stratum 10

#
# Drift file. Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
#
driftfile /etc/ntp/drift
broadcastdelay 0.008

#
# Authentication delay. If you use, or plan to use someday, the
# authentication facility you should make the programs in the auth_stuff
# directory and figure out what this number should be on your machine.
#
authenticate yes

#
# Keys file. If you want to diddle your server at run time, make a
# keys file (mode 600 for sure) and define the key number to be
# used for making requests.
#
# PLEASE DO NOT USE THE DEFAULT VALUES HERE. Pick your own, or remote
# systems might be able to reset your clock at will. Note also that
# ntpd is started with a -A flag, disabling authentication, that
# will have to be removed as well.
#
keys /etc/ntp/keys

I have checked some status and everything appears to be good:

[root@Hackbox root]# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*time.nist.gov .ACTS. 1 u 21 128 77 69.165 -7.639 0.622
clock.redhat.co 0.0.0.0 16 u - 64 0 0.000 0.000 4000.00
-clock.redhat.co .CDMA. 1 u 24 128 377 94.115 -13.909 0.621
-clock2.redhat.c .CDMA. 1 u 36 64 377 94.445 -5.937 1.052
-ns1.anycast.cac Tick.UH.EDU 2 u 33 128 377 91.214 -11.160 0.580
+louie.udel.edu ntp1.nss.udel.e 2 u 27 128 377 116.046 -8.276 0.466
+ourconcord.net NAVOBS1.MIT.EDU 2 u 34 128 377 127.577 -6.881 4.061
-avi-lis.gw.ligh .CDMA. 1 u 25 128 377 116.661 -0.672 0.949

Any ideas from here?

[Void Main]

Mine is 100% default except for the 1 line I put in to allow my local subnet. I don't have any servers defined in the ntp.conf. Those get defined in the /etc/ntp/step-tickers file which I only have two servers defined "clock.redhat.com" and "ntp.tuxfamily.net" (that is the step-tickers file on the server). On the client I just have my server's address in the step-tickers file. Here is my ntp.conf and step-tickers from the server:

http://voidmain.is-a-geek.net/files/ntp/

I make sure the ntpd on the server has been started:

# /sbin/service ntpd restart

I make sure the ntpd is off on the client:

# /sbin/service ntpd stop

I do an ntpdate command:

# /sbin/ntpdate -b -p 8 192.168.0.110

and it does this:

Code: Select all

19 Mar 06:59:03 ntpdate[11931]: step time server 192.168.0.110 offset 0.035313 sec


If your ntpd is a stock/default install with the exception of those minor changes and it does not work then I would have to guess some sort of personal firewall is getting in the way. Maybe you should do a sniff (run ethereal on both ends and see where the failure is). I ran a sniff and have NTP conversation going on between server and client with no problem. Also if you changed any of the other files in /etc/ntp you might want to remove the ntp RPM and that directory and the ntp.conf and reinstall the RPM so you have a clean install. Of course the first thing you should do is look for ntp error messages in your /var/log/messages file.

[ZiaTioN]

Yeah there is an issue somewhere because I mirrored your exact setup and got the same indications. No client will sink with the server. I scan the server with nmap using the -sU flag for syn UDP and I see port 123 open but no go on any client.

[Void Main]

What are the IP ranges of your server and clients?

[ZiaTioN]

They are all in the 192.168.0.0/24 subnet.

The server is 192.168.0.100/24 and the clients are 192.168.0.6/24 and 192.168.0.2/24 (the MAC and my other Linux box). My Windows boxes are 192.168.0.3-5/24.

[Void Main]

Are you running iptables on the server and/or clients or any other firewall software? What are the error messages in the logs on those sides? What does a "netstat -a | grep ntp" show on the server?

[ZiaTioN]

[root@Hackbox root]# netstat -a | grep ntp
udp 0 0 192.168.0.100:ntp *:*
udp 0 0 localhost.localdoma:ntp *:*
udp 0 0 *:ntp *:*

As far as iptables I am basically just running the defaults I chose when installing the OS. I only opened ports for https, ssh, ftp and that was it. Sad to say I am not too familair with ipchains and or tables yet. I have a hardware firewall so I guess that has made me a little lax or lazy when it comes to the desktop level.

I assume it is the firewall but need to read up on ipchains to create a rule for the ntp I think.

As for the error logs, everything looks on the up-and-up:

Mar 21 00:59:00 localhost ntpd: succeeded
Mar 21 00:59:01 localhost last message repeated 6 times
Mar 21 00:59:01 localhost ntpd[3918]: ntpd exiting on signal 15
Mar 21 00:59:01 localhost ntpd: ntpd shutdown succeeded
Mar 21 00:59:01 localhost ntpd: succeeded
Mar 21 00:59:02 localhost last message repeated 6 times
Mar 21 00:59:04 localhost ntpdate[5294]: step time server 192.43.244.18 offset -0.032744 sec
Mar 21 00:59:04 localhost ntpd: succeeded
Mar 21 00:59:04 localhost ntpd[5298]: ntpd 4.1.1c-rc1@1.836 Thu Feb 13 12:17:19 EST 2003 (1)
Mar 21 00:59:04 localhost ntpd: ntpd startup succeeded
Mar 21 00:59:04 localhost ntpd[5298]: precision = 21 usec
Mar 21 00:59:04 localhost ntpd[5298]: kernel time discipline status 0040
Mar 21 00:59:04 localhost ntpd[5298]: frequency initialized -77.965 from /etc/ntp/drift

Any guidance on setting up the firewall to allow incoming connections? One thing that struck me was that, like I said an nmap port scan returned an "open" status on UDP port 123 and this usually indicates no firewall intervention on that port. Usually if it is firewalled it will return a "filtered" state.

Here I have 2 seperate port scans, one with some detailed arguments and the other a pretty basic UDP scan and thewy both return the same results:

[root@Hackbox root]# nmap -sU -P0 -vv -g 53 192.168.0.100

Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2004-03-21 01:06 PST
Host 192.168.0.100 appears to be up ... good.
Initiating UDP Scan against 192.168.0.100 at 01:06
The UDP Scan took 7 seconds to scan 1478 ports.
Adding open port 111/udp
Adding open port 32768/udp
Adding open port 137/udp
Adding open port 989/udp
Adding open port 138/udp
Adding open port 123/udp
Interesting ports on 192.168.0.100:
(The 1472 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
111/udp open rpcbind
123/udp open ntp
137/udp open netbios-ns
138/udp open netbios-dgm
989/udp open unknown
32768/udp open omad

Nmap run completed -- 1 IP address (1 host up) scanned in 7.246 seconds
[root@Hackbox root]# nmap -sU 192.168.0.100

Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2004-03-21 01:07 PST
Interesting ports on 192.168.0.100:
(The 1472 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
111/udp open rpcbind
123/udp open ntp
137/udp open netbios-ns
138/udp open netbios-dgm
989/udp open unknown
32768/udp open omad

Nmap run completed -- 1 IP address (1 host up) scanned in 5.627 seconds

[Void Main]

As a test, turn off iptables on both server and client to see if that solves your problem:

# service iptables stop

If you ran the nmap from your client to your server (Hackbox being your client and not your server) and you can see port 123 open on it then it actually looks like it should work. You don't have any ntp error messages in your client log?

And again, I would fire up Ethereal on both ends and see where the ntp conversation fails.

[ZiaTioN]

Yep, it looks like it is an iptables issue.

[root@localhost root]# service iptables stop
Flushing all chains: [ OK ]
Removing user defined chains: [ OK ]
Resetting built-in chains to the default ACCEPT policy: [ OK ]
[root@localhost root]# ntpdate 192.168.0.100
21 Mar 10:26:46 ntpdate[7495]: step time server 192.168.0.100 offset 22.773386 sec
[root@localhost root]# ntpdate 192.168.0.100
21 Mar 10:26:52 ntpdate[7496]: adjust time server 192.168.0.100 offset 0.000094 sec
[root@localhost root]# ntpdate 192.168.0.100
21 Mar 10:28:01 ntpdate[7497]: no server suitable for synchronization found

Server:

[root@Hackbox root]# service iptables stop
Flushing all chains: [ OK ]
Removing user defined chains: [ OK ]
Resetting built-in chains to the default ACCEPT policy: [ OK ]
[root@Hackbox root]# service iptables start
Flushing all current rules and user defined chains: [ OK ]
Clearing all current rules and user defined chains: [ OK ]
Applying iptables firewall rules: [ OK ]

You can see on the client that when I stopped the service it synced up 2 times but when I went back to the server and restarted iptables it would not sync from the client the third time.

I even got my Windows box to sync to it when it was stopped. How would I add a rule to iptables to allow connections from my local network?

[ZiaTioN]

Ok I tried adding a rule to my ipchains by issuing the following:

iptables -A INPUT -p udp -s 192.168.0.0/24 --sport 123 --dport 123 -j ACCEPT

and:

iptables -A OUTPUT -p udp -d 192.168.0.0/24 --sport 123 --dport 123 -j ACCEPT

I then try to sync from my client and get rejected. I try to restart my iptables but then my new rules get flushed and are not there anymore.

[Void Main]

I personally don't run iptables on my clients on my inside network. I have a dedicated Linux box for my firewall with a DMZ and do all the firewall rules on that machine. I don't see the need to mess with it on the inside machines:

# chkconfig iptables off
# service iptables stop

But if you want to continue to run it you should only have to set the rules on your server. Don't forget to save them once you get it working the way you want:

# service iptables save

This is supposed to work:

Code: Select all

/sbin/iptables -A INPUT -p udp --dport 123 -j ACCEPT
/sbin/iptables -A OUTPUT -p udp --sport 123 -j ACCEPT


If it does you can then restrict it down by adding your IP range to it.