In this lecture, we will be talking about DNS flood attack and DNS amplification attack. Let's start with DNS flood in DNS flood attack. As you can see, in this picture, the attacker, by using multiple bots takes down the DNS resolver of the legitimate user. In other words, it makes the DNS resolver. The local DNS resolver of the user, or you can say have multiple users in this vicinity unavailable by sending multiple requests from bots. However, in DNS amplification attack, the attacker uses only one instance of the bot.

Whereas that bot basically exposes the MIS configuration of open DNS resolvers out there online or using spoofed requests. In other words, in this post request, the attacker malformed DNS query such that the source IP I mean the IP for the open DNS resolver to center replay query to victims IP. That's why when the bot sends multiple requests to open DNS resolvers, those DNS resolvers. Instead of replying back to bot, they'll respond to target victim. And all of a sudden, it's not even expecting that the target victim is spoofed by all these DNS resolvers. In this case, these DNS resolvers are not part of the botnet, they are just misconfigured.

Therefore, the main differences in DNS amplification attack, the attacker can overwhelm the target victim only with a small amount of bandwidth with one instance of botnet. Whereas in the DNS flood attack, basically the attacker is a huge number of bots. The methodology is different. However, the result is pretty much the same. So how can we detect any of these attacks? When it comes to detection?

There is a No one specific way. Basically, the most obvious one is to monitor incoming DNS traffic on port 53, which is the port for DNS, and create alert in case of exceeding thresholds. So basically, we will just monitor the incoming quality of incoming traffic on port 53. And you will basically set a threshold. And in case the traffic exceeds that threshold, you will just create an alert system to take action, which we're going to discuss in the mitigation section. And for emergent cases.

I mean, if you're suspicious that there's a DNS attack ongoing right now, you can check the current status of the traffic with this TCP dump command. And when it comes to the mitigation, first one is basically do not allow all sorts of DNS responses, meaning if you're not expecting such a DNS query, such a DNS response from a DNS is over, for instance, just drop it. Second one basically dropped quick retransmissions. Since one of the fundamental ways of DNS further attacks basically, is sending the same queries, or quite similar crafted queries over and over again, within a short period of time. By dropping quick retransmissions, you can alternate DNS flood attacks quite easily, at least most of the attacks. Likewise, similar to the second item, do not allow the same queries too soon.

If you have already sent a response, what the DNS resolver keeps asking for the same thing too quickly. You can just basically drop this purse source per request or blocked source IP, since this situation would most probably mean that the source doesn't even care if you're responding or not. Another way to tackle is basically dropping DNS queries and responses that are anomalous. Since most of these options carried out by some scripts, their functionality is limited. And sometimes the DNS queries that those scripts create are anomalous. In other words, they're against the rules of DNS, or sometimes even of TCP.

So if you're ready to check the anomalies in the queries, in most cases, it will also stop DNS attacks because again, those botnets that are attacking, you are usually created by some people who don't care about the rules of DNS or TCP. They just want to take it down. So checking anomalies can be a good option for defending against such attacks. And while everything is fine, no attacks happening, just build a table of legitimate queries that have been responded with a positive response. This will be used to detect and block unexpected or unsolicited DNS queries. Basically, what it says is just observe your traffic during ease times.

Just record the regular activity. I mean, like usually, what kind of DNS queries does your DNS server receive? Or what is the regular traffic volume. If you track those things during a flood time, it will be much easier for you to distinguish the attackers and legit requesters. Another thing is basically forcing the DNS client to prove that it is not a spoofed query. This is especially true for DNS amplification attack.

And basically what it says is to make the source prove that it's a valid DNS client by for example, forcing TCP transmission or forcing a retransmission of the DNS query. If the DNS client fails to adhere to these retransmissions, most probably is part of that botnet. And finally, try to use ACLs, geolocation, ACLs and IP reputation. ACL is as you know, accessible. troll list basically just tells which ports to be blocked, and which ports to be a lot, and by whom. However, if you have a DNS server, this might be the best option.

Since you know for instance, blocking the Port 53 by ACL is not a good idea. Since it will block to whole traffic. The only way it can be useful is just by blocking the source IPS. If you have a list of attacker IPS, you can use ACL. However, even in that case, it's not going to be an efficient way because the attackers can always use different IP. The same goes for geolocation ACLs.

If you're having regular attacks from some specific geo locations, like from China, for example, you can block the whole IP set of China. However, in that case, obviously nobody from China will be able to access to your service. And in relation to first two items, you can use I period reputation. What it means is basically you can start to create a record of IPS based on whether they have attacked you, whether their origins trusted etc. And based on that, you can start to use reputation and you can decide whether an IP is legitimate or not accordingly. This is recommended to be used as an ozone layer method only though after this lecture I will also leave you the link for an article scientific article, which discusses some ways of response challenging for DNS.