Analyst Chat #78: DNS and DNS Security

Welcome to the Kuppingercole analyst chat. I'm your host. My name is Mathias Reinwarth I'm senior analyst and lead advisor at KuppingerCole analysts. And I want to invite my guest today. My guest today is Alexei Balaganski. Hi, Alexei.
Hello Matthias. Thanks for having me.
Me again. Great to have you again and great to have you for the first time in, in video format so that people can associate a face with the voice. Um, yeah. Great to have you today. We want to talk about, uh, cybersecurity topic as you are covering cyber security as one of your main areas of expertise. And we want to talk about a technology that is actually quite old. That is actually quite, um, well used within many organizations, of course, in the internet. Um, we want to talk about the domain name system. We want to talk about DNS, uh, and as I mentioned, this is really a long-term around. Why do we want to talk about it? But first of all, what is it?
Well, first of all, thanks for the opportunity to talk about this topic. Like if you mentioned DNS and DNS security in particular, and he answers exactly one of those topics, which has been around so long that people just kind of don't think about them anymore, either they just kind of put it into the farthest corner of their mind, or they foolishly think that all of the security problems within a Florida been solved, which is not the case, and this is exactly what we are discussing today. But first, I guess we have to, uh, give a short reminder of what the intersexual means and why that's important, right?
So DNS, as you mentioned, means domain name system, and this is one of the foundational core services powering the internet. This is a service we use every time we want to connect to a website or open any named resource on the internet, basically to turn, uh, a name, a URL, like for example, www dot dot com to an IP address, to connect, to, to access our corporate website. So yes, DNS is one of the oldest most important internet services. And since it's one of the oldest, it's probably one of the least secure ones, and unfortunately it's been around so long. And so, so ingrained into the backbone of the internet, you cannot just throw it away and replace it with this better secure one. Right,
Right. I got it. So when you say it's, it's been a long, it's been around for a long time and, um, it's not necessarily designed from the beginning to be secure. Um, when we talk about the security of the DNS, and as you said, it's, it's one of the, the powering infrastructures of the, of the internet. Um, I assume that it's constantly under attack and, um, which are the areas where we should think of security. Um, and maybe other aspects when it comes to DNS, where is DNS, um, at stake where it's, um, uh, endangered?
Well, again, I guess it would be important to remind that kind of DNS as an infrastructure is strictly hierarchical. Doesn't mean that if I am currently at home and I want to connect to a website, let's say google.com. First my computer has to call the DNS server, built into my home router and ask what's the IP address for Google Chrome. If the rotor doesn't know it freely my request to the DNS server of my internet provider and that one would go even higher until it reaches a top level domain dinner solver, which is responsible for like the first, uh, top domains, like.com for example, and the top level, the main server or the main name, silver will refer back to the one which is responsible for Google. That's called authoritative sober. And that one will give me the final result. Now I know how to connect to Google.
And there are so many steps in between and all of those steps are absolutely in the open. They're not secured, they're not encrypted, they're not protected from snooping and manipulation, which is why 81 connect with the man in the middle. It can see which sites I'm accessing. It can manipulate the DNS server, like explore it a weakness or unpatched vulnerability. And given them the wrong way IP address, or a hacker can simply set up a domain, which would kind of to my eye look like Google would call. But in reality, it would be something like Google with the in the name. And it would lead me to a totally fake and management's website, or there are many, many different security and privacy related to problems with DNS. And I guess, uh, privacy related, the next problems would be a topic for a different discussion. So today we'll just kind of go through a list of the most important security problems,
Right? So on the one hand, we, of course we try to, or we have to trust the service. So this is these security issue. And on the other hand, um, we, of course we, we be present lots of more or less private, personal secret information to this simple mechanism just by typing in a website by connecting to a mail server, because we just disclose the address or the name of the, we want to contact. So it's, as you said, it's security on the one hand it's privacy. On the other hand, that's focused on the security side of things and pick up on the privacy issues, um, in a, in a later episode. So where is this secure? Where's one of the key security issues when it comes to talking to DNS. Um, you've mentioned the spoofing of, of IP addresses. Um, is this really a thing today?
Well, uh, first of all, uh, there is this, uh, uh, this kind of manipulating the domain names, basically again, you just register a domain name, which looks like a legitimate one, Google, Microsoft Cooper Cole, but just a different spelling or like one instead of an I, or can we like always sort of let it all and rescuer, you can just forge a link, which would look nearly perfect, like the real one, but would lead a user to a totally fraudulent. They can just use a standard fishing or, uh, manipulating techniques to, for example, kind of make the user to type in his password or his credit card number or whatever. This is like the most obvious type to explore it. And we're the ones mostly talking about those, but those are more or less, well, I wouldn't call them solved, but at least I would say one of the least concerns because traffic encryption is not prevalent and SSL certificate to tell us certificate usually comes with the domain name hard-coded into it. So usually you would notice if you're connecting to a different domain name, right. Or every modern browser will highlight the main name, which looks suspicious. Like for example, if it makes us different writing scripts, you would immediately see it. This
Would really mean that the awareness of the user, um, understanding what this sign and the browser in the, in the browser address list, um, what that really means that this address is not what you expected to be. This is also part of the protections on the one hand, it's the browser being so smart to realize it's not the right address that you're connecting to, but it still requires the awareness of the, of the, of the actual user. So training is on that, in that area. Also, again, very important, getting the people on board and making sure that they understand what this actually means, um, that this is not the right address. So it's technology plus an intelligent user. Uh, but for other address, um, for other attacks, what, what others are there, maybe not that common ones,
One interesting aspect of DNS security, much fewer people will know about is DNS exfiltration because I'm in DNS or even an internet service. So it requires an open port number 53, and this is one of those services, which has to work everywhere. So this ports usually open on every firewall and in network, just like the HTT people for the websites, like everyone needs DNS everywhere and hackers, when they get into a network and they need to exfiltrate sensitive data. Sometimes they rely on DNS exfiltration, which means that they in code the data, they want to steal into DNS requests and they would connect to their fraudulent own DNS server and imitate it as like, it would look like you just kind of trying to connect to a non-existent website. And of course your firewall would block that connection to the website, which doesn't exist anyway.
But to allow through the DNS queries in those quarters would be used to exfiltrate sensitive data. And this is extremely important that your firewall or intrusion detection or whatever, or network security solution that you have in place also understands how to deal with the next exfiltration and other totally unrelated aspect would be a denial of service attacks. For example, one interesting Clarke of the DNS protocol, or that's a reply to identify requests usually much larger than the request itself. For example, I could just send a packet to a DNS tomorrow, totally legitimate and manipulated one. It asked, like, tell me everything, you know about Google that con you know, two, three told me lots of data because Google has obviously a lot of Haas names and additional information. What I could do at the same time I could, uh, forge my IP address in that packet. And instead of sending that reply to me for the other story, what sent it somewhere else? This is called DNS amplification attack. And if you create lots of tiny DNS requests with forged salsa versus you don't mean like a dilute of DNS responses on an unsuspecting website, for example, this is not as popular as, or other types of distributed denial of service attacks, but it's a much more difficult to mitigate.
So just kind of a few kinds of different, totally unrelated to each other then after the X, because they explore different aspects or DNS as infrastructure. And the problem is there is no single tool which can fix all of those challenges at the same time. That's the biggest problem,
Right? And when we're talking about security, of course, we also want to have a look at what actually helps in mitigating these, these requests. And we've looked at the artists, these, these attacks, um, we we've already looked at, um, this, this mechanism of using encryption and SSL certificates for this DNS spoofing attack. What are the technologies that are in place to protect organizations and end users from the attacks that you've mentioned? So for example, this data exfiltration attack sounds really scary because you're exchanging the payload and you're transferring data outside your own network, using a, an infrastructure that needs to be open, which is the DNS system. What can organizations do to protect themselves from this mechanism?
Well, the problem is, again, you cannot just buy or DNS security tool like you would buy an antivirus tool. It was all those different, uh, attacks. They are almost unrelated. They have the only common thinking them and that they are exploited weaknesses in DNS. Of course, like for example, the easiest manipulation, which is probably very seldom on a desktop computer, but much more popular on a mobile device. It's just kind of replacing your legitimate DNS. Solberg is a fraudulent one. So every time you all tried to open the website, it would resolve through a hacker, harrows manipulated the next sorrow and lead you to a different website.
The only way to mitigate this type of attack is to have something on the same mobile device, which would ensure that your DNS settings is not manipulated. So you would need some kind of an endpoint detection and response or uplift and painting virus on your smartphone, right? If you want to prevent the NSX filtration, that alone would not be enough. You would need first of all, to be able to detect this type of exfiltration. So you will have to sniff all the network traffic and understand that there are the patterns of our DNS traffic flow looks suspicious for, you would probably need some kind of machine learning based behavior analytics solution in place, which would detect those kinds of anomalies. If, for example, you want to prevent, uh, so-called cash Paulson in attacks, which basically make a legitimate, like your own corporate DNS server to return fake responses.
But you will have to ensure that your DNS software as a software has no open a vulnerability. So it's batched it's maintained properly secured. So from that, you would probably need some kind of a managed security service, right? Or you just have to ensure that you are on ITT, knows how to deal with those types of attacks. So again, there is no turnkey solution for all types of DNS related problems. You have to be vigilant. You have to understand your risks. You have to basically understand, or the potential impact of different risks on your and make appropriate purchasing decisions.
Right? And when you you've mentioned that, that when you run your own DNS server, and there are good reasons to do so, for example, when you are in a, in a corporate environment, still that old, um, um, um, perimeter based security and an inside and outside of the network, you want to give names to your insight services as well. So you do have to run a DNS server and cannot just rely on external ones. So one, one good idea. And one recommendation from our side would be really to make sure that there's a proper patch management tool available that makes sure that the DNS software is always up to date. And that you add the additional security mechanisms that you've mentioned. Are there any other, um, maybe also services that are available around that can add additional layers of security? You've mentioned this machine learning mechanism that can detect anomalies in the behavior of a DNS server or at least outliers unexpected behavior. Is this, uh, is this a market, are there other vendors that provide these services to protect your DNS service?
Well, obviously if there are specialized security solutions, which focus on all aspects of network security nowadays, they probably called NDR network detection and response, but of course they will detect those DNS-based attacks and Ulta or other types of attacks as well, because they basically sniff all the, all your network flows and understand if something's not working as expected. Another potential solution would be just to basically invest in the commercial DNS service, instead of relying on public tennis software running somewhere outside or running your own dinner software internally could just outsource it to a managed DNS provider. Basically it's probably not entirely a SAS based solution because it still needs some infrastructure to run, but it will be infrastructure which is managed monitored, pitched whatever kind of operated reliably and securely by a quantified third party. But of course, the most interesting for us as a security focused analyst would be something like, or you've probably heard the term safety.
Everyone is talking about Stacy nowadays, secure access service edge. The idea of delivering a full security stack from the cloud and one other, uh, underlying technologies would be to deliver assesses tech based on DNS security, the idea that instead of using your own DNS, a solar or a public one, like from Google, for example, you will simply reconfigure your devices to let's say a Cisco umbrella servers and they take over your DNS management and they ensure that. And when we request to a DNS server, which goes from your infrastructure from your devices is double and triple checked on the fly, or if it's known to be malicious, the connection would be intercepted. And for example, routed to a cloud-based sandbox and the pay payload will be exploded and monitored for malicious activities. And if it's somehow detected to be malicious, you just, it will never reach you to be intercepted and blocked. And all this is done through just basically manipulating your DNS settings. It's like that hacking attack. I mentioned earlier on your mobile phone, but we, the good guys on your side. So to say, and of course, if you deploy it centrally, uh, and, uh, you manage properly through some kind of policy enforcement across different, uh, landscapes, like it deployments mobile devices, desk, company-wise inside the office or working from home. If it's done properly, if it's monitored, it's a great opportunity to reduce your overall costs on cybersecurity,
Right? But on the other hand, you have to, on the one hand trust this provider of this SASC service, and on the other hand, once something happens to this SESC provider, this would be the bottleneck for your complete infrastructure. So you hand over responsibility, you hand over the patch management and the, and the level of quality, um, over to the, to the service provider. Uh, so this decision must be really well done and needs, might require some additional measures to, to add levels of control, to make sure that, um, you are protected even in the case of an event at the SCSC provider. Um, is this something that you look at as well? Is there, um, are there attacks running a specialty against these providers?
Well, on one hand you are technically absolutely right. And there is a lot of people who are, I would say, could have share the same view and our general outlook on handling your security controls to somebody else because it goes, or essentially against the whole idea of the internet being decentralized. I mean, originally in the times of DARPA net, it was designed to withstand nuclear attack rights, or if a part of infrastructure would be completely physical destroyed, the internet should continue working nowadays. It's no longer the case, which companies like Cisco or Google or CloudFlare, for example, which handles security for millions of domains and websites. If those companies go down even for a second, like half of your internet resources want to be unavailable, right? So yes, this is a possibility, this is a risk, but I would argue that the risks that are cloud levels down with March much lower than the risk of your own corporate network going down simply because they have the advantage of scale and centralization, they ensure that the infrastructure is all dispatched, it's, it doesn't have bottlenecks and stuff like that. So, yeah. Problems happen, but you have to weigh the balance between the probability and the impact of those problems.
Got it. So, um, you've mentioned that there are different types of tools and different types of service providers that can help you in mitigating risks that are related to, to DNS. Um, before we close down today, is there some recommendation when it comes to reading, um, documents on our website or blogs or looking at videos, are there some recommendations for you from your side when people aim at protecting they're often overlooked, as you've mentioned, DNS infrastructure?
Well, I would like two different recommendations. First of all, every, a person who is responsible for infrastructure management or security just has promoted to learn a little bit more about DNS, because like, you know, there is an old meme among, uh, CIS admin, so that when there was something happens, the first thought is like, it cannot be DNS. The next step after a few hours of debugging would be like, it was never the NS before in the next day. It's always, yeah, it's DNS again, kind of DNS is still one of the most serious and often happening problems are more about DNS, how it works, why it works that way, what kinds of attacks are are possible? What kind of attacks are trending nowadays? This would be like the key recommendation. And of course, uh, after that, uh, just could have read more about possible mitigation problems. And for that we, as analysts can offer quite a few reading material now, website, especially focusing on those popular cloud limit security topics like Ceci, for example.
Okay, great. So start with the appropriate O'Reilly book, um, about domain name system as the basis, so that, you know, the, the, the gory details, and then look at how to protect these solutions as they are running on your prem, or as provided by a cloud provider who does this for many organizations. So, um, as mentioned, we will dig a bit deeper in another episode into the privacy aspects of DNS. So, so that we have today learned a bit, um, what DNS is so resolving name names on the internet to technical addresses, we've learned about the security implications or some of those, and how to solve them. And I'm looking forward to meeting you Alex again, virtually via camera for a second episode, and we will talk about DNS privacy for the time being, thank you very much, Alex.
Well, thank you much. Yes. And goodbye.