DNSSEC: Is Your Infrastructure Ready?
A few months ago, we teamed with Infoblox for a DNSSEC webinar. Jonathan George, F5 Product Marketing Manager, leads with myself and Cricket Liu of Infoblox as background noise. He’s a blast as always and certainly knows his DNS. So, learn how F5 enables you to deploy DNSSEC quickly and easily into an existing GSLB environment with BIG-IP Global Traffic Manager (GTM). BIG-IP GTM streamlines encryption key generation and distribution by dynamically signing DNS responses in real-time. Running time: 49:20 </p> <p>ps</p> <p>Resources:</p> <ul> <li><a href="http://www.f5.com/news-press-events/web-media/" _fcksavedurl="http://www.f5.com/news-press-events/web-media/">F5 Web Media</a></li> <li><a href="http://www.youtube.com/user/f5networksinc" _fcksavedurl="http://www.youtube.com/user/f5networksinc">F5 YouTube Channel</a></li> <li><a href="http://www.f5.com/products/big-ip/global-traffic-manager.html" _fcksavedurl="http://www.f5.com/products/big-ip/global-traffic-manager.html">BIG-IP GTM</a></li> <li><a href="http://www.f5.com/pdf/white-papers/dnssec-wp.pdf" _fcksavedurl="http://www.f5.com/pdf/white-papers/dnssec-wp.pdf">DNSSEC: The Antidote to DNS Cache Poisoning and Other DNS Attacks (whitepaper)</a> | <a href="http://devcentral.f5.com/s/weblogs/interviews/archive/2009/12/04/audio-tech-brief-dnssec-the-antidote-to-dns.aspx" _fcksavedurl="http://devcentral.f5.com/s/weblogs/interviews/archive/2009/12/04/audio-tech-brief-dnssec-the-antidote-to-dns.aspx">Audio</a></li> <li><a href="http://www.cricketondns.com" _fcksavedurl="http://www.cricketondns.com">Cricket on DNS</a></li> <li><a href="http://www.youtube.com/user/InfobloxInc" _fcksavedurl="http://www.youtube.com/user/InfobloxInc">Infoblox YouTube Channel</a></li> </ul> <p>Technorati Tags: <a href="http://devcentral.f5.com/s/weblogs/psilva/psilva/psilva/archive/2011/05/09/" _fcksavedurl="http://devcentral.f5.com/s/weblogs/psilva/psilva/psilva/archive/2011/05/09/">F5</a>, <a href="http://technorati.com/tags/webinar" _fcksavedurl="http://technorati.com/tags/webinar">webinar</a>, <a href="http://technorati.com/tags/Pete+Silva" _fcksavedurl="http://technorati.com/tags/Pete+Silva">Pete Silva</a>, <a href="http://technorati.com/tags/security" _fcksavedurl="http://technorati.com/tags/security">security</a>, <a href="http://technorati.com/tag/business" _fcksavedurl="http://technorati.com/tag/business">business</a>, <a href="http://technorati.com/tag/education" _fcksavedurl="http://technorati.com/tag/education">education</a>, <a href="http://technorati.com/tag/technology" _fcksavedurl="http://technorati.com/tag/technology">technology</a>, <a href="http://technorati.com/tags/internet" _fcksavedurl="http://technorati.com/tags/internet">internet, </a><a href="http://technorati.com/tags/big-ip" _fcksavedurl="http://technorati.com/tags/big-ip">big-ip</a>, <a href="http://technorati.com/tag/dnssec" _fcksavedurl="http://technorati.com/tag/dnssec">dnssec</a>, <a href="http://technorati.com/tags/infoblox" _fcksavedurl="http://technorati.com/tags/infoblox">infoblox</a> <a href="http://technorati.com/tags/dns" _fcksavedurl="http://technorati.com/tags/dns">dns</a></p> <table border="0" cellspacing="0" cellpadding="2" width="378"><tbody> <tr> <td valign="top" width="200">Connect with Peter: </td> <td valign="top" width="176">Connect with F5: </td> </tr> <tr> <td valign="top" width="200"><a href="http://www.linkedin.com/pub/peter-silva/0/412/77a" _fcksavedurl="http://www.linkedin.com/pub/peter-silva/0/412/77a"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="o_linkedin[1]" border="0" alt="o_linkedin[1]" src="http://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_linkedin.png" _fcksavedurl="http://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_linkedin.png" width="24" height="24" /></a> <a href="http://devcentral.f5.com/s/weblogs/psilva/Rss.aspx" _fcksavedurl="http://devcentral.f5.com/s/weblogs/psilva/Rss.aspx"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="o_rss[1]" border="0" alt="o_rss[1]" src="http://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_rss.png" _fcksavedurl="http://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_rss.png" width="24" height="24" /></a> <a href="http://www.facebook.com/f5networksinc" _fcksavedurl="http://www.facebook.com/f5networksinc"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="o_facebook[1]" border="0" alt="o_facebook[1]" src="http://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_facebook.png" _fcksavedurl="http://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_facebook.png" width="24" height="24" /></a> <a href="http://twitter.com/psilvas" _fcksavedurl="http://twitter.com/psilvas"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="o_twitter[1]" border="0" alt="o_twitter[1]" src="http://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_twitter.png" _fcksavedurl="http://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_twitter.png" width="24" height="24" /></a> </td> <td valign="top" width="176"> <a href="http://bitly.com/nIsT1z?r=bb" _fcksavedurl="http://bitly.com/nIsT1z?r=bb"><img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="o_facebook[1]" border="0" alt="o_facebook[1]" src="http://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_facebook.png" _fcksavedurl="http://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_facebook.png" width="24" height="24" /></a> <a href="http://bitly.com/rrAfiR?r=bb" _fcksavedurl="http://bitly.com/rrAfiR?r=bb"><img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="o_twitter[1]" border="0" alt="o_twitter[1]" src="http://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_twitter.png" _fcksavedurl="http://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_twitter.png" width="24" height="24" /></a> <a href="http://bitly.com/neO7Pm?r=bb" _fcksavedurl="http://bitly.com/neO7Pm?r=bb"><img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="o_slideshare[1]" border="0" alt="o_slideshare[1]" src="http://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_slideshare.png" _fcksavedurl="http://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_slideshare.png" width="24" height="24" /></a> <a href="http://bitly.com/mOVxf3?r=bb" _fcksavedurl="http://bitly.com/mOVxf3?r=bb"><img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="o_youtube[1]" border="0" alt="o_youtube[1]" src="http://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_youtube.png" _fcksavedurl="http://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_youtube.png" width="24" height="24" /></a></td> </tr> </tbody></table></body></html> ps Resources: F5 Web Media F5 YouTube Channel BIG-IP GTM DNSSEC: The Antidote to DNS Cache Poisoning and Other DNS Attacks (whitepaper) | Audio Cricket on DNS Infoblox YouTube ChannelThe BIG-IP GTM: Configuring DNSSEC
This is the fourth in a series of DNS articles that I'm writing. The first three are: Let's Talk DNS on DevCentral DNS The F5 Way: A Paradigm Shift DNS Express and Zone Transfers The Domain Name System (DNS) is a key component of the Internet's critical infrastructure. So, if the foundation of the Internet itself relies on DNS, then let's take a quick look at how stable this foundation really is. After all, DNS was born in the early 1980s...back when REO Speedwagon and Air Supply were cranking out hits on the radio. The question is...does the DNS of the 1980s have any issues we need to worry about today? Well as it turns out, DNS was not initially built with security in mind. When a user types a web address in his browser, he expects to be reliably directed to that website. Unfortunately, that doesn't always happen. One common example is seen when an attacker disrupts the user's request and redirects to a malicious site. Several DNS vulnerabilities like this have led the way to an interest in DNS Security Extensions (DNSSEC) to secure this critical part of our Internet infrastructure. What is DNSSEC? DNSSEC is a suite of extensions that add security to the DNS protocol by enabling responses to be validated. With DNSSEC, the DNS protocol is much less susceptible to certain types of attacks (like the DNS spoofing situation described above). DNSSEC uses digital signatures to validate DNS responses so that the end user can be assured he is visiting the correct website. Based on the design features of DNSSEC, it is most effective when deployed at each step in the DNS lookup process...from root zone to the final domain name. If you leave any of the steps unsigned, it creates weakness in the process and you won't be able to trust the entire chain. Keep in mind that DNSSEC doesn't encrypt the data, it just signs it to attest to the validity of the response. When a user requests a site, DNS kicks into gear by translating the domain name into an IP address. It does this through a series of recursive lookups that form a "chain" of requests. The picture below shows an example of a user requesting f5.com and the DNS system chaining together requests in order to match the domain name to the IP address so that he can access the website. This is all well and good, but the issue that forms the need for DNSSEC is that each stop in this chain inherently trusts the other parts of the chain...no questions asked. So, what if an attacker could somehow manipulate one of the servers (or even the traffic on the wire) and send the wrong IP address back to the user? The attacker could redirect the user to a website where malware is waiting to scan the unsuspecting user's computer. The picture below shows the same chain of requests, but this time an attacker has manipulated the last response so that the incorrect IP address is returned to the user. Not good. DNSSEC addresses this problem by validating the response of each part of the chain by using digital signatures. These signatures help build a "chain of trust" that DNS can rely on when answering requests. To form the chain of trust, DNSSEC starts with a "trust anchor" and everything below that trust anchor is trusted. Ideally, the trust anchor is the root zone. Fortunately for all of us, ICANN published the root zone trust anchor, and root operators began serving the signed root zone in July, 2010. With the root zone signed, all other zones below it can also be signed, thus forming a solid and complete chain of trust. In fact, ICANN also lists the Top Level Domains (TLD) that are currently signed and have trust anchors published as DS records in the root zone (most of the TLDs are signed). The following picture (taken from iiw.idcommons.net) shows the process for building the chain of trust from the root zone. DNSSEC uses two kinds of keys: Key Signing Keys and Zone Signing Keys. The Key Signing Key is used to sign other keys in order to build the chain of trust. This key is sometimes cryptographically stronger and has a longer lifespan than a Zone Signing Key. The Zone Signing Key is used to sign the data that is published in a zone. DNSSEC uses the Key Signing Keys and Zone Signing Keys to sign and verify records within DNS. BIG-IP Configuration The BIG-IP Global Traffic Manager (GTM) will not only respond to DNS requests, but it will also sign DNSSEC validated responses. But before you can configure the GTM to handle nameserver responses that are DNSSEC-compliant, you have to create DNSSEC keys and zones. The first step is to create the Zone Signing Key(s) and the Key Signing Key(s). The Zone Signing Key specifies the keys that the system uses to sign requests to a zone. The BIG-IP responds to DNSSEC requests to a specific zone by returning signed nameserver responses based on the currently available generations of a key. The Key Signing Key works the same as the Zone Signing Key except that it applies to keys instead of zones. To create these keys, navigate to Global Traffic >> DNSSEC Key List and create a new key. Note: this menu looks slightly different starting in version 11.5 (it's listed under "DNS" instead of "Global Traffic") but the Key Creation is still the same. On this page, you can create a Zone Signing Key and a Key Signing Key, and you can also specify several other settings like HSM use, algorithm selection, and key management action. Note that you can let the BIG-IP automatically manage your key actions or you can choose to do it manually. Configuration Settings The Bit Width for the key can be either 1024, 2048, or 4096 bits. The default is 1024. The TTL value specifies the length of time the BIG-IP stores the key in cache. A key can be cached between 0 and 4294967295 seconds (by the way, 4294967295 seconds is a little more than 136 years!). The default value is 86400 seconds (one day). This value must be less than the difference between the values of the rollover period and expiration period (referred to as the "overlap period"). Setting this value to 0 seconds indicates that client resolvers do not cache the key. The Rollover Period specifies the interval after which the BIG-IP creates a new generation of an existing key. The valid range for values for the Rollover Period is from 0 to 4294967295 seconds. The default is 0 seconds, which means the key does not roll over. This value of the rollover period must be greater than or equal to one third of the value of the expiration period and less than the value of the expiration period. The Expiration Period specifies the interval after which the BIG-IP deletes an existing key. The valid range for values is from 0 to 4294967295 seconds. The default is 0 seconds, which means the key does not expire. The value of the expiration period must be more than the value of the rollover period. Also, the overlap period must be more than the value of the TTL. FYI...the National Institute of Standards and Technology (NIST) recommends that a Zone Signing Key expire between 30-90 days, and that a Key Signing Key expire once a year. The Signature Validity Period specifies the interval after which the BIG-IP no longer uses the expired signature. The valid range for values is from 0 to 4294967295 seconds. The default is 7 days. This value must be greater than the value of the signature publication period. If you set this value to 0, the server verifying the signature never succeeds because the signature is always expired, so don't set it to 0! The Signature Publication Period specifies the interval after which the BIG-IP creates a new signature. The valid range for these values is from 0 to 4294967295 seconds. The default value is 4 days, 16 hours (two-thirds of a week). This value must be less than the value of the signature validity period. If you set this value to 0, the system does not cache the signature. TTL Values, Key Values, and Overlaps The following diagram shows an example of key generation timelines with rollover periods and overlaps. This diagram is useful when reviewing the configuration settings and values discussed in the section above. Notice that the expiration period must be greater than the rollover period, and the TTL must be less than the overlap period. You wouldn't want a key to expire before it rolls over; likewise, you wouldn't want a TTL period to outlast the overlap period...if it did, the key could still be valid after the expiration period. After you create and configure the Zone Signing Key(s) and Key Signing Key(s), the next step is to create a DNSSEC zone. A DNSSEC zone maps a domain name to a set of DNSSEC keys. In the BIG-IP, you create DNSSEC zones by navigating to Global Traffic >> DNSSEC Zone List and create a new zone. On this page, you can name the zone, configure state settings, assign algorithms, and activate zone keys. The hash algorithm options are SHA-1 (default) or SHA-256. The Zone Signing Key box specifies the zone keys that the BIG-IP uses to sign requests to a zone. The Key Signing Key works similar to the Zone Signing Key, except it is used to sign keys instead of requests. The following screenshot shows the options available for creating DNSSEC zones. To fully secure a zone, the parent zone needs to have copies of the child's public key. The parent zone then signs the child's public key with their own key and sends it up to their parent...this pattern is followed all the way to the root zone. Once you have created the DNSSEC keys and zones, you can submit the Delegation Signer (DS) record to the administrators of your parent zone. They will sign the DS record with their own key and upload it to their zone. You can find the DS record for your zone here: /config/gtm/dsset-dnssec.zone.name There's a lot to DNSSEC, and this article wasn't written to capture it all, but I hope it sheds a little light on what DNSSEC is and how you can create zones and keys on your BIG-IP. Stay tuned for more BIG-IP GTM articles in the coming days, weeks, and months. Until then, keep those DNS requests flowing, and make sure they are valid with DNSSEC! One last thing...did you know that F5 has an awesome Reference Architecture dedicated to Intelligent DNS Scale? The F5 Intelligent DNS Scale solution ensures that you can access your critical web, application, and database services whenever you need them...check it out!Lightboard Lessons: DNSSEC
DNS is absolutely critical to your life on the Internet. But, did you know that DNS was designed back in the 1980s and didn't really consider security as a key component? DNSSEC was developed to help with that problem. In this edition of Lightboard Lessons, I discuss the basics of DNSSEC and talk about how the BIG-IP can help protect your critical DNS infrastructure. Related Resources: Configuring DNSSEC on the BIG-IPA Living Architecture
You often hear people say, 'oh, this is a living document,' to indicate that the information is continually updated or edited to reflect changes that may occur during the life of the document. Your infrastructure is also living and dynamic. You make changes, updates or upgrades to address the ever changing requirements of your employees, web visitors, customers, partners, networks, applications and anything else tied to your systems. This is also true for F5's Reference Architectures. They too are living architectures. F5's Reference Architectures are the proof-points or customer scenarios that drive Synthesis to your data center and beyond. When we initially built out these RA's, we knew that they'd be continuously updated to not only reflect new BIG-IP functionality but also show new solutions to the changing challenges IT faces daily. We've recently updated the Intelligent DNS Scale Reference Architecture to include more security (DNSSEC) and to address the highly hybrid nature of enterprise infrastructures with Distributed DNS. F5’s end-to-end Intelligent DNS Scale reference architecture enables organizations to build a strong DNS foundation that maximizes the use of resources and increases service management, while remaining agile enough to support both existing and future network architectures, devices, and applications. It also provides a more intelligent way to respond and scale to DNS queries and takes into account a variety of network conditions and situations to distribute user application requests and application services based on business policies, data center conditions, network conditions, and application performance. It ensures that your customers—and your employees—can access your critical web, application, and database services whenever they need them. In this latest DNS RA rev, DNSSEC can protect your DNS infrastructure, including cloud deployments, from cache poisoning attacks and domain hijacks. With DNSSEC support, you can digitally sign and encrypt your DNS query responses. This enables the resolver to determine the authenticity of the response, preventing DNS hijacking and cache poisoning. Also included is Distributed DNS. Meaning, all the DNS solution goodness also applies to cloud deployments or infrastructures where DNS is distributed. Organizations can replicate their high performance DNS infrastructure in almost any environment. Organizations may have Cloud DNS for disaster recovery/business continuity or even a Cloud DNS service with signed DNSSEC zones. F5 DNS Services enhanced AXFR support offers zone transfers from BIG-IP to any DNS service allowing organizations to replicate DNS in physical, virtual, and cloud environments. The DNS replication service can be sent to other BIG-IPs or other general DNS servers in Data Centers/Clouds that are closest to the users. In addition, Organizations can send users to a site that will give them the best experience. F5 DNS Services uses a range of load balancing methods and intelligent monitoring for each specific app and user. Traffic is routed according to your business policies and current network and user conditions. F5 DNS Services includes an accurate, granular geolocation database, giving you control of traffic distribution based on user location. DNS helps make the internet work and we often do not think of it until we cannot connect to some resource. With the Internet of Nouns (or Things if you like) hot on our heels, I think Port 53 will continue to be a critically important piece of the internet puzzle. ps Related: Intelligent DNS Scale Resources F5 Synthesis DNS Reimagined keeps your Business Online DNS Does the Job The DNS of Things DNS Doldrums The Internet of Things and DNS Technorati Tags: f5,big-ip,dns,reference architecture,dnssec,iot,things,name_resolution,silva,security,cloud,synthesis Connect with Peter: Connect with F5:DevCentral Top 5: May 27, 2014
And here we are again...that fateful time when we admire and, yes, celebrate the amazing contributions of our DevCentral authors. The easy part is writing about all the great content; the hard part is picking just 5 articles to highlight. Nonetheless, here they are in no particular order...the DevCentral Top 5: Mitigating sslsqueeze and other no-crypto, brute force SSL handshake attacks If you don't know David Holmes, you pretty much need to stop whatever you are doing and start reading his stuff. In this article, he wows us again with his security expertise and shows us why we all love the flexibility (and programmability) of F5 technology. David wrote an article back in 2011 on an SSL Renegotiation DOS Attack and showed how a client can take advantage of a server in the SSL handshake because an SSL handshake requires at least 10 times more processing power on the server than on the client. Well, David recently found a new class of SSL attacks where the client doesn't do any cryptography at all...the client just sends a bunch of pre-canned packets that look like an SSL handshake. In this attack, the server uses 100 times more processing power than the client! David was able to get a copy of one of the tools (called sslsqueeze) that runs this attack and use it against a real, physical BIG-IP with cryptographic offload accelerators. He was able to take a $200 used computer and overload the BIG-IP with fake SSL handshakes. The good news is that he wrote an iRule (actually 2 iRules for different scenarios) to mitigate this attack. You gotta love the flexibility that iRules provide! The security world is an interesting one...attackers will always find a new vulnerability to exploit, and good guys will find a way to stop them. Thank goodness David Holmes is a good guy. Hybrid DDoS Needs Hybrid Defense It's not if you get DDoS attacked, but when. Lori MacVittie publishes another masterful write-up where she outlines a DDoS approach that many top analysts recommend. In the world of DDoS protection, it's best to implement off-premise detection and mitigation with on-premise protection. A hybrid solution provides the resiliency and scale of cloud based solutions with the granularity and always-on capabilities of on-premise solutions. Many times, when an organization is under attack, the answer is to shut down computationally expensive services to prevent overall service outages. But, this means IPS, firewalls, anti-fraud detection, etc are sometimes eliminated for the sake of keeping the network running. With a hybrid approach, an organization can take advantage of additional capacity in the cloud but still maintain the flexibility of protecting against more frequent and easily managed attacks. Where do you turn for the technology to make all this happen? The good news for everyone is that Defense.Net just joined forces with the F5 family. By combining the cloud-based services of Defense.Net and the on-premise protection of the F5 firewall, organizations will be better armed to detect and mitigate DDoS attacks at the network and application layers...simultaneously! The BIG-IP GTM: Configuring DNSSEC Is it awkward that I'm including one of my own articles in this edition of the Top 5? It's only weird if we let it be weird. So, I'm cool with it if you are. OK, but for real, F5 does some seriously awesome work when it comes to DNS services. We all know that DNS was originally built back in the 1980s, and it was designed with some inherent trust features that bad guys could exploit. When a user types a web address in his browser, he expects to be reliably directed to the correct website. If an attacker is able to manipulate the response from a DNS server, he could send the unsuspecting user to a malicious site that is full of malware. This vulnerability (among others) created the need for a more secure DNS experience. DNSSEC addresses the security problem by validating the response of DNS servers. This is done through a trust relationship that is built with a series of security keys. As you can imagine, validating each DNS response can be computationally expensive, so it's nice if you have custom-built, high powered hardware and software to do this job for you. Well, the BIG-IP GTM does just that. It will authoritatively answer your DNS requests, but it will also sign DNSSEC validated responses. You'll need to configure a few things on the BIG-IP to make this happen, but this article shows you all the steps needed to take care of that. So get out there and configure your BIG-IP GTM and let it handle all your DNS needs. Is OpenStack Ready For Production? Ranjeet Sonone answers THE question that runs through the mind of anyone diving deep on OpenStack. Way back in 2012, OpenStack lacked solid networking design and required significant resource allocation to be implemented in a true production environment. By 2013, OpenStack was gaining momentum and user success stories were helping it grow in popularity. But even then, you needed lots of system knowledge and scripting skills to assemble all the moving parts. So, many people were watching as 2014 approached to see if OpenStack was truly ready for prime time. The answer was given at the recent OpenStack summit in Atlanta, GA where 4,500 networking professionals heard about real world OpenStack success stories. OpenStack is now sufficiently rich in service offerings, and the core components are now stable for production environments...so, yes, it's ready for production! F5 has been investigating OpenStack for several years now, and we joined the OpenStack Foundation last year. Customers are now using F5 plug-ins in their OpenStack labs and sharing workloads between the public cloud and their private cloud. In the end, Ranjeet shows how F5 ensures that our customers have access to our custom built solutions when evaluating cloud platform integrations. Great job Ranjeet! Heartbroken and then Redeemed The Heartbleed vulnerability blew up a little over a month ago, and F5 was right there to help mitigate this significant problem. After the initial press from the Hearbleed bug had calmed down a little, a security researcher named Yngve Pettersen discovered hundreds of new Internet hosts that appeared to be vulnerable to Heartbleed. He called these newly vulnerable hosts "heartbroken" servers. He also noted that a specific characteristic on these servers suggested that they might be F5 devices. Not good, right? Well, our worldwide security evangelist David Holmes contacted Yngve and asked about his research. Yngve was kind enough to share his data with us. After all, he wasn't trying to give F5 a black eye, he was simply stating the results of his research. David (and a host of other F5 security experts) analyzed the data and found that actually none of the devices were F5 equipment. That's good news! Unfortunately, Yngve had already posted a technology blog about his initial findings, but he was gracious to remove the F5 references from his blog and offer an apology to F5 and F5's customers. I think that's really awesome stuff. Yngve is a really smart guy who discovered some very interesting data, but he is also a true professional in that he is willing to admit when he makes a mistake (as we all do). So, kudos to David for asking the clarifying questions, and kudos to Yngve for being a true professional.The DNS of Things
Hey DNS - Find Me that Thing! There's a new craze occurring in homes, highways, workplaces and everywhere imaginable - the Internet of Things or as I like to call it, The Internet of Nouns. Sensors, thermostats, kitchen appliances, toilets and almost every person, place or thing will have a chip capable of connecting to the internet. And if you want to identify and find those things with recognizable words instead of a 128-bit IP address, you're going to need DNS. DNS translates the names we type into browser or mobile app into an IP address so the services can be found on the internet. It is one of the most important components of the internet, especially for human interaction. With the explosion of mobile devices and the millions of apps deployed to support those devices, DNS growth has doubled in recent years. It is also a vulnerable target. While the ability to adjust the temperature of your house or remotely flush your toilet from around the globe is cool, I think one of the biggest challenges of the Internet of Nouns will be the strain on DNS. Not only having to resolve the millions of additional 'things' getting connected but also the potential vulnerabilities and risks introduced when your washing machine connects to the internet to find the optimal temperature and detergent mix to remove those grass, wine and blood stains. Recent research suggests that the bad guys are already taking advantage of these easy targets. Arstechnica reports that the malware that has been targeting routers has now spread to DVRs. Not my precious digital video reorder!! Last week, Sans found a Bitcoin mining trojan that can infect security camera DVRs. As they were watching a script that hunted the internet for data storage devices, they learned that the bot was coming from a DVR. Most likely, they say, it was compromised through the telnet defaults. In another report, ESET said it found 11 year old malware that had been updated with the ability to compromise a residential broadband router's DNS settings. The malware finds a vulnerable router and changes the default DNS entries to either send the person to a rogue site to install more malware (join the bot, why don't ya) or to just redirect them to annoying sites. Imagine if the 50+ connected things we will soon have in our homes also joined the bot? Forget about needing compute and bandwidth from machines around the globe, you can zero in on a neighborhood to launch an attack. Nominum research shows that DNS-based DDoS amplification attacks have significantly increased in the recent months, targeting vulnerable home routers all over. A simple attack can create tens-of-gigs of traffic to disrupt networks, businesses, websites, and regular folks anywhere in the world. More than 24 million home routers on the Internet have open DNS proxies which expose ISPs to DNS-based DDoS attacks and in February 2014 alone, more than 5.3 million of these routers were used to generate attack traffic. These are especially hard to track since it is difficult to determine both the origination and target of the attack. Lastly, Ultra Electronics AEP says 47% of the internet remains insecure since many top level domains (TLDs) have failed to sign up to use domain name system security extensions (DNSSEC). These include heavy internet using countries like Italy (.it), Spain (.es) and South Africa (.za), leaving millions of internetizens open to malicious redirects to fake websites. Unless the top level domain is signed, every single website operating under a national domain can have its DNS spoofed and that's bad for the good guys. We often don't think about the Wizard behind the curtain until we are unable resolve an internet resource. DNS will become even more critical as additional nouns are connected and we want to find them by name. F5 DNS Solutions can help you manage this rapid growth with complete solutions that increase the speed, availability, scalability, and security of your DNS infrastructure. And I do imagine a time when our current commands could also work on, for instance, the connected toilet: /flushdns. Just couldn't let that one go. ps Related: “Internet of Things” is the new Windows XP—malware’s favorite target Win32/Sality newest component: a router’s primary DNS changer named Win32/RBrute 24 million home routers expose ISPs to massive DNS-based DDoS attacks 24 million reasons to lock down DNS amplification attacks Half the internet lacks DNS security extensions F5 Intelligent DNS Scale Technorati Tags: f5,dns,dnssec,ddos,security,iot,things,big-ip,malware,silva,trojan Connect with Peter: Connect with F5:
DNS Reimagined keeps your Business Online
Whether your services are deployed in a data center or migrated to a hybrid cloud environment, DNS knows where to send your users to their cool new app or favorite social media experience. Invariably DNS points the way to a connected session. Yes, it’s at this IP address. Or, it’s not available here but accessible at that address location, all in milliseconds. So with all kinds of new mobile devices, apps, and services, DNS requests (.com/.net) continue to climb 100% over the last 5 years. In 2014, there are 10 billion devices alone with 77 billion mobile apps downloaded. It’s estimated that there will be 50 to 75 billion devices by 2020. Along with all the other products already connected or coming, the Internet of Things sending DNS requests is about to become much larger. In addition, we don’t like to wait. If a mobile user has to wait more than 10 seconds, they’ll leave for another experience and revenue potential is lost. At the same time, as more online experiences move to the hybrid cloud, these virtual services are in a myriad of locations all requiring DNS to inform the client where the data is in order for the user to have a connected session. More locations means more latency and DNS needs to perform with fast responses in order to keep users engaged. Since DNS is essentially the yellow pages of the internet resolving queries, it’s critical to have a highly scalable, exponential performing, and secure DNS infrastructure in order to deliver an optimized user experience. F5 reimagines the traditional DNS delivery infrastructure as a paradigm shift to the edge of the network moving DNS services and app routing closest to the client based on geolocation. BIG-IP Global Traffic Manager (GTM) with DNS delivery services, including Authoritative DNS, delivers very high performance responding to DNS queries on behalf of the DNS master server. In addition, much lower latency comes with Caching and Resolving services at the edge for internal users or subscribers, and increased DNS security services for DDoS mitigation and DNSSEC all come on an ICSA network firewall certified solution. Finally, implementing DNSSEC signing protects against man-in-the-middle and cache poisoning attacks that would redirect the user to a malicious session. The results are an easy integration into existing DNS infrastructure, and the performance capabilities well into the tens of millions of DNS query responses per second on higher end solutions to keep your web sites and apps available during all kinds of scenarios. Users will see a much faster and more secure query response allowing for a far better user experience and greater potential for business growth. Now your DNS infrastructure is ready to scale exponentially and securely to meet the growing demand and you have global app routing for an optimized and highly available sessions. Automatically, your users’ DNS request for that customized online experience materializes, or that new business analytics site located at a closer location to them quickly loads. And, malformed DNS queries, invalid requests, are dropped to mitigate attacks. With large increases in DNS requests; automatic responses are sent at very high performance to keep online sessions available. These and many more options for DNS services and customization support apps and services uptime, keeping your business alive. Now more recently you might have been informed that you need to move a portion of your apps and services to a hybrid cloud environment to meet cloud computing, disaster recovery, and cost reduction goals. As you ponder how to deliver a similar experience to users, consider what type of DNS and global app routing you need to replicate in various virtual and cloud environments in order to accomplish your new objective. To learn more about how DNS supports the internet and how F5 supports cloud-hosted services, read the F5 Synthesis: DNS Shrugged article to help you accomplish your new mission. For more information on Intelligent DNS and Global App Management: Intelligent DNS Services Scalable, Secure DNS and Global App Services
F5 Synthesis: DNS Shrugged
#DNSSEC #Cloud #SDAS #IoT #F5 DNS Anywhere and Everywhere "In Greek mythology, Atlas (/ˈætləs/; Ancient Greek: Ἄτλας) was the primordial Titan who held up the celestial sphere. He is also the titan of astronomy and navigation." (Wikipedia, Atlas) How apropos, then, that DNS should be much like the Atlas of the Internet, responsible for guiding users to their digital destinations by resolving easy to remember names (like constellations) into IP addresses (like coordinates used in astronomy to locate the stars). What if DNS shrugged? Just for a moment? The Internet, like the world, would fall over. Everything - from sensors, to computing devices to toasters and pens, from applications and business transactions would cease to function correctly. We could deluge you with data points showing losses of advertising revenue in the publishing space, or the chain reaction of revenue losses that can occur when a major payment processing center experiences a DDoS attack targeting DNS, or the losses in productivity that is the inevitable result of a non-responsive or downed DNS server that prevents employees from accessing critical data. But you already know all that, just as you know that IoT combined with increasing attacks are putting tremendous pressure on DNS not just to stay responsive, but stay up at all. That's why it's important to evaluate your DNS infrastructure now and determine whether or not it will shrug in the face of the forthcoming deluge of data and attacks. F5 Synthesis: DNS Anywhere and Everywhere F5 takes DNS seriously. It's the underlying enabler of global server load balancing, which means it's also responsible for enabling hybrid, multi-site cloud architectures. It's critical to the 42.9% of respondents that rely on secondary sites as their primary DR strategy according to the 2014 Disaster Recovery Benchmark. That means DNS needs to be fast and it needs to be flexible and it needs to be fluent. One of the services included in F5 Synthesis Software Defined Application Services (SDAS) is, as you might have guessed, DNS. That service isn't just caching DNS to ensure availability and performance of existing DNS infrastructures, it is a fully functional and highly performance DNS resolver itself, providing the highest performance DNS Caching and Resolving solution as well as the highest performance DNS DDoS attack mitigation, with the added bonus of LDNS cache poisoning protection with DNSSEC. When deployed on a full capacity F5 Synthesis High Performance Services Fabric, F5 DNS services can resolve nearly 630 million queries per second. At that rate, it would take less than 2 seconds to resolve the address of every one of the 861 million sites on the Internet according to the Jan 2014 Netcraft Web Server Survey. You may need think you don't need that kind of massive scalability, but with the increasing denial of service attacks on DNS, you will need that kind of scale if you're going to stay responsive. The reality is you can't stop someone from launching an attack because you don't control their actions. So you're going to be hit with thousands or millions of requests per second that you have to do something with. And if your DNS infrastructure can't scale to that capacity, the legitimate requests your customers, partners, and employees are waiting for are going to get lost. And that means lost revenue, lost trust, lost productivity. You might be thinking about using cloud computing to mitigate the potential risk or as a disaster recovery option. f5 Synthesis can make that happen, too. Because f5 Synthesis High Performance Services Fabric takes advantage of a heterogeneous resource approach, it can be deployed on hardware, software, virtual machines or in the cloud, That means high performance, scalable and secure DNS anywhere. Not only can F5 DNS replicate zones to cloud-hosted DNS services, but because it natively supports DNSSEC it can bring security to those environments that are not yet DNSSEC-enabled. Migrating to an F5 Synthesis-based DNS infrastructure can also significantly reduce the CAPEX and OPEX associated with scaling traditional DNS infrastructures and enable more accurate and intelligent decisions regarding application routing by taking advantage of F5 integrated services such as geolocation and botnet identification. No matter where you are in your DNS initiatives, take a minute to seriously consider what would happen if your DNS shrugged, and then take steps to avoid potential disaster. For more information on Synthesis: F5 Synthesis Site More DevCentral articles on F5 Synthesis
All your router are belong to us...
With the recent headlines about vulnerabilities in home broadband routers,http://www.scmagazineuk.com/concerns-over-asus-and-linksys-router-vulnerabilities/article/334710/ and http://www.bbc.co.uk/news/technology-26417441 , I was reminded of something that happened to me. A True Story I was spending time with my extended family over Christmas and, as usual, we all had our heads in our phones or “i” devices. Working in IT I generally spend my holidays fixing “computer issues” for my friends and family. I won’t ever tell them my secret, turn it off trick or else I may lose my payment in beer privileges… We were all engrossed in our online devices when my wife asked me to look at her laptop. She was reading a well-regarded news site when, all of a sudden, there were a lot of ads popping up on her screen. As I was a few beers in at this stage I decided I would look at in the morning, assuming it was some sort of malware and nothing that a quick scan wouldn’t fix. Imagine my surprise when the same adds started appearing on my iPad. "Gentlemen, you had my curiosity. But now you have my attention.” (Calvin Candie: [to Django and Schultz] - Django Unchained (2012)). What could have been causing this? I was really intrigued. As far as I knew it was very unlikely that my iPad had been compromised like this and, because it was now happening on all devices on the home WiFi, it could only be one thing: The Router The router in question, which was not a Linksys or Asus, but another major vendor, was in its usual place and all the correct lights were shining. I decided to take a look and logged on. Everything looked ok, nothing major jumped out, then I spotted an unfamiliar DNS server. I can’t actually remember what it was now but I changed it back to the “trustworthy” Google DNS of 8.8.8.8 and do you know what happened? All the ads disappeared - they stopped popping up on all the devices. So what happened and how can you prevent it? The most likely cause - and I say most likely because I did not spend too much time looking at it, I needed to get back to Christmas TV and my beer – is that someone, quite possibly form a generic port scan, spotted a vulnerable router and executed some remote code to update the DNS settings. I have to admit this particular device was using the default password, so it was not much of a challenge. Changing the DNS server was a very clever ploy. By doing this they could effectively respond with any address they wished, for any website that was being accessed from that router. All we managed to see were ads, so they were cashing in on selling ads for some of those dodgy link sites, but they could also have acted as a proxy for all internet traffic from this router. Imagine this: I access my bank account, unknown to me all my details are being intercepted and possibly stolen or used later to log on to my bank account. Now what can be done? Well, there are a couple of things. Don’t leave routers with default passwords and keep the software up to date. But what about my bank or the other sites I access? Could they do anything? Well actually there is a very simple solution that can protect any brand on the internet. A very simple tool called DNSSEC. It is the process of digitally signing a DNS request and getting a verified response back from the site you want to go to. It relies on a chain of trust within the DNS infrastructure form the ROOT to the individual organisations, so when a user tries to find your site they can be assured that they are looking at your actual site and not being routed through a proxy. In this case, when I accessed my bank’s website, I would have requested a DNSSEC response form my bank and unless the response actually came from my bank I would have seen an error, so I would have been able to take action at that point, regardless of where the actual issue was. The top level .uk domain has been signed since 2011 and it is relatively simple to enable on a domain. using something like F5 GTM you can transparently add DNSSEC to any DNS server without changing anything. It is really that simple. DNS is the forgotten security tool and can be used in your defence policy to help protect your brand online and provide an additional layer or protection to your customers and users.Carrier Grade DNS: Not your Parents DNS
Domain Name System (DNS) is one of the overlooked systems in the deployment of 4G and Next Generation All IP Networks. The focus tends to be on revenue-generating applications that provide ROI for these major investments. For these to be successful the CSP's have first got to be able to deploy these networks, and provide a high quality of experience in order to be sure that these services are truly revenue generating. However, most CSP’s have overlooked some of the basic IP functions in order to provide these revenue generating applications. The building blocks for these applications are a quality, efficient, scalable, and feature-rich IP architecture. One of the key items that are required for this IP architecture is Carrier Grade DNS. DNS has been a long-standing requirement for Internet services for CSP's. However with these all IP networks, DNS is being used for new capabilities along with supporting increases in data traffic for standard content and Internet services. For years CSP's and employed cheap, inexpensive, and basic DNS systems on their network. This was done to provide basic DNS services and to minimize cost. However with and developing networks, these basic DNS deployments will not support the requirements of the future. DNS services are starting to be used for new and unique capabilities, which include managing traffic on both the internal network along with external content that is located on the Internet. Along with this new functionality, DNS is also required to provide security of DNS transactions and have the ability to mitigate against DNS attacks, along with providing for authoritative DNS zone management, resolution, and non-authoritative support, such as caching. The significant challenge for communication service providers is to provide these DNS capabilities while still maintaining a manageable Capex and Opex. This challenge can only be met by deploying a carrier grade DNS solution. The carrier grade DNS solution comprises all the basic capabilities of DNS, along with including a logical scaling capability, security for DNS transactions, and an ability to intelligently manage authoritative zones. Historically, traditional DNS solutions have addressed scaling by simply adding more hardware. This method is a Capex nightmare. With the increases in data and data demands, these problems with DNS scaling will grow exponentially. The only solution to this problem is the ability to deploy an intelligent DNS system that allows the communication service provider the ability to manage how DNS queries and how DNS authoritative responses are managed and delivered to subscribers. Since DNS is key in the ability to identify the location of web content it is vulnerable to both DNS hijacking attacks and denial of service (DoS) or distributed denial of service (DDoS) attacks. To prevent DNS hijacking attacks, carrier grade DNS solutions must be incorporated DNSSEC. By incorporating DNSSEC, responses to subscribers are guaranteed the identity of the answering authoritative DNS. DoS/DDoS attacks cannot be prevented. The only strategy they can be taken against DoS/DDoS is to mitigate the impact of these attacks. The best way to address the mitigation the impact of DoS/DDoS attacks is through a distributed carrier grade DNS architecture. By using such technologies as Global Server Load Balancing (GSLB) and IP Anycast, a distributed carrier grade DNS architecture can isolate and limit the impacts of DoS/DDoS attacks. GSLB allows the communication service provider to manage how DNS requests are answered based upon the location of the contents and the requester. IP Anycast allows for multiple systems to share the same IP address thereby distributing the number of systems answering request. By using these distributed systems DoS/DDoS attacks can be isolated and minimize the number of systems impacted. As we have seen over the past year, data use on CSP networks is going to continue to increase. To provide a successful ARPU model, a Carrier Grade DNS that provides for high availability, economical scalability, subscriber security, and high performance in essential. With all of the many challenges in a CSP network, basic IP infrastructure can be overlooked. An intelligent management system of these IP essential systems is the first step in reducing an ever expanding Capex and providing for a high quality of experience for your subscribers. Related Articles DNS is Like Your Mom F5 Friday: No DNS? No … Anything. Audio White Paper - High-Performance DNS Services in BIG-IP ... DevCentral Weekly Roundup | Audio Podcast - DNS F5 Friday: When the Solution to a Vulnerability is Vulnerable You ... F5 News - DNS DNS Monitor Using Dig - DevCentral Wiki The End of DNS As We Know It F5 Video: DNS Express—DNS Die Another Day Ray Vinson – DNS
