WAFaaS with SSL Orchestrator
Introduction Note: This article applies to SSL Orchestrator versions prior to 11.0. If using version 11.0 refer to the articleHERE This use case allows you to insert F5 WAF functionality as a Service in the SSL Orchestrator inspection zone. WAFaaS is the ability to insert ASM profiles into the SSL Orchestrator Service Chain for Inbound Topologies.This configuration is specific to a WAF policy running on the SSL Orchestrator device.WAF and SSL Orchestrator consume significant CPU cycles so care should be given when deploying both together.It is also possible to deploy WAF as a service on a separate BIG-IP device, in which case you’d simply configure an inline transparent proxy service.The ability to insert F5’s WAF into the Service Chain presents a significant customer benefit. This guide assumes you already have WAF/ASM profile(s) configured, licensed and provisioned on BIG-IP and wish to add this functionality to an Inbound Topology.In order to run WAF and SSL Orchestrator on the same device you will need an LTM license with SSL Orchestrator as an add-on option.You cannot add a WAF license to an SSL Orchestrator stand-alone license. SSL Orchestrator does not directly support inserting F5 WAF policies into the Service Chain.However, the F5 platform is flexible enough to handle many custom use cases.In this case, the ICAP service configuration exposes a framework that is useful for any number of specialized patterns, including adding a WAF policy to an SSLO service chain.We will configure an ICAP Service and attach the WAF policy to it. Steps: Create ICAP Service Disable Strictness on the Service Disable TCP monitor for the ICAP Pool ICAP Adapt profiles removed from the Virtual Server Application Security Policy enabled and a Policy assigned under Security Step #1: Create ICAP Service Note: These instructions assume an SSL Orchestrator Topology and Service Chain are already deployed and working properly.These instructions simply add WAFaaS to the existing Service Chain.It is entirely possible to create the WAFaaS during the initial Topology creation, in which case you would create the service during the workflow, then make the necessary changes after the topology has been created. From the SSL Orchestrator Guided Configuration click Services then Add Scroll to the bottom, select Generic ICAP Service and click Add Give it a name, WAFaaS in this example For ICAP Devices click Add on the right Enter an IP Address, 198.19.97.1 in this example and click Done. Note:the IP address you use does not have to be the one above.It’s just a local, non-routable address used as a placeholder in the service definition.This IP address will not be used. IP addresses 198.19.97.0 to 198.19.97.255 are owned by network benchmark tests and located in private networks. Scroll to the bottom and click Save & Next. The next screen is the Services Chain List.Click the name of the Service Chain you wish to add WAF functionality to, ssloSC_ServiceChain in this example. Note: The order of the Services in the Selected column is the order in which SSL Orchestrator will pass decrypted data to the device.This can be an important consideration if you want some devices to see, or not see, the actions taken by the WAF Service. Select the WAFaaS Service and click the right arrow to move it to Selected.Click Save. Click Save & Next Click Deploy You should receive a Success message Step #2: Disable Strictness on the Service From the SSL Orchestrator Configuration screen select Services.Click the padlock to Unprotect Configuration. Note:Disabling Strictness on the ICAP Service is needed to modify it and attach the WAFaaS policy.Strictness must remain disabled on this service and disabling strictness on the service has no effect on any other part of the SSL Orchestrator configuration. Click OK to Unprotect the Configuration Step #3: Disable tcp monitor for the ICAP Pool From Local Traffic select Pools > Pool List Select the WAFaaS Pool Under Active Health Monitors select tcp and click >> to move it to Available.This removes the Pool’s Monitor because otherwise it would be marked as down or unavailable. Click Update Note:The Health Monitor needs to be removed because there is no actual ICAP service to monitor. Step #4: ICAP Adapt profiles removed from the Virtual Server From Local Traffic select Virtual Servers > Virtual Server List Locate the WAFaaS ICAP service that ends in “-t-4”virtual server and select it Set the Request Adapt Profile and Response Adapt Profile to None to disable the default ICAP Profiles Click Update Step #5: Application Security Policy enabled and a Policy assigned under Security For the WAFaaS-t-4 Virtual Server click the Security tab Set Application Security Policy to Enabled Select the Security Policy you wish to use.Click Update when done Note: In specific versions of SSL Orchestrator there is one extra configuration item that needs to be modified. This is NOT required in other versions. If this change is made, when performing an upgrade it is not necessarily required to back out this change. Required versions: SSLO version 5.9.15 available on TMOS 14.1.4 SSLO versions 6.0-6.5 available on TMOX 15.0.x Navigate to “Local Traffic››Profiles : Other : Service” Select the Service profile named “ssloS_WAFaaS-service” Change the “Type” from “ICAP” to “F5 Module” Conclusion The configuration is now complete.Using the WAFaaS this way is functionally the same as using it by itself.There are no known limitations to this configuration.
Orchestrated Infrastructure Security - BIG-IQ
The F5 Beacon capabilities referenced in this article hosted on F5 Cloud Services are planning a migration to a new SaaS Platform - Check out the latesthere. Introduction This article is part of a series on implementing Orchestrated Infrastructure Security. It includes High Availability, Central Management with BIG-IQ, Application Visibility with Beacon and the protection of critical assets using F5 Advanced WAF and Protocol Inspection (IPS) with AFM.It is also assumed that BIG-IQ is deployed, and basic network connectivity is working. If you need help setting up BIG-IQ for the first time, refer to the Dev/Central article series Implementing SSL Orchestrator here.That article covers SSL Orchestrator but the procedure to add Advanced WAF and AFM to BIG-IQ is the same. This article focuses on configuring BIG-IQ version 7.1.0 to manage F5 Advanced WAF, AFM and SSL Orchestrator.It covers management of BIG-IP running version 15.1.0.4 and SSL Orchestrator version 7.4.9, and version 16.0.0 with AFM and Advanced WAF. Please forgive me for using SSL and TLS interchangeably in this article. This article is divided into the following high level sections: Import BIG-IP Devices into BIG-IQ Service Import Error Resolution Schedule regular backups of BIG-IP devices Push backups to BIG-IP device Import BIG-IP Devices into BIG-IQ From the BIG-IQ GUI go to Devices > BIG-IP Devices.This is where you add new devices to be managed by BIG-IQ.You should add the two SSL Orchestrator’s using the Dev/Central article above.Click Add Device(s) to add Advanced WAF and AFM devices. Select the option to Add BIG-IP device(s) and automatically discover and import services.Then click Add Devices. Enter the IP Addresses of the Devices you want to add, 192.168.41.3 and 192.168.41.4 in this example (use the Plus sign to add another IP address field).These are the two AFM devices.Enter the username and password to access these devices.Under Services check the box for Network Security (AFM) then scroll down. Check the box to enable Statistics Collection.You can configure a Zone and/or Cluster Display Name if desired.Click Save and Close. Your screen should look like the following.Click Add Devices so we can add the two Advanced WAFs. Enter the IP Addresses of the Devices you want to add, 192.168.41.21 and 192.168.41.22 in this example (use the Plus sign to add another IP address field).These are the two Advanced WAF devices.Enter the username and password to access these devices.Under Services check the box for Web Application Security (ASM) then scroll down. Check the box to enable Statistics Collection.You can configure a Zone and/or Cluster Display Name if desired.Click Save and Close. Click Discover and Import. You should see a Progress screen.Click Close. When complete, your screen should look similar to the following.= Service Import Error Resolution Some devices had errors during Import.Click the first one to resolve it. There was a conflict importing SSM.Check the box to create a snapshot of the configuration then click Import. The following items were changed on the BIG-IP.You can choose to import these into the BIG-IQ by selecting Set all BIG-IP.Click Continue. A dialog screen will present you with more information about what you’re doing.Click Resolve. Click Import to complete the import process.You may want to create a Snapshot of the configuration by checking the box. The BIG-IP Devices screen should look like this.The Advanced WAF device has been successfully imported.Repeat this process for any devices with an import error. When all Devices are successfully imported the screen should look like this. Schedule regular backups of BIG-IP Devices Now is a good time to schedule regular Backups.Check the box next to Status to select all the BIG-IPs.Click the down Arrow next to More and select Schedule Backup. Give the Backup a name, Backup_all in this example.There are several options here that you may wish to enable.For Local Retention Policy, it’s not a bad idea to keep multiple backups, 3 in this example.The Start Date and time can be adjusted to suit your needs. The Devices should automatically be selected.You can optionally enable the Archiving of Backups to an external SCP or SFTP server.Click Save & Close. Push backups to BIG-IP Device At some point you may need to restore one of your BIG-IP devices from a backup.To do this select the Devices tab > Back Up & Restore > Backup Files. From here you can view the different backup files.You can also Compare, Download, Restore or Delete backup files.Select the backup you would like to restore then click Restore. You will be presented with a confirmation message warning you that the configuration of the device is about to be overwritten from the backup.Click Restore to proceed. While the device is being restored you will see the following. Select BIG-IP Devices to check the status of the device when the restore is complete. Summary In this article you learned how to import BIG-IP devices into BIG-IQ, import the BIG-IP Services and schedule regular backups of the BIG-IP devices. Next Steps Click Next to proceed to the next article in the series.Implementing SSL Orchestrator - Validation & Troubleshooting
Introduction This article is part of a series on implementing BIG-IP SSL Orchestrator. It includes high availability and central management with BIG-IQ. Implementing SSL/TLS Decryption is not a trivial task. There are many factors to keep in mind and account for, from the network topology and insertion point, to SSL/TLS keyrings, certificates, ciphersuites and on and on. This article focuses on verification that the solution is working. This article is divided into the following high level sections: How to check if content is being decrypted How to check if content is being blocked How to check if content is being bypassed Logging and Troubleshooting Please forgive me for using SSL and TLS interchangeably in this article. Software versions used in this article: BIG-IP Version: 14.1.2 SSL Orchestrator Version: 5.5 BIG-IQ Version: 7.0.1 How to check if content is being decrypted Go to a computer that connects to the internet through SSL Orchestrator.Go to an encrypted website like www.cisco.com.The page should load without error.Click the padlock icon in the Address Bar. Notice that the connection is secure and the certificate is valid.Click the Certificate to view more details.The certificate was issued to www.cisco.com but has been issued by subrsa.f5labs.com.The connection to this web site was decrypted and re-encrypted by SSL Orchestrator. Switch to the Palo Alto UI and go to Monitor > Traffic.It should look like this. Click the link on the left in the red box. This drills into more details. Notice the IP address of 72.163.10.10 and port 80 (not port 443).A quick lookup of that IP shows it belongs to Cisco. How to check if content is being blocked Now go to the website www.eicar.org.This site hosts a harmless test malware file so you can see if your security measures are effective.Click Download Anti Malware Testfile on the right. Click the Download link on the left. Scroll down on the next page.You should see a section with 8 different downloads. There are 4 different file types.The first group uses HTTP.The second group uses HTTPS.Click any of the HTTPS links to verify it is detected and blocked. You should get a block page like the following. Notice the URL indicates an attempt to download one of the compressed .zip files. How to check if content is being bypassed Next try a Banking website and make sure it is bypassed.On the client open a browser and go to www.chase.com.Click the Padlock icon in the address bar and it should look like this. Click the highlighted section for more details about this certificate. This certificate was issued by Entrust CA.The SSL Orchestrator is not decrypting this connection.We can check the Palo Alto logs to make sure it doesn’t have a record of this transaction. The image below shows ping traffic generated by SSL Orchestrator to test the health of the L2 Service.Notice there is no web-browsing or port 80 traffic. Logging and Troubleshooting To enable logging: -Connect to the WebUI -Go to SSL Orchestrator and click on Logs -Enable the required logging levels Note: By default, logs are stored locally on the BIG-IP. Below is a reasonably-ordered list of troubleshooting steps. ·If the SSL Orchestrator deployment process fails, review the ensuing error message. It would be impossible to list here all of the possible error messages and their meanings, but often enough the messages will reveal the issue. ·Re-review the lab steps for any missing or misconfigured settings. ·Enable debug logging in the SSL Orchestrator configuration. Tail the APM log from a BIG-IP command line or from the logs page in the management UI. Debug logging will very often reveal important issues. Specifically, it will indicate traffic classification matches, mismatches or deployment issues. tail –f /var/log/apm tail -f /var/log/restnoded/restnoded.log tail -f /var/log/restjavad.0.log ·If the SSL Orchestrator deployment process succeeds, but traffic isn’t flowing through the environment made evident by lack of access to remote sites from the client: o Never enable debug logging on the Per-Request Policy logging option in a production environment. If needed, be sure to turn it back off after capture logs. The PRP logging is extremely verbose and WILL affect system performance. o /var/log/apm is used to log data plane traffic flow o /var/log/restnoded/restnoded.log is used to log control plane (when SSLO configurations are deployed) o /var/log/restjavad is similarly used to log control plane restjava functions o It’s also sometimes useful to tail /var/log/ltm, which is where SSL and generic data plane issues will show up. oEnsure that the client is properly configured to either default route to the ingress VLAN and self-IP of the BIG-IP for transparent proxy access or has the correct browser proxy settings defined for explicit proxy access. oEnsure that traffic is flowing to the BIG-IP from the client with a tcpdump capture at the ingress interface. oReview the LTM configuration created by the SSL Orchestrator. Specifically, look at the pools and respective monitors for any failures. oIsolate service chain services. If at least one service chain has been created, and debug logging indicates that traffic is matching this chain, remove all but one service from that chain and test. Add one service back at a time until traffic flow stops. If a single added service breaks traffic flow, this service will typically be the culprit. oIf a broken service is identified, insert probes to verify inbound and outbound traffic flow. Inline services will have a source (S) VLAN and destination (D) VLAN, and ICAP and receive only services will each have a single source VLAN. Insert a tcpdump capture at each VLAN in order to determine if traffic is getting to the device, and if traffic is leaving the device through its outbound interface. o How to insert probes. The services VLANs are wrapped in application services so must be addressed accordingly in the tcpdump. Note that each inline service will create two separate VLANs – one for inbound and one for outbound, so it becomes easy to surgically insert captures at specific points in the flow (ie. to the service, coming from the service). So a tcpdump capture of a service named “FEYE” might look like this: tcpdump -lnni ssloS_FEYE.app/ssloS_FEYE Where “ssloS_FEYE.app” is the application service container, which contains the “ssloS_FEYE” VLAN. oBy default the ‘all traffic’ rule doesn’t attach a service chain, so it can be as simple as removing service chains from all of the security rules. If traffic doesn’t flow with no service chains attached anywhere, then the problem is in SSLO proper, likely a routing or decryption issue. If the traffic only fails with a service chain applied, this is when it’s useful to isolate the services. If a broken service is identified, insert tcpdump probes as described above. oIf traffic is flowing through all of the security devices, insert a tcpdump probe at the egress point to verify traffic is leaving the BIG-IP to the gateway router. oIf traffic is flowing to the gateway router, perform a more extensive packet analysis to determine if SSL if failing between the BIG-IP egress point and the remote server. tcpdump –i 0.0:nnn –nn –Xs0 –vv –w <file.pcap> <any additional filters> Then either export this capture to WireShark or send to ssldump: ssldump –nr <file.pcap> -H –S crypto > text-file.txt oIf the WireShark or ssldump analysis verifies an SSL issue: oPlug the site’s address into the SSLLabs.com server test site at: www.ssllabs.com/ssltest/ This report will indicate any specific SSL requirements that this site has. oVerify that the SSL Orchestrator server SSL profiles (two of them) have the correct cipher string to match the requirements of this site. To do that, perform the following command at the BIG-IP command line: tmm --clientciphers ‘CIPHER STRING AS DISPLAYED IN SERVER SSL PROFILES’ Further SSL/TLS issues are beyond the depth of this guide. Seek assistance. • If all else fails, seek assistance. Summary In this article you learned how to verify that SSL Orchestrator is decrypting SSL and passing it to an inline security device. You can verify that SSL is decrypted simply by viewing web site certificates. You can also use logging or reporting capabilities of an inline security device to verify that SSL is decrypted. You learned how to test whether the inline security device was blocking malicious content. You also learned how to verify that a policy to bypass SSL decryption is working. Then you learned how to enable logging and perform troubleshooting steps. Next Steps Click Next to proceed to the next article in the series.Implementing SSL Orchestrator - Guided Configuration
Introduction This article is part of a series on implementing BIG-IP SSL Orchestrator. It includes high availability and central management with BIG-IQ. Implementing SSL/TLS Decryption is not a trivial task. There are many factors to keep in mind and account for, from the network topology and insertion point, to SSL/TLS keyrings, certificates, ciphersuites and on and on. This article focuses on the SSL Orchestrator Guided Configuration and everything you need to know about it. This article is divided into the following high level sections: Configuration prerequisites Deployment Topology SSL certificate and key settings Service properties Security policy Interception rule Please forgive me for using SSL and TLS interchangeably in this article. Software versions used in this article: BIG-IP Version: 14.1.2 SSL Orchestrator Version: 5.5 BIG-IQ Version: 7.0.1 Configuration Prerequisites From the BIG-IP Configuration Utility click SSL Orchestrator > Configuration.This is the default landing page when SSL Orchestrator is not configured.The configuration options are presented on this page.Notice the Required Configuration settings on the top right.For DNS click the link to configure. Enter the IP address of the DNS server you wish to use and click Add.You can add multiple DNS servers.Click Update when done. Click SSL Orchestrator > Configuration.For NTP click the link to configure. Enter the IP address or hostname of the NTP server you wish to use and click Add.You can add multiple NTP servers.Click Update when done. Click SSL Orchestrator > Configuration.For Route click the link to configure. Name it.In this example it’s default_route.Enter the correct Destination and Netmask.In this example we’re using 0.0.0.0 as this is a default route.Enter the Gateway IP Address, in this example 10.0.0.1. Click Finished. Click SSL Orchestrator > Configuration.The Required Configuration section should look like the following. Deployment Topology We are now ready to begin the Guided Configuration.Click Next at the bottom. Choose the Topology you would like to deploy.In this example we will configure an L3 Outbound Topology. Name the Topology.For the Protocol choose Any.Select L3 Outbound then click Save & Next Note: some of the available Topologies might be greyed out if not supported by your platform.As an example, virtual machines don’t support L2. SSL Certificate and Key Settings Leave the Certificate Key Chain settings to their defaults. Edit the existing CA Certificate Key Chain by clicking the pencil icon. In a previous article you installed your own private key and certificate.Click the down arrow on the right to select that Certificate and Key.Click Done. Click Save & Next Notes: The difference between the Cert Key Chain and the CA Cert Key Chain: Certificate Key Chain – the certificate key chain represents the certificate and private key used as the “template” for forged server certificates. While re-issuing server certificates on-the-fly is generally easy, private key creation tends to be a CPU-intensive operation. For that reason, the underlying SSL Forward Proxy engine forges server certificates from a single defined private key. This setting gives customers the opportunity to apply their own template private key, and optionally store that key in a FIPS-certified HSM for additional protection. The built-in “default” certificate and private key uses 2K RSA and is generated from scratch when the BIG-IP system is installed. The pre-defined default.crt and default.key can be left as is. CA Certificate Key Chain – an SSL forward proxy must re-sign, or “forge” remote server certificate to local clients using a local certificate authority (CA) certificate, and local clients must trust this local CA. This setting defines the local CA certificate and private key used to perform the forging operation. Service Properties Click Add Service You can choose from many pre-defined templates from different security vendors.In this example select Palo Alto Networks NGFW Inline Layer 2 then click Add. Give it a name.Under Network Configuration click Add. Here you define the VLANS that the Palo Alto is connected to (or will be connected to).You can use existing ones or create new VLANS.We will create new ones by choosing the Create New radio button. Give each VLAN a unique name to help remember which device it’s connected to and in which direction data flows.Select the Interface from the drop-down menu.Click Done. Enable the Port Remap option and leave the port at 80. Click Save Notes: SSL Orchestrator allows for the insertion of additional iRule logic at different points. An iRule defined at the service only affects traffic flowing across this service. It is important to understand, however, that these iRules must not be used to control traffic flow (ex. pools, nodes, virtuals, etc.), but rather should be used to view/modify application layer protocol traffic. For example, an iRule assigned here could be used to view and modify HTTP traffic flowing to/from the service. Click Save & Next Click the button to Add a Service Chain List Give it a name.Click the arrow in the middle to move the Palo Alto Service to the Selected side.Click Save. Note: When you have multiple Services in a Service Chain you can adjust the order that they are used. Your screen should like the following.Click Save & Next. Security Policy The Security Policy is next.Notice you have the option to create new or use an existing one.By default, the policy should look like this. The Name is populated automatically but can be changed.If you click the pencil icon to the far right of the Pinners_Rule you can see the contents of the rule. The Pinners_Rule checks to make sure the content is SSL/TLS.It also checks the category “Pinners” which contains websites with Pinned Certificates.Sites in the category Pinners are automatically set to Bypass decryption.It is recommended to keep this setting. Notes: If you have a URL categorization database you can also bypass decryption based on website category. Conditions can be toggled between Match Any and Match All.Actions can be to Allow or Reject.Also note the Service Chain is bypassed by default.However, you can choose to send the encrypted content through the Security Chain. Click Cancel. The Pinners Category can be viewed/edited from SSL Orchestrator > Policies > URL Categories.Expand Custom Categories and you will see the Pinners category.Click Pinners (custom) to view and/or edit the sites. Back to the Security Policy.Click the pencil icon to the far right of the All Traffic rule to edit it. Set the Service Chain to the one created previously, in this case it’s ssloSC_SecurityServiceChain.Click OK. Click Save & Next at the bottom. Interception Rule Next is the Interception Rule.For Ingress Network select the VLAN that internal clients connect through.In this example select INTERNAL and click the arrow to move it to Selected.Note that you can also create VLANS from this screen. Click Save & Next at the bottom. Notes:L7 Interception Rules – FTP and email protocol traffic are all “server-speaks-first” protocols, and therefore SSL Orchestrator must process these separately from typical client-speaks-first protocols like HTTP. This selection enables processing of each of these protocols, which create separate port-based listeners for each. As required, selectively enable the additional protocols that need to be decrypted and inspected through SSL Orchestrator. Egress Settings For the Egress Settings Click Save & Next at the bottom. Last is the Summary screen.You can review and edit any of the Configurations we just went through.Click Deploy when done.The next screen should look like the image below. Click OK and you should see something like the following: Notes: The Palo Alto Service is shown as DOWN in red.This is because we haven’t configured it yet.We’ll do that in the next article. Summary In this article you learned how to use the SSL Orchestrator Guided Configuration to do the following: Configuration prerequisites Deployment Topology SSL certificate and key settings Service properties Security policy Interception rule Next Steps Click Next to proceed to the next article in the series.Implementing SSL Orchestrator - Certificate Considerations
Introduction This article is part of a series on implementing BIG-IP SSL Orchestrator. It includes high availability and central management with BIG-IQ. Implementing SSL/TLS Decryption is not a trivial task. There are many factors to keep in mind and account for, from the network topology and insertion point, to SSL/TLS keyrings, certificates, ciphersuites and on and on. This article focuses on SSL certificates and everything you need to know about them. This article is divided into the following high level sections: Using OpenSSL Using Microsoft CA Importing a private key and certificate into SSL Orchestrator Manually Installing Certificates in browsers Creating a Certificate Signing Request (CSR) for Inbound Topology Using Group Policy Objects (GPO) to distribute certificates Please forgive me for using SSL and TLS interchangeably in this article. Software versions used in this article: BIG-IP Version: 14.1.2 SSL Orchestrator Version: 5.5 BIG-IQ Version: 7.0.1 Using OpenSSL OpenSSL can be used to sign a CSR.It can also be used to generate a self-signed certificate.When creating a CSR for production, you might need to use OpenSSL with a template in order to populate certain fields like the Digital Signature. This information is provided as a courtesy. OpenSSL contains an open-source implementation of the SSL and TLS protocols. The core library, written in the C programming language, implements basic cryptographic functions and provides various utility functions. Wrappers allowing the use of the OpenSSL library in a variety of computer languages are available. OpenSSL can be used to create private keys, certificates and more.Here’s an example of the syntax used to create a self-signed certificate: openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout privateKey.key -out certificate.crt Full instructions about how to use OpenSSL are beyond the scope of this article.However, the links below contain excellent information on usage: OpenSSL - Command Line Utilities SSLShopper- Common OpenSSL Commands Note: If you want to create your own OpenSSL Certificate Authority the following Dev/Central Article is excellent: Building an OpenSSL Certificate Authority - Creating Your Root Certificate Using Microsoft Certificate Authority This method is generally preferred to using self-signed certificates. Rather than reinvent the wheel, the Virtually There Blog does an excellent job of explaining the process to sign a CSR with a local Certificate Authority.Click the link below to learn more: VirtuallyThere - Signing a CSR with your Microsoft Certificate Authority Note: If you’re looking for information about how to setup your own local Microsoft CA see this previous blog: VirtuallyThere - Building a Microsoft Certificate Authority for your lab Note: the blog author has given f5 permission to include the links above. Installing signed certificate into SSL Orchestrator From the Configuration Utility > SSL Orchestrator > Certificate Management > Traffic Certificate Management.Click on the certificate created earlier (my_certificate). Click Import. Click Choose File and select the signed certificate from the CA.Click OK/Open.Click Import. Note: Using Certificate Chains or Subordinate CAs If using Certificate Chains be sure to include all intermediate certificates in the chain.For more information on Certificate Chains, see this Microsoft article. Import private key and certificate into SSL Orchestrator Follow the steps below if you already have the private key and certificate you want to use for SSL decryption. From the BIG-IP Configuration Utility click SSL Orchestrator > Certificate Management > Certificates and Keys.On the far right, click Import. For Import Type click Select.Different types of import options are available. For this example, select Key.Give it a name, in this example SSL.key.You can upload the key from a local file or paste it in as text.Choose the method you prefer and click Import when done.The example below shows the local file method. Click the name of the Key you created. Click Import.You can upload the certificate from a local file or paste it in as text.Choose the method you prefer and click Import when done.The example below shows the local file method. You have successfully imported the private key and certificate. Note: most Enterprise customers will have their own local Certificate Authority (CA). Creating a Certificate Signing Request (CSR) for Inbound Topology If you are creating an Inbound Topology you can use this method to create a CSR. From the F5 Configuration Utility go to SSL Orchestrator > Certificate Management > Certificates and Keys.Click Create on the top right. Give the certificate a name.For Issuer select Certificate Authority.Fill in the rest of the form. Click Finished when done. The page should look like the following.Click Download my_certificate to download it as a file.You can optionally copy the text output to the Clipboard. Download the CSR so it can be signed by your Local Certificate Authority. Manually Installing Certificates in browsers Certificates generated by SSL Orchestrator need to be trusted by the client computers. If using a Microsoft Certificate Authority (CA) to sign the SSL certificates the clients will trust it automatically, assuming they are members of the same domain as the CA. If using Self-Signed certificates you need to install them in the Certificate store on all client computers. Most Enterprise customers won't do this in production but it's often used for testing or demos. Either way, it's important to know these procedures. Firefox has its own Certificate store.Click the icon on the top right then Preferences. Note: Firefox version 70.0.1 was used in the configuration below. Scroll to the bottom of the next screen.Under Security click View Certificates. Click Import. Find the Certificate on your computer.Select it and click Open. Select the option to Trust this CA to identify websites.Click OK. Internet Explorer/Edge and Chrome use the Windows Certificate store. Locate the Certificate on your computer and double click it.Click Install Certificate. Click Next at the Import Wizard. Select the option to Place all certificates in the following store.Click Browse. Select Trusted Root Certification Authorities then OK. Click Next. Click Finish. You should see a Security Warning like the following.Click Yes. Click OK to the Successful Import message. Using GPO to distribute certificates Microsoft has a variety of support articles and documentation for how to do this with GPO: Distribute Certificates to Client Computers by using Group Policy Summary In this article we covered the most common tasks associated with SSL certificates and how to use them with SSL decryption. Next Steps The next article in this series will cover the Guided Configuration component of SSL Orchestrator.Implementing SSL Orchestrator - Decryption Bypass by Category
Introduction This article is part of a series on implementing BIG-IP SSL Orchestrator. It includes high availability and central management with BIG-IQ. Implementing SSL/TLS Decryption is not a trivial task. There are many factors to keep in mind and account for, from the network topology and insertion point, to SSL/TLS keyrings, certificates, ciphersuites and on and on. This article covers creating policy to bypass SSL Decryption by web site Category. Please forgive me for using SSL and TLS interchangeably in this article. Software versions used in this article: BIG-IP Version: 14.1.2 SSL Orchestrator Version: 5.5 BIG-IQ Version: 7.0.1 Policy Creation Using the URL Categorization database, add sensitive categories to bypass decryption. From the Configuration screen click on the Topology Name. Click the Pencil icon to edit the Security Policy. Edit the Pinners_Rule to add the following categories to the bypass list: Financial Data and Services Health and Medicine Online Brokerage and Trading Click OK, Save & Next then Deploy. Summary In this article you learned how to specify URL Categories to bypass SSL decryption. Next Steps Click Next to proceed to the next article in the series.
SSL Orchestrator between client and explicit HTTP proxy
Hi Devcentral, I am testing SSL orchestrator with Inline mode (L2 / Trasparent) in order to inspect cleartext web browsing traffic using an IPS device, the scenario is the following: Client that points directly to F5 as a gateway Client have explicit HTTP forward proxy configured on the browser (Mozilla) for HTTP & HTTPS traffic SSLO is placed inline with SNAT Automap that points to router connected to the Internet I did a packet capture and I saw that the SSL handshake occurs between the client and the HTTP/HTTPS Forward proxy (tiny proxy) - using HTTP Connect / Proxy-Connect method but the SSL decryption will not occur if the HTTP Forward proxy is configured on the client. (I am testing this because one of our customer would like to implement SSL Orchestrator but actually the customer have explicit HTTP proxy configured in order to provide web reputation filtering to the clients) The architecture flow is the following (starting from the source): Client F5 SSL Orchestrator HTTP/HTTPS Forward Proxy (tinyproxy) Internet I'll expect to see that the traffic is decrypted correctly also using the HTTP forward proxy in place. (actually it works for outbound decryption but without the HTTP forward proxy --> point 3.)
Resumed SSL session and decryption
Hi, I tried to figure out if there is a way to decrypt resumed SSL session in Wireshark if first session with full SSL handshake (including pre-master key exchange) is not captured. Seems that it's not possible even when pre-master secret was captured via ssldump. But maybe I am doing something wrong? Scenario: tcpdump used to capture first session with full SSL Handshake ssldump used to extract pre-maset secret to the file Wireshark is capturing traffic including first session - everything is encrypted pre-master secret file configured in Wireshark - traffic decrypted, including following resumed sessions (same is true when private key is configured in Wireshark) New capture in Wireshark performed Client and server are still resuming SSL session (same SessionID reported in ClientHello) - no traffic decrypted. Is above correct? I assumed that when original pre-master secret is know to Wireshark it can generate master key and use it for resumed sessions even without seeing original full SSL Handshake. Am I missing something here? Is that just limitation of Wireshark or it is not technically possible at all to decrypt resumed session knowing original pre-master key. Sure I am talking about RSA non ephemeral cipher suites, in this case Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Piotr
Resumed SSL session and decryption
Hi, I tried to figure out if there is a way to decrypt resumed SSL session in Wireshark if first session with full SSL handshake (including pre-master key exchange) is not captured. Seems that it's not possible even when pre-master secret was captured via ssldump. But maybe I am doing something wrong? Scenario: tcpdump used to capture first session with full SSL Handshake ssldump used to extract pre-maset secret to the file Wireshark is capturing traffic including first session - everything is encrypted pre-master secret file configured in Wireshark - traffic decrypted, including following resumed sessions (same is true when private key is configured in Wireshark) New capture in Wireshark performed Client and server are still resuming SSL session (same SessionID reported in ClientHello) - no traffic decrypted. Is above correct? I assumed that when original pre-master secret is know to Wireshark it can generate master key and use it for resumed sessions even without seeing original full SSL Handshake. Am I missing something here? Is that just limitation of Wireshark or it is not technically possible at all to decrypt resumed session knowing original pre-master key. Sure I am talking about RSA non ephemeral cipher suites, in this case Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Piotr
