Everything old is new again. Security researcher Hanno Böck and friends built a neat little Python adaptive chosen-ciphertext attack proof-of-concept (POC) tool and ran it against many popular websites. They call their attack the “ROBOT”, which stands for Return of Bleichenbacher Oracle Threat, and they’ve published their results at robotattack.org. For this article I’ll be using the word Bleichenbacher to mean the general attack, and ROBOT to mean this latest, optimized version that includes a key signature attack. F5’s SSL/TLS stack was one of the stacks that was found vulnerable. We issued knowledge base article K21905460 in November of 2017 with details for immediate consumption. K21905460 is the official F5 response, and this article is for those looking for a more detailed explanation of the attack, as well as the detection and mitigation strategies related to the vulnerability. CVE-2017-6168 describes a Bleichenbacher attack against the F5 TLS stack. The theory of the attack isn’t new; primers on SSL/TLS mentioned it as early as 1998. The original RSA key exchange padding oracle attack for TLS, Bleichenbacher sends thousands of variations of ciphertext at a TLS server. The TLS server attempts to decrypt each one, and sends back one of two error codes—either the decrypt failed or the padding was messed up. By trying many variations of a message, and differentiating between the two error codes, the attacker could eventually decipher an RSA-encrypted plaintext, one bit at time. Key Points Previously recorded RSA sessions will be vulnerable to decryption until mitigation is applied. At best, the attack decrypts one past TLS session taking several hours and tens of thousands of failed handshakes. Only RSA-based TLS handshakes are vulnerable; elliptic curve (ECC) and Diffie-Hellman are not affected by Bleichenbacher. Recovery of the RSA private key is never a concern for this exploit. There is no need to rotate keys or get new certificates. There is a theoretical man-in-the-middle decryption attack, but it is highly unlikely to successfully exploited. The Bleichenbacher attack raises its head in Europe every now and then. Filippo Valsorda found one in the Python-RSA library in 2016. A German team found one in XML encryption in 2012. Another German team wrote about optimizations for Bleichenbacher in this 2014 paper. Hanno Böck lives in Berlin and writes mostly in German. Daniel Bleichenbacher himself, though, is Swiss. There are two obvious uses for the ROBOT attack. Threat vector #1: Use ROBOT to recover a TLS session Attacker Eve records a TLS browser session between user Alice and website Bob. Eve extracts the encrypted session key material from Alice’s session. Eve then sends thousands of variations of that session key at server Bob, changing a bit here and there. Of course the vast majority of the variations fail, in one of two ways. Sometimes Bob replies “I couldn’t decrypt that.” And sometimes he replies “I decrypted it, but the message padding is messed up.” Eve uses the difference between these error codes to test the validity of each bit she changed. Eventually, she reconstructs Alice’s original session key. She decrypts Alice’s session, and in that session Eve finds Alice’s user credentials, and then the breach is on. Threat vector #2: Use ROBOT during a man-in-the-middle attack In addition to decrypting a message, the Hanno Böck team claims that their variation of the Bleichenbacher attack can coerce a TLS server into signing a piece of data. Because signatures are used to verify the integrity of the TLS handshake, in theory, the ROBOT attack could be used to man-in-the-middle a new TLS session. However, such an attack would be difficult to exploit due to the tens of thousands of messages that Eve would need to send to Bob to construct a signature. Even if Eve was wicked fast, there’s only so many messages t

この投稿は、F5ネットワークスのシニア・ソリューション・デベロッパーであるPeter Silva のブログ投稿「The OWASP Top 10 - 2017 vs. BIG-IP ASM 」を元に、日本向けに再構成したものです。 OWASP Top 10の2017年正式版がリリースされましたので、BIG-IP ASMのWAF機能でどのくらい対応できるか概要を紹介したいと思います。 まず最初に、2013年版と2017年版の比較です。いくつかの新規項目の追加と、既存項目の統合が行われています。 では、BIG-IP ASMの対応状況を見ていきましょう。   Vulnerability BIG-IP ASM Controls A1 Injection Flaws インジェクション Attack signatures Meta character restrictions Parameter value length restrictions A2 Broken Authentication and Session Management 認証とセッション管理の不備 Brute Force protection Credentials Stuffing protection Login Enforcement Session tracking HTTP cookie tampering protection Session hijacking protection A3 Sensitive Data Exposure 機密データの露出 Data Guard Attack signatures (“Predictable Resource Location” and “Information Leakage”) A4 XML External Entities (XXE) XML外部実体参照(XXE) Attack signatures (“Other Application Attacks” - XXE) XML content profile (Disallow DTD) (Subset of API protection) A5 Broken Access Control アクセス制御の不備 File types Allowed/disallowed URLs Login Enforcement Session tracking Attack signatures (“Directory traversal”) A6 Security Misconfiguration セキュリティ設定のミス    Attack Signatures DAST integration Allowed Methods HTML5 Cross-Domain Request Enforcement A7 Cross-site Scripting (XSS) クロスサイトスクリプティング(XSS) Attack signatures (“Cross Site Scripting (XSS)”) Parameter meta characters HttpOnly cookie attribute enforcement Parameter type definitions (such as integer) A8 Insecure Deserialization 安全でないデシリアライゼーション Attack Signatures (“Server Side Code Injection”) A9 Using components with known vulnerabilities 既知の脆弱性を持つコンポーネントの使用 Attack Signatures DAST integration A10 Insufficient Logging and Monitoring 不十分なロギングおよび監視 Request/response logging Attack alarm/block logging On-device logging and external logging to SIEM system Event Correlation   新規に追加された「A4: XML外部実体参照（XXE）」の項目についても、すでにシグネチャで対応しています。     200018018           External entity injection attempt     200018030           XML External Entity (XXE) injection attempt (Content) また、XXE攻撃は、XMLプロファイルによって汎用的な防御も可能です。 （DTDsを無効にして、"Malformed XML data"バイオレーションを有効にします）   また「A8:安全でないデシリアライゼーション」の対応策として、こちらも多くのシグネチャがすでに提供されています。 これらシグネチャの多くは、下記のように“serialization” や“serialized object” といった名前が含まれています。     200004188           PHP object serialization injection attempt (Parameter)     200003425           Java Base64 serialized object - java/lang/Runtime (Parameter)     200004282           Node.js Serialized Object Remote Code Execution (Parameter) 以上、OWASP Top10 2017年版のリリースにともなう、BIG-IP ASMのWAF機能の対応状況のご紹介でした。 関連リンク： What’s New In The OWASP Top 10 And How TO Use It BIG-IP ASM Operations Guide  

Introduction Building a certificate authority (CA) for your lab environment is a pain. Until recently I relied on Jamielinux's OpenSSL Certificate Authority but it slowly lost relevance due to evolutions in Public Key Infrastructure (PKI) requirements, specifically ECC, hash, critical certificate extensions, and revokation changes. This guide adheres to current PKI needs namely RFC 5759 NSA's Suite B Certificate and Certificate Revocation List (CRL) Profile. Before you start burning effigies in the comment section, yes I know ECC curves NIST P-256 and NIST P-384 are not considered "secure" by SafeCurves related to rigidity1, ladder2, completeness3, and indistinguishability4. Modern PKI ends up being a slightly religious debate divided across admins who practice provable security versus evangelists preaching mathematically absolute cryptography. I err towards the side of practical and provable security. If we adjusted cryptological practices to comply with every cryptographic sermon, we'd have nothing left to provide our infrastructure that a reasonable number of clients could connect to; forget if my infrastructure can even support it. What Suite B does offer is compatibility with browsers and applications. Complying with popular standards allows us to learn about some of the more overlooked PKI requirements mentioned above. You don't need to fully understand the mathematical intricacies of elliptical curves but you do need to know what your applications and clients can use, especially when certain internet entities quietly drop support for unpopular curves "cough.... Chrome". So many caveats to PKI raise a question of why we're using OpenSSL and why are we building a CA compliant to NSA Suite B (specifically NIST P-384). OpenSSL is free and used by a majority of OS and application vendors. Many admins have familiarity with it's various commands My lab is in AWS and their provided Active Directory offerings do not allow us Enterprise Admin roles; a requirement for setting up Microsoft Certificate Authorities and I am not going to spin up independent AD infrastructure for isolated VPCs We learn OpenSSL commands related to elliptical curves (some of the many) We must pay attention to certificate extension attributes We must create a revocation policy which many existing guides gloss over We must pay attention to OpenSSL's caveat's and limitations to modern PKI requirements, including version support for various features. I tested this series against OpenSSL v1.0.2g (default on Ubuntu 16.04 LTS), and v1.1.0f (manual upgrade to OpenSSL current release). There are some featuers within OpenSSL I am eagerly waiting but are not available as of the current public release. I will keep updating this as requirements and feature become mainstream. This guide is not intended for the hemmoraging edge admin who lives a brazen alpha code lifestyle. Suite B PKI Requirements and CA Design Considerations This guide assists the reader to build a lab-ready CA using elliptical curves for cryptographic signatures and hash functions. RFC 5759 states: Every Suite B cert MUST use the x.509 v3 format and contain An ECDSA-capable signing key, using curves P-256 or P-384 OR An ECDH-capable key establishment key, using curve P-256 or P-384 Every Suite B certificate and CRL MUST be signed using ECDSA. The CA's (Root and Intermediary) MUST be on the curve P-256 or P-384 if the CA contains a key on the curve P-256. If the certificate contains a key on the curve P-384, the signing CA's Key MUST be on the curve P-384. Any certificate and CRL MUST be hashed using SHA-256 or SHA-384, matched to the size of the signing CA's key. Suite B PKI follows RFC5280 for marking extensions as critical and non critical. Microsoft helps distill the extension requirements to: subjectKeyIdntifier (SKI), keyUsage, and basicConstraints MUST exist keyUsage MUST be marked as critical ke

Creating ECC Certificates Previously on Building an OpenSSL CA, we created a certificate revocation list, OCSP certificate, and updated our OpenSSL configuration file to include revokation URI data. Now we are ready to create our first server certificate and sign them with our fully armed and operational CA. What's becoming a theme there are two caveats to note prior to creating our first server CSR. Stop rolling your eyes and stay with me. Certificates MUST have subjectAltName (SAN) extensions of type DNSName defined1. Openssl currently supports population of SubjectAltName through configuration files only, including the current version v1.1.0f (true at guides publication date)2. Copy the Gist openssl_server.cnf file to /root/ca/intermediate/openssl_server.cnf and modify the contents for your own naming conventions. The openssl_server.cnf file has new entries at the [server_cert] location to create the subjectAltName field our certificate mentioned in the earlier noted points. This alternative name should match what we enter for the [commonName] field. [ server_cert ] subjectAltName = @alt_names [alt_names] DNS.0 = webby.grilledcheese.us You can add additional names to the certificate by iterating the [alt_names] section. Below is an example of the openssl config formatting for multiple names. Example: [alt_names] DNS.0 = yourdomain.com DNS.1 = sassymolassy.yourdomain.com DNS.2 = *.skeletor.yourdomain.com DNS.3 = *.orco.greyskull.yourdomain.com   RFC 5280 regarding subject alternative names states no upper bound limit is defined (no limit to how many names you can enter). However there are practical and application limitations so plan your certificate's alternate names wisely and try to match what you would implement in production. You're also thinking, how does this scale for multiple CSRs? It doesn't. You'll need to either update the openssl_server.cnf every time you want to create a new certificate or create a copy for each new certificate. We'll worry about scripting and simplifying that process in another followup article. Create the private key and CSR. Create the private key and CSR and specify either P-256 or P-384 approved curves. Since the root and intermediary CA's use P-384, Suite B allows us to use either. If we created the CA using P-256, we would not be able to use P-384 for the client/server certificate. We also need to ensure our certificate's hash function matches the signing CA, in our case SHA-384. # cd /root/ca # openssl req -config intermediate/openssl_server.cnf -new -newkey ec:<(openssl ecparam -name secp384r1) -keyout intermediate/private/webby.cheese.key.pem -out intermediate/csr/webby.cheese.csr Generating an EC private key writing new private key to 'intermediate/private/webby.cheese.key.pem' Enter PEM pass phrase: Verifying - Enter PEM pass phrase: ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [US]: State or Province Name [WA]: Locality Name [Seattle]: Organization Name [Grilled Cheese Inc.]: Organizational Unit Name [Grilled Cheese Dev Lab]: Common Name []:webby.grilledcheese.us Email Address [[email protected]]: Create the Certificate Use the intermediary certificate to create and sign the CSR for webby.grilledcheese.us. # cd /root/ca # openssl ca -config intermediate/openssl_server.cnf -extensions server_cert -days 730 -in intermediate/csr/webby.cheese.csr -out intermediate/certs/webby.cheese.crt.pem Using configuration from intermediate/openssl_server.cnf Enter pass phrase for /root/ca/intermediate/private/int.cheese.key.pem: Check that the request matches the signature Signature ok

In last week’s article in the What is HTTP? series, we covered the basic settings of the HTTP profile. This week, we’ll cover the enforcement parameters available in the profile, again focusing strictly on the reverse proxy mode profile options. In TMOS version 12.1, the enforcement parameters are as follows (default values shown.) Allow Truncated Redirect This is a simple toggle that allows you to choose how BIG-IP handles redirects without the trailing CRLF. By default the redirect will be dropped silently.  Maximum Header Size & Count The HTTP specification does not dictate the max header size, which in this case is not the size of a single header but the size of the request line and all headers combined, and various servers set their maximums differently. The BIG-IP default is 32k, but Apache is 8k, and depending on version, nginx is 4k-8k, IIS is 8k-16k, and Tomcat is 8k-48k. So if you are fronting any of these servers other than potentially Tomcat on a particular virtual, you can dial down the profile default significantly without impacting the servers. There is a behavior difference, however. Most servers will return a 4xx status code, and I’ve seen 400, 404, and 413 offered up. Don’t you love standards? BIG-IP will simply reset the TCP connection. You can limit individual header sizes in iRules, which has been done in various rules written to provide 0day mitigations in advance of application server patches. The max header count is simply that. As long as the request is less than 65, all is well. Pipeline Action  The pipeline action is another simple toggle that allows or rejects new requests from clients if previous requests have not yet received a response. What is pipelining you ask? Think of a telephone conversation, when you ask a question, or make a comment, and the person on the other end responds. This is the behavior you see without pipelining. Now think of a debate you’ve observed, where one debater lays out a ten-part question. He typically does so all at once. After he has made all his statements or posed all his questions, the other debater will handle those statements and questions in order. This is the behavior you see with pipelining. This pipeline action setting is where the moderator in the debate would step in and allow or refuse the first debater any more statements/questions until the second debater had responded. Lori MacVittie shared this good visual for pipelining behavior in her article on security risks inherent with allowing pipelining (shown below.)     Method Management  These settings are helpful to eliminate attack vectors to the unknown. If your application is a simple GET/POST application, then there is no need to allow for anything else. By rejecting unknown methods and disabling all other methods from the enabled methods except GET and POST, you reduce your threat landscape to issues the server MAY be exposed to. Managing these settings carefully should mean that you have a tight communicative relationship with your application team, so as the application evolves there aren’t occasions where new methods are introduced without profile adjustments. Bonus Features! These are not enforcement settings, but they wrap up the reverse proxy settings in the HTTP profile so I am including them here. sFlow sFlow is a scalable packet sampling technology that allows you to observe traffic patterns for performance, troubleshooting, billing, and security purposes. The two settings in the HTTP profile are polling interval and sampling rate. The polling interval is the max interval between polls, and the sampling rate is the ratio of packets observed to the samples generated. So for the default of 10 seconds and 1024 packets respectively, there would be two polls within 10 seconds of each other in which the system randomly generates one sample for every 1024 packets observed. You can specify the the sample rate and polling interval

Yup, you read that right. I did not pass the F5 Certified BIG-IP Administrator test I took while at F5 Agility 2017. And I’m not ashamed since it was a challenging test and I will be trying again. Sure, I went through Eric Mitchell’s (F5er) comprehensive 201 Certification Study Guide along with the TMOS Administration Exam Blueprint. However, I probably should have taken more time ON a BIG-IP messing around…especially for tmsh commands…which is where, I believe, I got tripped up. This is key. Reading and memorizing commands along with some practicing can only get you so far. Doing it regularly is what’s needed. This is a key feature of the exams, particularly as you move up the exam expertise. The exams are designed to test real knowledge and experience, not if you can cram the night before. Pretty sure my errors came with tmsh and the UCS upgrade questions since I had limited experience in those areas. Going in, I was a bit less confident (than from the 101) but also, less anxious. And about three-quarters through the exam I was feeling pretty good. I might pass this thing. However, the 201 Certification exam is not something to take lightly and is much more challenging than the 101. While the 101 has a 70% pass rate overall, the 201 hovers around 67% pass rate overall. 69% correct is a pass – I got 63%. I probably would have received my diploma from an educational institution but for Dr. Ken, a 63 is not a ‘pass’ with the F5 Certification Program. But that’s OK and why I like the program. At whatever level, a pass is a true achievement. You know your stuff. At Agility 2017, the F5 Professional Certification team administered 227 exams. They had 245 scheduled so only 18 no-shows for whatever reason. When I took the exam on Monday, there was a constant flow of folks taking the exams and over the course of the event, I spoke to many who were either about to take one or had already completed theirs. No matter pass or fail, all were impressed with the caliber of the exams. For F5 Agility week, the disposition is as follows: So you don’t have to work out the percentages: Slight edge to the Pass group, congratulations…but still, you got a 50:50 shot. Even though I failed, I’m glad to have taken it and know what I need to brush up on for my next attempt. For others that also failed, don’t be discouraged. While in Chicago, I was reminded of this Michael Jordan quote: ‘I've missed more than 9000 shots in my career. I've lost almost 300 games. 26 times, I've been trusted to take the game winning shot and missed. I've failed over and over and over again in my life. And that is why I succeed.’ ps

A few months back VMware announced a joint collaborative effort on delivering even more applications to their Workspace One suite utilizing F5 BIG-IP APM to act as an authentication translator from SAML to legacy Kerberos and header-based web applications.   How does it work? VMware Workspace ONE acts as an identity provider (IDP) that provides SSO access to cloud, mobile and SAML applications.  F5 BIG-IP APM extends that functionality and as a service provider (SP) to Workspace ONE for Kerberos and header-based web applications. BIG-IP APM can take in a user’s SSO authentication credential (SAML assertion) from Workspace ONE and authenticate as that user into BIG-IP APM.  Once the Authentication is completed BIG-IP APM will create a Kerberos Constrained Delegation (KCD) or header-based authentication using the user’s Realm (Domain).  BIG-IP APM will then pass the authentication token to the legacy web application on behalf of the user. This will prevent the pop-up login dialog boxes from appearing and providing a seamless authentication from Workspace ONE to the legacy web application. BIG-IP can provide intelligent traffic management, high availability, secure SSL access through bridging or offloading, and monitoring using BIG-IP Local Traffic Manager (LTM) and BIG-IP DNS (Formerly BIG-IP GTM). BIG-IP's Access Policy Manager (APM) can also provide secure access to the apps and resources accessible through the Workspace ONE portal. You can now download the updated step-by-step guide for integrating VMware Workspace ONE and BIG-IP APM for Legacy Web applications. https://www.vmware.com/pdf/vidm_implementing_SSO_to_kdc-and-hb_apps.pdf.  You can also read more about this integration from VMware’s publishing’s from Ben Siler discussing the integration. https://blogs.vmware.com/euc/2016/10/single-sign-on-sso-legacy-apps-workspace-one-f5.html  F5 has also provided a brief video talking and showing this integration in action Click the link below to see the video. https://devcentral.f5.com/articles/lightboard-lessons-sso-to-legacy-web-applications-24410 Here is an snipping from the documentation on setting up Kerberos within F5 APM. Setting up Kerberos Constrained Delegation (KCD) in BIG-IP APM If you are integrating a KCD app, you should now set up KCD in APM. Open the F5 BIG-IP admin console. Click Access Policy > SSO Configurations > Kerberos > plus icon ( +). In the New SSO Configuration menu, click Kerberos. Enter a unique name for your KDC SSO Configuration Set the Username Source field to session.sso.token.last.username Set the User Realm Source field to session.ad.last.actualdomain Set the Kerberos Realm field to your active directory domain (in CAPS). Set the Account Name field to your Kerberos service account and enter your account password. Note: If a Kerberos Service Account hasn’t been created it is recommended to create one via the following documentation. https://www.f5.com/pdf/deployment-guides/kerberos-constrained-delegation-dg.pdf Set the Account Password and Confirm Account Password fields with the Password associated to the Kerberos service account. Leave all other non-required fields with the default settings. (Required fields have a blue line) . Click Finished. Setting up Domain Authentication In the BIG-IP admin console, click Access Policy > AAA Servers > Active Directory > plus Icon ( + ). Enter a friendly name in the Name field. Set the Domain Name field to your Active Directory Domain Name (FQDN). Set the Server Connection radio button to Use Pool to increase resiliency. Set the Domain Controller Pool Name to a friendly name for your pool (no spaces allowed). Set the IP Address field to the IP Address of your domain controller. Set the Hostname field to the short name for your domain controller. Click Add, to add the domain controller to your pool. Repeat steps iv, v, and vi for each domain controller you want to add to the p

Back in 2008 we noted that when it comes to cloud computing, vertical scalability was still your problem. Since that time, scalability – in general – has become a MUST have rather than something business hopes to need one day. Thanks to digital transformation and the rapid pace of technical innovation across apps and devices, scalability needs to be “baked in” to each and every application architecture. So it’s no surprise that cloud remains a significant market force. At the heart of the operational value proposition of cloud lies scalability, the very thing that’s so critical to enabling business growth in today’s digital economy. In fact, scale has risen to dominate the top adoption drivers and benefits of cloud computing models. NorthBridge 2016 Future of Cloud Drivers: scalability (51%), business agility (46%) and cost (43%). CloudPassage 2016 Cloud Security Spotlight report Benefits : Availability (46%), cost reduction (41%) and flexible scalability (36%) RightScale 2017 State of the Cloud  Benefits: Faster access to infrastructure (62%), scalability (61%), availability (56%) What we’ve seen in the past decade is no change in the responsibility for vertical scalability. If you need more CPU or more memory, well, get thee a phatter server, my friend. But the thing is that horizontal scale – the kind cloud excels at providing – has become the norm for scalability. Emergent trends in application architectures like microservices and APIs have combined with the rise of container-based environments to provide exactly the kind of architectures that are designed to horizontally scale out to heights we could never reach using vertical scalability. It’s true that there are still limitations to horizontal scalability, particularly in on-premises, private cloud implementations where the ability to re-architect the entire network is not possible. There are still network-hosted components that are best scaled out vertically – phatter pipes, higher port densities, and the like – but we continue to see rapid advances in the ability of cloud “stacks” to enable the same kind of horizontal scale of network components as we enjoy for application components. So yes, vertical scale is still your problem. The good news is, however, that more and more frequently the need for vertical scale is shrinking as we get better and better at horizontally scaling everything in the data path.

Introduction Welcome to week three of the Kubernetes and BIG-IP series. In the previous article we learned how easy it is to deploy complex applications into Kubernetes running on Google Container Engine (GKE). As you might imagine, that ease could quickly lead to large numbers of applications running in an environment. But what if you need application services on those applications? Suppose that you want a centralized TLS policy for all applications, including those deployed into Kubernetes? What if you plan to implement DDoS protection at an operational level, and not within the application? Suppose that your organization intends to deploy applications using more sophisticated approaches, such as blue/green deployments or canary releases made possible by iRules? Perhaps you need other advanced traffic management capabilities. If only there were a way to bring all of the power of advanced application delivery controllers into Kubernetes, then Kubernetes applications could have the same assurances that you give on-premises and cloud applications. Up until recently, blending BIG-IP with containers was impossible, but now that ability is available, and this article will walk you through it. This article walks through deploying an application with multiple instances then ties into a BIG-IP for application delivery. Requirements In order to perform the steps in this article, you will need a few things. Access to Google Cloud and familiarity with using it (see the previous article for details) A BIG-IP license As long as you have the above two items, you are ready to go. The next section gives an overview of F5’s Container Connector. Container Connector Container Connector is a containerized application that you install into Kubernetes that enables a BIG-IP to control a pool of pods. Once configured, as pods are created and destroyed, the corresponding BIG-IP pool members are also created and destroyed. This allows the BIG-IP to manage traffic for the pods, while letting the developers continue to deploy applications into Kubernetes. In the next section you will walk through the deployment. Deployment Deployment falls roughly into three sections: BIG-IP, Container Connector, and the actual application. Deploy BIG-IP To Deploy BIG-IP in Google Cloud, go to the launcher page at https://console.cloud.google.com/launcher/search?q=f5. From there choose the “F5 BIG-IP ADC Best -BYOL” option. Next, launch the BIG-IP. The next page provides default settings for several virtual machine parameters. At the bottom of the page are some firewall defaults and a Deploy button. Click Deploy to deploy the BIG-IP. It will take three or four minutes for the deployment to complete. Once the BIG-IP image boots, it will have a dynamic external IP address that changes on every reboot. In a real deployment we would take steps to obtain a static IP address but for this exercise, the external IP address is fine. Just be aware that the external address will change when the BIG-IP reboots. The next step is to set the admin password on the BIG-IP. To set the password, click on the SSH button. You will see a message about Google Cloud trying to transfer keys to the VM. After a few seconds you may see an error message. Do nothing. Instead, wait for another 10 seconds or so and the SSH session will be established. At the prompt, enter the command to modify the admin password. modify auth password admin You will be prompted for a new password and asked to confirm that password. Try to avoid characters that might create problems for BASH or other command shells. For example, avoid the bang (exclamation point) character and the question mark. For this exercise, I have changed the password to “nimda5873” and will use that password below. Close the SSH browser tab. The final step is to log into the BIG-IP instance and license it. Click on the instance name. The next page shows details about the instance, including its external IP address. In my case, the external IP ad

On Friday 12 May 2017 a large ransomware attack dubbed “WannaCry” was launched targeting more than 200,000 computers worldwide, including industries such as banks, hospitals and large telecom companies. Figure 1: “WannaCry” ransom massage Infection Methods One of the main infection methods of this ransomware is by exploiting a recently patched Microsoft Windows SMB vulnerability (MS17-010). This vulnerability was publicly discovered as a result of the Shadow Brokers leaks that happened in April this year. Another possible method of infection is by phishing emails being sent to arbitrary recipients. Either way, once this ransomware gets on a network it exploits the aforementioned windows vulnerability in order to spread further into the network and infect more computers. Figure 2: Shodan search for Windows  SMB service exposed directly to the internet Mitigation using BIG-IP BIG-IP is able to mitigate the Windows exploitation attempt and prevent the WannaCry ransomware infection by using the attached iApp which contains an iRule, the iRule detects a part of the kernel shellcode in the exploit and drops the packets containing it. sys application template WannaCry_Blocker_v2 { actions { definition { html-help { WannaCry Blocker

This iApp installs the WannaCry Blocker iRule which will detect, block,* log, and count attempts to exploit CVE-2017-0144 “WannaCry.”

Attach both the WannaCry Blocker iRule and the default Stream Profile /Common/stream to a TCP virtual server (the virtual server must not have an HTTP Profile).

The WannaCry Blocker iRule logs the source IP address and geolocation of each possible attack and counts attacks (per-virtual-server) using iStats.

* The WannaCry iRule blocks WannaCry attacks. It also has an option to log attacks then allow them to proceed, if you really want to do that.

} implementation { package require iapp 1.1.1 iapp::template start # Prepared by Mark Quevedo, f5 Networks #------------------------------------------------------------ set ir_wcry { # WannaCry Blocker iRule # # Attach this iRule along with the defaul Stream Profile # /Common/stream to a TCP virtual server to detect, block,* # log, and count CVE-2017-0144 "WannaCry" attacks. (The # virtual server must not have an HTTP Profile.) # # This iRule logs the source IP address and geolocation of each # attack and counts attacks (per-virtual-server) using iStats. # # * Normally this iRule blocks WannaCry attacks. If you really # wish to allow such attacks to proceed (to a honeypot, maybe?) # after they are logged, set the variable static::allow_wannacry # to '1' in the RULE_INIT event. # # Written by Mark Quevedo, f5 Networks # when RULE_INIT { # if static::allow_wannacry is set to 1 (true) (see next line) # then WannaCry attacks are not blocked, just logged and counted set static::allow_wannacry @@@@@ # Stream Profile target sequences here are TCL regular expressions. # TMOS maps payload octets as if they were ISO-8859-1 to Unicode chars set target_list { {\u00b9\u0082\u0000\u0000\u00c0\u000f\u0032\u0048\u00bb\u00f8\u000f\u00d0\u00ff{5}\u0089\u0053\u0004\u0089\u0003\u0048\u008d\u0005\u000a\u0000} {\u0010\u0000{4}\u00ff{4}\u0000{12}\u004a\u0000{3}\u004a\u0000\u0002\u0000\u0023\u0000{3}\u0007\u0000\u005c\u0050\u0049\u0050\u0045\u005c\u0000} } set static::wcry_targets "" append static::wcry_targets "/" [join $target_list "// /"] "//" } ; #RULE_INIT when CLIENT_ACCEPTED { STREAM::expression $static::wcry_targets STREAM::enable } ; #CLIENT_ACCEPTED when STREAM_MATCHED { if {$static::allow_wannacry} { STREAM::replace ; # no arg means don't replace, therefore allow set blocked "" } else { reject ; # block apparent WannaCry attack set blocked "blocked\x2