"Tightening the Cyber Screws" with #DNSSEC
In anticipation of a global cyber contagion event akin to WEF's famed exercise Cyber Polygon, the regulatory screws are being tightened on all things Internet. Here is what you need to keep an eye on.
Hardening a server on the sysadmin level is only a small fraction of what needs to be done to secure it, whether you run it in the cloud or on premises. In the cloud, it gets tricky, though, as you have to contend with restrictions on #pentesting and the like—unless you own your cloud, that is (Aloha to Amazon, the owner of AWS—yes, we are looking at you, from San Fran to Sydney and beyond).
Those of us who deploy in OPC (short for Other People’s Clouds, not to be confused with the OPC Foundation) have their hands full with the shared security paradigm. We’ll get to that point later. For now, suffice it to say, you are responsible for securing your cloud space.
Your infrastructure, cloud/ed in mystery (you’ve got your WAF in place and stuff), your containerized applications humming along and what not—is probably exposed to the world, one way or another, by virtue of necessity: it’s got to be reachable, right? Here is the kicker: DNS is an attack surface that overlays your multi-cloud.
DNS as an attack vector
The domain name system was designed for efficiency and resiliency, but not for security. Nope, these are not one and the same thing.
It’s worth repeating: The DNS system routes the Internet traffic insecurely by default. Most everything is insecure by default. Most of the time, you are thrilled that stuff works at all (just joking!).
There is this one thing you can do about DNS security right away: enable DNSSEC signing. This will make it much harder for attackers to manipulate DNS responses and redirect users to malicious sites when they try to visit your service.
DNSSEC (short for Domain Name System Security Extensions) signing adds cryptographic signatures to DNS records to certify that the responses of DNS servers for a hosted zone are authentic and have not been tempered with. It serves to establish a Chain of Trust from the root DNS servers down to individual domain names. Each level in the DNS hierarchy signs the level below it, validating the authenticity of the entire path.’
This can prevent DNS cache poisoning and DNS spoofing attacks. Without this measure in place, an attacker could redirect traffic to a malicious site or service.
DNSSEC authenticates responses to DNS queries to validate them as authentic by signing DNS records with a private key, which can be verified by anyone with means of a corresponding public key.
Doing nothing is not a good option
This is what an insecure DNSSEC config looks like, courtesy of world’s biggest e/tailer and world’s biggest cloud provider, Amazon (AMZN).
DNS configuration errors is where DNS poisoning and spoofing attacks originate, in case you were wondering about Amazon’s intrusive identity verification. Why they haven’t fixed their problems on their end and dropped the document harvesting, is indeed a valid question.
The DNSSEC Analyzer by Verisign Labs spotted nine errors for Amazon.com and six for AWS.com. Similarly, dnsviz.net is reporting a whopping five insecure records and an insecure delegation status for Amazon.com, plus two warnings.
This is what a correct DNSSEC configuration looks like. (@Amazon: It’s not personal. This particular site runs on AWS.)
In an upcoming article, we will dive into DNSSEC config implementations in more detail.
Let us know in the comments what you think.