DNS, unfortunately, is a prime target for DDoS attacks, a fact that cannot be ignored. This vulnerability poses a significant risk to the stability and accessibility of your online services.

Some servers and some setups allow the bad guys to use DNS servers to attack other servers. Other setups and servers are not configured or cannot protect against inbound attacks.

Why protect a DNS server?

No DNS = No Internet. It’s that simple, as no one knows the IP address for a server. Think of the sites you use every day, and ask yourself if you know the IPv4 address and then ask if you could remember the IPv6 address.

This means you have 2 different areas to protect

1. Protect your brand by keeping the Authorative DNS operational
2. Protect you caching DNS and ensuring it is not open for abuse internally or externally

Protecting your brand

Consider the scenario where a customer or a user is trying to access your website. They initiate a DNS lookup, which at some point involves your server. If your DNS server is down or overloaded due to a DDoS attack, the user cannot retrieve the IP address for the service they need. Hackers exploit this vulnerability, effectively blocking access to your service without even compromising your server. This underscores the urgency of protecting your DNS server.

This problem can cause financial issues and result in users accessing alternate providers to get the desired product or service.

Authoritative DNS servers need the ability to dynamically block these attacks without having to resort to the system administrator configuring the prevention at the time of the attack. These servers need the ability to report on the attack so that lessons can be learned, but the most obvious feature is uptime; they have to resolve legitimate queries while blocking the attack.

Protection needs to be built into the whole software stack. Using external platforms to protect insecure DNS servers is a bad idea as the system administrator cannot easily see the whole picture of the attack. The DNS solution in your network needs to be aware of the attack and protect itself.

Protecting the caching DNS server

There are far more caching DNS servers installed across the internet and inside networks than Authorative DNS servers. Sometimes, hackers abuse caching DNS servers into a DDoS cluster. If a DNS server is open as a resolver on the internet, the hacker can bounce malicious queries off it and hide their location and intention. This can be a massive problem on the internet.

Again, filtering needs to be deployed to protect the DNS server and ensure your servers are not used for malicious reasons.

Start low in the stack

DNS Software sits at the top of the ISO stack. Hackers know this and often attack the server with ICMP, TCP and UDP attacks which are nothing to do with DNS. Your protection, therefore, needs to secure the server against attacks from the lower layers of the stack, and critically, it needs to be able to report these attacks. An important factor is having all the various attacks correlated in the protection and reporting architecture and visible using a GUI. This ensures the system administrator doesn’t have to dig through logs and reports from different protection platforms where they cannot understand all the attack vector.

Visibility

Having a GUI that can see the attacks in near real-time is a factor to help understand when you are being attacked, how you are being attacked and how the attack changes over time.

If you have your protection split across different vendors and different protection boxes, seeing the ICMP and DNS attacks is often very hard as you may have multiple different reporting engines to view and try and correlate the data.

The reporting engine needs to work offline from the servers to ensure that it doesn’t impact the performance of the solution, but critically, you need real-time information to see the attack. Some platforms have large delays in reporting of minutes, and that doesn’t help when the attack could be over in the time taken to see the data.

Protect against misuse of the DNS

DNS Tunnelling is a clever technique that uses perfectly valid DNS queries from sources allowed to query the caching DNS server. Hackers embed the traffic they want to pass in a DNS query and response. The caching DNS server sends the packet to the Internet. Hackers can use this technique for service theft and data exfiltration. As the data is, in effect, valid, legacy solutions do nothing to stop this method.

DNS tunnelling protection has to be dynamic and not rely on lists of domains from a central source. The platform must be self-protecting and provide detailed reporting.

FORT COLLINS, COLO. (PRWEB) MAY 03, 2023

Secure64 Software Corporation, creators of purpose-built security and DNS solutions, announced today the launch of Secure64 CloudDNS™, a first-of-its-kind, cloud-native solution that delivers carrier-grade DNS utilising open Container-as-a-Service (CaaS) technologies and Kubernetes. CloudDNS is suitable for wireline and Wireless 3G/4G/5G services, allowing fast, reliable, scalable deployments.

As carriers modernize and upgrade their infrastructure, they often use applications from different vendors, each application having its unique approach to configuration, deployment, monitoring, scaling, and management. The result is that carriers incur additional operational costs and experience resource constraints as network teams must develop expertise in each of these disparate applications.

By utilizing modern cloud solutions, carriers can deploy within a shared framework to accelerate deployment, simplify configuration changes, and maximize hardware utilization. These solutions also provide functionality allowing automated scale-up or sale-down as required using rules based on load and performance.

“Our customers require automated delivery of DNS services in a cloud-native environment,” says Ian Sampson, Chief Marketing Officer of Secure64. “We have responded to this need and developed the ability to deliver our existing solutions in a Kubernetes or container environment with management and reporting using standardized tools.”

Secure64 CloudDNS™, with the power of K8s, allows carriers to deploy in a shared architecture and deliver the performance they need with automatic scaling capabilities to respond to network events such as attacks and peak load needs. This platform is part of the Secure64 ecosystem and augments the existing capabilities of Secure64 solutions to provide a secure, stable, and safety-focused customer-centric experience.

About Secure64
Secure64 brings trust to the internet through its suite of purpose-built, secure, carrier-grade DNS, network security, DDoS mitigation and reporting products. The company was built on a foundation of security, stability and safety and has forged solutions that are self-protecting and not only immune to malware but provide active protection for subscribers against Malware and phishing attacks. Secure64 secures the DNS infrastructures of leading service providers, government agencies and enterprises globally.

Our DNS supports a worldwide subscriber base of over 1 billion, representing over 20% of global mobile subscribers. Performing billions of DNS lookups every day across six continents, Secure64 lives up to its reputation for providing highly secure, safe, and stable DNS solutions.

Secure64 is a privately held company with deep technical and global experience in its leadership and technical staff. It is the only DNS solution provider that has authored a secure micro OS, the first to support IPV6 and built self-protecting DNS servers. For more information, visit http://www.secure64.com

Ian Sampson
Secure64 Software Corporation
Ian.Sampson@Secure64.com
http://www.secure64.com

Containers are a great idea. A small discrete element that allows a function to operate. They allow software developers to build and run these functions quickly. They contain all the elements needed to run the function within a pre-built package. They run knowing that the underlying architecture doesn’t need all the elements to run the code so that changes can quickly be made. According to recent research, the life of a container is often as small as 5 minutes. They are built at speed, deployed at speed and used at speed.

This is, however, one of the challenges of containers. They often reuse the core systems of the previously built container. That is to say, developers build upon and iterate the previous incarnation instead of building a new container. Any security vulnerabilities in the container and reused libraries/code are taken forward into the new container. It is not the developer’s fault, and this is just the way things happen.

We already saw attacks against containers with the Kiss-a-Dog attack last year.

DNS security is, therefore, a great place to prevent some of the resulting issues. Hackers use Command and Control infrastructures. As we all know, DNS is often used for an infected machine to get back to a control server. Hackers use techniques like fast flux and double fast flux to change where the C&C server is located quickly. This allows the hackers a more extraordinary ability to hide from detection.

Using a DNS blocking solution can help. Let’s be clear, it cannot stop inbound attacks, and it can’t protect the container from these attacks. It can, however, help stop an infected container from going to the C&C infrastructure. This is important. Often containers do not have limits on CPU and other core functions. By blocking the look-up at the DNS level for the infected machine, you prevent the infected container from using all its CPU and allowing it to carry out its core intended mission, not the mission the hacker wants it to do.

DNS security should be installed to help protect containers without the burden of applying local security elements to the container. This doesn’t limit the performance of the container and is a simple matter of using the DNS service that’s required anyway in the network.

So what are the benefits of a Secure64 Guard platform specifically for Container security?

1. Speed. You know the container will have security irrespective of the elements in the container
2. Performance. You are not hampering the performance of the container with unnecessary code
3. Reusability. The same DNS architecture is reused for every container deployed.
4. Visibility. Using the Vizion platform, you can see the calls to a Command and Control infrastructure that an infect container is making. You can then take proactive action to stop this from happening again.

If you would like to learn more about the Guard platforms, Vizion and our other services, please don’t hesitate to contact Secure64.