Categories
Computers Debian English Linux Networking

ntp running in chroot stopped working after Debian Stretch upgrade

Today I upgraded my root server from Jessie to Stretch, and suddenly ntp stopped working.

I found errors like follows in the log, which were obviously due to failures in name resolution:

2018-05-31T07:44:48.900756+00:00 myhost ntpd[22855]: giving up resolving host 1.debian.pool.ntp.org: Servname not supported for ai_socktype (-8)

The solution to make this work was to bind-mount some files and directories essential for name resolution into the chroot jail.

First create some directories and some dummy files:

# mkdir /var/lib/ntp/etc /var/lib/ntp/lib /var/lib/ntp/proc
# mkdir /var/lib/ntp/usr /var/lib/ntp/usr/lib
# touch /var/lib/ntp/etc/resolv.conf /var/lib/ntp/etc/services

Then update your /etc/fstab as follows:

...
#ntpd chroot mounts
/etc/resolv.conf  /var/lib/ntp/etc/resolv.conf none bind 0 0
/etc/services	  /var/lib/ntp/etc/services none bind 0 0
/lib		  /var/lib/ntp/lib none bind 0 0
/usr/lib	  /var/lib/ntp/usr/lib none bind 0 0
/proc		  /var/lib/ntp/proc none bind 0 0

Finally mount all these binds:

# mount -a

Thanks to the ArchLinux guys where I found this.

To check whether your ntp is working again, you can use the following command which shows a list of peers known to your ntp server:

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 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
*ptbtime1.ptb.de .PTB.            1 u   46   64  377   11.483   -0.411   0.201
+ptbtime2.ptb.de .PTB.            1 u   52   64  377   11.502   -0.533   1.069
+ptbtime3.ptb.de .PTB.            1 u   47   64  377   11.451   -0.510   3.866
#batleth.sapient 131.188.3.221    2 u   44   64  377    0.188    1.097   0.176
#5.199.135.170 ( 130.149.17.21    2 u   45   64  377   11.271    0.581   0.396
-mail.morbitzer. 193.175.73.151   2 u   47   64  377    2.760    0.556   0.278
#hotel.zq1.de    161.62.157.173   3 u   46   64  377    0.094    1.384   0.261
-ntp2.m-online.n 212.18.1.106     2 u   47   64  377    7.167   -0.333   0.190
#2a03:b0c0:3:d0: 81.94.123.16     3 u   49   64  377    6.288   -2.071   1.760
#touka.thehomeof 130.149.17.21    2 u   48   64  377    0.206    0.932   0.222
+maggo.info      124.216.164.14   2 u   42   64  377    0.278   -0.137   0.436
+weyoun4.cord.de 124.216.164.14   2 u   44   64  377    2.849   -0.255   0.409
+opnsense.sauff. 222.217.153.8    2 u   43   64  377    0.270   -0.617   0.167
-web1.sys.ccs-ba 192.53.103.104   2 u   35   64  377    0.173   -1.251   0.220
#uruz.org        122.227.206.195  3 u   49   64  377    0.216    1.694   0.309
#clients5.arcani 162.23.41.55     2 u   38   64  377    6.120   -1.500   0.130
+stratum2-1.NTP. 129.70.130.71    2 u   47   64  377   14.043    1.625   0.394

The following command confirms that your current time is actually correct (within certain limits, of course):

# ntpstat
synchronised to NTP server (192.53.103.108) at stratum 2
   time correct to within 15 ms
   polling server every 64 s

If this was helpful, I would be happy to hear from you.

Categories
Networking WTF

AVG can’t get DNS Setup right

It seems that antivirus company AVG can’t get their DNS Setup right.

Today I spotted the below in syslog:

DNS format error from 204.193.144.47#53 resolving crashportal.avg.com/AAAA for client 127.0.0.1#34590: Name avg.com (SOA) not subdomain of zone crashportal.avg.com -- invalid response

So the AVG updater tried to contact via IPv6, as a record type of AAAA was requested, a host called crashportal.avg.com. To do so it had to “resolve” that hostname crashportal.avg.com to an IP address in order to submit a crash dump for a recent crash of their virus scanner (very trustworthy!), and the DNS resolver failed to resolve the IP address. So why is this?

Let’s see:

# dig -t AAAA crashportal.avg.com

; <<>> DiG 9.9.5-9-Debian <<>> -t AAAA crashportal.avg.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 21322
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Huh? We can’t resolve this because our server failed? Let’s see what’s going on…

# dig -t SOA avg.com

; <<>> DiG 9.9.5-9-Debian <<>> -t SOA avg.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42124
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;avg.com.                       IN      SOA

;; ANSWER SECTION:
avg.com.                1160    IN      SOA     ns.grisoft.cz. domainadministration.avg.com. 2015061601 86400 3600 1209600 10800

;; AUTHORITY SECTION:
avg.com.                172607  IN      NS      a11-66.akam.net.
avg.com.                172607  IN      NS      a20-66.akam.net.
avg.com.                172607  IN      NS      a13-65.akam.net.
avg.com.                172607  IN      NS      a26-67.akam.net.
avg.com.                172607  IN      NS      a1-182.akam.net.
avg.com.                172607  IN      NS      a6-67.akam.net.

Ok, so the above quoted Akamai nameservers should be able to help… Let’s see:

# dig -t AAAA crashportal.avg.com @a11-66.akam.net.

; <<>> DiG 9.9.5-9-Debian <<>> -t AAAA crashportal.avg.com @a11-66.akam.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63788
;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 4
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;crashportal.avg.com.           IN      AAAA

;; AUTHORITY SECTION:
crashportal.avg.com.    300     IN      NS      gtm-atl.avg.com.
crashportal.avg.com.    300     IN      NS      gtm-self.avg.com.
crashportal.avg.com.    300     IN      NS      gtm-tnt.avg.com.

;; ADDITIONAL SECTION:
gtm-atl.avg.com.        3000    IN      A       204.193.144.47
gtm-tnt.avg.com.        3000    IN      A       173.245.115.70
gtm-self.avg.com.       3000    IN      A       212.96.161.252

So the server was not authoritative to answer the request and pointed us to a different set of servers.

Note that the IP address from my error message (204.193.144.47) belongs to one of the nameservers mentioned above!

Ok, let’s ask that server:

# dig -t AAAA crashportal.avg.com @204.193.144.47

; <<>> DiG 9.9.5-9-Debian <<>> -t AAAA crashportal.avg.com @204.193.144.47
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47390
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;crashportal.avg.com.           IN      AAAA

;; AUTHORITY SECTION:
avg.com.                60      IN      SOA     gtm-tnt.avg.com. hostmaster.gtm-tnt.avg.com. 2015052909 10800 3600 604800 60

Why does the nameserver respond with an SOA record even though it’s supposed to be authoritative and was asked for AAAA? It’s not a delegation as — and this is exactly the error message — avg.com is not a subdomain of crashportal.avg.com. Duh!

In my humble opinion it is very disappointing if an IT security company cannot even get the basics right, such as DNS.

This issue reminded me of another similar issue I observed a while ago: Avira can’t get their DNS Setup right. And guess what? This was an antivirus company, too…

Categories
English Networking Security WTF

Avira can’t get their DNS Setup right

Since many months I’m seeing the following issue with Avira‘s DNS setup, and I’m thinking it’s extremely embarassing for a company working in IT Security not to even get the basics right… 🙁

This is what I’m seeing:

named[2597]: DNS format error from 89.146.248.46#53 resolving dl4.pro.antivir.de/AAAA for client 127.0.0.1#52127: Name avira-update.net (SOA) not subdomain of zone antivir.de -- invalid response

So what does that mean?

Let’s have a look at which nameservers Avira are using anyway:

$ dig -t ns antivir.de

;; ANSWER SECTION:
antivir.de.        3600    IN    NS    ns13.avira-ns.net.
antivir.de.        3600    IN    NS    ns10.avira-ns.de.
antivir.de.        3600    IN    NS    ns9.avira-ns.net.
antivir.de.        3600    IN    NS    ns12.avira-ns.de.
antivir.de.        3600    IN    NS    ns14.avira-ns.de.

;; ADDITIONAL SECTION:
ns10.avira-ns.de.    86400    IN    A    80.190.154.111
ns12.avira-ns.de.    86400    IN    A    89.146.248.46
ns14.avira-ns.de.    86400    IN    A    74.208.254.45

Ok, so 89.146.248.46 in the error message quoted above is indeed one of the nameservers for domain antivir.de.

So let’s look up the IPv6 address record (AAAA) for dl4.pro.antivir.de on the given nameserver:
$ dig @89.146.248.46 -t AAAA dl4.pro.antivir.de

;; AUTHORITY SECTION:
avira-update.net. 3600 IN SOA ns1.avira-ns.net. domains.avira.com. 2015010301 10800 3600 2419200 3600

WTF?!

Why are they returning a domain name that is not a subdomain of the original domain?! That’s an error.

And it’s especially embarassing as this is the update URL for Avira’s AntiVir product. Again remember we’re talking about a security firm here!