I’m wondering if there is any kind of DDOS protection for Meteor apps when hosting on Galaxy? Especially against Meteor specific vectors. Something built in like Cloudflare or even Sikka would be great.
Meteor 1.2 does not stop all websocket DDOS attacks and testing one of my apps proved that a simple loop could take down the entire machine.
Installing Sikka fixed the issue but that project has issues and I don’t really want to to use Cloudflare for DNS.
Right now, some Galaxy customers are using Cloudflare. We don’t have this in Galaxy at this time, but I talked to our product team, and it’s on our radar.
Thanks for the update! I think this would be a really big value add. I was surprised at how easily it is to take down a Meteor server with the right script.
Thanks for the comment! It’s really helpful to know what’s important to you.
I hope that’s still on the radar!
I highly doubt it.
They don’t seem to even care about basic exploits in core (specifically logging in the user over websockets). Being that all Meteor apps login the same way, you can write one script to takedown any app.
They don’t seem to care as the exploit find was just brushed off. If core security isn’t important enough I highly doubt they’ll add a layer on top of Galaxy.
Can you tell me more about this exploit?
Do you have any link?
Create a PoC, then write a medium article about it. Post here, reddit, HN, etc. With the spotlight pointed at the issue, MDG will have no choice but to respond with a proper first-class solution.(IMO entire session/user system needs to be rewritten… hopefully adding an out-of-the-box rbac/permission system).
Whoever writes that article can tout themselves as the person who saved meteor from its critical vulnerability, yada yada… Easy fame and resume fodder right here. 
@SkinnyGeek1010, this would be good opportunity for you to save the day. Obviously this is an issue you’re unhappy about, and have some experience with.
Isn’t this something you could manage, to some extent, with the ratelimiter API? At least against the less distributed kind
You sound really insulted. What’s the exploit? I think if you would post it here they would have no other option but to patch it.
Did you file an issue on github?
Did you stop using Meteor because of that issue?
I think it’s also safe to assume they’re busy with a lot of other things - can you post a link to the github issue? 
given there is one
MDG no doubt has their hands full, but regardless… if you have a critical vulnerability, you drop everything and patch it.
I doubt MDG intentionally “brushed off” what now sounds like a potentially serious flaw in the security. Adam’s first message is quite vague, whereas his second message makes the issue sound much, much more serious.
Expanding on my previous post, I suppose I should add:
In the preceding posts, there’s no mention of Adam having explicitly/formally disclosed the vulnerability to MDG/package maintainers… So, I would caution against, well, just posting the thing here, as a GitHub issue, or through some other public medium without having first made a private disclosure. As long as the exploit is not readily available on the web/being used to a large degree, posting it might do more harm than good. TL;DR Posting a vuln PoC is the "nuclear option."
If a submitted disclosure was ignored, was not responded to in a reasonable amount of time, or not patched in a reasonable amount of time. Then certainly a public shaming is in order. I think this goes without saying, but I like typing, and also bumping this topic
But managing a deployment, couldn’t you handle this critical vulnerability outside of Meteor itself. Let’s say I deploy my application behind an NGINX proxy (for example to load balance between instances of my application) - why not use some tooling built into my NGINX proxy to handle DDOS, and just have my application handle whatever traffic I allow to reach it?
Ran a few words through google - this came out: https://www.nginx.com/blog/mitigating-ddos-attacks-with-nginx-and-nginx-plus/
I would say this is a better separation of concerns, instead of riddling my application with security measures that doesn’t actually rely on anything within the application itself? It’s not that I don’t see an option to tool for it, but isn’t there already great tools for this?
I’d somewhat expect this to be a non-issue if I was deploying my application with Galaxy, as some means of security was built in to handle this?
Your thoughts?
Well, I wanted to host on galaxy for some of their inherent meteor-specific benefits and ease of deployement. That’s why this topic was started in the first place, right?
I would expect it to be a given but it seems that currently the opposite is true.
Feel free to PM me for more details.
The exploit allows you to turn any meteor app on and off like a light switch using consumer hardware (1 machine!).
This specific vector does not get rate limited in 1.2 by default… Which I find odd being its a core piece.
I submitted an issue to MDG including a gist to reproduce it and a video showing it taking down a modulus host in seconds.
At any rate getting cloud flare or Sikka (which isn’t big proof) will prevent the attack (and others). I guess when MDG envisions an easy to use dev experience, security wasn’t a priority. Seems like a great value add compared to using other realtime platforms!
given it’s on Galaxy, as you can roll your own servers on Digital Ocean and not have this issue if you know your stuff? just to be clear
It’s a vulnerability no matter where it’s hosted. It can be prevented with a proxy like cloudflare, your own solution (Nginx etc…) or a software package like Sikka.
Personally the cloudflare solution is the cleanest but Sikka is a quick fix.
Just would like to add, that running any nodeJS system (without a load balancer) openly exposed in production is a straight malpractice. A single event loop can always just take so much, than it’s over.
And Meteor is a build tool to create a fancy NodeJS script.
Sounds to me like a far more valuable proposition for paying Galaxy users compared to, for example, prerender support… Would it make more sense to have this in Meteor compared to Galaxy, from your point of view? @SkinnyGeek1010 @dinos
Well, if you (need to) care about protecting yourself against DOS attacks, you need to use tools and services that are specialized for that. And those are not application hosters.
Services like Cloudflare and a basic understanding of web technology (DNS, Routing, http, websocket, tcp etc) are your get to go here.
In fact, as an Application hoster, I would argue that: if you know that your app might be targeted by DOS attacks and you don’t do anything to prevent that, taking down my servers, I would - the least - kick you off my system.
Protecting against malious attacks means to lock down and limit your application to essential aspects in use. Something never anyone, without super high knowledge, could do for you. Which is probably the reason why it’s not forced into 1.2/1.3. It can break stuff (application level).
Saying that, I think it’s not Galaxys job to defend you against illegitimate traffic. They could provide easy integrations, like done with letsencrypt, but regarding DOS, they basically do that already by allowing you to set DNS entries freely.
But to make it clear: If you need to worry about DOS attacks, you either made someone (on purpose) pretty angry or you probably should have enough money to meet your SLAs. Don’t think about it on day 1-100.
However, (easyily) fixable application level vectors in meteor open source are a whole different story. Those should be taken seriously. But I would also expect that our community has some pen testers looking for loops, provide best practice feedback and pull requests. I have not seen much. So maybe there isn’t much? I don’t know.
But as we are talking about security in applications: Read the docs/guide and know what you are doing.
For me personally - “the ability to take down something” - is not an exploit. It’s the fundamental aspect of the Internet. But if data appears to be in danger, I am very sensitive and intolerant about potential security vectors.