DDoS attack management using ACLs and AWS Lambda

Through this blog post we will speak in a detailed way about how the Enimbos’ team faced and managed a DDoS attack through the use of ACLs and AWS Lambda from a client who come to us searching a fast and completely effective solution to maintain customer and user demand:


1       Description

The client communicates us his need to establish an access control, due to the sporadic appearance of a large number of errors 404. The use of AWS WAF to manage the control of requests was raised at first, but it was necessary to have a greater solution control. The need to make a series of white lists due to the development tasks on the website, led to the need to propose a dynamic solution.


2       Solution provided

After considering the use of solutions managed by the cloud provider, it is concluded that it is better to develop an own solution according to the requirements proposed by the client. Taking into account these criteria and the need for a dynamic service, capable of separating and detecting false positives whenever a minimum of requests is exceeded, it is decided to use microservices to achieve this objective. Specifically, the proposed solution was based on AWS Cloudwatch (Alarm and error manager launch) and AWS Lambda (Error management using the Amazon API).

Therefore, if a recognizable address pattern was found at a time, these addresses would be added to an access control list. All addresses contained in that list would have blocked access to the page.

The use of recognition patterns allowed us to manage this issue in a safer and more efficient way, avoiding the occurrence of false positives using a double general verification -> specifies.


3       Internal function

First, the active instances of the scaling group for reading AWS Cloudwatch and the log of the current instances were consulted:

Then, the last log records were consulted and processed; getting a list of all requests made to the web application. To optimize the processing and thus reduce the attack time, only suspicious requests were scheduled to be stored:

For each suspect IP, the number of occurrences in the records was calculated and, if that number was greater than a previously established threshold, it was automatically added to the IP blacklist by creating a rule in the access control list . To avoid false positives, the range of IPs used by developers was added to a white list of addresses:

Finally, to maintain control and administration of the security service, a message was scheduled to be sent to the system administrators each time an attack was detected:

Related Posts