Re: Best pf practices to limit ddos attacks

2018-07-16 Thread Walt
On July 16, 2018 8:14 PM, Ax0n a...@h-i-r.net wrote:
 
> On Mon, Jul 16, 2018, 19:39 Walt neurobot...@protonmail.ch wrote:
> 
> > 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




Re: Best pf practices to limit ddos attacks

2018-07-16 Thread Ax0n
On Mon, Jul 16, 2018, 19:39 Walt  wrote:

>
> 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.

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
> 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.​
>
>
>


Best pf practices to limit ddos attacks

2018-07-16 Thread Walt
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.​