1

So I have an ethernet point to point connection from my PC to a device running NTP on UDP port 123. This is what nmap shows:

root@kali:~# nmap -sU mydevice
PORT    STATE         SERVICE
123/udp open|filtered ntp

Now when i start ntp and check its status this is what I'm getting:

root@kali:~# sudo service ntp start
root@kali:~# sudo service ntp status
● ntp.service - Network Time Service
   Loaded: loaded (/lib/systemd/system/ntp.service; disabled; vendor preset: disabled)
   Active: active (running) since Fri 2019-12-06 10:31:22 CET; 1s ago
     Docs: man:ntpd(8)
  Process: 4203 ExecStart=/usr/lib/ntp/ntp-systemd-wrapper (code=exited, status=0/SUCCESS)
 Main PID: 4209 (ntpd)
    Tasks: 2 (limit: 4915)
   Memory: 2.2M
   CGroup: /system.slice/ntp.service
           └─4209 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 105:111

Dec 06 10:31:22 kali ntpd[4209]: Listen normally on 2 lo 127.0.0.1:123
Dec 06 10:31:22 kali ntpd[4209]: Listen normally on 3 eth0 10.96.104.97:123
Dec 06 10:31:22 kali ntpd[4209]: Listen normally on 4 wlan0 192.168.1.126:123
Dec 06 10:31:22 kali ntpd[4209]: Listen normally on 5 lo [::1]:123
Dec 06 10:31:22 kali ntpd[4209]: Listen normally on 6 eth0 [fe80::868a:75a:e3ad:2cbc%2]:123
Dec 06 10:31:22 kali ntpd[4209]: Listen normally on 7 wlan0 [fe80::cbd2:c686:502d:d0d0%3]:123
Dec 06 10:31:22 kali ntpd[4209]: Listening on routing socket on fd #24 for interface updates
Dec 06 10:31:22 kali ntpd[4209]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Dec 06 10:31:22 kali ntpd[4209]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Dec 06 10:31:23 kali ntpd[4209]: Soliciting pool server 162.159.200.123

And this is the response from ntpq -npcrv

root@kali:~# ntpq -npcrv
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.96.104.98    .STEP.          16 u    -   64    0    0.000    0.000   0.000
 0.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 1.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 2.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 3.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
*83.168.200.199  192.36.143.130   2 u   76   64    1    3.652   -0.742   0.646
 193.182.111.143 194.58.202.20    2 u   40   64    1    2.206   -0.768   4.768
-213.199.225.30  212.160.106.226  2 u   46   64    3   44.320    0.156   4.717
+213.251.52.202  195.66.241.10    2 u   11   64    3   19.966   -1.813   1.371
-109.201.133.100 151.80.124.104   3 u   44   64    3   31.114    1.118   0.964
+147.78.228.41   193.11.166.36    2 u   11   64    3    3.708   -1.263   0.946
 193.182.111.14  192.36.143.130   2 u   40   64    1    2.196   -0.488   0.677
+193.182.111.13  194.58.202.20    2 u   47   64    3    2.062   -1.249   4.331
+27.124.125.250  85.199.214.98    2 u   45   64    3   31.547   -1.261   1.389
 218.186.3.36    .GPS.            1 u   38   64    1  307.278   37.465  11.156
 162.159.200.1   10.128.8.119     3 u   41   64    1    1.660   -0.669   0.295
+62.201.225.9    62.201.214.162   2 u   45   64    3   84.179   -1.641   0.768
-45.231.168.6    23.31.21.163     3 u   46   64    3  170.302  -27.169   0.945
 193.182.111.141 194.58.202.20    2 u   42   64    1    2.567   -0.554   2.066
 102.130.49.223  85.199.214.98    2 u   42   64    1  186.493   -1.765   0.277
 176.9.241.107   130.149.17.8     2 u   40   64    1   36.654   -0.853   0.272

associd=0 status=0618 leap_none, sync_ntp, 1 event, no_sys_peer,
version="ntpd 4.2.8p13@1.3847-o (1)", processor="x86_64",
system="Linux/5.3.0-kali2-amd64", leap=00, stratum=3, precision=-22,
rootdelay=4.995, rootdisp=219.827, refid=83.168.200.199,
reftime=e19b727a.eb1b269c  Wed, Dec 11 2019 14:49:46.918,
clock=e19b72c6.3c2e95c2  Wed, Dec 11 2019 14:51:02.235, peer=1791, tc=6,
mintc=3, offset=-1.425931, frequency=-5.187, sys_jitter=0.437287,
clk_jitter=0.668, clk_wander=0.017, tai=37, leapsec=201701010000,
expire=202006280000

It says Listen Normally on 3 eth0, which is my remote device.b Now with wireshark I can see incoming and outgoing NTP packets to/from this host.

Wireshark trace

EDIT: This is a google drive folder containing, screenshots of two requests, one client and one server, aswell as the complete .pcap from wireshark: https://drive.google.com/drive/folders/1PbvjJugtpRJKN0YrvX5VbI9iJfnJxdYH

So far so good, there seems to be NTP communication between my PC and the device.

However, when I try to ntp query the device:

root@kali:~# ntpdate -q mydevice
29 Nov 12:59:17 ntpdate[9599]: no server suitable for synchronization found
root@kali:~# ntpq -p mydevice
10.96.104.98: timed out, nothing received
***Request timed out

Why am I unable to manually query the remote host, when my wireshark clearly shows me that I'm having "automatic ntp communications" with it? Is it because the remote host is only running a ntp client and not a ntp server? If so, what kinda ntpq commands can I use to communicate with it?

Sam
  • 11
  • 3
  • The mydevice is probably filtered, as indicated in nmap : "open|filtered". UDP can not make a difference as no packet will be send back if filtered. So check the firewalls – Dom Dec 05 '19 at 10:15
  • @Dom thanks for the reply, that was also my first thought, but I'm a bit dumbstruck since Wireshark shows me that I'm having NTP communications with the device, so some things are going through, I just dont know how to make sense of it – Sam Dec 05 '19 at 10:42
  • Could you add the Wireshark traces to your question then ? – Dom Dec 05 '19 at 13:43
  • @Dom I added some more information, such as the ntp status and a wireshark trace(however I'm not allowed to embed pictures at the moment). To me it seems like the remote host i.e 10.96.104.98 is only running a client, would you agree? If so, what kind of ntpq commands can I use to communicate with this device? – Sam Dec 06 '19 at 09:40
  • Do you have administrative access to 10.96.104.98? If so, please post the output of `ntpq -npcrv` (or the equivalent if it's a different NTP implementation) from both that system and your client. Also a copy of the configuration files using `grep '^[^#]' /etc/ntp.conf` (or the equivalent if it's a different NTP implementation). – Paul Gear Dec 07 '19 at 06:03
  • @PaulGear I don't have administrate access unfortunately. I updated the original post so that it shows the response from ntpq -npcrv. Is it possible the other device blocks ntp queries? As I see it from my wireshark trace, the other device only acts as a client in that communication. – Sam Dec 11 '19 at 13:51
  • @Sam It seems from your `ntpq` output that you have good connectivity to all of your other configured hosts, and since you are seeing reply packets in your wireshark trace, the remote host is not blocking your packets. If you can save the wireshark trace as a binary pcap and post it somewhere, we could analyse in more detail. Or even a screenshot of wireshark's bottom panel with the NTP fields expanded and one of the replies selected might do. – Paul Gear Dec 12 '19 at 03:24
  • @PaulGear I've added a link to a gdrive folder containing a screenshot of the first client ntp request sent from the device to me, and the server response from me to the device, named client.png and server.png respectively. I also added the .pcap file for the 15 or so first NTP packets sent after connection. – Sam Dec 12 '19 at 09:09

1 Answers1

1

Based on your packet capture, the local clock of 10.96.104.98 was set to 1 Jan 1997 00:00 when you started NTP. For the first 4 polls, the clock was still set to that time, which would mean that you weren't synchronised (because the offset was too large). By the time of the 5th poll, 10.96.104.98 had changed its clock to the right time, and by the 6th poll it was showing 10.96.104.97 as its reference clock.

The ntpq -npcrv output you captured was showing a maximum of 3 successful polls to any time server. So that suggests the output was captured before the 5th poll. If you try it again now (or any time after that 6th poll), it should show successful synchronisation.

Please note that if you don't control 10.96.104.97, it's normal for it to refuse to respond to ntpq -p, and ntpdate wouldn't have selected it because your time was too far out.

Double check that your ntpd is being started with the -g or -G flags so that it sets the clock correctly on initial startup.

Paul Gear
  • 4,367
  • 19
  • 38