Discussion:
Best pf practices to limit ddos attacks
Walt
2018-07-17 00:37:26 UTC
Permalink
With the prevalance of ddos attacks today, are there any steps we can do to limit them. We've been the subject of a few ddos attacks over the last 15 years lasting anywhere between a couple of hours and several days. One lasted a week or two but was largely broken into two parts -- the first lasting a couple of days before disappearing and then showing up again a week later for a couple of hours. The last one lasted about three days nonstop.

I'm not sure what would be useful for when we are the target of an attack. It seems to me that when the attack is going on, our bandwidth is so saturated that I'm not sure what we can do except to wait it out or to pay our provider to help mitigate the attack.

On the other hand, there are steps that we can take to limit any unwitting participation in an attack from our side. For example, I have already been blocking all incoming UDP, TCP, and ICMP packets from the internet that claim to originate from our IP addresses and all outgoing UDP, TCP, and ICMP packets to the internet that are not from our IP addresses.

With the ever increasing sophistication of ddos attacks, is anything else we can do in order to keep anything on our network from being used as part of a botnet or in order to reduce the severity of an incoming ddos attack.

Walt


​Sent with ProtonMail Secure Email.​
Ax0n
2018-07-17 01:14:56 UTC
Permalink
Post by Walt
I'm not sure what would be useful for when we are the target of an
attack. It seems to me that when the attack is going on, our bandwidth is
so saturated that I'm not sure what we can do except to wait it out or to
pay our provider to help mitigate the attack.
This is pretty much the gist of it. One cannot stop this class of DDoS from
the customer's end. There are a variety of solutions involving reverse
proxies and big, scalable clusters, but the fact is if the attacker knows
your real IP address, they can food your residential or small business
connection easily.

On the other hand, there are steps that we can take to limit any unwitting
Post by Walt
participation in an attack from our side. For example, I have already been
blocking all incoming UDP, TCP, and ICMP packets from the internet that
claim to originate from our IP addresses and all outgoing UDP, TCP, and
ICMP packets to the internet that are not from our IP addresses.
This is a great start. Most recent attacks rely on either a fleet of many
hacked IoT/"Smart" devices to generate a bill of coordinated traffic from
thousands or even millions of networks, or they rely on UDP amplification
attacks.

It sounds like you are taking adequate precautions against publicly
accessible assets that might get hijacked, so I'll focus on amplification
attacks.

UDP amplification is where an unwitting third party (such as yourself) is
hosting a UDP service that is capable of responding back with a much larger
payload than that which is sent to it. The simplest and most obvious
example is hosting an open, recursive DNS resolver. The attacker spoofs a
request for a large record (often a TXT entry) using the IP address of the
real victim. Your resolver, in return, recursively fetches and caches the
answer, then forwards the rather large response to the victim, which, of
course, didn't actually make the request and is not expecting this data.
The attacker does this repeatedly, and in tandem with a large corpus of
similarly misconfigured services hosted by other unwitting third parties.
Now tens of thousands of unsolicited DNS responses per second are
exhausting the bandwidth of the victim, and the attackers' real address
isn't even involved. Similar attacks have used misconfigured NTP servers.

Make sure your public, likely-authoritative DNS servers are not publicly
recursive for domains you don't control.
https://en.m.wikipedia.org/wiki/Split-horizon_DNS

With the ever increasing sophistication of ddos attacks, is anything else
Post by Walt
we can do in order to keep anything on our network from being used as part
of a botnet or in order to reduce the severity of an incoming ddos attack.
Walt
​Sent with ProtonMail Secure Email.​
Walt
2018-07-17 04:15:23 UTC
Permalink
I'm not sure what would be useful for when we are the target of an attack.  It seems to me that when the attack is going on, our bandwidth is so saturated that I'm not sure what we can do except to wait it out or to pay our provider to help mitigate the attack.
This is pretty much the gist of it. One cannot stop this class of DDoS from the customer's end. There are a variety of solutions involving reverse proxies and big, scalable clusters, but the fact is if the attacker knows your real IP address, they can food your residential or small business connection easily.
On the other hand, there are steps that we can take to limit any unwitting participation in an attack from our side.  For example, I have already been blocking all incoming UDP, TCP, and ICMP packets from the internet that claim to originate from our IP addresses and all outgoing UDP, TCP, and ICMP packets to the internet that are not from our IP addresses.
This is a great start. Most recent attacks rely on either a fleet of many hacked IoT/"Smart" devices to generate a bill of coordinated traffic from thousands or even millions of networks, or they rely on UDP amplification attacks.
I just wish everyone could do this.
It sounds like you are taking adequate precautions against publicly accessible assets that might get hijacked, so I'll focus on amplification attacks.
UDP amplification is where an unwitting third party (such as yourself) is hosting a UDP service that is capable of responding back with a much larger payload than that which is sent to it. The simplest and most obvious example is hosting an open, recursive DNS resolver. The attacker spoofs a request for a large record (often a TXT entry) using the IP address of the real victim. Your resolver, in return, recursively fetches and caches the answer, then forwards the rather large response to the victim, which, of course, didn't actually make the request and is not expecting this data. The attacker does this repeatedly, and in tandem with a large corpus of similarly misconfigured services hosted by other unwitting third parties. Now tens of thousands of unsolicited DNS responses per second are exhausting the bandwidth of the victim, and the attackers' real address isn't even involved. Similar attacks have used misconfigured NTP servers.
Make sure your public, likely-authoritative DNS servers are not publicly recursive for domains you don't control. https://en.m.wikipedia.org/wiki/Split-horizon_DNS
We did this some years ago when it began to be a problem.  It's surprising how many probes we get every day by people looking for openly recursive servers.

I am getting older (nearly retirement age but with no intention of retiring) and am trying to reduce my workload somewhat.  This includes moving our web pages, e-mail, and DNS to outside providers.

I'm trying to get rid of our e-mail and DNS servers first.  I've already moved the DNS for our own domains to a third party provider. All that is left is the DNS we host for a customer's domain and I've been trying to get them to move it elsewhere, but they are really dragging it out.  I've even offered to move it to where I moved our DNS and all they have to do is change the DNS records with the registrar, but the customer doesn't seem to be in any big hurry to move it elsewhere.

One thing that I'm very curious about is how those behind ddos attacks decide which networks to attack.  I know they attack some people for money but most seem to be just to cause problems.  Do they just randomly pick a block of addresses and attack it or is there some criteria that make them more likely to attack?

Walt

Loading...