For this attack and many like it, yes, the bots hide their IP.
Per the article, this attack was a combination of DNS amplification and UDP flood. UDP packets don't use a connection like TCP (where the recipient verifies it can talk back to the sender); instead, the packet just declares where it came from, and the recipient fires-and-forgets a response to that IP, blindly assuming that IP is actually the sender.
So for the UDP flood portion, the victim receives a packet with a fraudulent source IP and no way to tell where it really came from.
For the DNS amplification part (also done over UDP), the attacker finds an open DNS resolver online, sends it a request to resolve a record, and fakes the UDP source IP, telling the DNS server to send the response to the attack victim. Not only does this mean the DDoS packets aren't coming directly from the attacker, but DNS responses can easily be much larger than DNS requests, so an attacker multiplies how many gigabits of traffic they hit the victim with, versus just sending UDP packets directly to the victim.
Here's Cloudflare's primer on DNS amplification attacks: https://www.cloudflare.com/en-gb/learning/ddos/dns-amplifica... and UDP floods: https://www.cloudflare.com/en-gb/learning/ddos/udp-flood-ddo...
As far as solutions go, the answers are broadly 1) get everyone in the world to stop putting up UDP services that send large responses to unverified requests (this attack used DNS, but this happens with other protocols too), and 2) convince ISPs everywhere to deny outbound UDP packets which claim a source IP from outside that ISP's network. Since this is one of those "you have to be perfect, but the attacker only has to find one weakness" scenarios, these sorts of attacks will keep happening until it becomes impractical to find enough abusable networks/services to mount high-volume attacks.
I haven’t tried but I would hope my ISP would drop any packets I send out from my home network which do not have the public IP address of my router, but I haven’t tested it.
CF actually wrote a pretty nice article about challenges in doing so - https://blog.cloudflare.com/the-root-cause-of-large-ddos-ip-...
If cooperation of intermediary networks is assumed, these attacks can be crippled by convincing ISPs to deny outbound UDP packets claiming source IPs from outside their networks.
In some cases, it's simple, one address/subnet per port, would be 'easy' to enforce; this is often the case for normal residential connections and commercial users that didn't bring their own IPs. In other cases, networks are connected to networks and what to send there and what is ok to receive may not be the same and may also be dynamic.
If they apply this algorithm to the source IP and find that the optimal route to the source is a different interface than it was received on, that’d potentially be a red flag. But if the optimal route to the source is the same as the optimal route to the destination, that’d be a huge red flag.
That is explicitly a simplified representation used only to compute the checksum of the UDP package. It doesn't even include the full IP header, nor does it touch any of the protocols the IP package would be encapsulated in at all. Network tagging and other fun things happen as low as the Ethernet layer.
> these attacks can be crippled by convincing ISPs to deny outbound UDP packets claiming source IPs from outside their networks.
Not sure this would be enough, I think ISPs generally have complete ranges of IP addresses so it would be trivial for an attacker to create a list of "valid" IPs to use.
It doesn't help much with direct volumetric attacks, but it would potentially make it easier to track (hey ISP, we're getting a lot of traffic evenly divided over your IP ranges, and they can confirm it's coming from their network and maybe figure out where it originates)
I see the IP packet ID field (which appears to have this very use prohibited?) and the 802.1Q VLAN tag on Ethernet frames (a 32-bit value). Is that what you're referencing? Does that mean the idea is each network tagging traffic during transit within their network, with a process for downstream entities to request logged tracking data? I got the impression you meant for the end recipient to receive the intermediate tracking markers alongside the sender's original data, but maybe I misunderstood :)
> Not sure this would be enough, I think ISPs generally have complete ranges of IP addresses so it would be trivial for an attacker to create a list of "valid" IPs to use.
It would prevent the reflection portion of these attacks (a bot could only reflect traffic back into its own IP block, not towards an arbitrary global target), and knowing which networks originated the traffic would enable other countermeasures.
> It would prevent the reflection portion of these attacks (a bot could only reflect traffic back into its own IP block, not towards an arbitrary global target), and knowing which networks originated the traffic would enable other countermeasures.
That makes sense.
What about the ones overseas that just don't care?