A problem...?

[Paul Theodoropoulos]

On 8/6/2018 19:28 PM, Eric S. Raymond wrote:
> Paul Theodoropoulos <paul at anastrophe.com>:
>> svwh.net however did respond when I asked about it.  They sent a dump of
>> packets, which showed - bizarrely - that some of my queries were coming in
>> to their server on port 4. Yup, 4. The rest of my queries come in properly
>> on 123.
> That is utterly bizarre.
>
> Not only have we never had a report like this, but I just checked the code
> and there does not seem to be any path that makes it possible for packets to
> ship on anything but port 123.
>
> The key line is the one that reads "create_sockets(NTP_PORT);"
>
> find . -type f -exec grep --color -nH -e NTP_PORT {} +
> ./build/main/pylib/magic.py:16:NTP_PORT	= 123	# included for non-unix machines
> Binary file ./build/main/pylib/magic.pyo matches
> Binary file ./build/main/pylib/magic.pyc matches
> ./ntpd/ntp_io.c:339: *     to bind to to the interface address on NTP_PORT so that
> ./ntpd/ntp_io.c:340: *     all wild and specific bindings for NTP_PORT are taken by ntpd
> ./ntpd/ntp_io.c:405:	create_sockets(NTP_PORT);
> ./ntpd/ntp_io.c:1286:	new_interface_found = update_interfaces(NTP_PORT, receiver, data);
> ./ntpd/ntp_io.c:2549: * address by connecting a new socket to destinationaddress:NTP_PORT
> ./ntpd/ntp_restrict.c:272:			|| NTP_PORT == port))
> ./ntpd/ntp_restrict.c:299:			|| NTP_PORT == (int)port))
> ./ntpd/ntp_sandbox.c:214:		 * ports that allow binding to NTP_PORT with uid != 0
> ./ntpd/ntp_config.c:2656:		SET_PORT(&peeraddr, NTP_PORT);
> ./ntpd/ntp_config.c:2696:	    SET_PORT(&peeraddr, NTP_PORT);
> ./ntpd/ntp_config.c:3508:	SET_PORT(addr, NTP_PORT);
> ./ntpd/ntpd.c:822:		 * ports that allow binding to NTP_PORT with uid != 0
> ./ntpd/ntpd.c:1023:			    htons(NTP_PORT), 0, NULL, NULL, NULL) != kDNSServiceErr_NoError ) {
> ./include/ntp.h:61:#define	NTP_PORT	123	/* included for non-unix
>
> Could you have a bad rewrite rule in your iptables setup somewhere?

As far as I'm aware, I have nothing in place on the Raspberry that would 
'mangle' packets like that, particularly for outbound traffic and most 
particularly shifting it onto privileged port 4 of all places. At the 
time of the report from svwh.net, I had this ruleset in place - but have 
eliminated all but the masquerades while trying to figure out what was 
going on:

# Generated by iptables-save v1.6.0 on Tue May  1 13:25:46 2018
*nat
:PREROUTING ACCEPT [545148:106303644]
:INPUT ACCEPT [175661:21985907]
:OUTPUT ACCEPT [52147:3740449]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -j MASQUERADE
-A POSTROUTING -o eth0 -p udp -j SNAT --to-source 108.196.98.101
COMMIT
# Completed on Tue May  1 13:25:46 2018
# Generated by iptables-save v1.6.0 on Tue May  1 13:25:46 2018
*filter
:INPUT ACCEPT [754:88756]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [114:8408]
-A INPUT -p udp -m udp --sport 123 -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
COMMIT

I'm not an expert on routing/fw rules,  but I don't see anything there 
that could cause packets to appear elsewhere on a privileged port other 
than their source port.

I have  a few necessary rulesets in place on the stupid ATT router, 
NATing udp 123 specifically to the ntpsec server, and (attempting to) 
allow unprivileged source ports to connect to destination port 123 (more 
on that later).

As far as ATT,  I've dug deep , and while claims in their terms that 
they block NTP traffic in both directions - they only block traffic 
inbound to ATT destination addresses from a non-privileged source-port 
to port 123. Which is why a handful of folks who've tried to peer with 
me or just use ntpsec.anastrophe.com for timeservice (particularly on 
Windows) get no response. It is blocked administratively within ATT's 
network, so nothing I could do on my router would have any effect. But 
again - that's only on traffic *inbound*.

And I should say that I don't particularly suspect this to be a bug/ 
defect in ntpsec itself. It's just a truly bizarre report I received. 
I've also left tcpdump running sniffing port 4, and have seen no 
evidence of any traffic on it. The utterly incomprehensible transmit 
timestamps of packets outbound in my tcpdump output is the one that 
really sends a chill down my spine. At first blush, it makes me think 
I'm spewing deadly packets to timeservers all over the place.

-- 
Paul Theodoropoulos
www.anastrophe.com