Denial Of Service

The very first DoS attack, way back in 1999, occurred when a network of 114 computers at the University of Minnesota were infected with a malicious script called “Trin00”. Twenty years later, and DoS attacks are now one of the most common and most difficult types of attacks to address.

HOW DOES IT WORK?

Most DoS attacks flood a target with so much traffic that it simply cannot respond or crashes, preventing access for legitimate users. Affected services include email, websites, online accounts, and remote working services. For this reason, DoS attacks cost organisations both time and money - how can you continue to operate when your employees cannot access your network or your website no longer responds?

THE MOST COMMON ATTACKS INCLUDE:

There are many different types of DoS attacks, but let's take a quick look at a few:

SMURF ATTACK: The adversary asks the target machine whether they are experiencing any communication problems and whether data is being received in a timely manner. This is known as an ICMP or ‘ping’ request. The attack is successful because the adversary generates hundreds of these ping requests from fake systems and the targeted machine crashes when trying to reply to them all.

SYN Flood: The adversary asks the target machine whether it is happy to connect and communicate. The connection process requires 3 distinct steps (known as the 3-way handshake), but the attacker’s machine never completes these steps. Instead, it sends more and more requests to connect, leaving the server in a metaphorical limbo and unavailable for legitimate users.

TEARDROP: If someone wanted to send information to another computer over the internet, the message is broken down into tiny 'packets' of data. This is known as 'fragmentation'. Of course, these packets contain instructions so that the recipient machine, can reassemble them into the original message. In a teardrop attack, a cybercriminal will 'fudge' these packets so that the receiving machine gets confused and crashes.

EXPLOITS: Web pages are stored on web servers such as Apache and Tomcat. Web servers are a bit like restaurant waiters. They greet you at the door; check your booking information, and then bring you lunch. Similarly, the web server runs a few security checks on you and then brings you the website you wanted to look at. It will also clean the table when you are done (by wiping memory, cache, modules etc.) for new customers. Of course, if the web server contains out of date software, has default configurations or some other form of intrinsic vulnerability, an attacker can launch an 'exploit' - to knock that server offline.

OTHER TYPES OF ATTACKS: Can include the use of radio jammers to interfere with your Wi-Fi (RF interference), or 'account take-overs' - when your domain name, Twitter account or other essential online accounts is hijacked - often as a result of poor access controls (have you been using a strong password!?!). This is particularly serious if your organisation depends upon cloud services, as the attacker can disable your infrastructure and prevent you from gaining access to fix the problem.

WHAT IS A DISTRIBUTED DENIAL-OF-SERVICE ATTACK (DDOS)?

A DDoS attack occurs when there are many machines (called bots) working together to attack a targeted system. These bots represent hijacked computers, and are as much a victim as the target of the DDoS.

Cybercriminals can even hire bots to perform these attacks - which is very common when the hacker lacks the necessary skill set to create their own bot net. DDoS allows for exponentially more requests to be sent to the target machine, increasing the attack power of the hacker. It also increases the difficulty of attribution, as the true source of the attack is harder to identify.

HOW DO YOU KNOW IF AN ATTACK IS HAPPENING?

Symptoms of a Denial of Service (DoS) can resemble a network availability issue or other non-malicious availability issues.

Typical symptoms are:

Unusually slow network performance (opening files or accessing websites)

Unavailability of a particular website, or - for that matter - any form of cloud service

POSSIBLE SOLUTIONS:

Enrol in a DoS protection service that detects abnormal traffic flows, filters malicious packets and passes clean traffic to your network.

Contact your ISP to ask if there is an outage on their end or even if their network is the target of the attack and you are an indirect victim. In either case, they may be able to give advice.

Harden you web or DNS server by
- Using good patch management
- Removing default accounts
- Using strong - unique - passwords and two factor authentication where possible
- Removing unnecessary services
- Following vendor configuration settings

Use vulnerability scanning to identify weakness and penetration testing to see if internet facing devices are exploitable. There are a number of free scanners, but the latter will require some investment.

Most cloud services offer rapid elasticity - meaning that applications and infrastructure can be quickly expanded to cope with the heavier traffic of an attack. Put time aside to see if your service level agreement cover your critical systems and services and what the financial implications will be for heavier usage.

Many organisations will use multiple service providers to create better resiliency. Whilst this is more difficult to manage - especially if systems have to be integrated - it does afford better protection from this type of attack.

Create and test an incident response plan. This will ensure that you understand:
- What systems are critical and how DoS attacks will adversely affect the organisation.
- How much you are prepared to invest protecting such systems.
- How you will identify when an attack is taking place and judge its severity.
- How you will isolate, mitigate and recover systems when an attack is taking place.
- Who will do what and when and how efficient lines of communication will be maintained during the crisis.

Quite often, an organisations must implement a graceful degradation of services to cope with an attack. It is critical, therefore to understand what your business can tolerate before irreparable harm is done. For example, will your business survive if web traffic is effectively halved or response times take half as long? Knowing this threshold will help response teams implement mitigation strategies that work for you.

GETTING TECHIE WITH SOME ILLUSTRATIVE EXAMPLES:

Quite often an incident response team will need to monitor network traffic to confirm the presence of an attack; identify the source, and mitigate the situation by applying firewall rules, dropping traffic or enabling some form of configuration setting.

SYN FLOOD: For example, you might be able to open a terminal on a web server and run netstat -n -p TCP | grep SYN_RECV to confirm the presence of a SYN flood. Meanwhile, mitigation might be as simple as entering nano /etc/sysctl.conf and changing the kernel settings from: "net.ipv4.tcp_syncookies=0" to syncookies=1. Simple! Just be sure to save the text file and then reload the kernel using sysctl -p

SLOWLORIS: A Slowloris attack, on the other hand, opens multiple connections to the web server using partial http headers. To the web server, these requests look like they originate from a client with a very slow internet connection, so it keeps it alive. Eventually, the server has so many malicious connections open with data trickling in that it can’t respond to legitimate requests. If we were running Apache, we could probably stop this attack by entering something along the lines of cat /etc/apache2/mods-available/qos.conf to check if QS_SrvMaxConnPerIP is enabled. This module limits the number of open connections from an IP, limits the number of requests to a URL and prevents HTTP connections from being kept open if its exceeds a certain threshold. To enable the module enter  a2enmod qos and then restart apache: e.g. systemctl restart apache2.service