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
