From Newsgroup: news.admin.peering

Dear Newmasters,
my PCs is currently targeted by a significant DDoS attack,
which is impacting my Usenet services and my connectivity.
I am currently away from home, but I am actively working remotely to mitigate the traffic,
analyze the logs, limit services, and block the malicious IP ranges as quickly as possible.
Please expect some instability or routing delays while these mitigation steps are being applied.
I am doing everything I can to fully restore normal operations shortly.
Thank you for your patience and understanding.
Best regards,
--
Roberto CORRADO
news.corradoroberto.it
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: news.admin.peering

Il 03/07/2026 16:26, Roberto CORRADO ha scritto:

my PCs is currently targeted by a significant DDoS attack,

Il tuo PC? Vuoi farti ridere dietro? Devi scrivere il mio datacenter
come minimo. :-)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: news.admin.peering

Am 03.07.26 um 16:26 schrieb Roberto CORRADO:

my PCs is currently targeted by a significant DDoS attack,
which is impacting my Usenet services and my connectivity.

Interesting.
Is that attack targeted to NNTP or to another protocol?
--
Gru|f
Marco

Spam bitte an abfalleimer2001@stinkedores.dorfdsl.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: news.admin.peering

"Marco Moock" wrote:

Interesting.
Is that attack targeted to NNTP or to another protocol?

Hi Marco,
Here is an update regarding the recent service disruption.
To clarify, my NNTP service was not the target of the attack.
Instead, we experienced a massive Distributed Denial of Service (DDoS) attack targeting my HTTP and DNS services, specifically utilizing the DNS Watermarking technique.
This flooded my systems with unique, random queries that bypassed caching, causing severe CPU saturation on our authoritative DNS and web servers.
Due to this resource exhaustion, secondary servicesrCoincluding SMTP, NNTP, and our proxy serversrCosuffered a complete takeover/freeze as they were starved of processing power.
The attack also fully saturated our network bandwidth.
To mitigate the issue, we applied Layer 7 geo-blocking on our Zyxel WAF/firewall. By restricting and excluding traffic originating from the specific target countries driving the attack, we successfully restored resource stability and bandwidth.
All services are now running normally, and we are continuing to monitor the traffic.
By next year, I'll be switching to a 1 Gbit/s FTTH provider, up from my current 30 Mbit/s.
thanks all for the support.
--
Roberto CORRADO
news.corradoroberto.it
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: news.admin.peering

This morning, a new UDP attack on DNS port 53 occurred.
There are about 30,000 connections per second coming from various IPv4 addresses.
I am in contact with my carrier, and we may proceed with replacing the CPE next week.
Please be patient; I will get back to you as soon as possible.
--
Roberto CORRADO
news.corradoroberto.it
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: news.admin.peering

This morning, a new UDP attack on DNS port 53 occurred.
There are about 30,000 connections per second coming from various IPv4 addresses.
I am in contact with my carrier, and we may proceed with replacing the CPE next week.
Please be patient; I will get back to you as soon as possible.
--
Roberto CORRADO
news.corradoroberto.it
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: news.admin.peering

On Thu, 16 Jul 2026 13:47:25 +0200, Roberto CORRADO wrote:

This morning, a new UDP attack on DNS port 53 occurred.
There are about 30,000 connections per second coming from various IPv4 addresses.
I am in contact with my carrier, and we may proceed with replacing the
CPE next week.
Please be patient; I will get back to you as soon as possible.

drop the raw packets to 53, you do have another dns server off that
network I assume, so let it deal with requests - of course it too might
be under same attack and need some loving, which is why it pays to have a tertiary dns server, on someomebody elses AS network with shitload of
grunt eg: HE (I dont and wont use shared hardware by likes of cloudfare
et al)

if you drop it raw, it stays clear of the CPU because they're dropped
before the SCT's see them, so wont bog down routers cpu.

cisco easy as...
ip access-list extended drop-dns
deny udp any any eq 53
deny tcp any any eq 53
permit ip any any

int _your_inbound_interface_
ip access-group drop-dns in

or mikrotik...
/ip firewall raw
add action=drop chain=prerouting in-interface=_yourinbound_interface protocol=udp dst-port=53
add action=drop chain=prerouting in-interface=_your_inbound_interface protocol=tcp dst-port=53


It wont help as much as above, but if you use bind, might pay to check
out the rate-limit {} section under options.

Since its DDoS this also might be useless, but if on linux I would limit
20 hits a second per IP...
iptables -A INPUT -p udp --dport 53 -m hashlimit --hashlimit-name
DNS_LIMIT --hashlimit-upto 20/sec --hashlimit-burst 60 --hashlimit-mode
srcip -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -m hashlimit --hashlimit-name
DNS_LIMIT --hashlimit-upto 20/sec --hashlimit-burst 60 --hashlimit-mode
srcip -j ACCEPT

hope your upstream deals with this quickly, in fact, they may already
have since this post is 20 hours ago :)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: news.admin.peering

On Fri, 17 Jul 2026 18:18:22 +1000, noel wrote:

On Thu, 16 Jul 2026 13:47:25 +0200, Roberto CORRADO wrote:

This morning, a new UDP attack on DNS port 53 occurred.
There are about 30,000 connections per second coming from various IPv4
addresses.
I am in contact with my carrier, and we may proceed with replacing the
CPE next week.
Please be patient; I will get back to you as soon as possible.

drop the raw packets to 53, you do have another dns server off that
network I assume, so let it deal with requests - of course it too might
be under same attack and need some loving, which is why it pays to have
a tertiary dns server, on someomebody elses AS network with shitload of
grunt eg: HE (I dont and wont use shared hardware by likes of cloudfare
et al)

if you drop it raw, it stays clear of the CPU because they're dropped
before the SCT's see them, so wont bog down routers cpu.

cisco easy as...
ip access-list extended drop-dns deny udp any any eq 53 deny tcp any any
eq 53 permit ip any any

int _your_inbound_interface_
ip access-group drop-dns in

or mikrotik...
/ip firewall raw add action=drop chain=prerouting in-interface=_yourinbound_interface protocol=udp dst-port=53 add
action=drop chain=prerouting in-interface=_your_inbound_interface protocol=tcp dst-port=53

It wont help as much as above, but if you use bind, might pay to check
out the rate-limit {} section under options.

Since its DDoS this also might be useless, but if on linux I would limit
20 hits a second per IP...
iptables -A INPUT -p udp --dport 53 -m hashlimit --hashlimit-name
DNS_LIMIT --hashlimit-upto 20/sec --hashlimit-burst 60 --hashlimit-mode
srcip -j ACCEPT iptables -A INPUT -p tcp --dport 53 -m hashlimit --hashlimit-name DNS_LIMIT --hashlimit-upto 20/sec --hashlimit-burst 60 --hashlimit-mode srcip -j ACCEPT

hope your upstream deals with this quickly, in fact, they may already
have since this post is 20 hours ago :)

Actually, you're screwed until your ISP steps in, you have committed a cardinal network sin, but I trust by tomorrow you will have learned your lesson and resolved that.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: news.admin.peering

noel <deletethis@invalid.lan> ha scritto:

Actually, you're screwed until your ISP steps in, you have committed a cardinal network sin, but I trust by tomorrow you will have learned your lesson and resolved that.

thank you for your advice, I found it very interesting and useful.
you are all very smart and it's a pleasure be part of this usenet
group
--- Synchronet 3.22a-Linux NewsLink 1.2