{"id":5181,"date":"2016-01-19T10:22:04","date_gmt":"2016-01-19T10:22:04","guid":{"rendered":"http:\/\/www.intelligentcio.com\/me\/?p=5181"},"modified":"2016-01-19T10:22:04","modified_gmt":"2016-01-19T10:22:04","slug":"securing-infrastructure-and-data-from-dns-based-threats","status":"publish","type":"post","link":"https:\/\/www.intelligentcio.com\/me\/2016\/01\/19\/securing-infrastructure-and-data-from-dns-based-threats\/","title":{"rendered":"Securing infrastructure and data from DNS-based threats"},"content":{"rendered":"<p class=\"p1\"><span class=\"s1\">DNS, or Domain Name System, is the protocol used for converting fully qualified domain names (FQDNs) like <a href=\"http:\/\/media.ne.cision.com\/l\/iqrrqhxr\/www.google.com\/\"><span class=\"s2\">www.google.com<\/span><\/a> into machine-usable IP addresses that computers use to communicate with each other. Without a working DNS protocol, it would be almost impossible to have an Internet of Things that communicate with each other and organizations would not have a cyber-presence. In short, the internet as we know it would not exist without a robust DNS infrastructure, writes\u00a0<em>Cherif Sleiman, General Manager, Middle East at Infoblox.<\/em><\/span><\/p>\n<p class=\"p1\">Given that DNS servers are mission-critical infrastructure, it is crucial that they continue to respond to queries even when they are under attack. When designing a DNS infrastructure, it is important to build an environment that is not only sufficient for current needs, but also provides room for future growth. In addition, while architecting the DNS, it is also important to understand the security threats the DNS might be vulnerable to.<\/p>\n<p class=\"p1\"><span class=\"s1\"><b>Securing the DNS platform against hacking<\/b><\/span><\/p>\n<p class=\"p1\"><span class=\"s1\">Hacking of DNS servers is becoming more prevalent every day. Conventional DNS servers have multiple attack surfaces and extraneous ports such as port 80 and port 25 that are open for attack. Hackers can use these ports to access the operating system (OS) and hack the servers. If an enterprises\u2019 DNS servers don\u2019t support tiered security privileges, any user could potentially gain access to OS-level account privileges and cause configuration changes that could make the servers vulnerable to hacks.<\/span><\/p>\n<p class=\"p1\"><span class=\"s1\">In order to protect DNS services from various hacks, DNS servers should be secured in the following ways:<\/span><\/p>\n<ul class=\"ul1\">\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Hardened appliance with minimal attack surface<\/b> &#8211; The infrastructure should not have any extra or unused ports to access server or power external devices (e.g. Wi-Fi) and no root login access within operating system. It should have role-based access to maintain overall control<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Secured access methods<\/b> \u2013 There should be two-factor authentication for secured login access, web and API access should use encryption to secure communication and DNS TSIG keys should be used for strong authentication of DNS updates<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>High availability and disaster recovery<\/b> &#8211; Simple, configurable fail-over and fail-back to ensure service availability<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Simple, unified updates for OS and applications <\/b>&#8211; Updates for both the OS and applications should be accomplished in a single process to reduce downtime and risk of incompatibility<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Security certification by an accepted industry<\/b> <b>organisation<\/b> &#8211; External validation of security measures must be taken on hardware, applications\/OS, and manufacturing process. The bar should be set at a minimum of Common Criteria EAL2 certification which covers verification of hardware, software and manufacturing processes<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Simple DNSSEC implementation &#8211; <\/b>DNSSEC reduces the risk of attacks like cache poisoning. It should be simple to implement and self-manage the updating of encryption keys between servers<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Secure Forwarder Configuration<\/b> \u2013 Restrict queries to DNS Forwarder servers to those sent by authorized addresses<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Detailed audit logging \u2013<\/b> This<b> <\/b>enables compliance and control over server configurations and operations<\/span><\/li>\n<\/ul>\n<p class=\"p1\"><span class=\"s1\"><b>Defending against DNS attacks<\/b><\/span><\/p>\n<p class=\"p1\"><span class=\"s1\">Another consideration is the protection of the DNS infrastructure from external attacks. Authoritative DNS servers are reachable from the internet. Even though the server sits behind a firewall, most of these attacks cannot be mitigated by typical firewalls. Firewalls are ill-prepared to protect DNS against application-layer attacks. The ones that do, the so-called NextGen firewalls, tend to have very little coverage for DNS protocols. These solutions typically spread their security policies across a large number of protocols and sacrifice depth for breadth of coverage.<\/span><\/p>\n<p class=\"p1\"><span class=\"s1\">There are a whole spectrum of attacks that can target DNS:<\/span><\/p>\n<ul class=\"ul1\">\n<li class=\"li1\"><span class=\"s1\">Dos\/DDoS \u2013 Send 10s or 100s of thousands of queries per second to the DNS server in order to exhause resources on the server and cause a service outage<\/span><\/li>\n<li class=\"li1\"><span class=\"s1\">DNS reflection\/DrDoS \u2013 Use 3rdparty DNS servers (open resolvers) to propagate DDoS attacks<\/span><\/li>\n<li class=\"li1\"><span class=\"s1\">DNS amplification \u2013 Use specially crafted queries to amplify response and congest bandwidth<\/span><\/li>\n<li class=\"li1\"><span class=\"s1\">DNS-based exploits \u2013 Attacks that exploit vulnerabilities in the DNS software<\/span><\/li>\n<li class=\"li1\"><span class=\"s1\">TCP\/UDP\/ICMP floods \u2013 Flood a victim\u2019s network on Layer 3 with large amounts of traffic<\/span><\/li>\n<li class=\"li1\"><span class=\"s1\">DNS cache poisoning \u2013 Corrupt the DNS cache data with a rogue address<\/span><\/li>\n<li class=\"li1\"><span class=\"s1\">Protocol anomalies \u2013 Cause the server to crash by sending malformed packets and queries<\/span><\/li>\n<li class=\"li1\"><span class=\"s1\">Reconnaissance \u2013 Attempts by hackers to get information on the network before launching attacks<\/span><\/li>\n<li class=\"li1\"><span class=\"s1\">DNS tunnelling \u2013 Tunnelling of another protocol through DNS for data exfiltration<\/span><\/li>\n<\/ul>\n<p class=\"p1\"><span class=\"s1\">Protection from these attacks should be done at the DNS level. The DNS appliance should have:<\/span><\/p>\n<ul class=\"ul1\">\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Intelligent detection and mitigation<\/b> &#8211; It should detect and drop the attack queries before they reach the core DNS server. The DNS server should not spend valuable CPU and memory resources to process these requests. This can be achieved by offloading the threat protection to built-in dedicated compute<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Automatic threat updates<\/b> \u2013 It should stay up-to-date with new and evolving threats automatically. There should be no need for writing scripts or manually applying new protection rules to the DNS server every time a new threat is detected<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Fine-tuning of protection<\/b> \u2013 DNS traffic patterns and attacks might not be the same for each organisation and customisation of protection is necessary to minimise false positives. It should allow for adjusting of parameters for each rule and customise them for the environment<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Centralized visibility of attacks<\/b> \u2013 Centralized reporting capability is important to provide visibility into the load on the system, diagnose problems, and identify attacks that are happening across the network<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Secure Authoritative Name Servers<\/b> \u2013 External authoritative name servers should have recursion disabled. Inbound\/outbound zone transfers should be disabled or secured with TSIG to prevent resource exhaustion attacks<\/span><\/li>\n<\/ul>\n<p class=\"p1\"><span class=\"s1\"><b>Preventing Malware and APTs from Using DNS<\/b><\/span><\/p>\n<p class=\"p1\"><span class=\"s1\">Data breaches are growing at a staggering pace. Investing in next-generation firewalls or Intrusion Prevention Systems (IPSs) can stop some Malware from entering the network, but not all. Trends like Bring Your Own Device (BYOD) complicate the situation further and provide new avenues for Malware to enter and go undetected for longer periods of time.<\/span><\/p>\n<p class=\"p1\"><span class=\"s1\">Malware and APTs evade traditional defences by using DNS to find and communicate with botnets and command-and-control servers. Botnets and command-and-control servers hide behind constantly changing combinations of domains and IP addresses. Once internal machines connect to these devices, additional malicious software is downloaded or sensitive company data is infiltrated.<\/span><\/p>\n<p class=\"p1\"><span class=\"s1\">Sometimes Malware and APT attacks are hidden or disguised by external attacks on networks. During an external attack, IT staff are distracted in protecting the network and might miss alerts or warning logs about Malware and APT activity within the network.<\/span><\/p>\n<p class=\"p1\"><span class=\"s1\">In order for DNS to detect and block queries for malicious domains and networks, a Response Policy Zone (RPZ) must be configured and implemented. At a very minimum the RPZ must have the following capabilities:<\/span><\/p>\n<ul class=\"ul1\">\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Configurable RPZ policy<\/b> \u2013 RPZ should be configured to apply either Pass-through, Block, NXDOMAIN or Substitute policies to malicious traffic<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Up-to-date threat data<\/b> \u2013 The threat data should come either from Generic malware or targeted APT (though ideally, it would come from both)<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Timely visibility on malicious DNS queries and infected devices<\/b> \u2013 data should include the number of attempts to reach malicious domains, the names of the malicious domains and the date\/time.<\/span><\/li>\n<\/ul>\n<p class=\"p1\"><span class=\"s1\"><b>Security built in is better than security bolted on<\/b><\/span><\/p>\n<p class=\"p1\"><span class=\"s1\">Many IT organisations today are using load-balancers, IPS and firewall devices, generic DDoS protection solutions and cloud-based solutions to try and counter DNS-based attacks. All of these solutions are limited in what they can and cannot protect. Most of them are external solutions that are \u201cbolted on\u201d rather than built from the ground up to secure enterprises\u2019 DNS against attacks. None of them can compare to the effectiveness of a purpose-built, DNS-specific defence solution.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>DNS, or Domain Name System, is the protocol used for converting fully qualified domain names (FQDNs) like www.google.com into machine-usable IP addresses that computers use to communicate with each other. Without a working DNS protocol, it would be almost impossible to have an Internet of Things that communicate with each other and organizations would not [&hellip;]<\/p>\n","protected":false},"author":20,"featured_media":5193,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[5,6],"tags":[317,177,104,10],"class_list":["post-5181","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-enterprise-security","category-insights","tag-dns","tag-infoblox","tag-malware","tag-security-2"],"acf":[],"publishpress_future_workflow_manual_trigger":{"enabledWorkflows":[]},"_links":{"self":[{"href":"https:\/\/www.intelligentcio.com\/me\/wp-json\/wp\/v2\/posts\/5181","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.intelligentcio.com\/me\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.intelligentcio.com\/me\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.intelligentcio.com\/me\/wp-json\/wp\/v2\/users\/20"}],"replies":[{"embeddable":true,"href":"https:\/\/www.intelligentcio.com\/me\/wp-json\/wp\/v2\/comments?post=5181"}],"version-history":[{"count":0,"href":"https:\/\/www.intelligentcio.com\/me\/wp-json\/wp\/v2\/posts\/5181\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.intelligentcio.com\/me\/wp-json\/wp\/v2\/media\/5193"}],"wp:attachment":[{"href":"https:\/\/www.intelligentcio.com\/me\/wp-json\/wp\/v2\/media?parent=5181"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.intelligentcio.com\/me\/wp-json\/wp\/v2\/categories?post=5181"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.intelligentcio.com\/me\/wp-json\/wp\/v2\/tags?post=5181"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}