In our first two blogs concerning Distributed Denial of Service (DDoS) attacks and small service industries, we presented measures organizations can take to prepare for and defend against DDoS attacks. In this final installment on the subject, we will discuss methods of response to these incidents.
The first thing to do when you think you are under DDoS attack is to not panic. Calm and considered responses are always more effective than immediately jumping in and possibly cutting off legitimate connection requests. An ill-considered response on your part could cause the very denial of service your attacker intended in the first place. The best thing you can do is to immediately access your incident response plans and begin to implement those pre-planned procedures you worked so hard on. We are constantly amazed at how many organizations fail to follow their own response planning in the heat of a real incident!
The next step in the process is traffic (log) analysis. You need to be able to identify what type of attack is being perpetrated and the kinds of bogus requests that are being made. This is where large log capacities and log aggregation tools come in very handy. Being able to view a large amount of data from a central console truly helps you recognize patterns in the attack. Since application layer attacks that employ IP spoofing are presently being used, pattern and type recognition are often the only means you have to discern good traffic from bad.
Once you are able to get a handle on what the bad traffic looks like, you can start filtering it out. This is best done by appliances as close to the network edge as possible. You can also work with your ISP which may be able to assist with filtering as well as other mechanisms such as rate and connection limiting.
After the attack is under control, don’t forget to work with law enforcement agencies such as the FBI and US-CERT. They are interested in these events and may be able to assist you in finding and dealing with the perpetrators. Reporting incidents is important because it is crucial to know the number and types of DDoS attacks that are really taking place out there in order to effectively respond to them. Reporting ends up being good for everybody!
Finally, it is very important to conduct lessons learned meetings and to adjust your incident response and business continuity planning. Table top exercises and other incident preparation techniques are helpful, but nothing helps you learn the hard lessons like a real incident. Why waste the only valuable thing to come out of the whole mess!
This series is written by John Davis, MicroSolved, Inc.
In our first blog about Distributed Denial of Service (DDoS) attacks and small service industries, we discussed measures that organizations should take to prepare themselves for DDoS attacks. In this second installment, we will go over some methods that are useful in defending networks from these attacks. (The third and final installment in this series will deal with responding to DDoS attacks).
One good way to defend your network from DDoS attacks is to hire a service organization that specializes in the problem. They typically employ algorithm-based firewalls, large networks, monitoring, and other techniques to thwart these attacks, and can be very effective. However, these services are also pretty expensive and impractical for smaller organizations unless the threat level is very high indeed. The good news is that you can do a lot to defend yourselves from DDoS attacks.
The first step is knowing exactly what it is that you are defending. Computer networks tend to grow organically and it is a sad fact that most organizations have a very imperfect picture of how their networks are set up and how they behave. To defend against DDoS, it is important to know what typical network traffic looks like throughout the business year. This helps you set proper thresholds for automated detection devices and ensures quick detection of the onset of events such as DDoS attacks.
Another step you can take to help defend against DDoS attacks is to consider a cloud-based approach for your web services. With the traffic volumes DDoS attacks can currently generate, internal web servers at smaller organizations are sure to be overwhelmed. But by employing a content distribution network in a cloud setting you vastly increase your capacity, reduce the chance of any one server becoming unserviceable and are able to deal with the event more efficiently.
It is also important to work with your Internet Service Provider (ISP) during DDoS attacks. Your ISP could help in many ways including source blocking, scrubbing, load distribution and rate limiting. In addition, it should be remembered that many DDoS attacks are launched as diversions to cover up other attacks against organizations. Ensuring that your network is properly enclaved and monitored can go a long way in protecting your information and control assets during these attacks.
This series is written by John Davis, MicroSolved, Inc.
This post introduces a 3 part series we are doing covering distributed denial of service attacks (DDoS) and helping organizations prepare for them. The series will cover 3 parts, Prepare, Defend and Respond.
Part 1 of 3 – Prepare.
Distributed Denial of Service (DDoS) attacks use networks of compromised computers (botnets) or web servers (brobots) to flood organization websites with so much traffic that it causes them to fail. This is especially worrying for financial institutions and utilities which rely so very heavily on the availability of their services and controls. DDoS attacks are also mounted by attackers to hide fraud or other hacking activities being perpetrated on networks. Although these types of attacks are not new, they are presently increasing in frequency and especially in sophistication. Application layer DDoS attacks do a good job of mimicking normal network traffic and recent DDoS attacks have been measured at a huge 65 Gb (nearly 10 times the previous high point). The purpose of this blog is to discuss some methods small organizations can employ to properly prepare for DDoS attacks. (Later articles in this series will discuss means for defending against and responding to these attacks).
The first thing any organization should do in this effort is proper pre-planning. Ensure that DDoS is included in your risk assessment and controls planning efforts. Include reacting to these attacks in your incident response and business continuity plans. And as with all such plans, conduct practice exercises and adjust your plans according to their results. In all our years in business, MSI has never participated in a table top incident responce or disaster recovery exercise that didn’t expose planning flaws and produce valuable lessons learned.
Next, your organization should consider DDoS when choosing an ISP. It helps immensely to have an Internet provider that has enough resources and expertise to properly assist if your organization is targeted for one of these attacks. Ensure that you develop a close relationship with your ISP too – communicate your needs and expectations clearly, and find out from them exactly what their capabilities and services really are.
Finally on the preparation side of the problem, make sure that you keep well informed about DDoS and the actual threat level it poses to your organization. Keep active in user groups and professional organizations. Use the net to gather intelligence. The Financial Service Information Sharing and Analysis Center (FS-ISAC) has plenty of useful and up to date information on DDoS. You can even turn the World Wide Web against the enemy and use it to gather intelligence on them!
–This article series is written by John Davis of MSI.
PS – This is NOT a problem you can “purchase your way out” of. Organizations can’t and should not buy huge amounts of bandwidth as a preparation for DDoS. The cost impacts of such purchases are not effective, nor is bandwidth size an effective control in most cases. Note that some technology solutions for packet scrubbing and the like do exist. Your milage may vary with these solutions. MSI has not reviewed or tested any of the DDoS technology products as a part of this series.
A vulnerability has been reported in Avaya Call Management System that can be exploited to create Denial of Service. For more information see the original advisory at:
An independent researcher, Luigi Auriemma, has found several vulnerabilities in Version 7.53 of HP’s OpenView Network Node Manager. These include a format string error and stack based buffer overflows and Denial of Service issues. All of the vulnerabilities were discovered within the ovalarmsrv.exe process which listens on ports 2953 and 2954. If you are running this product you should ensure that access is limited to known and trusted parties. The original advisory can be found at: http://aluigi.altervista.org/adv/ovalarmsrv-adv.txt
The Cisco Systems Product Security Incident Response Team release a group of security advisories today. The majority of the vulnerabilities can result in Denial of Service for multiple products. Here’s the round up:
Cisco IOS Virtual Private Dial-up Network Denial of Service Vulnerability
Devices running certain versions of Cisco IOS prior to 12.3 with VPDN enabled may be affected by the vulnerabilities. The vulnerabilities are a result of a memory leak and an inability to reuse virtual interfaces. See the original advisory for full details:
Vulnerability in Cisco IOS with OSPF, MPLS VPN, and Certain Processors
Some Cisco Catalyst 6500 Series and Cisco 7600 Routers running particular branches of Cisco IOS based on 12.2 may be vulnerable to a denial of service vulnerability. To be vulnerable they must be configured to use OSPF and MPLS enabled VPNs. Products known to be vulnerable are based on the Supervisor Engine 32 (Sup32), Supervisor Engine 720 (Sup720) or Route Switch Processor 720 (RSP720). See the original advisory for full details: http://www.cisco.com/warp/public/707/cisco-sa-20080326-queue.shtml
Cisco IOS User Datagram Protocol Delivery Issue For IPv4/IPv6 Dual-stack Routers
Devices running Cisco IOS software with Internet Protocol version 6 (IPv6) enabled may be subject to a denial of service attack. To be vulnerable the device must also have certain Internet Protocol version 4 (IPv4) User Datagram Protocol (UDP) services enabled. See the original advisory for full details: http://www.cisco.com/warp/public/707/cisco-sa-20080326-IPv4IPv6.shtml
Multiple DLSw Denial of Service Vulnerabilities in Cisco IOS
All devices running Cisco IOS with the Data-link Switching (DLSw) feature enabled may be susceptible to a vulnerability that can result in a reload or memory leak when processing specially crafted UDP or IP Protocol 91 packets. See the original advisory for full details: http://www.cisco.com/warp/public/707/cisco-sa-20080326-dlsw.shtml
Cisco IOS Multicast Virtual Private Network (MVPN) Data Leak
All devices running Cisco IOS and configured for MVPN are susceptible to a vulnerability that can allow an attacker to receive multicast traffic from other MVPN networks. See the original advisory for full details: http://www.cisco.com/warp/public/707/cisco-sa-20080326-mvpn.shtml
Multiple F-Secure products contain unspecified issues in their handling of archive files. This could allow specially crafted archive files to be used as an attack vector. The results of a successful attack could cause a Denial of Service or possibly result in the compromise of the affected host. The products at risk are:
F-Secure Internet Security 2008
F-Secure Internet Security 2007
F-Secure Internet Security 2007 Second Edition
F-Secure Internet Security 2006
F-Secure Anti-Virus 2008
F-Secure Anti-Virus 2007
F-Secure Anti-Virus 2007 Second Edition
F-Secure Anti-Virus 2006
F-Secure Client Security 7.11 and earlier
F-Secure Anti-Virus Client Security 6.04 and earlier
F-Secure Anti-Virus for Workstations 7.11 and earlier
F-Secure Anti-Virus Linux Client Security 5.54 and earlier
F-Secure Anti-Virus for Linux 4.65 and earlier
Solutions based on F-Secure Protection Service for Consumers version 7.00 and earlier
Solutions based on F-Secure Protection Service for Business version 3.10 and earlier
F-Secure Mobile Anti-Virus™ for S60 2nd edition
F-Secure Mobile Anti-Virus™ for Windows Mobile 2003/5.0/6
F-Secure Mobile Security™ for Series 80
F-Secure Anti-Virus for Windows Servers 7.01 and earlier
F-Secure Anti-Virus for Citrix Servers 7.00 and earlier
F-Secure Anti-Virus Linux Server Security 5.54 and earlier
F-Secure Anti-Virus for Microsoft Exchange 7.10 and earlier
F-Secure Internet Gatekeeper 6.61, Windows and earlier
F-Secure Internet Gatekeeper for Linux 2.16 and earlier
F-Secure Anti-Virus for MIMEsweeper 5.61 and earlier
F-Secure Messaging Security Gateway 4.0.7 and earlier
Details on patching the products list above can be found at:
Avaya has released an advisory covering CMS R12, R13/R13.1, R14 and Avaya IR 2.0, 3.0 that contain vulnerabilities that could lead successful security bypass or remote Denial of Service attacks. The issue at hand is actually in the underlying Solaris firewall. Full details can be found in the original advisories:
Two new vulnerabilites have been reported in Symantec’s Veritas Storage Foundation product. Both are primarily Denial of Sevice issues, but one may lead to the execution of arbitrary code. This more serious issue is caused by input validation issues in the Administrator Service and can be exploited by sending a specially crafted packet to one of the products default ports, 3207/UDP. This vulnerability affects version 5.0 on both Windows and Unix/Linux systems. The lesser vulnerability is also caused by an input validation issue, this time in the Veritas Scheduler service. It can be exploited by sending a specially crafted packet to the default port 4888/TCP.
The original Symantec advisories are available at:
VMWare has released new patches that address vulnerabilities in Tomcat and Java JRE that could lead to compromise of systems, Denial of Service or the ability to circumvent security restrictions. The updates are for VirtualCenter 2.0.2, ESX 3.0.1 and ESX Server 3.0.2.
The original VMWare announcement can be found at: http://lists.vmware.com/pipermail/security-announce/2008/000003.html