f



Query NTP server in container (docker/NAT)

For my home LAN, I'm running a ntpd server which uses the NTP pool service =
(thanks for it by the way!!), and I'm using this local NTP server for my ot=
her devices on the LAN.

I want to improve the containment of my ntpd server. Instead of chrooting i=
t, I decided to use Docker. Everything works fine but I cannot monitor the =
server anymore (timeout). I suspect NAT/masquerading to be the problem.

So is my monitoring time-outing just because the client is on a different s=
ubnet than the server (due to NAT)? If yes, how can I solve that?


**Some background/context**:

For monitoring I used collectd (https://collectd.org/) and the ntpd plugin.=
 Basically it calls something equivalent to 'ntpdc -c kerninfo <host>' and =
a few other queries. When ntpd was running on the host directly, this used =
to work fine. However when running inside the container the same ntpd versi=
on using the same ntpd configuration (with just updated IPs for restrict st=
atements) fails due to timeout. Strangely everything else works as expected=
 (ntpdate or ntpq from the LAN works when using the containerised ntpd serv=
er), but not when using the above ntpdc command.

I've tested it inside the container with some reasonable restrict statement=
s and also without any. But in both cases I timeout. Running tcpdump in the=
 container shows that the UDP packet arrives, but nothing is answered. Of c=
ourse, using tcpdump I see both request and response when using ntpq which =
is working.

If I run the ntpd server on the host directly, using the same ntp.conf file=
, the 'ntpdc -c kerninfo <host>' succeed from the host and other computers =
on the LAN I authorised!

So the only difference is the Docker networking (NAT/masquerading as far as=
 I understood). I've set it up that the UDP port 123 is forwarded. But the =
ntp.org documentation does not mention anything really about NAT/masqueradi=
ng in combination with querying.

Note: my container image is based on ubuntu:16.04 which runs ntpd 4.2.8p4@1=
..3265-o (from the Ubuntu official repositories). The host runs Ubuntu 16.04=
 as well. Amd I also did run the ntpd inside the container with the -ddd op=
tion to get a more verbose output. The only relevant data that were logged =
are:

read_network_packet: fd=3D19 length 192 from 192.168.1.3
receive: at 26 172.17.0.2<-192.168.1.3 flags 19 restrict 000

(the address 172.17.0.2 is the one inside the container where the ntpd serv=
er is running; the address 192.168.1.3 is on my LAN)
0
Huygens
11/2/2016 11:02:29 AM
comp.protocols.time.ntp 4895 articles. 2 followers. Post Follow

5 Replies
141 Views

Similar Articles

[PageSpeed] 25

On Wednesday, November 2, 2016 at 12:02:30 PM UTC+1, Huygens wrote:
>=20
> Note: my container image is based on ubuntu:16.04 which runs ntpd 4.2.8p4=
@1.3265-o (from the Ubuntu official repositories). The host runs Ubuntu 16.=
04 as well. Amd I also did run the ntpd inside the container with the -ddd =
option to get a more verbose output. The only relevant data that were logge=
d are:

There is an error in my statement, actually the host is still running Ubunt=
u 14.04, I forgot to upgrade it. So there is another difference which is th=
e ntp version. On the host this is ntp 4.2.6p5 whereas on the container it =
is 4.2.8p4.

I've quickly modified my Dockerfile to be based on Ubuntu 14.04 instead of =
16.04, and now both collectd and my ntpdc commands work. I did a test using=
 Debian Jessie for the container and it is working too (also version 4.2.6p=
5). But when I selected Ubuntu 16.10 and Debian Stretch, both based on 4.2.=
8p8, I ended up with the same error (timeout) as described originally.

So it seems that NAT is not the culprit. But that between ntpd 4.2.6 and 4.=
2.8 something has changed. Is it a bug or feature?
0
Huygens
11/2/2016 9:52:33 PM
On 2016-11-02, Huygens <jcberthon@gmail.com> wrote:
> I've quickly modified my Dockerfile to be based on Ubuntu 14.04
> instead of 16.04, and now both collectd and my ntpdc commands work. I
> did a test using Debian Jessie for the container and it is working too
> (also version 4.2.6p5). But when I selected Ubuntu 16.10 and Debian
> Stretch, both based on 4.2.8p8, I ended up with the same error
> (timeout) as described originally.
>
> So it seems that NAT is not the culprit. But that between ntpd 4.2.6
> and 4.2.8 something has changed. Is it a bug or feature?

The ntpdc protocol is disabled in 4.2.8 by default. You can enable it
with "enable mode7" in ntp.conf, but be careful to restrict it to your
private network, as it can be exploited for DDoS attacks.

-- 
Miroslav Lichvar
0
Miroslav
11/3/2016 7:50:33 AM
On Thursday, November 3, 2016 at 8:50:34 AM UTC+1, Miroslav Lichvar wrote:
> The ntpdc protocol is disabled in 4.2.8 by default. You can enable it
> with "enable mode7" in ntp.conf, but be careful to restrict it to your
> private network, as it can be exploited for DDoS attacks.

Hi Miroslav and thank you for your feedback.

Indeed, setting mode7 in the config file solved my problem. I've found an issue now in collectd to update their plugin (https://github.com/collectd/collectd/issues/932). So I hope they will fix it soon.

One last question. How can I be sure that mode7 is restricted? Which of the "no*" terms restrict the access to mode7?

I have this default restrict for both IPv4 and IPv6:
"default kod notrap nomodify nopeer noquery limited"
0
Huygens
11/3/2016 8:32:08 AM
On 2016-11-03, Huygens <jcberthon@gmail.com> wrote:
> One last question. How can I be sure that mode7 is restricted? Which
> of the "no*" terms restrict the access to mode7?

It's the same as with the mode6 (ntpq) packets - noquery.

> I have this default restrict for both IPv4 and IPv6:
> "default kod notrap nomodify nopeer noquery limited"

That looks good.

-- 
Miroslav Lichvar
0
Miroslav
11/3/2016 9:10:26 AM
On Thursday, November 3, 2016 at 10:10:27 AM UTC+1, Miroslav Lichvar wrote:
> On 2016-11-03, Huygens wrote:
> > One last question. How can I be sure that mode7 is restricted? Which
> > of the "no*" terms restrict the access to mode7?
> 
> It's the same as with the mode6 (ntpq) packets - noquery.
> 
> > I have this default restrict for both IPv4 and IPv6:
> > "default kod notrap nomodify nopeer noquery limited"
> 
> That looks good.

Thank you very much Miroslav for your support :-) problem solved.

0
Huygens
11/3/2016 9:36:45 AM
Reply: