The F5 BigIP is a great network tool for both functionality and security. F5 leads the Application Delivery Controller market and has been placed in the Leaders Quadrant by Gartner for 9 consecutive years. However, no matter how capable any product is, poor implementations can dramatically reduce your return on investment (ROI), and F5 is no different. Together, we can prevent some of the common mistakes seen repeatedly in just about every install. Below are some simple things you can do to make your install more secure and effective.

1. Round Robin and Load Balancing Methods. Let’s start out with an easy one, load balancing. This is the namesake of today’s Application Delivery Controllers (ADC). Sounds easy, right? Yet more often than not, I see the default option set, Round Robin. It’s not even a real load balancing mechanism. In the broad sense of load balancing, it does spread first time connections out, but it does not balance them.

Load balancing is, and should be, just that, balancing the connection load. In order to do so, you have to maintain a record or a table of the connections you are handling and you have to make an intelligent decision based on those records. Round Robin does not do this. It simply selects the next pool member, in sequence, and continues on despite whether the connections are long or short lived, or persisted, or not. This means that over time, connections can stack up on a server by means of attrition and their random nature.

There are many better load balancing methods to choose from. I like Least Sessions. It’s a constant check against the connection table every time a new connection comes in and it checks against a second table that monitors persisted connections that have not yet timed out. Best of both worlds are had here. Least Connections is good too, but it just checks the connection table. If you reuse backend servers frequently for “similar” applications, you could utilize something “node” based, but I prefer “member” selections because they tend be more application service oriented.

When I say similar, I’m talking about a webserver hosting a dozen of the same or similar websites, like portal pages or home pages, all on different listening ports. I’m not talking about a server running Outlook Web Access (OWA) on one port, PeopleSoft on a second, and FTP on a third. Be reasonable. The expectations for each app/service need to jive for node selection to be of use.

“But I want to use cookie persistence,” you say. That means you have a connection table, but no persistence table. How does that work with Least Sessions? It doesn’t. Since the nature of the cookie is persistence offloaded from the BigIP to the browser, this is a problem. If you are going to use cookie persistence, there are a couple things you should also do as well to help with balancing that load.

a. Use Least Connections as your load balancing method. It will manage the new connections as they come in, but will ignore the ones with a cookie already.
b. For Cookie Persistence, try to use the JSESSION cookie if the app sets one. If the Application sets a different session cookie consistently, use that one. There are canned iRules all over DevCentral for this. Pick one; insert the cookie name into it; they work great and you are done.
c. If you must use the Local Traffic Manager (LTM) cookie instead, make sure it is NOT a session cookie. Expire them. Set the expiration to whatever the Applications timeout is. If the application doesn’t have one, set something reasonable like 15 minutes. The smaller the window, the better. This is about load, security, and user expectation. If a user walks away from their machine for roughly 15 minutes, the machine should have implemented a screensaver with a lock, right? The users already expect this. The expectation that the Application would have logged them out for security reasons should be there as well. Nurture that perception.
d. Lastly, TCP timeouts should be aggressive. The default is 5 minutes. These will close stale TCP sessions to both the client and the server and will help reduce connection load. Yes, I did not mention oneconnect, that’s another discussion entirely.

2. SSH and HTTP Allowed list. This one is actually easy and should go without saying. More often than not, I see this missed during setup. Restrict what IPs or IP Ranges can connect to the management functions of the BigIP. Make them only allowable from your internal subnets. Better still, make them the IP Ranges assigned to the subnets your admins utilize for management purposes. If you use jumpboxes, use those IPs. Just remember to allow all of the BigIP’s MGMT ports to talk to each other too.

SSH can be set during the initial GUI install portion of the build and can be accessed anytime after by selecting System>Platform>SSH Allow.

For whatever reason, the HTTPD list, or the admin gui, if you prefer, is managed by TMSH and can be done so by implementing: tmsh modify /sys httpd allow add { <IP address or IP address range> }

3. Port Lockdown. This is another security feature that works in conjunction with the allow lists. By default, any interface IP you assign to a BigIP, allows it to talk to the network. Pretty straightforward. Did you know, that this also means each IP is a way to connect to the admin gui, or to access the cmd line?

Enter Port Lockdown. This feature allows you complete control over what MGMT functions are allowed PER IP. You do need a little bit of knowledge here, but it’s still pretty easy. When you define an IP on the LTM, if it faces clients or the Internet, set Port Lockdown to Allow None. If it faces the servers or other BigIP devices, set it to Allow Default. None means zero; no MGMT functions at all. Default means allow iQuery, 443, SNMP, SSH, DNS, OSPF, and CAP, which is network failover. This assumes you trust the Internal IPs. If you do not, than you are using Allow Custom and have to know what you need on each IP. Personally, I always use Allow Custom. I assume you should know if the IP you are assigning is facing the SNMP server, or GTM, or another BigIP. Remember, settings on the self-IPs and Floating IPs need to match!

As an update to this, in version 12.0, BigIPs, set this to Allow None.

4. Default Cookies. These are used for Persistence but actually are a security feature too. Every time you make a connection to an LTM Virtual Server with Cookie Persistence enabled and you are proxied to a pool member, you get a session cookie. By default, all BigIP Cookies in the LTM module show up as BIGipServer<pool_name>. It tells the client you are using a BigIP and the pool name you are connecting to, and if they decode the payload, the server IP and its listening port as found in this SOL article here. This can be classified as information disclosure about your install. Encrypt your cookies and their payload and make your install more secure!

Create your own default HTTP and Cookie profile for your install. Use them to encrypt the cookie contents and the cookie itself. Keep in mind these things:

a. Do not use your company name. Vanity here gives away information to a hacker.
b. Do not use the application name. Same here, and this can make things far easier to target as well.
c. The Cookie name should make sense only to you. Generating a random Cookie Name is not a bad idea.
d. Set the Cookie Encryption Use Policy to required in the new Cookie Profile. This will make sure that cookie contents are encrypted.
e. Set a Cookie Passphrase keeping in mind a, b, and, c. I recommend generating a random passphrase and keeping it in a password vault. The passphrase is used as the key in the encryption of the Cookie payload, and should be protected as a sensitive credential.
f. Lastly, when you create the HTTP profile that references the Cookie Profile you just set up, set a new passphrase. Do not use the same passphrase that you used in the Cookie Profile. This should be protected as a sensitive credential too.

For more information on this, reference sol14784: Configuring BIG-IP cookie encryption (10.x – 11.x).

5. Default Profiles. These are not as good as they used to be, especially the TCP profiles. TCP capabilities in BigIP have evolved but the profile settings have remained largely unchanged. If you are using the base TCP profiles, you may be missing out on a lot of free optimization, response time, and most important of all, end user experience improvements. Ever heard of Multipath TCP? Nagel’s Algorithm? How about the TCP Window Scaling described in RFC 1323?

TCP options are really their own topic. Fortunately, for those not in the know, there are several articles from F5 and TCP gurus to help you out on this point. I recommend Stop Using the Base TCP Profile! on DevCentral and these two white papers from the F5 main website: TCP Optimization for Service Providers and Optimize WAN and LAN Application Performance with TCP Express. Also, if you have not already gotten a copy, you may want to consider downloading High Performance Browser Networking. It’s free and a really good read.

These articles break down the TCP features and give you quite a bit of insight into what you can do without having to spend a serious amount of time researching TCP. The best part is that all of these features are built into the stack and are sitting there ready to do their thing. Making these changes on one side is usually enough to reap the benefits because of TCP’s negotiation.

6. SSL Decryption. I see the lack of this a lot, and it boggles my mind. If you went through the trouble of buying and installing an F5 BigIP, why would you not terminate SSL on it? It is purpose built and hardware accelerated to handle that traffic. Plus, removing that SSL load from the server processing those transactions means more resources for whatever application is running on it. And since you would be sending clear text to the server, securely intercepting and monitoring that traffic becomes easier. You want to inspect the traffic on the LTM and make intelligent decisions with it; iRules, Policies, pool selection, root redirects, stream expressions, etc., all rely on inspection of traffic.

You might say you need SSL on the server for the application to function properly or for Authentication reasons. Well, you have two options then. First, you can re-encrypt to the back end servers, throwing up a server profile on your Virtual Server. This usually works fine, and you get to do all those other cool traffic decisions I mentioned, but you might need to add an iRule for passing along Client Certificates. Or secondly, you could use Proxy SSL, which essentially creates a channel from the client to the backend server passing on the client Auth mechanism to the server while allowing the F5 to still do its thing as a proxy. Application Security Manager (ASM), the F5 Web Application Firewall (WAF) product, works great with this too.

7. HTTP Server Header. This is another one of those security things. This one might take a bit of “know your application” sense. The Server Header is a little used field with the purpose of information disclosure and fingerprinting the server. It’s there to help out the Hackers by telling them what application you are using and which version they need to hack!

Okay, that’s not really what it’s there for. RFC 2616 for HTTP 1.1 says ‘product tokens are used to allow communicating applications to identify themselves by software name and version.’ Basically, it’s a mechanism in the HTTP standard to allow the client side of a HTTP stream to verify applications and/or versions of the server for security reasons. No one uses it. Best to make it go away.

Here’s the issue with the LTM, though. It actually inserts this field when it does certain things like 302 redirects. So, if you are going to make this go away, you are going to have to add an iRule or some of its logic if you already have an iRule assigned. Here’s a good one from DevCentral. Or, you could add ASM and utilize all the security benefits a WAF provides.

8. Cipher Strings. I would be remiss if I did not mention this when talking about security features. There are many versions of BigIP running out there and practically each version has a different set of ciphers. I do not expect you to know them all. I do expect you to know what your version does though. I also expect that you at least learned what a cipher is, what it’s for, and what it’s made up of. That said, here’s some help.

a. sol13156: SSL ciphers used in the default SSL profiles (11.x – 12.x)
b. sol13171: Configuring the cipher strength for SSL profiles (11.x)
c. https://f5.com/Portals/1/Premium/Architectures/RA-SSL-Everywhere-deployment-guide.pdf
d. www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Server_Protocol_and_Cipher_Configuration
e. www.feistyduck.com/books/openssl-cookbook/

F5 is touchy about these. They will not make recommendations on cipher strings unless there is an outright security issue with a particular cipher. They typically just give suggestions or examples. Invest some time here and get to know the “what’s” and “how’s”. You need to know what you don’t know. Read the F5 stuff, then the openssl, and such. Don’t think for a minute that the defaults are going to be fine. Vulnerabilities and attack techniques such as Poodle, Heartbleed, and Logjam are getting more and more common it seems, and weaknesses in ciphersuites such as RC4 continue to create issues for otherwise “secure” web applications.

As a note, if you start your install with the creation of a new “default” client SSL profile, you can then set it as the parent for all of the individual profiles you will create later. Then, when something like RC4 pops up, you can make the change in that parent and it filters down to the others. Powerful, but handle with care.

9. LTM Denial Of Service. I mention this one as a suggestion. LTMs do some pretty cool things right out of the box on DOS Protection like SYN Cookies. Some simple configuration tweaks add a bit more coverage. While not a comprehensive solution or a replacement for adding in ASM, an IDS/IPS, firewall, etc., it’s free with the product. Why not use it?

a. https://devcentral.f5.com/questions/ddos-attack-prevention-in-ltm
b. https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm_implementation/sol_dos.html
c. https://support.f5.com/kb/en-us/solutions/public/14000/800/sol14813.html

10. IP Intelligence. It’s a cheap little security feature you can buy for the LTM and other modules that really makes sense. It’s an IP reputation database that updates constantly over the Internet to an F5 Partner. The database contains a list of suspicious and known bad IPs from across the Internet that you do not want to access your install. It costs about as much as a yearly certificate renewal for a single website, but this can be leveraged for every website on that LTM.

F5 even supplies two neat little iRules you can use or modify as needed, and are located here. I highly recommend adding this even if you are not doing anything with GEOLOCATION on the F5. But if you are, don’t just block the bad countries, cities, whatever. Block the BAD IPs in the countries you are allowing.

Tony Turner, Practice Lead for Application Delivery, recently hosted a webinar about how application delivery technologies can help support availability, optimization, management, overall security and more. Please click here to view the webcast.

About GuidePoint Security

GuidePoint Security LLC provides customized, innovative and valuable information security solutions and proven cyber security expertise that enable commercial and federal organizations to successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Herndon, Virginia, GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM). Learn more at: http://www.guidepointsecurity.com.