It is the same company. They started off as Neotel, later became Liquid Telecom and is now called Liquid Intelligent Technologies.
From earlier, TIME and DAYTIME: I’d suggest just dropping those. Malicious traffic or not, but they’re not going to get a response from your server anyway, or pretty much from any other server in the pool. It has never been a requirement for pool servers to serve those protocols.
Edit for clarity: If the destination port of these is 123 (NTP) they’re probably NTP and harmless and only misidentified. If the destination port is 37 (TIME) or 13 (DAYTIME) they’re also probably harmless but could just as well get dropped because there’s nothing on your server listening on these two ports.
Regarding your Wireshark screenshot: Those packets that Wireshark identified as DNS queries are actually NTP queries. Wireshark only misdetected those as DNS. There isn’t a good “magic number” inside NTP packets so Wireshark had to rely on the port numbers to determine the protocol. This time it picked the wrong port from the two options. That’s why you see the DNS query decoded as an odd “Unused Root Unused”. Normal DNS queries would show up as “TXT example.com OPT” for example.
I managed to capture a packet that looks very much like yours. Here’s how Wireshark identified it at first:
When I right-clicked on the packet and selected “Decode as” and then forced decoding as NTP, the packet was displayed as:
Here you’ll see that the NTP version was 4 (sounds legit) and all but the transmit timestamps were empty (the client’s clock hasn’t synchronized yet). So this was indeed an NTP query, but I can’t tell from the packet capture alone if the sender’s IP address was forged or not. As mentioned earlier, I drop these spt:53→dpt:123 UDP packets at the firewall as a precaution anyway.
1 Like
Wow! Thank you! I did not realize that wireshark can be so misleading. I was worried that this was an NTP vulnerability type probe. And I checked, even the DAYTIME and TIME messages does decode as NTPv4 packets. And that is why my server was responding to all these messages, including the BOOTP messages. 
But I then still don’t know what is triggering the “excessive traffic” log entries, but I’m giving up on that one.
I see NTP requests coming from all 65536 UDP source ports, including port 0. The distribution below excludes several peaks, but shows structure coming from the various ephemeral port ranges. There are 2.4 x 10^9 requests in the data set. [You’ll see similar distributions in the NIST paper]
Client port 123 (NTP) is the most common with 58M requests (2.4%)
Port 53 has 0.2 M requests for this data set.
I was surprised to see 6M requests coming from client port 60539 and 14M requests coming from client port 60540. It was interesting to see that 67 client IPs (coming from 21 ASs) sent the exact same number of requests during the period. There’s no way to determine whether the source addresses were legitimate or spoofed.
Any client UDP port analysis should be aware of known bugs that create large bursts (e.g., Fortigate). that can affect distributions. I still see bursts >10K/second from my server in the LT zone.
The use of port 53 may be a coincidence, malicious, or just poor programming.
1 Like
