Responses to "10 step's to mitigate ddo s attacks"
0 likes390 views
The document critiques a white paper outlining 10 steps to mitigate DDoS attacks, arguing that the recommendations are mostly reactive and impractical for real-world scenarios. It emphasizes the need for businesses to adopt proactive measures and prepare in advance for potential DDoS threats, highlighting various assumptions made in the vendor's approach that fail to consider the complexities of modern attacks. Overall, it calls for businesses to recognize DDoS as a significant risk and develop a competent response strategy.
Responses to "10 step's to mitigate ddo s attacks"
- 1. Responses to 10 Steps in Mitigating DDoS Attacks in Real Time B V S Narayana CISSP, CISA @bvsnarayana03 layer4to7.wordpress.com
- 2. • Very recently a white paper was released by one of the IT vendor, on how to deal with a DDoS attack when they are struck with it. The document highlights 10 key factors, which they claim are the measures to be taken during the attack. But the document mostly deals with certain hypothesis and mostly approaches which are reactive in nature. • Next few slides highlight why these steps might not be helpful during DDoS crisis.
- 3. • Verify that there is an attack. Rule out common causes of an outage, such as DNS mis-configurations, upstream routing issues, and human error. • Response: This indicates that one should wait till they are attacked and not take any proactive measures to handle the attacks or mitigate them. This also hints at human intervention and decision to decide whether they are under attack or not. In such a scenario, one could most probably take a guess on the nature of traffic only if there is a spike. Otherwise, for any attacks which are taking place at normal traffic pattern are sure will be ignored. This puts any network at high risk.
- 4. • Contact your Team Leads. Here the vendor mentions that the network and application leads must be immediately contacted to verify the areas being attacked and to confirm the attack and areas affected. • Response: This is a tedious task and absolutely not sure if there would be a common affirmation for such case. On any normal day of business operation if the user complaints of slowness in application, both teams safeguard themselves and passes the blame on to the other team. Application team puts the cause of slowness on network and vice versa. How then under an attack scenario, one can expect the two teams to be cohesive and confirm whether or not its an attack and if it is, then confirm the magnitude.
- 5. • Triage your applications. The vendor mentions that during DDoS attack, focus should be on protecting the critical apps / revenue generators. Response: Now such decisions are a part of BCP/DR plan and the strategy is clearly defined on which apps are critical, when should the DR be invoked, what should be the RTO and RPO for such applications. One doesn’t decide about a critical application and the strategy to keep it live when struck by an attack. When under attack, you may affected at internet/mpls pipes, network devices like firewals, IPS, load balancer might be impacted, server infra might be hampered or the applications might be siffering. So irrespective of the strategy you have, even if you have good BCP in place, how do you ensure that the attack doesn’t reach your 2nd or 3rd DC or DR from where you host the business critical apps.
- 6. • Protect remote Users. Vendor asks to maintain White-List IP addresses and asks to propagate it across the network devices even up to the ISP. • Response: While internet is shrinking the world and businesses are striving to be available globally today, how easy it is for any organisation to know whether the genuine user should be hitting the application from US, UK, India etc. It is completely un-realistic and also not expected of the business to know the IP pool from where the users would access the application. Business in present era is all about being available to everyone from everywhere at all times. White-listing approach is not a fit and completely out of question to handle ddos.
- 7. • Classify the Attack. Whether the attack is Volumetric, Slow, Low? Service Provider must have already taken remediation steps. • Response: Here the hypothesis is that the customer is already subscribed to a mitigation service from ISP. Even bigger hypothesis is that the ISP is equipped to handle all types of DDoS attacks and is capable of identifying and mitigating them in real-time. If the hypothesis is correct and for assumption the ISP has really handled the attack, then what is the white paper published for? Customer if at all they are relying on the ISP, must understand what capabilities are built in his cloud to identify and mitigate various DDoS flavours. Whether the ISP is offering any SLA’s for availability, is there a level of transparency with customer on when the attack started, when it ended, actions taken, is there a portal for access to customer in real-time, whether the ISP is willing to sign a penalty clause in case attacks get leaked and reach to customer network.
- 8. • Evaluate Source address mitigation options. Vendor asks to identify the source of attacks and block the at firewall. Response: Gone are the days of DDoS attacks which emerged from a single source. Now with sophisticated tools and the reach of internet, attacks can be launched from anywhere from any no. of source IP’s, spoofed addresses, attacks might be coming from proxies or CDNs (which also carry legitimate traffic). How do you keep a track of the IPs in such scenario. Even if the IPs are tracked and ACL are applied at firewall or at perimeter routers, the attack has still reached those devices and might result in exhausting their resources or choking the entire service provider pipe.
- 9. • Mitigate Application Layer Attacks. Vendor asks to indentify whether the malicious traffic is generated by a tool. Specific application attacks might be mitigated by existing solutions. • Response: Here vendor has another hypothesis that the customer has intelligent solutions to handle L7 attacks. Application layer attacks are quite complex in nature and require specialised solution. They cant be identified and treated by generic security solutions like firewalls and IPS. Especially when the traffic is HTTPS, perimeter security solutions are incapable of handling such attacks.
- 10. • Leverage your security perimeter If attacks still persist, it could be asymmetric layer 7 ddos floods. • Response: Nothing of the above counter measures or suggestion were successful so it is obvious that the attacks would still persist in your network. But its too early to conclude on a specific attack type without having treated them at various levels.
- 11. • Constrain Resources. Vendor asks to rate-Limit all traffic. • Response: This is a severe concern and might be risk to revenue. If couple of genuine transactions get dropped in an attempt to block the attack traffic, there is high possibility of the consumer landing on to competitor business and thus you loosing the revenue. Rate-limit is good technique to manage QoS for out going traffic, but its very risky if using this for incoming traffic.
- 12. • Thus overall, the steps suggested in form of a white paper are completely helpless to a customer under attack. • There are various assumptions and hypothesis as indicated at relevant points, there seems lack of experience in handling such live scenarios under attack. • For any customer/business, the right time to be prepared to handle DDOS attacks is “NOW”. • Businesses has to be proactive in nature and should acknowledge that DDOS is a crucial factor if they are existing on internet. • Risk management documents should indentify DDoS as a crucial risk element. • There must be proactive measures and a competent response team to handle such attack patterns.