At the API layer, there isn't much that can be done in the way of prevention. However, Sails offers a few settings to mitigate certain types of DDOS attacks:
The session in Sails can be configured to use a separate session store (e.g. Redis), allowing your application to run without relying on the memory state of any one API server. This means that multiple copies of your Sails app may be deployed to as many servers as is necessary to handle traffic. This is achieved by using a load balancer ), which directs each incoming request to a free server with the resources to handle it, eliminating any one app server as a single point of failure.
Socket.io connections may be configured to use a separate socket store (e.g. Redis) for managing pub/sub state and message queueing. This eliminates the need for sticky sessions at the load balancer, preventing would-be attackers from directing their attacks against the same server again and again.
Note that, if you have the long-polling transport enabled in sails.config.sockets, you'll still want to make sure TCP sticky sessions are enabled at your load balancer. For more on that, check out this writeup about sockets on Deis and Kubernetes.
References
https://sailsjs.com/documentation/concepts/security/ddos
No comments:
Post a Comment