DoS / DDoS protection in ecommerce and fintech
Intro
There are dozens of resources on the Internet which cover protection against denial-of-service attacks. I don’t want to repeat them again and give the definition. This attack type has been known for decades. No sense to retalk old commonly known stuff. So, is it really necessary to create another one article about it? Let’s sort it out.
It’s obviously that ecommerce and fintech have specific features. Like key trading period, high availability of personal account, global availability of marketplace and public API. These things give cool opportunities for adversaries. They could save resources and aim their tools to the most weak services in your website.
Successful attack against some specific critical service can significantly increase the competitor’s revenue in high trading period. It’s really quite simple monetization. There are many facilities in dark web which help you to do unexpected load testing of your business opponent. He only has to find the most vulnerable and critical service in your site. It leads us to service-oriented protection approach. We must take into account the specific of service when design the DoS protection.
There is no point in attacking the entire site. Just break down an authentication. Online store becames useless if customer can’t login and place the order.
Ok, it’s clear. Let’s have a look at defensive side. We’ll take a walk from common to more particular things.
Protection
Basic
These days many CDN providers give this basic protection for free. It makes sense, cause these attacks could bring harm for the network of providers themselves. Each edge server has the limited amount of memory and cpu, each network device has limits for throughput rate, so CDN providers have to implement at least an essential protection mesures. Under hood it mostly ordinary rate limits on the network level.
Example - AWS Shield Standard. AWS claims the protection works in transparent mode without any latency for services.
Rate control
Rate control is definitely the most common method to protect against extensive amount of requests. To define it we apply the specific thresholds for each HTTP method and web service.
At first it should be GET and POST methods. GET as the most common request type. Most of page view requests consist of GET. POST is the most common method for content delivery. When user type something in user input it delivered to back end.
How to define the thresholds? This isn’t a simple question. The rate control thresholds are always a tradeoff between security and availability. My recommendations here:
- Thresholds should be adaptive and depends on several attributes like source type (is a service or person expected?), API method (requests to payment system or authentication should be rear, but business eventing is often for exmaple), time (day or night, high trading period or not), HTTP Method (GET, HEAD, POST, PUT, etc.)
- It’s good practice to define thresholds on at least two criteria — burst threshold (short period of time, to process spikes) and average threshold (long period, to get smooth estimation).
- Also, I can advise you to ask your QA team about latest load testing (stress testing) results. It’s pretty likely they already performed some kind of DoS attack against companies’ apps.
The main idea is to find the point when requests bring a really serious performance degradation in your services (data base primarily). In case of application DoS attack the things are different. For exmaple ReDoS attack can be sourced jsut from one host but breaks down multiple web services.
As soon as you define your rate limits, implement them in most safe way. At first do test on staging, review results and move to production. Run it there in monitring mode and perform tests again. Apache JMeter is the one of the most poplar tool for that. Keep in mind PPDIOO methodology when making such critical changes.
Other reasonable things
- Don’t forget to forbid unused HTTP methods. Developers often use a framework without understanding how it works. So it brings risks when your application receives DELETE requests but it didn’t designed for it.
- If your app is designed only for web — deny All UDP Traffic and allow only TCP/80 and TCP/443.
- If you use CDN provider then always restrict access to origin. Also don’t expose service to the public access if it is not required. Yeah, so simple way for attack vector elimination.
- Implement geo restrictions. Do you have a business in ip source country? If it isn’t just close all network access from that country. It reduces the scope of attack surface. White / black listing can be one of the defense lines in your protection.
- Anti-bot protection — there is a growing security market of anti-bot protection. It isn’t WAF. It mostly combination of ML and reputation services delivered through SECaaS or SaaS. DoS is just the one of many threats which covered by them. It’s expensive, but effective. Akamai Bot Manager is one of these solutions.
- Consider an interaction with partners by using JWT tokens. Make sure you implement it in the secure way.
- Notify your partners about allowed rate limits. They should know how to design their app to interact with yours well. But keep secret other rate limits. For example customers of online store don’t need to know the borders of suspicious behaviour.
How to implement these recommendations? In general there are two ways to do it.
- Infrastructure way — implementing WAF, reverse proxy and some load balancers.
- SLA way — ISP or CDN providers can give you DoS protection as a service.
The best and the most expensive way — apply both of them =)
OK, it’s done. So, what’s next? Next steps will be monitoring and creating alerts. Looking for anomalies and identification of attack pattern. DDoS attack detection and mitigation is always a challenge for security specialist. But this is subject for separate article.
