Suspicious subscription spikes

Yesterday we got suspicious sub rate spikes for one of the publication in our app (Meteor 2). It was sub rate growing from ~20 per minute to ~6000 per minute for about 30 minutes in a row each time (total 12 times). It’s the first time I see something like that in 2 years of this app being in production. Here is an example from Monti APM:

This subscription is for logged in users, and we don’t have public signup form (only our corporate clients can signup their users). Subscription looks like this:

Meteor.publish('tours', function(orgID,start,end) {

  const user = Meteor.user()

  if(!user || !orgID) return []

  const query = { 
    orgID: orgID,
    start: { $lte: start },
    end: { $gte: end }
  }
  if(!Roles.userIsInRole(this.userId, ['TOURS_MANAGE'], orgID)) {
    query.status = 'confirmed'
  }

  if(Roles.userIsInRole(this.userId, ['VIEW'], orgID)) {
    return ToursCollection.find(query)
  }
  else {
    return []
  }
  
})

What is surprising, that this subscription checked user roles collection, so it was some kind of logged in “user”. Here is screenshots from DB monitoring, showing role-assignment collection reads spikes:


Non of the other subscriptions or methods in the app was affected. There is nothing suspicious in the nginx logs. So it must be some kind of direct DDP activity.

I have no idea why it’s this one subscription in particular, nothing special about it. It’s never being subscribed without a few others at the same time.

I know I should add DDPRateLimiter to the subscriptions, but at this point I’m reluctant to do so — just curious to see if it will happen again.

I would be happy to hear if anybody has an idea what it could be, other than a targeted attack.

Check the traces in MontiAPM for the arguments. It may be an attack, but it also can be some bug in the frontend code, looping subscriptions forever. The latter combined with even one user who thought “maybe it was temporary” looks exactly the same :stuck_out_tongue:

(That’s how some people learn to never subscribe using current date with a millisecond precision.)

1 Like

Oh, thanks, I couldn’t find publications arguments in MontiAPM before, but took another look and succeeded.