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!
