I run a server currently in the Netherlands zone and see a roughly twice-daily 30 minute spike of traffic from a single IPv4 address within ziggo.nl, with a constant source port that is not 123. The packets are unusually formatted, with almost all fields zeroed exept the transmit timestamp, according to tcpdump.
An image of the network throughput of such a spike is attached, showing a very sharp ramp up/down and the end after almost exactly 30 mins, suggesting this is a single client caching the DNS record? At its peak it is around 30 Mbps or 40 Kpps, which is well above the normal ~1 Kpps rate seen in the zone. Normally this sort of throughput shouldn’t be an issue as the server is set as 1 Gbps for the NTP pool, but as this traffic is quite peculiar it has occasionally tripped some rather too sensitive anti-DDOS measures and subsequently impacted other services on the same machine that try to use UDP (i.e any DNS).
Is anybody else in the zone seeing similar behaviour and is there a protocol for contacting companies that may be originating such traffic? Simply dropping, rejecting or KoD’ing the traffic doesn’t have any noticable impact on the inbound rate, suggesting a poorly behaving client implementation. The only other reference to the IP in question online appears to be a drop rule in someone elses firewall config.
I have a server in the NL zone. I have noticed very large spikes in CPU usage og NTPD a couple of times a day. I have not investigated why, but it sounds like the same.
We’re running in the NL-zone as well and we too see an occasional peak at 3.5K pps but it’s rare and i suspected a misconfigured client… Is this still an issue somewhere in the network?
(if only there was some global monitoring across the pool )
Originally I wasn’t going to, but I shall now as it’s a continuing issue (> 20 GB in the last 24 hours! Possibly 30 GB) and this might help people block it. Or if there are any ziggo employees watching, they can tell the customer to knock it off. If I was paying for bandwidth per GB, I’d be quite irritated by this or even removing from the pool.
From the last full capture I made on March 17th, it was IP 94.209.158.162, with source port always 43172. Based on the traffic asymmetry in the graph in the first post, it may also be requesting daytime protocol on port 13/udp, but these are all rejected and weren’t logged.
However, note that this resolves back to 5ED19EA2.cm-7-2c.dynamic.ziggo.nl, which suggests it might be consumer connection with an IP that won’t be static if the client restarts their router etc. Hence the IP might have changed since and you might have to block an entire range.
The next time I catch it in progress I’ll do a similar capture and see if the IP has changed.
Hope that helps.
Edit: as an aside: could known offending IPs be blocked at the pool level by blacklisting their initial DNS requests?
Have you ruled out the possibility that the source IP address was forged, and 94.209.158.162 is just an innocent victim that is getting bombarded by NTP servers?
If I were you, I’d contact Ziggo’s abuse department with any relevant evidence you have about the issue. The email address might be abuse@as9143.net.
I just happened upon this post… I’m having the exact same problem and brought it up today in my post about getting hit hard. Same domain but different IP.
Hi there, just registered to add this (hopefully) useful contact info
(I speak Dutch, so I can navigate Ziggo’s website, though some other people in this thread seem to have Dutch-sounding usernames on their Profile ):
Phone number, Help desk category “problems”: 0900 - 1884 (Netherlands special tarif number, not sure if reachable internationally? seems to be their general help-desk number, minus subscription questions)
Phone number Help desk when calling from abroad: +31 881 212 817
web contact form (in Dutch; at “kies onderwerp” (“choose subject”) choose “Misbruik / Overlast” (“abuse / disruption”)
@avij: There’s no way to tell from the end of the pipe if it’s being spoofed, so that is certainly a possibility and one I hadn’t considered. Either way, Ziggo would be able to tell what’s what, so I’ll be sending them an email with a link to this thread, thanks for the address and also the extra info @juleskers.
Actually there is a way, although it is not perfect.
There is a so called IP TTL field which is reduced by one on every hop. In a legitimate case, the IP TTL stays more or less the same, whereas in a spoofed scenario, your server might receive packets from many places on the internet and as a result there is more variation in the IP TTL values.
across the pool )