There was a ddos with SYN/ACK against ON3YH’s BGP subnet, but that is the only one I heard of uptil now. My own subnet does not show any signs (yet) nor does the general /16 for Belgium. Fingers crossed that it stays that way.. Ruben - ON3RVH

Here in the Dutch network, everything is as normal. (i.e. plenty of incoming garbage) So it appears to target a host, not the entire network. Rob On 9/25/21 5:35 PM, K7VE - John via 44Net wrote:

Nothing directed to my /24 Matt On 26/9/21 1:35 am, K7VE - John via 44Net wrote: -- _____ _____ |___ |___ / Matt Perkins VK2FLY (advanced) / / |_ \ Woolloomooloo NSW (QF56od) +61403571333 matt(a)vk2fly.com / / ___) | A pround member of ARNSW, The WIA, /_/ |____/ And the Waverley Amateur Radio Society.

And how would that help? It won't make the bandwidth available, the packets would still saturate the public interface. On 27/09/2021 09:15, Borja Marcos via 44Net wrote:

So, it was a TCP port 80 attack directed against one IP address. I passed this on to my contacts at CAIDA who passed it onto the UCSD NOC who have got the IP blocked. The traffic has now returned to normal. Chris - G1FEF

Yes it would be worthwile to research (with the IP address as information) what could be the reason behind this.  Assuming it was not 44.0.0.1 but some amateur's IP, it could be some retaliation against that person and they may be able to identify a likely source and legal action may be possible. Aside from that, I think there is too little headroom on this connection and it needs to be upgraded to 10Gbit or some teamed 1Gbit links when that is more practical. The background noise already takes up 650Mbit/s of the 1Gbit/s available... Rob On 9/27/21 9:33 AM, Marius Petrescu via 44Net wrote:

There has been a plan in place to upgrade the link to 10Gb/s for nearly a year, there were two attempts at upgrading which failed due to the new link not working, but UCSD have now identified the issue and the upgrade has been expedited and, all being well, it will be upgraded within the next week or two. Of course that just means the next DDOS will be hitting the gateway much harder, but at least we will have some decent headroom under normal circumstances. 73, Chris - G1FEF

Hello Chris, This 1Gbps link is to the IPIP gateway system in San Diego right? If so, even if you get a faster pipe, can this gateway server (I want to say this is a FreeBSD machine right?) actually forward at those rates? --David KI6ZHD On 09/27/2021 02:10 PM, Chris Smith via 44Net wrote:

Do you have or can you get RTBH setup with UCSD? So from the 44net gateway box you can announce problematic /32s or larger with a black hole community e.g :666, which they then null route on their borders? Also that they then propagate to their upstreams. This is a very common simple setup. If today the 44net space is static routed from UCSD to the gateway box then you could still do private BGP with them which only the blackhole prefixes are announced, leaving the static in place for the covering routes. On Mon, 27 Sep 2021 at 22:12, Chris Smith via 44Net <44net(a)mailman.ampr.org> wrote: -- Nat https://nat.ms +44 7531 750292

We have a customer with a misconfigured router being used as a DDoS amplification. Sorry about it, I play whack-a-mole with them but sometimes I miss one or two. On the bright side it gives me visibility over Hamnet's particular issue (and our customer is putting just around 600 Kbps) I can tell you that AMPRNet is suffering an ongoing DNS based DDoS attack since Sep 23rd , 10:00 UTC. The destination addresses are two: 44.37.62.8 44.72.200.252 The traffic profile is a classic DNS DDoS. Large UDP packets with source port 53 and fragments (which on Netflow flows appear as source and destination port 0). Mitigating this is particularly easy. Use an “internal” DNS resolver with a different IP address and make sure your upstream filters large UDP packets with popular DDoS source ports such as 53 (DNS), 123 (NTP), etc and fragments. No need to drop them all but you can cap them at, say, 100 Mbps so that they won’t flood your network port. Avoid fragmentation wherever possible of course. And setting up some Netflow monitoring is mandatory, so that you can quickly characterize hostile traffic. As long as you have proper monitoring, you can ask your upstream to accept FkowSpec rules from you. FlowSpec is a specification to transport IP filtering configuerations over BGP so that you can install limited filters on your upstream router without their intervention. Other sype of DDoS attacks, such as a TCP Syn flood can be a bit more complicated to mitigate and the best strategy is to use operating systems with enough resources and proper mechanisms (such as TCP syncookies) to withstand it. Blackholing is a last resource measure. Cheers, Borja - EA2EKH