Fending of DoS attacks against nats-server by auto-revoking auth-keys

[dsidirop]

Let's assume we have 100k accounts in a nats-fueled infrastructure each one enjoying their own auth-credentials.

Let's assume that one of them has his auth-credentials leaked and attackers exploit the credentials to launch an attack against nats by either (a) spamming a huge volume of traffic towards nats (b) opening millions of connections towards nats

It's indeed documented that nats does in fact support revoking the auth-keys of the affected account:

https://docs.nats.io/using-nats/nats-tools/nsc/revocation

How would you advise making the revocation process automatic to make the system recover elegantly all by itself from these DoS attacks?

(a) Does nats support setting some "auto-revoke" policy for auth-keys so that if it detects that a certain account is misbehaving to knock it out of commission by promptly revoking its auth-key?

(b) If nats doesn't have the aforementioned auto-revoke feature (and there are no plans to implement it either) is it possible to use something like 'nats top' or some rest-api to scrape metrics and send them to prometheus (or w/e) in order to alert ourselves in case we notice a DoS attack and revoke the auth-key(s) involved there to deactivate the exploited account(s) that the attackers are abusing?

Thanks in advance!

[derekcollison]

We do not have auto-revoke, that is very semantic and needs quite a bit of context.

For the above issue, you can limit both the server and accounts to the number of connections they are allowed etc. You can also of course lock down what users can do as well.

So for the system to be responsive in terms of a new admin account connection during this time, set its connection max to a number higher (in aggregate across the whole system) than the account's max.

[dsidirop]

@derekcollison

Thank you for the prompt response - much appreciated.

We do not have auto-revoke, that is very semantic and needs quite a bit of context.

Understood. In retrospect it indeed makes absolute sense that auto-revoke would be "a bit too harsh" as an out-of-the-box feature when taking into account all the implications.

you can limit both the server and accounts to the number of connections they are allowed

Thumbs up for the insight! I had searched through the configuration parameters of the nats-server for the 'accounts' but I couldn't (and still can't) spot a clear example which show-cases how to set the connection-limit for each account.

( I have only found a section show-casing the global connection-count limits )

Based on https://github.com/nats-io/nats-server/blob/main/server/configs/accounts.conf I assume one could do something like this (but not sure - I would be happy to stand corrected):

   accounts: {
     some_user_acount_name_here: {
       nkey: ADMHMD...
       max_connections: 10,   <---- is this correct name for the property?

       users = [
         # Bob
         {nkey : UC6NLCN7...
         # Alice
         {nkey : UBAAQWT...
       ]
   }

Thank you again for everything!

[derekcollison]

Here is a very simple one to get you started.

server_name: S22
max_connections: 1024

no_auth_user: nats22

accounts {
  default: {
    users = [ { user: nats22 } ]
    limits = {
        max_connections: 256
	max_payload: 4k
    }
  }
}

@gcolliso @jnmoyne We should make sure the docs have the account limits section documented.

[dsidirop]

You're a legend! (But I'm not telling you something you don't already know! :) )

[derekcollison]

If I was a legend it would have been in the docs ;)