DevCentral

You know how scientists hypothesize that there are an infinite number of universes? 2016 is a year that forces me to confront the reality that they may be right. I've been starting to think that we live in one of the bizarre, alternate universes where crazy things happen on a regular basis. In all those the other sane universes, the following things didn't happen in 2016: George Michael, "singer of Last Christmas", doesn't die... on Christmas Murder clowns don't hide in the woods and cause teen panic. The Cubs don't come from 3-1 to win the World Series in game 7. Harambe doesn't gather 14,000 votes in the presidential election. A reality show star doesn't become the President of the United States. The closer you look the more you'll realize that I'm right. It's unsettling to think about it. So let's think about something else - how about a retrospective on the ramblings of your rogue security storyteller. Also check out this cool Spanish vanity website I built with Django.  www.davidholm.es/pro/year/2016 Drawing from this archival site for all things yours truly, we can see there are 47 items to choose from. That's too many, so let's just do have a look at the best ones. Network World: What Keeps White Hat Hackers from Turning the Dark Side? The idea for this, one my favorite articles ever, had been rattling around my head for years. The premise came from a lunch discussion among my friends: "how much would it take for you to hack for evil?"  I surveyed over three dozen of my friends and colleagues to find out what their prices were, if any. Some illuminating results.  DevCentral Video: SSL Outbound Lightboard Lesson People loved this 12-minute video illustrating a complex problem. Well my colleagues did anyway. Had fun flying to St. Louis where Jason Rahm and John Wagnon let me use their supercool lightboard studio. Newsroom: Making Sense of the Krebs / OVH / Dyn DDoS Attacks Here's my take on the huge DDoS attacks of September and October 2016. Had to rush this one to release as an official company position on the attacks. I really like how it came out. One customer read it and said "We need to talk to the guy that wrote this! Get him here!" Blog: The Top Ten Hardcore F5 Security Features in BIG-IP 12.1 It took me 23 hours to write this! But people LOVED IT. Continuing my tradition of the top security features of each F5 BIG-IP release. Follow my countdown of the top ten most hardcore security features in the TMOS 12.1 release. Whitepaper: 2016 DDoS Attack Trends Here's an awesome whitepaper I wrote in the fall of 2016. I embedded eight references to Huey Lewis and the News. Can you find them all?   SecurityWeek: Is DROWN a 'Hello Kitty' SSL Vulnerability? Should you panic about the DROWN SSL vulnerability? Is it cute and kid-friendly, or is it a monster vulnerability coming to expose your most sensitive data? This piece I did for SecurityWeek builds upon the "Stack Ranking SSL Vulnerabilities" article I'd written the year before. SecurityWeek: Cyber Espionage Report: APT at RUAG I get lucky sometimes. This was one of those times. I ran into a member of CERT.be, and he told me of an interesting report about a cyberespinage case in Europe. Made for a great SecurityWeek article. DevCentral iRule: Mirai Strikeback - an iRule to kill IoT Bot Processes from your F5 Wrote this cool script to kill Mirai bots that are attacking your website. So satisfying because how often do you get to strike back at your cyber attackers? Almost never! Use at your discretion, because technically it's a bit of a hack, and hacking is illegal kids. So many consider this a proof concept. SecurityWeek: Hacking Europe's Smart Cities A young hacker came up to me after a talk in Belgium and told me how some hackers were taking slight advantage of the smart city infrastructures in Europe. Made for a

IT organizations have a simple goal: make it easy for workers to access all their work applications from any device. But that simple goal becomes complicated when new apps and old, legacy applications do not authenticate in the same way. In this Lightboard Lesson, I draw out how VMware and F5 helps remove these complexities and enable productive, any-device app access. By enabling secure SSO to Kerberos constrained delegation (KCD) and header-based authentication apps, VMware Workspace ONE and F5 BIG-IP APM help workers securely access all the apps they need—mobile, cloud and legacy—on any device anywhere. ps Related: Single Sign-On (SSO) to Legacy Apps Using BIG-IP & VMware Workspace ONE Simple & Secure Access to Legacy Enterprise Applications (pdf) Lightboard Lessons Playlist

The BIG-IP Application Security Manager (ASM) is a powerful Web Application Firewall that protects your web applications against all kinds of threats.  It's important to understand, though, how this tool works and what options you have for building a security policy.  In this edition of Lightboard Lessons, we talk about the different options for building a security policy with the ASM and why you might choose one option over another.  Enjoy!   Additional Resources: BIG-IP ASM Data Sheet Configuring BIG-IP ASM (Article Series)  

Get Started with SSL Orchestrator SSL and its brethren TLS is becoming more prevalent to secure IP communications on the internet. It’s not just financial, health care or other sensitive sites, even search engines routinely use the encryption protocol. This can be good or bad. Good, in that all communications are scrambled from prying eyes but potentially hazardous if attackers are hiding malware inside encrypted traffic. If the traffic is encrypted and simply passed through, inspection engines are unable to intercept that traffic for a closer look like they can with clear text communications. The entire ‘defense-in-depth’ strategy with IPS systems and NGFWs lose effectiveness. F5 BIG-IP can solve these SSL/TSL challenges with an advanced threat protection system that enables organizations to decrypt encrypted traffic within the enterprise boundaries, send to an inspection engine, and gain visibility into outbound encrypted communications to identify and block zero-day exploits. In this case, only the interesting traffic is decrypted for inspection, not all of the wire traffic, thereby conserving processing resources of the inspecting device. You can dynamically chain services based on a context-based policy to efficiently deploy security. This solution is supported across the existing F5 BIG-IP v12 family of products with F5 SSL Orchestrator and is integrated with such solutions like FireEye NX, Cisco ASA FirePOWER and Symantec DLP. Here I’ll show you how to complete the initial setup. A few things to know prior – from a licensing perspective, The F5 SSL visibility solution can be deployed using either the BIG-IP system or the purpose built SSL Orchestrator platform. Both have same SSL intercept capabilities with different licensing requirements. To deploy using BIG-IP, you’ll need BIG-IP LTM for SSL offload, traffic steering, and load balancing and the SSL forward proxy for outbound SSL visibility. Optionally, you can also consider the URL filtering subscription to enforce corporate web use policies and/or the IP Intelligence subscription for reputation based web blocking. For the purpose built solution, all you’ll need is the F5 Security SSL Orchestrator hardware appliance. The initial setup addresses URL filtering, SSL bypass, and the F5 iApps template. URL filtering allows you to select specific URL categories that should bypass SSL decryption. Normally this is done for concerns over user privacy or for categories that contain items (such as software update tools) that may rely on specific SSL certificates to be presented as part of a verification process. Before configuring URL filtering, we recommend updating the URL database. This must be performed from the BIG-IP system command line. Make sure you can reach download.websense.com on port 80 via the BIG-IP system and from the BIG-IP LTM command line, type the following commands: modify sys url-db download-schedule urldb download-now false modify sys url-db download-schedule urldb download-now true To list all the supported URL categories by the BIG-IP system, run the following command: tmsh list sys url-db url-category | grep url-category Next, you’ll want to configure data groups for SSL bypass. You can choose to exempt SSL offloading based on various parameters like source IP address, destination IP address, subnet, hostname, protocol, URL category, IP intelligence category, and IP geolocation. This is achieved by configuring the SSL bypass in the iApps template calling the data groups in the TCP service chain classifier rules. A data group is a simple group of related elements, represented as key value pairs. The following example provides configuration steps for creating a URL category data group to bypass HTTPS traffic of financial websites. For the BIG-IP system deployment, download the latest release of the iApps template and import to the BIG-IP system. Extract (unzip) the ssl-intercept-12.1.0-1.5.7.zip template (

The Web, while convenient and necessary for business, can be a dangerous and scary place.  The good news is that F5 offers a security solution called WebSafe.  WebSafe protects against sophisticated fraud threats, leverages advanced encryption, detects client-less malware, and analyzes session behavior in a single solution.  MobileSafe is very much like WebSafe except it is uniquely designed and tuned for the mobile environment.  The frosting on the cake for all this goodness is that WebSafe and MobileSafe alerts come to our F5 Security Operations Center (SOC) where our team of security experts are hard at work 24x7 to analyze all your threat data and help mitigate the threats to your business.  How does WebSafe actually work?  What about MobileSafe?  Check out this edition of Lightboard Lessons to learn more!     Related Resources: WebSafe Data Sheet MobileSafe Data Sheet  

I’ve been reading up on APIs cause, coolness. And in particular I really enjoyed reading Best Practices for Designing a Pragmatic RESTful API because it had a lot of really good information and advice. And then I got to the part about compressing your APIs. Before we go too far let me first say I’m not saying you shouldn’t compress your API or app responses. You probably should. What I am saying is that where you compress data and when are important considerations. That’s because generally speaking no one has put their web server (which is ultimately what tends to serve up responses, whether they’re APIs or objects, XML or JSON) at the edge of the Internet. You know, where it’s completely vulnerable. It’s usually several devices back in the networking gauntlet that has be run before data gets from the edge of your network to the server. This is because there are myriad bad actors out salivating at the prospect of a return to an early aughts data center architecture in which firewalls, DDoS protection, and other app security services were not physically and logically located upstream from the apps they protect today. Cause if you don’t have to navigate the network, it’s way easier to launch an attack on an app. Today, we employ an average of 11 different services in the network, upstream from the app, to provide security, scale, and performance-enhancing services. Like compression.   Now, you can enable compression on the web server. It’s a standard thing in HTTP and it’s little more than a bit to flip in the configuration. Easy peasy performance-enhancing change, right? Except that today that’s not always true. The primary reason compression improves performance is because when it reduces the size of data it reduces the number of packets that must be transmitted. That reduces the potential for congestion that causes a Catch-22 where TCP retransmits increase congestion that increases packet loss that increases… well, you get the picture. This is particularly true when mobile clients are connecting via cellular networks, because latency is a real issue for them and the more round trips it takes, the worse the application experience. Suffice to say that the primary reason compression improves performance is that it reduces the amount of data needing to be transmitted which means “faster” delivery to the client. Fewer packets = less time = happier users. That’s a good thing. Except when compression gets in the way or doesn’t provide any real reduction that would improve performance. What? How can that be, you ask. Remember that we’re looking for compression to reduce the number of packets transmitted, especially when it has to traverse a higher latency, lower capacity link between the data center and the client. It turns out that sometimes compression doesn’t really help with that. Consider the aforementioned article and its section on compressing. The author ran some tests, and concluded that compression of text-based data produces some really awesome results: Let's look at this with a real world example. I've pulled some data from GitHub's API, which uses pretty print by default. I'll also be doing some gzip comparisons: $ curl https://api.github.com/users/veesahni with-whitespace.txt $ ruby -r json -e 'puts JSON JSON.parse(STDIN.read)' without-whitespace.txt $ gzip -c with-whitespace.txt with-whitespace.txt.gz $ gzip -c without-whitespace.txt without-whitespace.txt.gz The output files have the following sizes: without-whitespace.txt - 1252 bytes with-whitespace.txt - 1369 bytes without-whitespace.txt.gz - 496 bytes with-whitespace.txt.gz - 509 bytes In this example, the whitespace increased the output size by 8.5% when gzip is not in play and 2.6% when gzip is in play. On the other hand, the act of gzipping in itself provided over 60% in bandwidth savings. Since the cost of pretty printing is relatively small, it's best to pretty print by default and ensure gzip compression is supported! To further hammer in this point, Twitter

Gartner predicts that by 2020, IoT security will make up 20 percent of annual security budgets. 2020 seems to be an important milestone for the Internet of Things. That’s the year that Cisco says there will be 50 billion connected devices and also the year Gartner notes that over 50% of major new business processes and systems will incorporate some element of the Internet of Things. That’s the good news. A recent Symantec Internet Security Threat Report says there are 25 connected devices per 100 inhabitants in the US. Minimum 25 entry points to your personal information, not counting your front door, personal computers, compromised ATMs and other data sources. As your connected devices grow, so will your exposure. And with no clear methods of identifying and authenticating connected devices, enterprises will have a challenging time getting a handle on how many employee shirts, shoes, fitness trackers, and smartwatches are connected to the corporate network. And more importantly, what do they have access to? The sneaky spreadsheet macro malware will soon be a spoofed critical alert requiring instant attention. Healthcare is a prime target for IoT attacks and researchers have already compromised several devices revealing personal info and worse, causing the devices to malfunction. ‘Hey, why isn’t my heart beating any……’ The chaos on the feature first consumer side can be frustrating but nothing compared to industrial and manufacturing. The Industrial Internet of Things (IIoT) focuses on industrial control systems, device to network access and all the other connective sensor capabilities. These attacks are less frequent, at least today, but the consequences can be huge – taking out industrial plants, buildings, tractors, and even entire cities. If you think data protection and privacy are hot now, just wait until 2020. Like BYOD, security pros need to be ready for the inevitable not just the potential of a breach. While the gadgets get all the interest, it’ll be the back end data center infrastructure that will take the brunt of the traffic – good and bad. Organizations need an infrastructure that can both withstand the traffic growth and defend against attacks. Over on F5’s Newsroom, Lori MacVittie talks about the 3 Things the Network Must Provide for IoT – delivery, security and visibility. Things that can communicate securely with back-end apps, ADC’s that can understand the languages of things (like MQTT) and the ability to see what is going on with the things. According to TechTarget, ensuring high availability of the IoT services will rely on boosting traffic management and monitoring. This will both mitigate business continuity risks, and prevent potential losses. From a project planning standpoint, organizations need to do capacity planning and watch the growth rate of the network so that the increased demand for the required bandwidth can be met. If you already have BIG-IP in your back yard, you’re well on your way to being IoT ready. You got the network security to protect against inbound attacks; you can offload SSL to improve the performance of the IoT application servers; you can extend your data centers to the cloud to support IoT deployments; scale IoT applications beyond the data center when required and both encrypt and accelerate IoT connections to the cloud. A pair of BIG-IPs in the DMZ terminates the connection. They, in turn, intelligently distribute the client request to a pool (multiple) of IoT application servers, which then query the database servers for the appropriate content. Each tier has redundant servers so in the event of a server outage, the others take the load and the system stays available. The BIG-IP tuning may vary but it is still all about nodes, hosts, members, pools, virtual servers and the profiles and services applied. The BIG-IP platform is application and location agnostic, meaning the type of application or where the application lives does not matter. As long as you tell the BIG-IP

Fun and a little mental. If you’ve been following along the DevCentral team’s journey toward F5 Certification, then you may be aware that we were in Chicago last week for F5’s Agility 2016 conference and took our 101 Application Delivery Fundamentals exam. I am happy to report that all of us, Jason, John, Chase and I, passed our exams. I gotta tell you, it’s a relief since I didn’t want to title this article, 'Two Out of Three Ain’t Bad.' Good song but wanted to avoid that. We started this excursion back in April (me in March) with the team deciding to create a study group. Each week we’d tackle a topic with the guidance of Eric Mitchell’s excellent Study Guide. We worked through the sections and decided to test our luck with the Certification Team’s mobile testing center...with the pressure of passing during an F5 event. Imagine the slight pre-test anxiety going through our minds if we didn’t pass. ‘How long have you been at F5?’ the questions would have started. My mouth covering, embarrassing, face-palming, muffled response of, ’12 years,’ would not have been sufficient. As Ken told us on the way into the exam room, ‘I tell people it is either pass or fail…so don’t worry about your overall score.’ But he also added specifically to me, ‘You know if you fail, I will give you grief.’ No Pressure. Well, we were prepared and we all passed! Jason, John and I took the exam Tuesday morning. After registering and scheduling with Pearson Vue, we arrived at the mobile test center. You need to sign in and present two forms of ID, one with your picture. Even though the Certification team knew all of us, we still needed to follow the procedure, no exceptions. We liked that we had no special treatment – other than the ‘hello’ hugs – and had to process and pass fair and square. We were seated in different areas since the exam room was fairly full when we entered. The moderator helped each of us get to the proper test associated with our registration and the timer started. For the 101, you have 90 minutes to answer 80 questions. At 23 minutes in, Jason got up and was finished. ‘Wa?!?’ as I look up seeing him walk by, ‘I’m only on question 28!’ I lamented. At least John was still there and I kept an eye on my time and question count the rest of the way. But I also told myself, ‘I’m in no hurry and if I need the full 90 minutes, I’ll take it to the last tick.’ John finished about a 40 minutes later and I was left for the last 30 to myself. With 10 minutes left, I was done but took that remaining time to review my answers. One tip: you can flag questions for review during the test or make comments for yourself as you move along. Close out the ones you know and go back for the more challenging questions. In the end I think I changed 3 answers. No idea if it swayed the results either way. When you are done, you walk back to the registration room and your preliminary results are already waiting. I felt a quiver when Heidi glanced at my results and gave that ‘I’m sorry,’ look. But that was soon turned to glee as I read, ‘you have Passed.’ We were 3 for 3. Chase took the test on Wednesday and also passed. I feel it was a very fair test to determine one’s basic application delivery knowledge. Some networking, some security, some infrastructure. And although we did prepare, it was still a challenging test. These exams are not supposed to be cake-walks but a good way to measure your knowledge around a certain topic. While we passed and may be certifiable in our own right, we are not ‘officially’ F5 Certified. That comes with the 201 exam. The 201-TMOS Administration exam is the second exam required to achieve Certified F5 BIG-IP Administrator status. Candidates must have passed the 101-Application De

An interesting topic was talked about in the recent Black Hat conference. It is a new attack called HEIST (HTTP Encrypted Information can be Stolen through TCP-windows) which demonstrates how to extract sensitive data from any authenticated cross-origin website. What makes this attack unique is the ability to execute without any sort of traffic eavesdropping or man-in-the-middle scenarios. The attack happens in the browser, upon visiting an attacker-controlled website. Basics of a HEIST The HEIST attack, as described by Leuven University researchers Mathy Vanhoef and Tom Van Goethem, makes use of a new browser feature called Service Workers and specifically a new interface called Fetch API. The Fetch API, much like XMLHttpRequest (XHR), allows for arbitrary requests to be sent from the browser. These requests may also include sensitive authorization information such as session cookies. It is obviously not so trivial to read the responses from requests sent by Fetch API or XHR, due to the Same-origin Policy (SOP) enforced by the browser. However, it may be possible to use side channel attacks to infer information about the size of the response and in certain circumstances even extract personal data. No Empty Promises The attack uses the Fetch API and its performance measuring tool. Shortly after an arbitrary request is sent using Fetch API, the browser creates a Promise object in the DOM. This object is created once the browser starts receiving data from the server. A “responseEnd” attribute is added to the object once the browser fully receives the entire data. The “patent” of the attack is knowing whether the response consisted of either one TCP packet, or more. That is by measuring the time between the Promise object creation and “responseEnd”. This allows the attacker to detect an approximate size of any page, as it appears to the victim. For pages that reflect user-input data, the attacker may detect the exact size of the response. Can I (Ab)Use? Service Workers are supported in the following browsers: This table shows that a rather large majority of browsers in the market today already support Service Workers. The trend is expected to grow as Service Workers are useful with creating dynamic and responsive web applications. Source: http://caniuse.com/#feat=serviceworkers Call the Police! In this section we’ll go over possible mitigations, including solutions available for BIG-IP users. Disable third-party cookies The researchers list disabling third-party cookies as the only real mitigation for this attack. By disabling this functionality, the browser won’t send authorization information in Fetch API and XHR requests made to cross-origin domains. Pros: Completely disables the attack. Cons: The setting happens in the browser. Web servers cannot enforce this setting upon users. Also, it is unclear what functionality may be hampered by disabling third-party cookies. Applying data in varying lengths to responses The researchers also list this action as a possible mitigation. The idea is to add data at random lengths to every response. This will considerably affect the attacker’s ability to understand what is the actual response length. The original attack requires up to 14 requests in order to detect the exact response length. By adding random data in different possible lengths, the attacker may have to work much harder and be more aggressive towards the web server. The following is an iRule that adds this functionality to BIG-IP virtual servers: when HTTP_RESPONSE { set sRandomString {} set iLength [expr {int(rand() * 1000 + 1)}] for {set i 0} {$i < $iLength} {incr i} { set iRandomNum [expr {int(rand() * 62)}] if {$iRandomNum < 10} { incr iRandomNum 48 } elseif {$iRandomNum < 36} { incr iRandomNum 55 } else { incr iRandomNum 61 } append sRandomString [format %c $iRandomNum] } HTTP::header insert X-HEIST $sRandomString log local0. "Added random header X-HEIST

Companies that are subject to security audits, such as PCI DSS, could benefit from a solution that takes sensitive information and moves it from their web servers to the enterprise edge or ingress point and thus reduces the exposure of live and regulated data on the internal IT network.  In this edition of Lightboard Lessons, I walk through a creative solution that was developed by F5's own Adam Auerbach and Ziv Saar (with iRule support from Rodney Newton), and this solution can significantly reduce the cost and complexity of sensitive data audits.       Related Resources: Secure Data Tokenization White Paper