I was informed on February 25th, 2020 that this article may no longer be correct or relevant.
In the Meteor docs for DDPRateLimiter, they have updated it to now allow rules to be created on an actual connectionId. As I understand it, this would effectively solve the problem that your blog article is about. The fact that connections are not being rate limited.
Meteor’s DDPRateLimiter was released into Meteor in version 1.2 with surprisingly little fanfare. I say this is surprising because DDPRateLimiter helps minimize one of the most prevalent risks found in nearly all Meteor applications: Denial of Service attacks.
By putting hard limits on the rate at which people can call your methods and subscribe to your publications, you prevent them from being able to overrun your server with these potentially expensive and time consuming requests.
Unfortunately, Meteor’s DDPRateLimiter in its current form only partially solves the problem of easily DOS-able applications.
Meteor’s Rate Limiter
In this forum post, Adam Brodzinski, points out that the "meteor.loginServiceConfiguration" publication within the core accounts-base package is not being rate limited by default. He argues that this exposes a serious vulnerability to all Meteor applications using this package who haven’t taken extra precautions.
Without an established rate limit on this publication, any malicious user can potentially exploit it by making repeated subscriptions. These subscriptions flood the DDP queue and prevent other requests from being processed.
The exploit allows you to turn any meteor app on and off like a light switch.
These types of method and publication-based Denial of Service attacks are fairly well documented, and they’re even discussed in the Guide. Be sure to take a look if this kind of attack is new to you.
A Chink In The Armor
The initial vagueness of Adam’s post intrigued me. I started digging deeper into how and when DDPRateLimiter is used by Meteor core. My sleuthing payed off!
I found a chink in the rate limiter’s armor.
The DDPRateLimiter is invoked on the server whenever a subscription is made, and whenever a method is called. These invocations are fairly simple. They increment either a "subscription", or "method" counter and use these counters to check if the current rate of subscription or method calls exceeds any established limits. If the subscription/method exceeds a limit, an exception is thrown.
However, there’s a third type of DDP interaction that can be abused by malicious users: the DDP connection process itself.
Meteor users SockJS to handle its WebSocket connections. You’ll find the actual code that handles these connections in the ddp-server package. The DDP server extends this connection hooking functionality and registers callbacks for handling DDP-specific WebSocket messages.
If you look closely at the "connection" event handler, you’ll notice that it makes no attempt to rate limit the number of connection requests.
In fact, the DDPRateLimiter doesn’t even have a "connection" type. This means that a single user can repeatedly spam a Meteor server with DDP/WebSocket connection requests, all of which will be happily accepted until the server runs out of resources and chokes.
If abused, this can bring down a Meteor server in seconds.
Protecting Your Application
Sikka, like DDPRateLimiter, is another Meteor package designed to enforce rate limiting. Unfortunately, Sikka also won’t help protect against this particular kind of attack.
Sikka works by hooking into the processMessage method found in Meteor’s livedata server. Unfortunately, the processMessage method is called after a WebSocket connection is established. From within this method, we have no way of preventing abusive connection requests.
As discussed, DDPRateLimiter in its current form won’t prevent this type of Denial of Service attack.
Thinking out loud, one potential solution may be to modify Meteor core and add a third rate limiting type: "connection". This new rate limit type could be incremented and validation within each "connection" event:
self.server.on('connection', function (socket) {
if (Package['ddp-rate-limiter']) {
var DDPRateLimiter = Package['ddp-rate-limiter'].DDPRateLimiter;
var rateLimiterInput = {
type: "connection",
connection: socket
};
DDPRateLimiter._increment(rateLimiterInput);
var rateLimitResult = DDPRateLimiter._check(rateLimiterInput);
if (!rateLimitResult.allowed) {
return socket.end();
}
}
...
If this technique works, extending the DDPRateLimiter in this way would give Meteor developers the power and flexibility to establish connection rate limits that make sense for their own applications.
Maybe this kind of functionality could even be implemented as a Meteor package, if the "connection" event listeners could be correctly overridden.
The surefire and recommended way of preventing this kind of attack is moving your Meteor application behind a proxy or load balancer like NGINX or HAProxy. Implementing rate limiting using these tools is fairly simple, and very effective.
Rate limiting on the network level means that abusively excessive requests to the /websocket HTTP endpoint will fail, which stops the WebSocket handshake process dead in its tracks, killing the connection before it hits your Meteor server.
I highly recommend moving your Meteor applications behind some kind of proxy layer, rather than exposing them directly to the world.
Final Thoughts
Denial of Service attacks in the Meteor world can be a scary thing to think about. The use of WebScokets and queue-based processing of DDP messages means that when they hit, they hit hard.
Fortunately, with the proper precautions, naive Denial of Service attacks are totally avoidable! Be sure to always rate limit your methods and publications, and move your application behind a proxy that does the same.