Let's talk about rate controls. We briefly discussed this before. But I would like to bring this up again, because this is an internal part of your defense mechanism against DDoS. This layer can be actually applied either at your router or at load balancer, or through another device supporting this functionality, like an IDS IPS solution, it depends on your infrastructure. Again, it's all about rules. So at this stage, I assume that you have already watched the previous video about firewalls and all unused ports are already filtered out.
What we are discussing here is kind of for the ports that are being used and not filtered. And for these ones, what I recommend is basically setting the thresholds for the traffic per source per destination and their combination If you decide to go with the source, you can do it by about just IP, or the combination of source IP and user agent. The latter is preferred. If the clients are always behind the net or proxy for tracking the combination, you can define session IDs on the application layer. Then setting rules for these thresholds, things like you know, if the number of SYN requests from a single source is more than 1000 per second, or you know if the destination receives 10,000 HTTP POST requests per second, things like that. Here, I recommend you to define rules for two categories overall, and first, overall is to track the request over a specific period of time like two minutes whereas burst is to track instantaneous hit windows like five seconds.
In other words, first you decide what to track source that nation or their combination, then you set the rules as shown here. And then you just assign an action to be taken when the rule that you set is triggered. And I recommend three actions at the rate control stage, either block monitor or a lot. Basically, what monitor is, it indicates that, you know something might be going on there. Just ensure that you track all the related traffic and based on the results of monitoring, if, for example, the traffic is still increasing, just block it, or On the flip side, after taking the action monitor. If things start to slow down, or after investigation, you conclude that it's not an actual attack to set the low.
So you can call monitor a yellow light in the traffic which indicates that something might be going on. So make sure to track it and based on the tracking satellite to either red or green And again, the first two best practices are pretty much the same. Logging is also extremely important at this stage. And for HTTPS. The same thing applies here as well. Since it is encrypted, and new best practices take care of the time to monitor flagged light traffic.
In other words, once the actual monitor is taken, you need to also define carefully for how long you want to monitor that traffic. Because as you can imagine, monitoring traffic takes a lot of resources from your devices. So once the threshold is exceeded, and the rule is triggered, and the action monitor is taken, you need to ensure that you are not overusing your resources just to track something. You need to define the time to be tracked for that flag traffic adequately.