Using AWS CloudHSM with F5 BIG-IP
With the release of TMOS version 17.5.1, BIG-IP now supports the latest AWS CloudHSM hardware security module (HSM) type, hsm2m.medium, and the latest AWS CloudHSM Client SDK, version 5. This article explains how to install and configure AWS CloudHSM Client SDK 5 on BIG-IP 17.5.1F5 BIG-IP and ENTRUST nShield HSM SSL key/cert auto synchronization between HA peers with iCall
Code version: The code was tested on 15.1.8. Main Article: For more information about RFS and Client agent I suggest seeing the vendors article. https://nshielddocs.entrust.com/security-world-docs/v13.3/connect-ug-nix/intro.html Useful F5 links for F5 and nShield Integration for GTM and LTM: https://my.f5.com/manage/s/article/K000135349 https://techdocs.f5.com/en-us/bigip-15-1-0/big-ip-system-and-nshield-hsm-implementation/setting-up-t... The nShield architecture includes a component called the Remote File System (RFS) that stores and manages the encrypted key files. The RFS can be installed on the BIG-IP system or on another server on your network. Basically the HSM agent/client is installed on the F5 devices hos Linux host system and the F5 devices are also the RFS servers. The RFS commands are bellow as when installed on the BIG-IP the HSM agent and RFS they are available for use: https://nshielddocs.entrust.com/security-world-docs/utilities/rfs-sync.html The issue I solved with iCall script is that when when you create a new HSM key for BIG-IP HA, you must run command ‘rfs-sync --update’ on all standby BIG-IP devices (the devices where the cert/key were not created or changed) to update the local Thales encrypted file object cache. Without this action, SSL traffic using this key will fail when BIG-IP fails over to one of the unsynced standby devices. When you create the the key and cert on the active F5 device "rfs-sync -commit" and "rfs-sync -update" run automatically on it but not the "rfs-sync -update" on the standby devices and the icall script basically is triggered on the standby devices when you run the normal config sync. The iCall script matched an event called "HA_EVENT" that is configured in the custom alarms section and triggers the full command with the path "/opt/nfast/bin/rfs-sync --update" to check if there was an update in the rfs. I suggest reading the links below that explain the iCall (one is from JRahm ) and the HA logs and the last one is mine that is from the time before I learned proper article formatting 😅 and it also shows how to run scripts not only with iCall but also during HA events and so on. Run tcpdump on event | DevCentral What is iCall? | DevCentral https://my.f5.com/manage/s/article/K34291400 https://my.f5.com/manage/s/article/K3727 https://my.f5.com/manage/s/article/K11127 Knowledge sharing: Ways to trigger and schedule scripts on the F5 BIG-IP devices. | DevCentral tmsh list sys icall sys icall handler triggered ha-handler { script ha-script subscriptions { ha-subscription { event-name HA_EVENT } } } sys icall script ha-script { app-service none definition { exec /bin/bash -c "logger -p local0.notice 'yes'" exec /bin/bash -c "/opt/nfast/bin/rfs-sync --update" } description none events none } cat /config/user_alert.conf alert HA_EVENT "(.*)Sync of device group(.*)" { snmptrap OID=".1.3.6.1.4.1.3375.2.4.0.500" } You can use tmsh::log "yes" to log to /var/log/ltm as shown in: iCall script to validate Virtual Server and node with same IP addresses Testing: This can be tested even without HSM as I don't have one at my home using "logger -p" to inject the logs. I have added "yes" in the logs as a test 😎 logger -p local0.notice "010714a0:5: Sync of device group /Common/Failover" cat /var/log/ltm ............ Jul 1 08:34:07 bigip1.com notice root[23762]: yes Jul 1 08:34:53 bigip1.com notice root[23940]: 010714a0:5: Sync of device group /Common/Failover Using Linux bash script: In some versions you can trigger from icall script a bash or sh script with advanced logic inside, for example /bin/sh -c "/var/tmp/ha_script" but I saw issues on 17.1.x triggering from from icall a bash script that in previous versions I solved by adding "HOME=/root <linux bash command>" . In the "What is iCall" it is shown that you can do "if else" or "for" loops inside the iCall script but I find it easy to use bash for advanced logic. Good thing like everything with F5 usually there is more than one way to do things and this case in the user_alert.conf you can actually trigger a bash script from the log messages! What is iCall? | DevCentral iCall script triggers error need ${HOME} to run | DevCentral Running a command or custom script based on a syslog message cat /var/tmp/ha_script #!/bin/bash logger -p local0.notice "yes" /opt/nfast/bin/rfs-sync --update cat /config/user_alert.conf alert HA_EVENT "(.*)Sync of device group(.*)" { exec command="/var/tmp/ha_script" } Extra Notes: Using /opt/nfast/bin/rfs-sync --update or rfs-sync --update depends in some cases on the versions in the iCall script. In the release notes I saw a new bug https://cdn.f5.com/product/bugtracker/ID1429897.html that is solved in the latest 17.1.x versions where if the RFS is on the BIG-IP after a key/cert are created 'rfs-sync -c' needs to be run on the F5 Device that created them as well. The 'rfs-sync -c' can also be automated the way I have shown and my iCall script will work as well for BIG-IP that use external RFS and after the key/cert are created and committed from an F5 device (usually the active one) then an HA config sync needs to be started that will trigger 'rfs-sync -u' on the other F5 devices. Another nice way if you are using something like Ansible for example is to make to trigger the RFS update command on all F5 devices in a cluster as F5 supports bash commands even through API not only CLI. Example: curl -sku admin:XXX https://XXXX/mgmt/tm/util/bash -H "Content-Type: application/json" -X POST -d '{"command":"run", "utilCmdArgs":"-c \"/opt/nfast/bin/rfs-sync --update\""}' https://clouddocs.f5.com/products/orchestration/ansible/devel/f5_bigip/modules_2_0/bigip_command_mod...Hardware Security Modules
In this final stretch of security month, what hopefully has been a helpful serving of security content concludes with a look at some of the technologies that support our integrated solutions. In this article, we’ll cover the hardware security modules (HSM.) An HSM is a crypto management device that generates and stores keys locally, protects that key material from leaving the device as well as enforces policy over key material usage, and secures cryptographic operations. Back before I had the privilege to work for F5, my first exposure to HSM was working on a DoD contract. The web application infrastructure I was responsible for was subject to the FIPS requirements mandating key material be kept under hardware lock and, ahem, key. For years this was under the hood of your BIG-IP appliance (on select models ordered with FIPS cards,) and is still available in that configuration. The need for crypto offload Locking away the keys in a custom hardware module in your BIG-IP is all well and good, and still applicable in many situations, but with the advent of hybrid and completely virtualized infrastructures, the need for network-based HSMs, or netHSMs (and now cloudHSMs for that matter,) arose. F5’s integration points with netHSM technologies were developed specifically for this need, allowing VE, vCMP, Viprion chassis, as well as any other BIG-IP appliance without FIPS hardware to be utilized with FIPS deployments. In the fall, John covered some of the crypto offload options available to F5, FIPS compliant HSMs and otherwise in this Lightboard Lesson if you haven’t checked it out. The Fine Print With a netHSM deployment, there are considerations on both the client and server side. For BIG-IP, a separate license is required to use a netHSM. On the netHSM, depending on the number of clients (i.e., BIG-IP devices) you use, you might need additional licenses from the netHSM vendor. Just like your infrastructure and application servers, redundancy and scale should be considerations as well, so understanding your SSL traffic needs is important. The netHSM configurations require installation of the client software on BIG-IP, so that should be included not just as part of the initial deployment, but considered in future hotfix and upgrade plans as well, as the client software will not be carried forward and will need to be reinstalled. For vCMP and Viprion systems, please note that client software will need to be installed for each guest needing FIPS validation. For further questions on the deployment scenarios and nuances with regard to either the Thales (née SafeNet) or nCipher (née Thales) solution, drop a comment below, ask a question in Q&A , or reach out to your sales team. Resources Configuring one of our partner netHSMs on BIG-IP is a more complex scenario than most deployments. The install guides for Thales (née SafeNet) and nCipher (née Thales) are below in this list of resources. BIG-IP System and Safeness Luna SA HSM: Implementation BIG-IP System and Thales HSM: Implementation Top 10 Hardcore F5 Security Features in 11.5 (good BIG-IP FIPS/nCipher/Thales comparison chart here) US Federal: CCRI Season Lessons Learned
F5 and SafeNet HSM integration
As f5 doc suggest we can use fipskey.nethsm to create key/CSR/certificate as below: Generating a key/certificate using the fipskey.nethsm utilityBefore you generate a key/certificate, make sure that the SafeNet Luna SA client is running on the BIG-IP® system.You can use the fipskey.nethsm utility to generate private keys and self-signed certificates on the BIG-IP system.Display the available options.fipskey.nethsm --helpGenerate the key, using any options you need.fipskey.nethsm --genkey -o This example generates the three files that follow: fipskey.nethsm --genkey -o siterequest /config/ssl/ssl.key/siterequest.key /config/ssl/ssl.csr/siterequest.csr /config/ssl/ssl.crt/siterequest.crt The key is saved in /config/ssl/ssl.key/.key. The certificate request is saved in /config/ssl/ssl.csr/.csr. The self-signed certificate is saved in /config/ssl/ssl.crt/.crt. After you generate keys and certificates, you need to add the local key to the BIG-IP configuration using tmsh. The local key points to the HSM key, which resides in the HSM. I am a bit of confused with the above. My question is: is "siterequest.key" local key which is used by F5 LTM to access the real private key stored on HSM.
SafeNet vs Thales (FIPS) with F5 Advice?
Doesanybody have any advice or pros and cons of Thales vs. Safenet? I know both are good but have a customer that is looking to decide between the two. Any advice on which should be used or certain environments, what should be the determining factor, etc... would be most helpful. Again, I know both are good products that F5 partners with but looking for scenarios on when to use one vs the other. Thanks
Crypto Client's clientssl profile config issue(External Crypto )
Hi Everyone Who has configured external crypto function ? Crypto Client's clientssl profile cert&key and Crypto Server's crypto-server-default-clientssl profile cert&key is the same? This guide “https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-ssl-administration-12-0-0/18.html” is not very clear about the certificate requirements. Many thanks D.LuoAbout F5 VE External Cryptographic issue.
Hi Everyone I refer to this guide https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-ssl-administration-12-0-0/18.html in my lab. Client -----> BIGIP-1 VE v12.1 (Crypto client) -----> BIGIP-2 VE v12.1( Crypto Server ) I used tmsh commany show crypto server have normal output at below. Sys::Crypto Server: my_Crypto_Server Received Packets 156 Received Bytes 6.1K Transmitted Packets 156 Transmitted Bytes 3.8K But client web browser display common name is localhost.localdomain by Crypto client's default clientssl cert，It not by Crypto server's crypto-server-default-clientssl cert. My understanding was that use External Crypto function and its purpose is to use the Crypto server security save and management certificate. The Crypto server is responsible for the final SSL offload function.So I think client browser dispaly certificate should be Crypto server's instead of Crypto client 's localhost.localdomain. Do I understand correctly and How to correctly configured? Many Thanks D.LuoImplementing THALES netHSM to our F5 LTM VE edition
Hello I’m in the beginning steps of implementing THALES netHSM to our F5 LTM VE……and wanted to know if IOS 11.5.1 with Hotfix 4 ok to implement with THALES……also looking for any best practices for this implementation, lesson learned, or things to watch out for?.......I see three different implementation manuals (11.5) (11.6) (12.0) wanted to know does it really matter which IOS version? Thanks.
The Top Ten Hardcore F5 Security Features in BIG-IP 11.5.0
that went unsung at #RSAC 2014. There’s lots of new security stuff in BIG-IP that shouldn’t be overlooked amidst all the press releases and hoopla at #RSAC 2014. Don’t get me wrong, hoopla has its place: for example, the banking community is excited about the new anti-fraud thing we bought. And Pete Silva’s video interview of Joel Moses for the new Secure Web Gateway forward proxy is great. But the features I’m talking about are too low-level to warrant a press release, interview, or media dinner. In a way they’re even more important because platform-level security features are often the basis for the higher-level software-defined applications services that reside upon them. Just before the RSA 2014 conference, we upgraded the BIG-IP platform to version 11.5.0. The upgrade has hundreds of new features and bug fixes, but these following security features are particularly cool. The Top 10 Hardcore F5 Security Features in BIG-IP 11.5.0 UDP Flood protection in AFM –The new UDP flood protection in the Advanced Firewall Manager (AFM) module automatically detects and mitigates UDP floods. It even categorizes incoming UDP packets so that you don’t end up rate-limiting legitimate DNS requests. Full ECC and DSA Support for client SSL profiles -- on the same virtual server with RSA profiles! A single client SSL profile can now have up to three certificate/key pairs associated with it to support the full range of cipher suites now available! This is huge; people have been asking for it since before germs. Heavy URL DDoS Protection in ASM. Smart attackers may attempt to slow a website by repeatedly requesting heavy URLs such as large media objects or slow database queries. The new Heavy URL DDoS feature of ASM identifies your vulnerable URLs and then defends them. AES-GCM mode for TLS1.2! The crypto community has been waiting for GCM to become prevalent enough to start switching away from simple block and streaming ciphers. This is a big step toward enabling the whole world to be ready for GCM, and what we hope is a future reduction in TLS protocol weaknesses. Improved whitelist and blacklist support in AFM. IP addresses that are blacklisted or whitelisted can be assigned to pre-existing or user-defined blacklist classes (called categories in tmsh), and firewall actions can be applied based on those categories. AFM can be configured to query dynamic lists of blacklist or whitelist addresses, called feeds, and update the configuration accordingly. SafeNet Luna SA HSM integration. For the last few years we’ve been getting requests to integrate with Networked Hardware Security Modules (HSM). We’ve been supporting nCipher (née Thales) HSMs, and now with 11.5.0 we’re announcing our integration with Thales (née SafeNet). Hook your virtual BIG-IPs up to this and you have a pretty compelling security story. F5 HSM Feature Comparision 11.5.0 Features BIG-IP FIPS nCipher (née Thales) Thales (née SafeNet) VIPRION ✔ ✔ ✔ vCMP ✔ ✔ GTM/DNSSEC ✔ ✔ PKCS#11 N/A ✔ ✔ Virtual Edition ✔ ✔ AWS CloudHSM ✔ FIPS 140-2 Level 2 ✔ ✔ ✔ FIPS 140-2 Level 3 ✔ ✔ Perfect Forward Secrecy ✔ ✔ ✔ EAL4+ ✔ ✔ Performance 9000 TPS 3000 TPS 1500 TPS 45 Hardware-level DDoS protections in AFM. The firewall team has added and refactored the network DDoS code to make the hardware vectors exactly match the software vectors. See the complete list of pathological packets that will be dropped before the CPU even sees them. Full PKCS#12 support for key import. The paranoid among us point to the Edward Snowden files and say they’ve never had more reason to be paranoid. For them, we’re making it possible to import SSL keys directly to BIG-IP without them ever being available in the clear. Appliance Mode for vCMP guests. Appliance mode disables the root account and prevents access to the bash system shell. Appliance mode can now be configured on a guest-by-guest basis in multi-tenant environments where a particular guest virtual instance may be less trusted than others. BER-encoding iRule commands. When I was a lazy software developer, one of my goals was to get through life without ever having to write an ASN1 decoder. Guess what, someone has done just that for iRules! Check out the BER/DER iRule command reference. Honestly, this is kind of amazing. These were just the top 10 - there are a ton more features in 11.5.0 (release notes). You can play with them all in your cloud with the virtual edition of BIG-IP – download it here and have fun!
