automatic rtbh trigger using flow data

Aaron Gould aaron1 at gvtc.com
Fri Aug 31 18:35:29 UTC 2018


(I think this is all about volumetric attacks btw...it's my belief that
slow-and-low attacks are continually occurring and are going largely
unnoticed...i'll speak for myself)

Few years ago we began seeing certain ports used as attack vectors, thus we
began our internet boundary policers for these ports... as time went on, we
add to that list of ports.  Some ports as we know, like dns, and I think ntp
from time to time (dang, sorry, lol) are used in amplification, and so, we
can't police legit ports too slowly or real stuff is affected... so that's
what Roland probably meant by "judiciously"

We also have inside this set of qos tools at the internet boundary, an
ever-growing acl that we call "repeat victims"...  we have grown to
understand that, if a customer ip address is attack once, it's likely it
will be attacked again...

There are new attacked ports all the time, so sometimes, an attack gets
through... which is causing me to think about an overall UDP limit on my
internet boundary ports... since most attacks are udp-based*....furthermore,
along with that overarching udp limit, I may mark internet-sourced-udp with
a certain marking dscp/exp so that as it travels through my internet
network, it will be the first to get dropped (? Wred ? work well for udp?)
during congestion when an attack gets through

-Aaron

* btw, what can you experts tell me about tcp-based volumetric attacks...
please help me to understand... does tcp have an inherent inability to
ramp-up to massive speeds/loads with it's sliding window and
must-rcv-ack-before sending more segments ??  I ask since I heard this years
ago about tcp and I wonder if this is why 




-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Roland Dobbins
Sent: Friday, August 31, 2018 12:13 PM
To: NANOG list
Subject: Re: automatic rtbh trigger using flow data


On 31 Aug 2018, at 23:53, Lotia, Pratik M wrote:

> Instead of rtbh I would suggest blocking/rate limiting common ports 
> used in DDoS attacks.

This isn't an 'instead of', it's an 'in addition to'.  And it must be 
done judiciously; many operators doing this have concentrated on common 
port-pairs observed in UDP reflection/amplification attacks.

It's important to understand that any kind of packet of any 
protocol/ports (if such concepts apply on the protocol in question) can 
be used to launch DDoS attacks.

We've many tools in the toolbox, and should use them in a 
situationally-appropriate manner.  And when we're using techniques like 
QoSing down certain ports/protocols, we must err on the side of caution, 
lest we cause larger problems than the attacks themselves.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>




More information about the NANOG mailing list