At a glance, this didn’t look like a DDoS to me, because:
- Heavy traffic load appears only when the monitoring system includes a server in the pool.
- Traffic drops to negligible values once the pool no longer includes the server.
In my understanding, this looks like legitimate clients making their first-time requests. If it was a DRDoS, then the traffic would remain indefinitely, once the “attackers” become aware of server existence.
However, inspecting the MRU list gave me some thoughts:
$ ntpq -c 'mrulist sort=-count'
lstint avgint rstr r m v count rport remote address
==============================================================================
0 0 3d0 L 3 3 82834 437 171.22.215.174 (RLINE1 = AS35608)
0 0 bd0 K 3 4 43905 46178 80.76.106.190 (dynip6-190.tdsplus.ru)
1 0 3d0 L 3 4 41390 39532 80.76.96.53 (TDS+ = AS51547)
3 0 3d0 L 3 4 40596 52981 80.76.96.43 (TDS+ = AS51547)
0 0 3d0 L 3 3 38341 294 45.141.93.253 (RLINE1 = AS35608)
1 0 3d0 L 3 4 30959 40020 80.76.110.197 (dynip10-197.tdsplus.ru)
3 0 3d0 L 3 4 21990 22305 80.76.96.37 (etra-plus.ru)
1 0 3d0 L 3 4 21932 50388 80.76.96.35 (dkkonversiya.ru)
2 0 3d0 L 3 4 17815 42734 80.76.110.195 (dynip10-195.tdsplus.ru)
2 0 3d0 L 3 4 17723 33731 80.76.96.33 (TDS+ = AS51547)
5 0 3d0 L 3 4 17013 50980 80.76.96.39 (TDS+ = AS51547)
1 0 3d0 L 3 3 15484 19523 171.22.213.22 (RLINE1 = AS35608)
First of all, the most frequent addresses are from a small bunch of domestic ISPs. This fact alone does not indicate anything, as many users in Russia are behind NAT and thus sharing same IP addresses. However, the ISPs figured here are not anywhere popular, AFAIK, to generate such an amount of traffic, while none of the really popular ISPs showed up in the logs. This makes me think that some ISPs may be the target of an attack, or may be the source of some IoT devices which went out of control, etc.
Second, many requests “from” those clients have strange source port numbers — neither 123 nor 32768–65535, and sometimes even below 1024. I decided to block such requests on the firewall to decrease the probability of reflection attacks on third-party infrastructure (or at least to halve its intensity if the “source” port is chosen randomly by a spoofer). If those are legitimate legacy systems using ports starting from 1024, then I think it is acceptable “collateral damage” in current desperate circumstances.
PS. Well, after inspecting the firewall logs during “peace time”, I reconsidered and enabled ports 1024–32767 as well.
JFYI. For me, the bottleneck is not the NTPd server itself (although its Atom D2500 is nearly fully loaded when incoming traffic reaches 20 to 50 Mbit/s), but pfSense router based on Celeron G3900 and an Intel NIC which seems to generate a lot of interrupts, so that a single core is almost eaten by handling them.