 This set of slides will dive into DDoS attacks. In this lecture, we give some of the basic concepts related to denial of service attacks, and we then focus on providing real example of attacks as we see them in operational networks. Let's start with semantic and volumetric attacks. A semantic denial of service attack leverages on the characteristic of the misuse protocol or server at the target to enter the functionality of the target. It is therefore not so much about how many requests the attacker sends to the target, but mostly about the malicious content of the request. For example, wasting computational power in a database by requesting intensive queries is an example of semantic attack. Another example, it does low-lawries too, which submits partial requests to the web server, periodically sending a small part of the partial request, but never completing it. Today, it keeps a pool of connection busy for a long time, therefore depleting the number of available connection on the server. A volumetric attacks, as the name suggests, aims at generating a large volume of traffic or requests. In this case, there are several ways to temper with the functionality of the target. One can aim at exhausting resources like the number of available sessions in a server. However, targeting the infrastructure, for example the network connection of the target, is effective as well. The target needs only to generate enough traffic of some kind, such as to overload the network link, and the target is effectively taken online. Let's add two remarks. First, in most attacks, volumetric and semantic characteristics can both be used, for example in the case of a large number of malicious requests. Second, in this first set of slides, we did not mention distributed attacks, but it is clear that those categories apply to distributed attacks as well. In the following, we focus on distributed attacks. Adidas attacks can be direct, indicating that a set of malicious hosts directly generate traffic that is sent to the target. We talk instead of indirect attacks when malicious hosts use an intermediary set of hosts to generate attack traffic. These scenarios include several types of attacks. For example, the secondary set of hosts can be bots in a botnet that gets instructed by the commander control to start an attack. Another example can be legitimate, not infected hosts for which the malicious hosts are able to exploit some software or protocol characteristic for malicious use. We will see an example of this when we talk about reflection. In both cases, it is clear that to be effective, distributed attacks needs coordination. Let's look to a concrete example. In this picture, we see the layout of a distributed and highly coordinating attacks against an IRC server in our university network. On the x-axis, we have time. While on the y-axis, we have the number of unique IP addresses that were involved in the attack. The attack lasted roughly 13 minutes, and during this time, more than 376 million TCP packets against port 6667 were sent. More than 20,000 unique IP addresses, which with some approximation we can in this case associate with 20,000 unique hosts, have taken part in the attack. Not all of them were active all the time, but it is clear from the picture that the bulk of them have joined and stopped the attack at the same time with an initial peak of 70,000 distinct attacker per 10 seconds. These attacks also give us the opportunity to have a look at possible side-effects of a DDoS attack. So far, we have focused mainly on the effect of a DDoS attack on the target, namely stopping the target from delivering service. Implicitly, we assume that we will be able to serve such an attack. This might not always be the case. Let's have a look at this picture, which is another view of the same attack we just discussed, but from the point of view of the measurement point. The plot summarizes quite a lot of information. So let's look at it step by step. On the x-axis, we have again time. On the left, y-axis, we have the number of exported flow record from our measurement point for malicious traffic, the full line. The number of flow records for malicious traffic is in the range of million, roughly between 3.5 and 7 million. On the right, y-axis, we have the number of exported flow record for benign traffic, the dashed line. In this case, ranging between 50,000 and 300,000 flow records. Let's look at the time evolution of the attack and what it does to the monitoring infrastructure. Under normal operation, the monitoring point exports roughly 60,000 flows every 10 seconds. In the moment the attack starts, we see a sudden rise in the number of malicious flows. Since most of the traffic was same packets, each one of them was treated as a single flow by the monitoring point. So, most of the attack flows accounted for a single packet, which is a very inefficient situation for the flow cache of the monitoring point, which suddenly needs to handle an unexpectedly high number of entries. This has interest inside the facts on how the normal traffic is treated. The probe needs to free up space in the cache, therefore it starts exporting older entries. As a consequence, we see a higher number of benign flow records being exported. So, let's take a look at the picture that during the attack there is also more benign traffic, but this is not the case. We are dealing here with an artifact due to the fact that the probe is handling an overly high number of flows. Finally, there is an anomalous drop in the number of normal flows after the end of the attack. Again, this is an artifact, the probe at crash in this unfortunate case. The lesson learned here is that you should not assume that you are able to monitor a DDoS attack, and probably you need to put in place measure for protecting your monitoring infrastructure. In a way, the monitoring infrastructure can be made blind by a carefully crafted attack, even if it was not the primary target. We have mentioned before that some DDoS attacks can be indirect. Let's now talk about a specific class of indirect attacks, namely reflection and amplification attacks. A reflection and amplification attack involves one or several attackers, a target and a reflector, which typically is a server that is misused for the attack. A typical example is an OpenDNS resolver. There are two main ingredients in this type of attack. The first is reflection. The attacker sends crafted requests to the reflector using the service address of the target. We call those spoof requests. Reflection can already account for quite a lot of unwanted traffic reaching the target. However, the attacker can become more effective if the attacker is able to prompt the reflector to send only large replies to the target. This is the second ingredient, amplification. Amplification can be a very beneficial feature for the attacker. Not only amplification means that an higher traffic load will reach the target, it also means that for achieving the same attack load, an attacker needs to generate himself a smaller number of requests, since the reflector, which is also an amplifier, does the work for him. We define amplification factor as the ratio between the response size and the request size. From an attacker point of view, the higher the amplification factor is, the more the attacker can achieve less resources. Reflection and amplification attacks typically use servers as amplifiers and leverage protocol characteristics that generate large answers. A typical example is a DNS-based attack that use any queries, because they generally yield larger responses. The table on the right shows examples of bandwidth amplification factors here indicated as BIF, for a set of known protocols. NTP can amplify an attack up to more than 550 times. Charging, which we will look at in a while, more than 350 times. Let's have a look at an example. This plot shows the traffic to and from the University of Toronto network as seen from our provider, Surfnet, in August of 2014. Again, the target was an IRC server. The attack used in this case was a distributed NTP reflection and amplification attack, which caused a peak of 19 gigabit per second. We now know how reflection and amplification attacks work, and that they can achieve higher amplification factor by misusing regular protocols. Well, actually it is, and it has to do both with amplification factor as well as with the number of possible amplifiers on the Internet. Let's have a look at the OpenDNS Resolvers. An OpenDNS Resolver is a DNS resolver that answers queries from any source IP, not only a host from the same network. OpenDNS Resolvers are a very likely target to be used in an amplifier. The OpenDNS project tracks the number of such systems on the Internet. In June 2016, the project reported around 17 million OpenDNS Resolvers. Although there is a decreasing trend, the actual number of possible amplifiers is still extremely high. But it is not just DNS. The number of OpenNTP servers is probably around 4 million, and the number of OpenSNMP servers is around 7.9 million. And those are only protocols for which we have some indicative statistics. We have indicated that the issues in reflection and amplification attacks are the number of possible amplifiers and the amplification factor. Let's have a look at the Chargent protocol, for example. Chargent is a legacy protocol running on port 19 originally developed for network troubleshooting. A host sends a Chargent request and receives back a string of characters. According to RFC 864, such a string should have a random length between 0 and 512 characters. In practice, the traffic characteristics that we measure in the case of two attack traces we collected using one of our host as a target are telling a different story. Let's look at the packet distribution of Chargent reflected traffic. Following the RFC, the maximum packet size we should see should be in the order of 550 bytes, roughly including headers. This is not the case, and the maximum packet size is actually close to 7000 bytes. The distribution of the packet size is expected for Chargent, very close to be uniformly distributed. This means that there is a population of amplifiers on the internet that are not RFC compliant, and therefore can cause a much higher amplification factor than expected. If we look at the traffic we captured for those attacks, we can easily reach 7GB per second attack traffic. Interestingly enough, a deeper investigation has shown that hosts with such an amplification characteristics are related to family Chargent implementation in Windows system. However, the Linux Chargent implementation also allows for strings as long as 1024 bytes.