Mastodon can be used as a DDOS tool

[valentin2105]

Hi !

Today I found this tweet : https://twitter.com/mattiasgeniar/status/892446659245993984

I tried to post a link on my instance, Mastodon.cloud, and follow the link's web server logs ->

400 instant requests.

Imagine I flood 10 link, I think that go to generate more than 4k requests..
It's not great for link's web server..

Any idea how to mitigate this on futur releases ?
Why Mastodon need to crawl the link ?

Thanks

---

• I searched or browsed the repo’s other issues to ensure this is not a duplicate.
• This bug happens on a tagged release and not on master (If you're a user, don't worry about this).

[angristan]

Tested on my account with 1.5k followers (I don't know how many instances).

Result : 578 requets in 20 seconds.

Examples :

2001:41d0:c:ec9::2b43:1d3 - - [01/Aug/2017:23:35:16 +0200] "HEAD / HTTP/1.1" 200 0 "-" "http.rb/2.2.2 (Mastodon/1.5.0; +https://mstdn.io/)"
2001:41d0:c:ec9::2b43:1d3 - - [01/Aug/2017:23:35:16 +0200] "GET / HTTP/1.1" 200 36402 "-" "http.rb/2.2.2 (Mastodon/1.5.0; +https://mstdn.io/)"
62.210.247.240 - - [01/Aug/2017:23:35:16 +0200] "HEAD / HTTP/1.1" 200 0 "-" "http.rb/2.2.2 (Mastodon/1.4.7; +http://oc.todon.fr/)"
163.172.20.35 - - [01/Aug/2017:23:35:17 +0200] "HEAD / HTTP/1.1" 200 0 "-" "http.rb/2.2.2 (Mastodon/1.4.3; +http://mastodon.partipirate.org/)"
2001:41d0:d:2389::7 - - [01/Aug/2017:23:35:17 +0200] "HEAD / HTTP/1.1" 200 0 "-" "http.rb/2.2.2 (Mastodon/1.4.7; +http://mastodon.top/)"
2001:41d0:c:ec9::2b43:1d3 - - [01/Aug/2017:23:35:17 +0200] "GET / HTTP/1.1" 200 36402 "-" "http.rb/2.2.2 (Mastodon/1.5.0; +https://mstdn.io/)"
163.172.185.23 - - [01/Aug/2017:23:35:17 +0200] "HEAD / HTTP/1.1" 200 0 "-" "http.rb/2.2.2 (Mastodon/1.5.0rc3; +https://mastodon.social/)"
62.210.247.240 - - [01/Aug/2017:23:35:17 +0200] "GET / HTTP/1.1" 200 36402 "-" "http.rb/2.2.2 (Mastodon/1.4.7; +http://oc.todon.fr/)"
163.172.20.35 - - [01/Aug/2017:23:35:17 +0200] "GET / HTTP/1.1" 200 36402 "-" "http.rb/2.2.2 (Mastodon/1.4.3; +http://mastodon.partipirate.org/)"
2001:41d0:d:2389::7 - - [01/Aug/2017:23:35:17 +0200] "GET / HTTP/1.1" 200 36402 "-" "http.rb/2.2.2 (Mastodon/1.4.7; +http://mastodon.top/)"
2001:4b99:1:2:216:3eff:feaf:f948 - - [01/Aug/2017:23:35:17 +0200] "HEAD / HTTP/1.1" 200 0 "-" "http.rb/2.2.2 (Mastodon/1.4.7; +http://m.massy.city/)"
188.165.228.227 - - [01/Aug/2017:23:35:17 +0200] "HEAD / HTTP/1.1" 200 0 "-" "http.rb/2.2.2 (Mastodon/1.4.7; +http://mastodon.eliotberriot.com/)"
2001:bc8:3862:4272::42 - - [01/Aug/2017:23:35:17 +0200] "HEAD / HTTP/1.1" 200 0 "-" "http.rb/2.2.2 (Mastodon/1.5.0; +https://mastodon.xyz/)"
163.172.185.23 - - [01/Aug/2017:23:35:17 +0200] "GET / HTTP/1.1" 200 36402 "-" "http.rb/2.2.2 (Mastodon/1.5.0rc3; +https://mastodon.social/)"
2a01:4f8:10a:3e15::2 - - [01/Aug/2017:23:35:17 +0200] "HEAD / HTTP/1.1" 200 0 "-" "http.rb/2.2.2 (Mastodon/1.4.4; +http://framapiaf.org/)"
62.210.247.240 - - [01/Aug/2017:23:35:17 +0200] "GET / HTTP/1.1" 200 36402 "-" "http.rb/2.2.2 (Mastodon/1.4.7; +http://oc.todon.fr/)"
163.172.20.35 - - [01/Aug/2017:23:35:17 +0200] "GET / HTTP/1.1" 200 36402 "-" "http.rb/2.2.2 (Mastodon/1.4.3; +http://mastodon.partipirate.org/)"
2001:41d0:d:2389::7 - - [01/Aug/2017:23:35:17 +0200] "GET / HTTP/1.1" 200 36402 "-" "http.rb/2.2.2 (Mastodon/1.4.7; +http://mastodon.top/)"
2001:41d0:a:fb29::1 - - [01/Aug/2017:23:35:17 +0200] "HEAD / HTTP/1.1" 200 0 "-" "http.rb/2.2.2 (Mastodon/1.4.7; +http://toot.tzim.net/)"
195.154.133.191 - - [01/Aug/2017:23:35:17 +0200] "HEAD / HTTP/1.1" 200 0 "-" "http.rb/2.2.2 (Mastodon/1.5.0; +https://soc.ialis.me/)"
163.172.149.63 - - [01/Aug/2017:23:35:17 +0200] "HEAD / HTTP/1.1" 200 0 "-" "http.rb/2.2.2 (Mastodon/1.5.0; +https://m.dumez.info/)"
2001:41d0:1:9064::1 - - [01/Aug/2017:23:35:17 +0200] "HEAD / HTTP/1.1" 200 0 "-" "http.rb/2.2.2 (Mastodon/1.4.7; +http://antisocial.narinimous.fr/)"
91.121.37.224 - - [01/Aug/2017:23:35:17 +0200] "HEAD / HTTP/1.1" 200 0 "-" "http.rb/2.2.2 (Mastodon/1.4.7; +http://mastodon.at/)"
78.205.21.170 - - [01/Aug/2017:23:35:17 +0200] "HEAD / HTTP/1.1" 200 0 "-" "http.rb/2.2.2 (Mastodon/1.5.0rc2; +https://ma.zy.lc/)"
2001:41d0:2:d230::15 - - [01/Aug/2017:23:35:17 +0200] "HEAD / HTTP/1.1" 200 0 "-" "http.rb/2.2.2 (Mastodon/1.5.0; +https://hostux.social/)"

[ykzts]

duplicate of #3518

[ghedipunk]

I wouldn't call it a duplicate.

Related, absolutely. Not duplicate.

The issue with #3518 is that a single server is making 3 different requests for the same resource.

The issue in this is that hundreds of servers are requesting the same resource, as soon as they get a notification of the toot.

[valentin2105]

Imagine you got 10 account on 10 instances and you post 10 links on each.
It would be a big mess.

[Gargron]

I can totally see this being a problem, but I also don't see a solution to it, because people want previews. An idea could be to randomly delay the fetching of the preview, however, you would get complaints from people "why doesn't the preview show up?" when they immediately check it. Anyone have any other ideas?

[ghedipunk]

Perhaps "trust, but verify." Also, humans are a great source of randomness.

Bear with me as my assumptions about how the federation works may not be completely accurate -- the details shouldn't matter.

Have the originating server send metadata about the link's preview along with the toot.

When the client requests the preview, their own server can then verify the link and update the preview if necessary.

This way, there's always something to show up front. Since the Web client doesn't attempt to show the preview until the user clicks on a toot, we have a random wait -- on the order of seconds, minutes, or years -- so we aren't creating a thundering herd based only on the toot hitting the federated servers.

Also, if nobody is even going to look at the preview, one never gets loaded, saving a few completely unnecessary requests.

The only real concern is a malicious server sending incorrect information in the toot's metadata... That's why I say to verify.

(This would also give users the ability to set a preferred preview image, as they're able to do on FB and G+, but that really belongs in a feature request rather than a discussion about a bug report)

[Hexalyse]

I was thinking about the same thing : couldn't the preview be generated when the toot is posted, by the server from where it's posted... then other instances would fetch this preview from the originating instance, as they do for media attachments ?

Just a random idea tho. I don't know if it would fit in the mastodon federating scheme.

[bortzmeyer]

Calling 400 HTTP requests a "dDoS" seems very exaggerated.

[ghedipunk]

Someone running Wordpress on a stripped down VPS without any CDNs mitigating traffic spikes would be very unhappy to see 400 HTTP requests hit in an instant.

Many hosts automatically reboot VPS servers if they exceed their memory allotment, bringing the site down for minutes... and on Mastodon, the first few minutes after a link is posted accounts for 95%+ of the visits that the site is going to get from that toot.

Arguably, the people who buy the cheapest VPS are the ones who need that traffic the most; by rebooting their server each time someone links to them on Mastodon, you're not just DOSing them, you're creating a bad user experience, driving away potential customers.

A DDOS doesn't have to last for days, harnessing the power of millions of misconfigured routers and IP cameras to be effective... It just has to come from more than one source at once and deny normal users use of the service.

[bortzmeyer]

@ghedipunk If I had to run a site on a "stripped down VPS", I would run a static site, for which 400 requests is nothing, even on a Raspberry Pi. But my main point is that generating 400 requests is very simple for any attacker. Mastodon is not really needed.

[LogalDeveloper]

This is not an issue just about 400 HTTP requests. The main issue here is that as Mastodon gets bigger and more instances are created, the larger and more serious the attacks can become. Another part of this is that while the attacks can be on purpose by a malicious person, they can also be on accident by an innocent person with a lot of followers who simply wants to share a meme they liked a lot.

[ghedipunk]

You're experienced in web hosting, as are the vast majority of people who would participate in this thread here on Github.

However, looking at small business sites, it's very clear that we're in the minority.

We know about Cloudflare and using nginx as a TLS terminator in front of Varnish-Cache that does intelligent edge-side includes on Apache/PHP generated content...

We know what design decisions to make on a completely static HTML only site so that if we need to update the site's layout, we can do it quickly.

We know that if you want to sell things online, you have to resize your 48000x28000 pixel product images before displaying them to the users.

And, we know that there are users who don't know these things.

This isn't about helping us, the technical elites who can run a successful site off of a Raspberry Pi. It's about being good neighbors.

[mherrb]

I really don't see where the problem is. The distributed nature of mastodon will spread the requests over a (small for humans but large for the network) interval and when you publish some link on a public media, you expect traffic coming back to the site in question. Otherwise there's little interest on publishing it.
And when the number of mastodon instances will grow, the load will also be spread over a wider interval since it will take more time for the toot to propagate to all instances.

[bortzmeyer]

Indeed, when you post a link on Twitter, you get more requests (not from Twitter itself, because of its centralized nature, but because of all the bots that read Twitter and act).