@muaddib I respectfully disagree. What I’m talking about are
slow loris type attacks over websockets that typical network firewalls have no way of identifiying if they do not do deep packet analysis (which is either hard or illegeal for ssl terminated connections anyway)
ddp specific attacks that are 100% platform specific therefore requiring the security layer to have a deep knowledge of how the platform (meteor) works and of course also keep updated as meteor gets new updates related to ddp. This would also be highly inefficient and lagging behind actual meteor versions.
So basically, you are suggesting that someone should create a C/C++ layer above DDP, that is outside the app, knows all about DDP message contents (also a legal concern by the way) and keeps updated whenever meteor gets new updates. All the while, supporting different front end servers like nginx, haproxy, apache, etc, and creating a vendor lock-in since you just cannot use meteor-only clustering options either.
But yes, of course anyone can do anything anywhere. But that is just extremely inefficient and a very odd place to do it.
Regarding our comments on owasp guidelines, well of course security is not an exact, deifinitive and static science. It keeps changing, evolving and adapting. That’s why meteor has a very talented and respected security expert on board. That being said, in the current state of affairs, meteor is known to be not susceptible to those conditions outlined on that article. (Again, except for those that the app dev can screw up)
But I am very very very interested in actual physical pointers that you might bring up. That’s why I carried over our converstion here. So that we don’t hijack the thread over there and continue freely, if you also would like to do that with me.
Legal concern/SSL: I’m supposing that you either are the owner of the app, or you have been authorized by the owner of the app to defend it. I don’t care about defending some stranger app for the purpose of generosity.
I already delegate SSL to nginx, on a different server. If you have both SSL and meteor and mongo on the same server, have can you know what is causing problems when there is a CPU spike?
In the configuration I think it’s best we have one or more VMs with Nginx for load balancing, static caching, filtering and SSL termination. One or more meteor instances to handle the app load, and one or more mongodb instances to handle the DB.
In this scenario is already smart to deploy your main defence on the first line, i.e. nginx, rather than on meteor instances, which are already gobbling CPU time.
SSL encrypts the content, not the header or the TCP/IP flags. Otherwise how could packets be routed?
D/DoS attacks rely on some sort of spoofing of the sender, only by verifying the authenticity of the sender you are blocking most of the malicious traffic. All this without reading a single data.
Application layer attacks are dangerous, and we should all look after them. The community must be always en garde.
Nginx websocket module is already written in C++, and I already use it in production for load balancing, filtering, and SSL encryption. As I know others do. Not a single C/C++ developer was harmed/used in this
It is also VERY VERY efficient, cpu wise, unlike node server.
It’s useless to say the meteor core is secure (a arguable statement) when what you have to defend are real world apps with poorly written code. Having an abstract solution that could at least mitigate the problem no matter how poor the code is would be really really cool.
In the security business it pays off to be paranoid.
That’s some sparse points that came to my mind reading your reply. Feel free to bug me if something wasn’t clear
Well I will not dive into the legal argument. The way I see it, laws
and their implications should concern all of us, even when they don’t
directly affect us.
I think we are talking about two very different things when we are
talking about about a dos-like security exploit around websockets/ddp.
Dos attacks are generally over the low level specs that run over the
tcp/ip stack. Hence its implications on http based services. That we
agree on. That I concur a low level service provider like a http server
(eg nginx) can/should have baked in protection.
On the other hand websockets is not a traditional request response
protocol, rather, it is another layer that reuses an initial http
handshake to continuously deliver two-way messaging. Now at this point,
the headers do not make sense any more, rather the content, the
websocket frames need to be examined.
DDP is another layer on top of that that constitutes a protocol made up
of the content of those frames having special meanin to both the client
and the server.
At this point, a protection layer on nginx/haproxy/varnish/apache/etc
must have definitive knowledge of what ddp is, how it works, and be
updated to every new release of ddp and its releant content that mutate
client/server states.
I just don’t see that efficiently applicable, that’s all. Do you?
I have already deployed it in production, so no, it doesnt seem impossible. But I’ve been working in cloud security fields for 3/4 years now, so it could be just a point of view.
So your deployed solution can be compiled with nginx as a module and
can in fact detect arbitrary piling calls to subscriptions and looped
calls to meteor methods that uses a valid initial ddp connection over
the browser?
