Security: DDos

Jquery version try to trigger modules/Mobile/api.test.php a few times and the server will crash

@nilay.automatesmb Can you please get more input on this issue? Steps to reproduce.

@uma.s to reproduce, you will have to setup an environment through which you could make concurrent calls.

We hosted a CRM on t2.medium instance on AWS and upon doing concurrent calls to webservice or mobile api CPU utlization just went shooting.

You might say that this is not related to code or the server resources must be expanded.

But, the point here is to have a rate limiter on the Webservices or to have a queueing mechanism.

I’ve just done 100,000 calls on api.test.php on my local web server and apache didn't crash. maybe you are having issues with Apache/nginx/PHP/FPM/DB configuration? Unless you provide a more specific example it seems very hard to produce any meaningful advice/fix as I cannot replicate the issue.

@code80 were those request sequential or concurrent?

Server configurations are:

1. Ubuntu 16
2. Apache2 default configuration, with memory limit set to 256 MB
3. Database is MySQl with default configuration

@code80 logically, if you do 100,000 calls concurrently, that means the server must have atleast

60 MB * 100,000 of Physical memory available.

Think logically considering the nature of DDos attacks rather than be defensive.

And it is not just api.test.php even webservice.php

"Jquery version try to trigger modules/Mobile/api.test.php a few times and the server will crash" I've made a statement of fact: I wasn't able to crash my server with 100000 requests. Not sure how much more analytical can I be. Maybe you should start describing the experienced issue more clearly?

"But, the point here is to have a rate limiter on the Webservices or to have a queueing mechanism." DDOS attacks are mostly mitigated at firewall level not sure why would you have any limitation at app level.

How about the following:

1. having a rate limiter that would serve only configured no. of requests per minute
2. having a queue mechanism in place such that the requests are handled sequentially (or a defined no of requests at a given point of time, which could be configured)rather than starting a huge no. of processes at the same time, eventually exhausting the resources.

This would require no firewall for legit operations.

Unless the app has got a memory leak, all the issues you've decribed can be easily sorted with industry standard tools. Some examples:

https://blog.programster.org/rate-limit-requests-with-iptables https://www.percona.com/blog/2015/01/02/the-mysql-query-cache-how-it-works-and-workload-impacts-both-good-and-bad/ https://docs.nexcess.net/article/what-is-the-php-fpm-limit-max_children.html

https://blog.programster.org/rate-limit-requests-with-iptables

• it can block legit requests as well

https://www.percona.com/blog/2015/01/02/the-mysql-query-cache-how-it-works-and-workload-impacts-both-good-and-bad/

• there is no official documentation from Vtiger on these configurations

https://docs.nexcess.net/article/what-is-the-php-fpm-limit-max_children.html

• use rate limiter and queues, rather than giving error responses as the server cross max child configuration!

Have you had a go with load balancing? https://aws.amazon.com/elasticloadbalancing/

Have you had a proper look at php-fpm (or similar). It will deal with queueing (what you call sequential queueing).

Not sure what other advice I could give you

So are you saying:

To mitigate DDos use firewall.

For handling concurrent workload, use load balancing, optimize mysql parameters, look into php-fpm.

But just don't improve the CRM by adding a rate limiter?

To mitigate DDos use firewall. - correct For handling concurrent workload, use load balancing, optimize mysql parameters, look into php-fpm. - correct

Thefore with regards to the issue with "Security: DDos" that you've pointed out, I haven't got anything else to add.

Status changed to closed by commit cd8bebf3

Its good to control configuration at the Webserver end.

Okay.

Milestone changed to 7.2.0