Zero Day Hole found in Samsung FindMyMobile (CVE-2014-8346)

About FindMyMobile

Samsung FindMyMobile is a mobile web-service that provides samsung users different features to locate lost device, lock a device remotely so that no one else can use the device, or to play an alert on a remote device.


About the vulnerability

Original release date: 10/24/2014
Last revised: 10/24/2014



The Remote Controls feature on Samsung mobile devices does not validate the source of lock-code data received over a network, which makes it easier for remote attackers to cause a denial of service (screen locking with an arbitrary code) by triggering unexpected Find My Mobile network traffic.



CVSS Severity (version 2.0):
CVSS v2 Base Score: 7.8 (HIGH) (AV:N/AC:L/Au:N/C:N/I:N/A:C) (legend)
Impact Subscore: 6.9
Exploitability Subscore: 10.0
CVSS Version 2 Metrics:
Access Vector: Network exploitable
Access Complexity: Low
Authentication: Not required to exploit
Impact Type: Allows disruption of service


References to Advisories, Solutions, and Tools

By selecting these links, you will be leaving NIST webspace. We have provided these links to other web sites because they may have information that would be of interest to you. No inferences should be drawn on account of other sites being referenced, or not, from this page. There may be other web sites that are more appropriate for your purpose. NIST does not necessarily endorse the views expressed, or concur with the facts presented on these sites. Further, NIST does not endorse any commercial products that may be mentioned on these sites. Please address comments about this page to

External Source: MISC
External Source: MISC


Technical Details

Vulnerability Type (View All)


Credit:  NIST

DDoS + Breach = End of Business

A distributed-denial-of-service attack and subsequent data breach that led to the shuttering of source code hosting firm Code Spaces offers an eye-opening reminder: Beware of DDoS attacks used as a diversionary tactic to draw attention away from devastating hacking.

“With a DDoS attack, it’s all hands on deck with security [staff] focused on it,” says Rodney Joffe, senior vice president and senior technologist at security vendor Neustar. “They don’t watch for other subtle things occurring in the background.”


In addition to taking steps to mitigate the impact of DDoS attacks, organizations need to monitor for subsequent intrusions and ensure they have multiple backups to store mission-critical data that could potentially be exposed or deleted.

Defense against DDoS attacks should be considered a routine cost of doing business on the Internet, says Dan Holden, a director at Arbor Networks, a security firm. “No one is immune and the possible motivations of attackers leveraging DDoS are vast,” he says. “This could range from cybercrime, geo-political disagreement or competitive takeout.”



Code Spaces Attack

Code Spaces, in a message posted to the homepage of its website, says the DDoS attack against its servers and unauthorized access into the company’s cloud control panel resulted in most of its data, backups, machine configurations and offsite backups being partially or completely deleted.

“Code Spaces will not be able to operate beyond this point,” the company says. “The cost of resolving this issue to date and the expected cost of refunding customers who have been without the service they paid for will put Code Spaces in an irreversible position both financially and in terms of ongoing credibility.”

During the June 17 DDoS attack against Code Spaces’ servers, an unauthorized individual gained access to the company’s Amazon cloud control panel, leaving a number of messages for the company to contact the intruder using a Hotmail address.

“Reaching out to the address started a chain of events that revolved around the person trying to extort a large fee in order to resolve the DDoS,” the company says.

As Code Spaces worked to regain control of the cloud panel by changing passwords, the intruder created multiple back-up logins. “Upon seeing us make the attempted recovery of the account, [the intruder] proceeded to randomly delete artifacts from the panel,” the company says.

The incident took place over a 12-hour period, Code Spaces says. The company is now working on supporting affected customers and exporting back to them any remaining data stored with Code Spaces. “All that we can say at this point is how sorry we are to both our customers and to the people who make a living at Code Spaces for the chain of events that led us here,” the company says.

Code Spaces did not immediately respond to a request for additional information.


Lessons Learned

The attack against Code Spaces points to the need for organizations to segment their core services and have multiple backups in place.

“You cannot depend on a sole service for your business continuity,” says Michael Smith, a director at Akamai Technologies, a DDoS mitigation provider. “You need to put backups and business-critical data and functions in redundant services, locations and technologies so that they are not all impacted together.”

What made the incident against Code Spaces particularly devastating was the combination of a DDoS attack and an intrusion into the company’s systems.

“DDoS is survivable,” Smith says. “For it to be a business-ending event it has to be combined with other attacks. The direct cause was the hacking attack against their administration panel and the unavailability of their service because the attackers deleted storage groups and backups which were located in the same place with the same administrative access.”

One key issue was the fact that the backups for Code Spaces were accessible via the admin account, Joffe of Neustar says. “From the admin, the [hacker] was able to delete the backups or the mechanisms to get to the backups,” he says. With the way backups work now, files are moved electronically to other locations online. “The problem is it’s only electronically reachable,” he says. “If you have all the credentials in your master account, whoever takes over has the ability to find those files.”

As a result, there should be secure isolation between the administration domains of these systems, says Ashley Stephenson, CEO of Corero Network Security, “so that an attacker cannot compromise the backup or alternate site from the primary sites.”

Organizations need to identify the types of attacks to which they’re most vulnerable and develop steps to mitigate those threats, says Carl Herberger, vice president of security solutions at Radware. “This will help an organization see how, and, more importantly, if, they are covering the cyber-attack threats facing their environment.

“Today’s cyber-attacks are not just a nuisance and they are not isolated simple events,” Herberger says. “All too many believe that a cyber-attack is just about volumetric attacks and [all] you need to do is buckle down to weather a storm that will eventually pass. However, this event demonstrates how technical actions must be taken.”


CREDIT: bankinfosecurity

Sinkholes – Legal and Technical Issues in the Fight against Botnets

CREDIT: Pierluigi Paganini


The security community is observing a sensible increase of botnet activities, in particular of cloud-hosted botnets that are mainly based on the Amazon cloud architecture.

Amazon isn’t the only provider that’s been abused by cybercrime. “Cheap hosting” providers represent a privileged choice for bad actors because they usually implement a poor monitoring system and a put in place a few safeguards to prevent bad bot origination.

The financial services industry is the one that serves up the highest botnet traffic, according to recent research proposed by Distil Networks Security.

The DNS sinkhole is a technique adopted by principal security firms to analyze malicious traffic related to a botnet, spyware and any other kind of malware. The principle is very simple: security experts analyze outbound DNS requests for malicious domains and interfere with communications that occur between the infected machine within a targeted organization and the malicious domains that usually host malicious code and command and control servers.

The term sinkhole indicates a standard DNS server that is configured to provide non-routeable addresses in response to the DNS requests for all domains in the sinkhole. All the computers that refer to it for naming resolution will fail to get access to the real website.

Practically, DNS sinkholing consists of the spoofing of the authoritative DNS for malicious domains. The administrator configures the DNS forwarder for outbound traffic in a way to return wrong IP addresses for bad domains. With this technique, specialists can analyze the overall traffic to an unwanted domain, estimate the entity of an infection, and apply the necessary mitigation strategy.

“Sink Holes are the network equivalent of a honey pot.” (Green, Barry Reveendran & McPherson, Danny 2003)

The DNS Sinkhole technique could be used to decapitalize a botnet (destructive mode) by interrupting the bot access to the Command & Control servers, or to monitor the activities of bad actors (monitoring mode). DNS sinkhole could be used to mitigate different types of cyber threats that adopt DNS resolution.

One use is to stop botnets by interrupting the DNS names the botnet is programmed to use for coordination.

Security firms use it to analyze the connections to bad domains to discover the clients that have been compromised by the cyber threat.

To mitigate the threats, administrators could use the techniques interfering with all the connections to domains included in the lists of malicious domains. On the Internet numerous entities provide constant updates for these lists (e.g. SANS Internet Storm Center). Sinkhole administrators could benefit from these open sources that list bad domains. Let’s think, for example, to establish an intrusion detection policy based on the analysis of outbound DNS requests for the malicious domains included into public black lists (e.g. ). The administrators could also contribute to the improvement of the lists, providing further information elaborated from the observation of the infected systems within their infrastructure.

Note that there isn’t an official and authoritative list of sinkholes and the reason is intuitable. Sinkhole operators try to keep their structures reserved. To avoid that, botnet operators implement mechanisms to avoid sinkholes.

The DNS sinkhole technique doesn’t request a significant effort to network administrators. They could use a well-known DNS zone file to manage unwanted hosts and domains that are typically noted in public lists maintained by a community of security experts. The principal benefits related to the use of the sinkhole technique are its limited cost, scalability of solutions, and easiness to maintain.


One of most common Sinkhole solutions is based on an internal DNS sinkhole server that is used by administrators to impersonate an authoritative DNS server for blacklisted domains. Of course for single entities it is also possible to implement a sinkholing technique using the local host’s file.

The servers responds to the DNS queries for unwanted domains with private addresses. For the efficiency of the technique, it is crucial to maintain an updated list of malicious domains.

To improve overall security of systems, it is possible to adopt Intrusion Prevention Systems that analyze outbound DNS requests looking for anomalies in the related packers. A typical indicator for illicit activities is for example the presence of a packet with a a short DNS time-to-live (TTL). This setting allows us to rapidly propagate changes.

It is important to understand that DNS sinkhole is efficient to detect indicators for the presence of malware, but it could not be considered a method to detect or eradicate malware.

Another typical limitation of the technique is represented by its inefficiency to block malicious codes that don’t use an internal DNS server. Malware authors in many cases use IP addresses equipped with a built-in DNS server, which will never be detected by sinkhole servers of the targeted company.

As explained in a paper published by the SANS organization, a possible mitigation strategy for malware that doesn’t refer the internal sinkhole server is represented by the regimentation of outbound DNS queries. Administrators can authorize traffic only from authorized DNS servers.

One of the principal problems is represented by a false positive. A sinkhole erroneously blocks traffic to non-malicious domains with serious impact on the organization.

Malware inside our network

Once a victim machine is infected by attackers, via phishing attack or a watering hole, the malicious agent dropped on the machine resolves a malicious domain name to retrieve the IP address for the command & control server. The authoritative DNS server responds to the DNS query sent by the malware. In this way, the malicious core retrieves the IP address for the bot controller and establishes the connection.

The most simple DNS Sinkhole architecture includes the following components:

  • A DNS Sinkhole server.
  • A list of malicious and unwanted hosts and domains.

Figure – DNS Sinkhole (

In the above image is shown the flaw for domain name resolution in the presence of a Sinkhole server.

Also, in this case the infected machine tries to resolve a malicious domain name to retrieve the IP address for the command & control server. The DNS Sinkhole server intercepts the DNS query sent by the malicious code on the infected machine. The request is captured by the internal DNS Sinkhole server that acts as the authoritative DNS server and provides in response a fake IP address.

In the above scheme, the DNS Sinkhole receives the DNS request for the malicious domain and responds with an authoritative answer configured by the administrator. In this way, the bot will not be able to contact the command & control server.

In the image the DNS Sinkhole returns with an IP of to force the client to connect to itself instead the bot controller domain.

Real-time notification: Sinkhole and advanced detection

The identification of the malicious agent is just a part of the administrative work. With the sinkholing it is also able to partially contain the threat, but it must be considered that malware, despite being unable to reach the C&C server, could try to propagate itself within the network anyway.

To improve the above solution, it is possible to add an IDS with customized sinkhole signatures for realtime alerting. In a typical scenario which includes an Intrusion Detection System, the compromised machine resolves a malicious domain name to retrieve the IP address for the command & control server. The DNS Sinkhole server responds to the DNS query sent by the malware, and the infected machine receives a legitimate IP address of the network. The IP address sent to the infected client by the DNS sinkhole is a re-direct to an IP address controlled by the administrators. The administrator configures on this IP address a listening service on most common HTTP ports (e.g. 80, 8000, 8080) to detect malicious activities.

To monitor traffic to a malicious domain, it is possible to write an IDS signature for each sinkhole group. The IDS will detect each time an infected system is redirected to the sinkhole.

Figure – DNS sinkhole+ IDS

Sinkholing data … a growing business with technical and legal issues

The continuous growth of principal cyber threats has increased the demand of companies for botnet data. In response to the commercial request, a growing number of companies provides different threat data types including botnet victim identities, malicious and unwanted domains, bad URL information, and much more.

This information is precious for companies that want to protect their networks from threats.

Behind many of these commercial feeds offered on the market, there are sinkholes, and as explained by experts at Damballa, there are quite a variety of sinkhole approaches:

“Ranging from passive systems that simply catalogue the IP addresses of devices that attempt to connect to them (in response to a domain that’s been forcefully extracted from the hands of a cybercriminal), through to active systems that are more honeypot-ish in nature (that engage in digital conversations with malware victims), and anything in-between – but in essence the sinkhole exists to extract information about previous victims and/or attempt to neuter a communication channel associated with a particular threat.”

Are sinkhole data really reliable?

There are different legal and technical issues related to the sinkholing practice. Let’s start from the principal limitations related the use of the passive sinkhole to harvest botnet data.

  • DHCP Churn – ISPs typically assign residential IP addresses from pools of dynamic IP address ranges. It is impossible to predict how long an IP address is assigned to a specific machine that is detected by a sinkhole server. This can cause a false positive.
  • Network Address Translation (NAT) – If the victim’s network includes a firewall or a router, there is the concrete probability that the IP gathered by a sinkhole is not linked to the real identity of the infected machine. In this case also the extension of the infection is missed. Behind a single IP address there could be dozens or hundreds of compromised PCs.
  • Timing Windows – One of the most important factors to evaluate for botnet data harvested by sinkhole data is the time. If it’s not possible to uniquely identify the compromised machine, it is crucial to identify the frequency in which it reaches out to the sinkhole servers. This calculation is hard due to the issued described in the previous points, DHCP churn and NAT.
  • Darknet Scanning – Thousands of devices crawl the Internet for various purposes. As consequences, even “hidden” sinkholes and darknets are constantly being probed, which affects data collected by this monitoring architecture. This generates false positive identifications.

The above limitations have a serious impact on the fidelity of harvested data, but other serious considerations are related to the legal sphere.

  • Data drops – When security experts hijack traffic related to a malicious domain, and if the malicious domain was intended to be used as the drop location for the victim’s stolen data (e.g. an FTP server), then the administrator for sinkhole servers will collect a huge quantity of personally identifiable information (PII) and/or sensitive documents. The maintenance of this information must be regulated by law. In these scenarios, it must be also considered that sinkhole operators are perpetuating the abuse; for example, by sinkholing a malicious or unwanted domain name, the malware may continue to upload data, continuing to cause the loss of personal and confidential information.
  • Device failure – If the compromised machine fails due the impossibility to communicate with the C&C server, there is an objective responsibility of sinkhole administration. Critical functions executed by compromised machine could be impacted by sinkholing activity.
  • Compromised machines seizure – Once the compromised machine is identified, their control and seizure is the responsibility of law enforcement.
  • Unauthorized access – Sinkhole operators in some cases could be able to manage remote access to compromised machines that was originally granted to command and control servers. Sinkhole operators could not abuse these acquired privileges.

CASE study Sinkhole activities – CERT.PL

Poland CERT has recently published a report on the activities conducted during 2013. The organization was very active in the botnet takeovers, with the most prominent examples being Citadel, Zeus, Dorkbot, Andromeda and Sality.

CERT also identified a rogue domain registrar, Domain Slver Inc., which specialized in the creation of domains exclusively used for illicit activities.

“The agreement with Domain silver Inc. was terminated, and the domains were successively taken over by CeRT Polska. Due to these domain became a less attractive target for cybercriminals,” stated the CERT report.

The report also presents current trends in cyber threat scenarios, reporting details on principal incidents, but the scope of this post is to give visibility to their sinkholing operations.

The CERT data on botnets were collected from sinkhole and honeypot systems, P2P botnet crawlers, and not from antivirus systems. They used multiple sources to overwhelm the problems of fidelity described in the previous paragraph, helping to minimize the rate of false positives.

The experts at CERT discovered that in Poland there are not more than 300,000 infected computers active per day. They observed that there is a growing number of small botnets consisting of several thousand machines.

CeRT Polska has created a sinkhole server since 2012 to redirect malicious traffic from .pl domains. The IT architecture is composed of a DNS server, which responds with the appropriate IP address to the domain query, and a TCP server, which allows emulation of many types of C&C servers.

Domains are sinkholed by CeRT Polska servers in three ways:

  1. By changing the A-record – by the request of CeRT Polska, a registrar changes the domain A record to point to the IP address of the sinkhole server.
  2. By a takeover of a .pl domain – the records in the registry are changed to redirect the respective NS records to All queries of such domain are received by the sinkhole server and it replies with an appropriate IP address in response.
  3. As a side effect – if domain name(s) used in NS records of another domain are sinkholed, then that domain is also effectively sinkholed, because all queries for its names are resolved by the sinkhole server.

Figure – Domain Sinkholig CERT PL

In 2013, experts noticed several new botnets targeting Polish users. The criminal organizations behind them mainly targeted online banking customers. The malicious code served by cyber criminals was used to steal used login data and valid TAN codes to bypass the two-factor authentication process implemented by principal banking solutions.

Figure – Sinkhole data – CERT PL

Thanks to sinkhole activity, experts also verified that botnets are making large use of cryptography in the implementation of bots. Sinkholed Andromeda botnet used the RC4 stream encryption, the “Mobile Antivirus” application for Android phones used Aes encryption, and the popular CryptoLocker ransomware uses advanced cryptography.


In 2013, CERT PL received 12,674,270 submissions on 8,393,693 unique malicious URLs, including 1,486,066 submissions relating to 497,721 unique URLs in the .pl domain. The data confirm the intense activity of a criminal organization, an average of 1,363 malicious sites in the .pl domain per day.

Figure – Malicious domains 2013 (CERT PL)

The following table reports the list of the countries where servers with malicious sites in the .pl domain were located. In previous year the situation is unchanged, Poland is confirmed at the first place of the ranking.

Figure – Countries with malicious domains


Sinkhole activity is a crucial part of botnet tracking. It is a powerful technique largely adopted by security firms, but is important to consider that it must be integrated with other methods to maximize its efficiency and fidelity of its data, reducing to a minimum value the occurrence of a false positive.

Next time you read a security report, please carefully evaluate the data extracted with this technique. Now you certainly have more info to analyze them.




CREDIT: Pierluigi Paganini

Protect Apache web-server from application DoS attacks (Ubuntu)

This tutorial assumes that you have a running Ubuntu Server, that networking has been set up, and that you have ssh access.

Apache2 is the default web-server used by many Linux installations. It is not the only one available, or the best for all circumstances, but it covers many usage scenarios. During the installation, you may be asked which web-server to reconfigure automatically. Answer ‘apache2’.

Install Apache2

Use the following command to install Apache2 and other libraries.

$ sudo apt-get -y install apt-get install apache2 apache2.2-common apache2-doc apache2-mpm-prefork apache2-utils libexpat1 ssl-cert libapache2-mod-php5 php5 php5-common php5-gd php5-cli php5-cgi libapache2-mod-fcgid apache2-suexec php-pear php-auth php5-mcrypt mcrypt libapache2-mod-suphp libopenssl-ruby libapache2-mod-ruby

Update Timezone and Check Correct Time

To reduce confusion with shared or mirrored data, all servers ought to run as close to as in-sync as possible. Some cryptographic key management systems require accurate time. Lastly, for corporate servers, Sarbanes-Oxley and HIPAA Security Rules require accurate timestamping.

$ sudo apt-get -y install openntpd tzdata
$ sudo dpkg-reconfigure tzdata
$ sudo service openntpd restart

Disable AppArmor Conflicts

While AppArmor is a suite that does provide an additional layer of security, it is my opinion that custom profiles will need to be created for each system. That is something not covered in this tutorial. So for now, we are going to disable it to prevent conflicts with any default configurations.

$ sudo /etc/init.d/apparmor stop
$ sudo update-rc.d -f apparmor remove
$ sudo apt-get remove apparmor apparmor-utils

Note: disabling AppArmor is not recommended for a production web server. For those wanting to create a custom AppArmor profile, refer to the official documentation.

Stop DDoS Attacks

A DDoS attack is a distributed denial-of-service attack. An Apache module exists to stop such attacks.

$ sudo apt-get -y install libapache2-mod-evasive
$ sudo mkdir -p /var/log/apache2/evasive
$ sudo chown -R www-data:root /var/log/apache2/evasive

Append the following to the bottom of mod-evasive.load:

$ sudo nano /etc/apache2/mods-available/mod-evasive.load

DOSHashTableSize 2048
DOSPageCount 20            # maximum number of requests for the same page
DOSSiteCount 300           # total number of requests for any object by the same client IP on the same listener
DOSPageInterval 1.0        # interval for the page count threshold
DOSSiteInterval 1.0        # interval for the site count threshold
DOSBlockingPeriod 10.0     # time that a client IP will be blocked for
DOSLogDir “/var/log/apache2/evasive”

Stop Slowloris Attacks

An Apache modules also exist for Slowloris attacks, though the module name depends on which version of Ubuntu that you are using. For Ubuntu 12.10 or later:

$ sudo apt-get -y install libapache2-mod-qos

Then check configuration in qos.conf:

$ sudo nano /etc/apache2/mods-available/qos.conf
## QoS Settings
<IfModule mod_qos.c>
    # handles connections from up to 100000 different IPs
    QS_ClientEntries 100000
    # will allow only 50 connections per IP
    QS_SrvMaxConnPerIP 50
    # maximum number of active TCP connections is limited to 256
    MaxClients              256 
    # disables keep-alive when 70% of the TCP connections are occupied:
    QS_SrvMaxConnClose      180
    # minimum request/response speed (deny slow clients blocking the server,     
    # ie. slowloris keeping connections open without requesting anything):
    QS_SrvMinDataRate       150 1200
    # and limit request header and body (carefull, that limits uploads and 
    # post requests too):
    # LimitRequestFields      30
    # QS_LimitRequestBody     102400

Note: If you are running a version of Ubuntu prior to 12.04, use the following instead.

$ sudo apt-get -y install libapache2-mod-antiloris

Check config in antiloris.conf.

$ sudo nano /etc/apache2/mods-available/antiloris.conf
<IfModule mod_antiloris.c>
	# Maximum simultaneous connections in READ state per IP address 
	IPReadLimit 5 

Stop DNS Injection Attacks

Spamhaus is a module that uses DNSBL in order to block spam relay via web forms, preventing URL injection, block http DDoS attacks from bots and generally protecting the server from known bad IP addresses.

$ sudo apt-get -y install libapache2-mod-spamhaus
$ sudo touch /etc/spamhaus.wl

Append the config to apache2.conf

$ sudo nano /etc/apache2/apache2.conf
<IfModule mod_spamhaus.c>
  MS_WhiteList /etc/spamhaus.wl 
  MS_CacheSize 256 

Restart Apache to load new modules.

$ sudo service apache2 restart

Now the webserver has been installed and is up and running. Point your web browser at your domain for a default message that confirms you are working. As a final check, run the following to see if your server has any error message. If there are errors, you will want to Google them and address them now.

$ sudo tail -200 /var/log/syslog


New SNMP Reflection DDoS Attacks

The DDoS techniques have massively increased with the attackers becoming more skillful at working around the network security. A massive 300Gbps DDoS attack launched against Spamhaus website almost broke the Internet a year ago and also earlier this year, hackers have succeeded in reaching new heights of the massive DDoS attack targeting content-delivery and anti-DDoS protection firm CloudFlare, reaching more than 400Gbps at its peak of traffic.


Akamai’s Prolexic Security Engineering and Response Team (PLXsert) issued a threat advisory on Thursday reporting a significant surge in DDoS attacks last month abusing the Simple Network Management Protocol (SNMP) interface in network devices.
Simple Network Management Protocol (SNMP) is a UDP-based protocol which is commonly known and often used to manage network devices. SNMP is typically used in devices such as printers, routers and firewalls that can be found in the home and enterprise environments as well.


Just as DNS amplification attacks, SNMP could also be used in Amplification attacks because a cyber criminal can send a small request from a spoofed IP address in order to sent a much larger response in return.
Over the past month, researchers have spotted 14 Distributed Denial-of-Service (DDoS) attack campaigns that have made use of SNMP amplified reflection attacks. The attacks targeted a number of different industries including consumer products, gaming, hosting, non-profits and software-as-a-service, mainly in the United States (49%) and China (18.49%).


The Distributed Denial of Service (DDoS) attack is becoming more sophisticated and complex and so has become one of favorite weapon for the cyber criminals to temporarily suspend or crash the services of a host connected to the Internet.
The use of specific types of protocol reflection attacks such as SNMP surge from time to time,” said Stuart Scholly, the senior vice president and general manager of the Security Business Unit at Akamai. “Newly available SNMP reflection tools have fueled these attacks.


The attack only targets the devices that runs an older version of SNMP, i.e. version 2, which by default is open to the public Internet unless the feature is manually disabled. The latest version of SNMP, version 3 is more secure management protocol.
The cyber criminals made use of affective DDoS tools in an effort to automate the GetBulk requests against SNMP v2 that caused a large number of networked devices to send their entire stored data at once to a target in order to overwhelm its resources.
The attack is nothing but a distributed reflection and amplification (DrDoS) attack that allows an attacker to use a little skill and relatively small amount of resources in an attempt to create a larger data flood.


Network administrators are encouraged to search for and secure SNMP v.2 devices,” added Scholly. “The Internet community has been active in blacklisting the devices involved in recent DDoS attacks, but we also need network administrators to take the remediation steps described in the threat advisory. Network administrators can help prevent more devices from being found and used by malicious actors.”


Since 2013, Hackers have adopted new tactics to boost the sizes of Distributed Denial of Service (DDoS) attack which is also known as Amplification Attack’, leveraging the weakness in the UDP protocols. The most common is the (Domain Name System) DNS and (Network Time Protocol) NTP Reflection Denial of Service attack, but now cyber criminals have manage to use (Simple Network Management Protocol) SNMP to cause major damage.




Application Layer DoS Attacks Overview

Recent years have been very dramatic in security landscape with emerging threats; the application layer is now a more prominent target.  The new (and deadly) Layer 7 attacks called slow HTTP Denial of Service (DoS) attacks are on the rise.  Although they are not as new as they might sound, anything that is not frequently spoken of in the security world is often new!

In my experience, the common perception of DoS is a volumetric attack that occurs quickly, not slowly.  Traditionally, DoS/DDoS attacks have been volumetric, required a large number of clients and could be geographically distributed.  But slow attacks that consume minimal resources/bandwidth from the attacker side can still bring down your Web server.

Here are the results of using slowhttptest against a vulnerable Apache server in our lab environment.  The snippet below shows the tool in action where new connections are established very quickly with the server.  The Web server becomes unavailable after 5 seconds of launching the attack.

The HTML screenshot below shows the results of the same test.  The tool opens 1000 connections with rate of 200 connections per second, and the server is able to concurrently process only 351 connections, leaving the remaining 649 connections pending.


Why is this a problem?

  • These connections look like legitimate user connections.
  • Traditional rate detection techniques will skip them.
  • Existing IPS/IDS solutions that rely on signatures will generally not recognize them either.
  • They require very few resources and little bandwidth for execution.
  • Such attack can bring down a Web server, irrespective of its hardware capabilities.


How do these attack work?

Slow HTTP DoS attacks rely on the fact that a Web server will faithfully honor client requests.  The attacker’s motive is to send a legitimate-looking request to keep the server resources busy handling said requests for the longest time possible. If the attacker keeps adding to such long-ended requests, the server can quickly run out of resources.

Slow HTTP Denial of service attacks have different variants, but before we get into the details, let’s review the normal HTTP structure and flow:



HeadersPOST /account/login HTTP/1.1 CRLFAccept: */* CRLF

Content-type:  application/x-www-form-urlencoded CRLF

Content-Lenngth: 60 CRLF

Connection: keep-alive CRLF

Host: CRLF

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:22.0) Gecko/20100101 Firefox/22.0 CRLF



HeadersHTTP/1.1 200 OK CRLFServer: Apache/2.2.22 (Ubuntu) CRLF

Content-Type: Text/html CRLF

Content-Length: 200 CRLF

Date: Fri, 12 Jul 2013 05:31:32 GMT CRLF

Connection: Keep-Alive CRLF






The different stages of the request flow can be exploited to craft different types of slow attacks:

  • Slow HTTP Headers (Slowloris): In this attack, an attacker sends partial HTTP headers at a very slow rate (less than the idle connection timeout value on the server), but never completes the request. The headers are sent at regular intervals to keep sockets from closing, thereby keeping the server resources occupied.  Below is an illustration of such an attack.


  • Slow HTTP Post (RUDY): As the name suggests, an attacker will slowly POST the data to Form fields. The request contains all the headers with a legitimate Content-Length header (usually with a high value) making the server aware of the amount of data expected. The attacker now injects the data in the Form at a very slow rate, forcing the server to keep its resources busy expecting more data to arrive. Eventually the server runs out of resources. Below is an illustration of such an attack.


  • Slow Read Attack: The client sends a full request, but when the server responds, it advertises a very small TCP window for accepting response data. Thus the server sends data slowly to the client keeping its sockets open. It keeps probing the client to check its receive windows size while the client always advertises a small window size, slowing down the transfer. The larger the file size, the more time it will take to complete such connections. Multiple such requests for a large file can potentially DoS the server quickly.


CREDIT: David Senecal and Aseem Ahmed

NTP-based DDoS attacks

Over the last couple of weeks you may have been hearing about a new tool in the DDoS arsenal: NTP-based attacks. These have become popular recently and caused trouble for some gaming web sites and service providers. We’d long thought that NTP might become a vector for DDoS attacks because, like DNS, it is a simple UDP-based protocol that can be persuaded to return a large reply to a small request. Unfortunately, that prediction has come true.

The UK's Speaking Clock


DNS Reflection is so 2013

We’ve written in the past about DNS-based reflection and amplification attacks and NTP-based attacks use similar techniques, just a different protocol.

A reflection attack works when an attacker can send a packet with a forged source IP address. The attacker sends a packet apparently from the intended victim to some server on the Internet that will reply immediately. Because the source IP address is forged, the remote Internet server replies and sends data to the victim.

That has two effects: the actual source of the attack is hidden and is very hard to trace, and, if many Internet servers are used, an attack can consist of an overwhelming number of packets hitting a victim from all over the world.

But what makes reflection attacks really powerful is when they are also amplified: when a small forged packet elicits a large reply from the server (or servers). In that case, an attacker can send a small packet “from” a forged source IP address and have the server (or servers) send large replies to the victim.

Amplification attacks like that result in an attacker turning a small amount of bandwidth coming from a small number of machines into a massive traffic load hitting a victim from around the Internet. Until recently the most popular protocol for amplification attacks was DNS: a small DNS query looking up the IP address of a domain name would result in a large reply.

For DNS the amplification factor (how much larger a reply is than a request) is 8x. So an attacker can generate an attack 8x larger than the bandwidth they themselves have access to. For example, an attacker controlling 10 machines with 1Gbps could generate an 80Gbps DNS amplification attack.

In the past, we’ve seen one attack that used SNMP for amplification: it has a factor of 650x! Luckily, there are few open SNMP servers on the Internet and SNMP usually requires authentication (although many are poorly secured). That makes SNMP attacks relatively rare.

The new kid on the block today is NTP.


Network Time Protocol attacks: as easy as (UDP port) 123

NTP is the Network Time Protocol that is used by machines connected to the Internet to set their clocks accurately. For example, the address seen in the clock configuration on my Mac is actually the address of an NTP server run by Apple.

My Mac quietly synchronizes with that server to keep its clock accurate. And, of course, NTP is not just used by Macs: it is widely used across the Internet by desktops, servers and even phones to keep their clocks in sync.

Unfortunately, the simple UDP-based NTP protocol is prone to amplification attacks because it will reply to a packet with a spoofed source IP address and because at least one of its built in commands will send a long reply to a short request. That makes it ideal as a DDoS tool.

NTP contains a command called monlist (or sometimes MON_GETLIST) which can be sent to an NTP server for monitoring purposes. It returns the addresses of up to the last 600 machines that the NTP server has interacted with. This response is much bigger than the request sent making it ideal for an amplification attack.

To get an idea of how much larger, I used the ntpdc command to send a monlist command to a randomly chosen open NTP server on the Internet. Here are the request and response packets captured with Wireshark.

At the command line I typed

ntpdc –c monlist

to send the MON_GETLIST command to the server at The request packet is 234 bytes long. The response is split across 10 packets totaling 4,460 bytes. That’s an amplification factor of 19x and because the response is sent in many packets an attack using this would consume a large amount of bandwidth and have a high packet rate.

This particular NTP server only had 55 addresses to tell me about. Each response packet contains 6 addresses (with one short packet at the end), so a busy server that responded with the maximum 600 addresses would send 100 packets for a total of over 48k in response to just 234 bytes. That’s an amplification factor of 206x!

An attacker, armed with a list of open NTP servers on the Internet, can easily pull off a DDoS attack using NTP. And NTP servers aren’t hard to find. Common tools like Metasploit and NMAP have had modules capable of identifying NTP servers that support monlist for a long time. There’s also the Open NTP Project which aims to highlight open NTP servers and get them patched.


Don’t be part of the problem

If you’re running a normal NTP program to set the time on your server and need to know how to configure it to protect your machine, I suggest Team Cymru’s excellent page on a Secure NTP Template. It shows how to secure an NTP client on Cisco IOS, Juniper JUNOS or using iptables on a Linux system.

If you’re running an ntpd server that needs to be on the public Internet then it’s vital that it’s upgraded to at least version 4.2.7p26 (more details in CVE-2013-5211). The vulnerability was classed as a bug in the ntpd bug database (issue 1532).

If you are running an ntpd server and still need something like monlist there’s the mrulist command (see issue 1531) which now requires a nonce (a proof that the command came from the IP address in the UDP packet).

Neither of these changes are recent, ntpd v4.2.7p26 was released in March 24, 2010, so upgrading doesn’t require using bleeding edge code.

If you’re running a network (or are a service provider) then it’s vital that you implement BCP-38. Implementation of it (and the related BCP-84) would eliminate source IP spoofed attacks of all kinds (DNS, NTP, SNMP, …).



The black and white photograph at the top of this blog post shows the UK’s original speaking clock and the original voice of the clock Jane Cain. A common way to synchronize clocks and watches was to telephone the speaking clock to get the precise time.

Geeks like me will be amused that the NTP UDP port for time synchronization is 123 and that the telephone number of the UK speaking clock is also 123. Even today dialing 123 in the UK gets you the time.


CREDIT: CloudFlare

DOS Attack Types And Tools

Denial of service (DOS) attack, a type of attack on a network that is designed to bring the network to its knees by flooding it with useless traffic. Many DoS attacks, such as the Ping of Death and Teardrop attacks, exploit limitations in the TCP/IP protocols.


Teardrop attack

is type of attack where fragmented packets are forged to overlap each other when the receiving host tries to reassemble them.


Ping of death:

type of DoS attack in which the attacker sends a ping request that is larger than 65,536 bytes, which is the maximum size that IP allows. While a ping larger than 65,536 bytes is too large to fit in one packet that can be transmitted, TCP/IP allows a packet to be fragmented, essentially splitting the packet into smaller segments that are eventually reassembled. Attacks took advantage of this flaw by fragmenting packets that when received would total more than the allowed number of bytes and would effectively cause a buffer overload on the operating system at the receiving end, crashing the system. Ping of death attacks are rare today as most operating systems have been fixed to prevent this type of attack from occurring.


DDOS Attack:

A distributed denial of service attack (DDoS) occurs when multiple systems flood the bandwidth or resources of a targeted system, usually one or more web servers. This is the result of multiple compromised systems (for example a botnet) flooding the targeted system(s) with traffic. When a server is overloaded with connections, new connections can no longer be accepted.


Peer to Peer Attack:

Attackers have found a way to exploit a number of bugs in peer-to-peer servers to initiate DDoS attacks. Peer-to-peer attacks are different from regular botnet-based attacks. With peer-to-peer there is no botnet and the attacker does not have to communicate with the clients it subverts. Instead, the attacker acts as a “puppet master,” instructing clients of large peer-to-peer file sharing hubs to disconnect from their peer-to-peer network and to connect to the victim’s website instead. As a result, several thousand computers may aggressively try to connect to a target website. While peer-to-peer attacks are easy to identify with signatures, the large number of IP addresses that need to be blocked (often over 250,000 during the course of a large-scale attack) means that this type of attack can overwhelm mitigation defenses.

For all known DOS attacks, there are software fixes that system administrators can install to limit the damage caused by the attacks.

Top 10 Dos Attack Tools

1. LOIC (Low Orbit Ion Canon)
This tool was used by the popular hackers group Anonymous. This tool is really easy to use, even for a beginner. This tool performs a DOS attack by sending UDP, TCP, or HTTP requests to the victim server. You only need to know the URL of IP address of the server and the tool will do the rest.

2. HOIC: High Orbit Ion Canon HOIC
HIgh Orbit Ion Canon HOIC is Anonymous DDOS Tool. HOIC is an Windows executable file

High-speed multi-threaded HTTP Flood

– Simultaenously flood up to 256 websites at once
– Built in scripting system to allow the deployment of ‘boosters’, scripts
designed to thwart DDoS counter measures and increase DoS output.
– Easy to use interface
– C an be ported over to Linux/Mac with a few bug fixes (I do not have
either systems so I do
– Ability to select the number of threads in an ongoing attack
– Ability to throttle attacks individually with three settings: LOW, MEDIUM,
and HIGH –


XOIC is another nice DOS attacking tool. It performs a DOS attack an any server with an IP address, a user-selected port, and a user-selected protocol.

XOIC have 3 modes:
-Test Mode
-Normal DoS attack mode (No request counter and TCP HTTP UDP ICMP message because of performance )
-DoS attack with a TCP/HTTP/UDP/ICMP Message

4. Tor Hammer
Tor’s Hammer is a slow post dos testing tool written in Python. It can also be run through the Tor network to be anonymized. If you are going to run it with Tor it assumes you are running Tor on Kills most unprotected web servers running Apache and IIS via a single instance. Kills Apache 1.X and older IIS with ~128 threads, newer IIS and Apache 2.X with ~256 threads.

5. Anonymous-DoS
Anonymous-DoS is a http flood program written in hta and javascript, designed
to be lightweight, portable, possible to be uploaded to websites whilst still
having a client version, and made for Anonymous ddos attacks.

How does it work?
It will flood a chosen web server with HTTP connections, with enough it will
crash the server, resulting in a denial of service.

It is a tool for committing distributed denial of service attacks using execution on other sites.

7. PyLoris

PyLoris is a scriptable tool for testing a server’s vulnerability to connection exhaustion denial of service (DoS) attacks. PyLoris can utilize SOCKS proxies and SSL connections, and can target protocols such as HTTP, FTP, SMTP, IMAP, and Telnet.

8. Dereil
Dereil is professional (DDoS) Tools with modern patterns for attack via tcp , udp and http protocols . In computing, a denial-of-service attack (DoS attack) or distributed denial-of-service attack (DDoS attack) is an attempt to make a machine or network resource unavailable to its intended users.

9. Moihack Port-Flooder
This is a simple Port Flooder written in Python 3.2 Use this tool to quickly stress test your network devices and measure your router’s or server’s load. Features are available in features section below. Moihack DoS Attack Tool was the name of the 1st version of the program. Moihack Port-Flooder is the Reloaded Version of the program with major code rewrite and changes.

DDOSIM simulates several zombie hosts (having random IP addresses) which create full TCP connections to the target server. After completing the connection, DDOSIM starts the conversation with the listening application (e.g. HTTP server).

Java-Bot::Cross-platform malware launching DDoS attacks from infected computers

Java Bot, a Cross platform malware launching DDoS attacks from infected computers

These days botnets are all over the news. In simple terms, a botnet is a group of computers networked together, running a piece of malicious software that allows them to be controlled by a remote attacker.

A major target for most of the malware is still Windows, but the growing market of Mac OS X, Linux and Smartphones, is also giving a solid reason to cyber criminals to focus.
Recently, Kaspersky Lab has detected another cross-platform Java-Bot, capable of infecting computers running Windows, Mac OS X, and Linux that has Java Runtime Environment installed.
Last year, Zoltan Balazs – CTO at MRG Effitas submitted the samples of malicious Java application for analysis to Kaspersky Lab and they identified it as HEUR:Backdoor.Java.Agent.a.
According to researchers, to compromise computers, Java-Bot is exploiting a previously known critical Java vulnerability CVE-2013-2465 that was patched in last June. The vulnerability persists in Java 7 u21 and earlier versions.
CVE-2013-2465 description says:
An unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 21 and earlier, 6 Update 45 and earlier, and 5.0 Update 45 and earlier, and OpenJDK 7, allows remote attackers to affect confidentiality, integrity, and availability via unknown vectors related to 2D.
Once the bot has infected a computer, for automatic initialization the malware copies itself into the home directory, and registers itself with system startup programs. The Malware is designed to launch distributed denial-of-service (DDOS) attacks from infected computers.
It uses the following methods to start it based on the target operating system:
  • For Windows HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
  • Mac OS the standard Mac OS service launch is used
  • For Linux /etc/init.d/
cross platform java bot

The malware authors used Zelix Klassmaster Obfuscator (encryption) to make the analysis more difficult.  It creates a separate key for the classes developed due to which analysis of all classes has to be done to get the decryption keys.

cross platform java bot 2
The botnet executable contains an encrypted configuration file for the Mac OS ‘launchd service‘. It also encrypts internal working methodology of malware.
The malware uses PricBot an open framework for implementing communication via IRC. Zombie computers, then report to an Internet relay chat (IRC) channel that acts as a Command-and-control server.
The Botnet supports HTTP, UDP protocols for flooding (DDoS attack) a target whose details i.e. Address, port number, attack duration, number of threads to be used are received from the IRC channel.

Users should update their Java software to the latest release of Java 7 update 51 of 14 January 2014, can be found on Oracle’s Java website. The next scheduled security update for Java is on 14 April 2014.

Coordinated Attacks Against the U.S. Government and Banking Infrastructure

Cisco Blog > Security

Coordinated Attacks Against the U.S. Government and Banking Infrastructure

 | May 1, 2013 at 12:11 pm PST


On April 10, 2013, a collective of politically motivated hacktivists announced a round of planned attacks called #OPUSA. These attacks, slated to begin May 7, 2013, are to be launched against U.S.-based targets. #OPUSA is a follow-up to #OPISRAEL, which were a series of attacks carried out on April 7 against Israeli-based targets. Our goal here is to summarize and inform readers of resources, recommendations, network mitigations, and best practices that are available to prevent, mitigate, respond to, or dilute the effectiveness of these attacks. This blog was a collaborative effort between myself, Kevin TimmJoseph KarpenkoPanos Kampanakis, and the Cisco TRAC team.


If the attackers follow the same patterns as previously witnessed during the #OPISRAEL attacks, then targets can expect a mixture of attacks. Major components of previous attacks consisted of denial of service attacks and web application exploits, ranging from advanced ad-hoc attempts to simple website defacements. In the past, attackers used such tools as LOICHOIC, and Slowloris.

Publicly announced attacks of this nature can have highly volatile credibility. In some cases, the announcements exist only for the purpose of gaining notoriety. In other cases, they are enhanced by increased publicity. Given the lack of specific details about participation or capabilities, the exact severity of the attack can’t be known until it (possibly) happens.

Likely Avenues of Attack

Using previous attacks as indicators, there are three major categories in which likely attacks can be placed.

Vulnerable Software Exploitation
Some of the lowest-hanging fruit for attackers are systems that aren’t patched against current, well-known, or even old vulnerabilities. Always make sure your software and firmware are upgraded to the most recent vendor-recommended releases, and make doubly sure your edge devices are patched. For Cisco software and hardware, you can always check our PSIRT page for the latest information on Cisco security advisories and our Applied Mitigation Bulletin page for up-to-date information on techniques that use Cisco product abilities to detect and mitigate exploits.

Bandwidth Saturation
Against such common distributed denial of service (DDoS) attack tools as LOIC and HOIC, there are a few suitable mitigations, including the following:

These mitigations will be discussed in more detail below.

Moreover, the reader should note that some mitigations might only be able to drop attack traffic after it has saturated the victim’s link to the Internet. For example, we can block traffic at the Internet edge of the network of the web resource under attack. Even when that is achieved, the mitigation has not succeeded in protecting the infrastructure or resource under attack, since the Internet edge link is already saturated. In these situations, traffic must be blocked with the upstream Internet service provider (ISP). With this in mind, the mitigations below will prevent any internally compromised devices from triggering an attack, and the mitigations should be deployed close to the edge of these devices.

  • Unicast Reverse Path Forwarding (uRPF)
  • Reputation-based blocking (of compromised servers)
  • Access control list (ACL) filtering from the upstream provider

The mitigations themselves will be discussed in more detail below.

DNS amplification attacks, also known as DNS reflection attacks, leverage DNS ANY queries and Internet-based open DNS resolvers to amplify denial of service (DoS) traffic and overwhelm targets. Additionally, you make sure your DNS infrastructure adheres to industry best practice and your DNS servers should not function as open resolvers.

DNS amplification attacks should be expected in the event the operation takes place. Cisco has the following additional recommendations:

Resource Starvation
In contrast to the bandwidth consumption denial of service attacks, attackers can also starve off resources using so-called “low and slow” techniques. Tools in the Slowloris family, in addition to tools like R.U.D.Y., work by exhausting web server resources. The tools typically open a large number of connections to the target and slowly trickle small amounts of traffic using never-ending streams of data. Note that these attacks have been shown to use HTTPS as well as HTTP and in some cases odd port and protocol combinations such as UDP port 80.

Mitigating these attacks against affected web servers can prove challenging, but some of the methods to use include:

  • Increasing the maximum number of clients the web server will allow (you would want to ensure the web server can handle this increased load)
  • Reducing the number of concurrent connections a single IP address can have (this can cause problems for customers behind Network Address Translation [NAT] or proxied connections)
  • Imposing restrictions on the minimum transfer speed a connection is allowed to have (this can cause problems for customers on unreliable or very remote networks)
  • Reducing the amount of a time a client can stay connected (this too can cause problems for customers transferring large files or working in long interactive sessions)

Some of these mitigations can be enforced using network devices (firewalls) and will be discussed in more detail below.  The best defense will probably be to use a blended approach and utilize a combination of the above methods.  Finally, we even recommended moving affected web servers to software that is unaffected by this form of attack. It is worth noting that while the above mitigations can help, volumetric attacks can overwhelm any of these stateful devices used for mitigation.

Other network devices that can help in mitigating these types of attacks are:

  • Intrusion prevention systems
  • Web Application Firewalls ensuring web application conformance

Network Identification and Mitigation Technologies

The following technologies are extremely helpful in many different forms of attack detection and mitigation.

NetFlow is a protocol for collecting IP-based telemetry information about traffic flowing through a network. NetFlow offers a treasure trove of security-related information about who is doing what on the network and can be one of the early warning indicators of network misuse.
A few resources are below:

Source-Based Remotely Triggered Black Hole Routing
Remotely triggered black hole (RTBH) routing is a BGP-based DDoS mitigation technique for service providers and large enterprises. It works by injecting a NULL BGP route into the network, forcing all BGP routers to drop malicious traffic based on destination. This technique is effective at filtering attack traffic to Internet hosts, but it is also considered quite heavy handed. It some cases it is better to block only certain source IP ranges (blocking based on source address) rather than blocking all traffic intended for a single target (blocking based on destination address). Combining uRPF with RTBH routing, (known as Source-Based RTBH routing or S/RTBH routing) allows the network to null route based on source address, which will only block attacking source addresses. For more information, you can read our white paper and some additional resources can be found here:

Global Resources
For organizations that can leverage global data centers, geographical resource distribution can be an important DDoS protection. This can be achieved using global server load balancing (GSLB) or anycast. Anycast is a network addressing and routing methodology that provides an increase of speed and resilience. Using anycast, a single server is replicated in several physically disparate locations, all with the same IP address. Using GSLB or anycast, when a client wants to connect to the server, it is routed to the topologically closest node out of the group. Thus, by leveraging an HTTP/HTTPS termination point in each location, users throughout the globe will always reach the resource closest to them as shown in the figure below.


While complicated to set up, anycast presents a larger attack surface against would-be DDoS attacks. If one server is taken offline, users in other parts of the world will not be affected and mitigation can be deployed on the location that is attacked. Additionally, it would require many more resources for the attackers to take down all the locations. Of course, the requirement for this scheme to work is for a global infrastructure that can distribute the load.

In March 2013, anti-spam juggernaut Spamhaus came under a massive 75Gb/s DDoS attack. To mitigate the attack, they turned to Cloudflare and its massive anycast network.

Unicast Reverse Path Forwarding
Unicast Reverse Path Forwarding (uRPF) is a security feature enabled on the router that helps to limit the propagation of spoofed IP addresses. Please refer to a comprehensive white paper on what uRPF is and how configure it on a Cisco router and a paper on using uRPF to deter DoS attacks.

Tightening Connection Limits and Timeouts
For those of you with Cisco Adaptive Security Appliance (ASA) deployments, you can tighten connection limits and timeouts, which will reduce your susceptibility to some of the attacks mentioned above. For example, if the normal traffic to a web server is a quick connection of a few seconds, we may want to drop connections that are open for more than 5 minutes. Cisco provides a document explaining Cisco ASA connection limits and timeouts, such as how to set maximum TCP and UDP connections, maximum embryonic connections, maximum per-client connections, connection timeouts, and dead connection detection. When enabling embryonic connection limits, the Cisco ASA leverages its TCP intercept feature in order to enforce TCP SYN cookies that are used to mitigate the threat of TCP SYN flood attacks. TCP SYN cookies practically complete the TCP handshake before allowing the connection to the server, which ensures that spoofed traffic cannot waste TCP connections to the server. Resources are available for learning about SYN flood attacks and several mitigations. Readers should note that before changing connection limits, you must have a good understanding of the normal traffic profiles and baselines to ensure you do not inadvertently cause issues.

Reputation-Based Blocking
All Internet traffic must originate from an IP address. A plethora of organizations use various criteria and methods to rank, rate, and score IP addresses with respect to how “notorious” they are. More specifically, if a given IP address is known to be that of a spammer, distributing malware or a part of a botnet army, it can be flagged in one of the ill repute databases, often with a numeric score contextual to the rating system. For example, Cisco Email and Web Security and ASA Botnet Traffic Filter use an integral system from -10 for the worst offenders to +10 for the most angelic. Integrating with one of many IP reputation products or services available can help to reduce the malicious traffic generated by compromised servers.

Web Application Firewalls
A Web Application Firewall (WAF) is a device that provides firewall-like functionality to web-based applications. For organizations with substantial web-based applications, WAFs are recommended as a front-line defense against attackers. There is a thorough best practices document on WAF deployment.

Intrusion Prevention Systems
Intrusion prevention systems (IPS) are appliances that monitor the network for malicious activity. When malicious activity is detected, the IPS can alert or block the traffic and prevent it from entering your network.

Access Control Lists
Access control lists (ACLs) are used by network devices to restrict network traffic flows. Most of the time, ACLs are focused on filtering ingress traffic at network edge devices, specifically traffic that is considered provocative or malicious. A common but effective ACL methodology is to adopt a doctrine of least privilege where only what is absolutely necessary is allowed in. Cisco offers a detailed paper on how to configure ACLs on Cisco IOS Software. Note that using ACLs to block DDoS traffic can be challenging due to the dynamic nature of the attack and the management overhead it would introduce. Additionally, you can read up on transit ACLs and infrastructure ACLs.


Distributed denial of service attacks are a moving target. We may be familiar with many of the tools and how they look on a network, but until the actual attack we don’t know all of its characteristics. Now is a good time to re-evaluate your defenses and determine where they can be improved. When preparing for possible attacks it is best to cover as many possible attack vectors as possible. Yes, this means simple things like patching, monitoring NetFlow, working with Internet service providers, and having a strong incident response and contingency plan.