New F5 ASM Version 12.x Features Improve Performance

In today’s blog, we will discuss the newest features of F5’s Web Application Firewall (WAF), Application Security Manager (ASM). ASM has been around for quite some time, but with recent updates I thought it is worth discussion.

F5 Networks recently released version 12.1.1, the first long-term support release for version 12. If you haven’t read through the release notes, take a few minutes and do so. I am really excited by some of the most recent features and I would like to share some of them with you.

I was ecstatic to see Unified Policy Building in 12.0 because now you have one screen to view all learning suggestions. This makes it far easier to sort through. If your policy builds automatically or statically based on your custom thresholds, you now have only one screen to manage.

Following the style already set in ASM, there is a dropdown menu that allows you to select the policy for which you want to see suggestions. Tabbed across the top is also Enforcement Readiness, and they moved Learning and Blocking Settings here as well. This makes the overall flow better while making it easier to see which settings you have for each selected policy — no more bouncing around the mouseover menus.

Next up in 12.0 is Proactive Bot Defense. This is a set of additional features added to the Denial of Service (DoS) functions ASM already used. F5 added improved defense against unwanted browsers and browsing agents that are non-human initiated. CAPTCHA and javascript insertion does this, but with some caveats. If you use CORS (Cross-Origin Resource Sharing), like with AJAX calls, you will have issues and you should add those URLs to the bot whitelist.

F5 Networks also added malicious bot signatures. Now when you update your ASM application signatures, bot signatures are classified as malicious or benign. Just like with application signatures, you can create your bot signatures as well. You even have the ability to create signature sets with either malicious or benign classifications. This gives you greater control. Once created and applied via a “dos” profile, traffic is automatically classified and either accepted or discarded as configured.

Version 12.1 was not outshined by 12.0, and really cranked up the dial. It added more dos enhancements with the ability to track using device IDs. Now device IDs can use dos, brute force, and session hijacking. You can define bad behavior and set thresholds to classify traffic from them and either log or block them. F5 even extended Analytics to sort by these IDs. More reporting is always a good thing!

Using a similar set of metric definitions, you can now automatically blacklist IPs attacking your layer 7 resources and increase your dos footprint. This does not require use of IP intelligence or any other classification engine. This dos feature is through your config definitions. Adding IP intelligence, however, is a good thing in my opinion. I encourage you to look at it as more than just ASM.

Two huge new features in ASM are the ability to define methods per URL and support websockets per URL. In previous versions, methods were globally defined for an application. This is great news. For apps that might have only one page that support a POST, you can define it only for that page.

Websockets are new altogether. Websocket protocol allows client and server to stream data bidirectionally indefinitely. Websockets create a connection over HTTP, but then switch to a single TCP connection using message frames. This allows full duplex and low latency transport. Chances are you used these in your last internet chat. When you think of what could be hiding in one of those, protection really matters.

The last feature I want to mention is the ability for ASM to automatically detect and configure login pages in your application. If you have spent time parsing through someone else’s code to define a login page, you will welcome this feature. Now, that alone would be cool, but if you defined policy settings for brute force and session tracking, it will automatically add those options to the login forms it creates. This is a rockstar feature!

These are some of the main features ASM received in 12.0 and 12.1. There are still others like improved policy building, reduced policy building resource consumption, etc. Once again, if you have not reviewed the release notes, you should. I hope this generates a little interest in seeing what ASM has to offer now, and that you continue to find success in using F5 Networks Application Security Manager.

If you don’t already have ASM, consider what ASM can do for you. If you are already a Guidepoint Security customer and want to know more, reach out to your representative. If you are not a customer and would like to learn more, please feel free to contact us. We have several ASM certified engineers to answer your questions. For more information, email info@guidepointsecurity.com.

About GuidePoint Security
GuidePoint Security LLC provides innovative and valuable cyber security solutions and expertise that enable organizations to successfully achieve their mission. 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 is with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.

F5 Networks’ ASM: Secure Your Applications, Don’t Give Away Your Kingdom

It occurred to me while I was writing another blog that we need to talk about Web Application Firewalls (WAF). We think everyone should use one. Your current network and security infrastructure is the castle and drawbridge, whereas WAF is your portcullis. Not securing your applications is like giving away the keys to your kingdom.

What is a WAF?

WAFs are the first and last line of defense for your application. A WAF takes over at layer 4 of the Open Systems Interconnection (OSI) model, moves up to layer 7, and looks at the request, response, and payload. It validates data and the package it’s carried in, and its authenticity. In essence, a WAF applies a set of security rules to all aspects of an HTTP conversation.

The difference from your next-generation firewalls (NGFW) and IDS/IPS units, which only inspect packet-by-packet, is that a WAF digs into HTTP content and conversations, and validates the content request, response, and payload against white and black lists. Using predefined signatures or behavioral baselines, the WAF takes appropriate countermeasures based on configured policy elements. WAFs also include enhanced logging, alerting, connection intermediation, and even content manipulation to mitigate the impacts of attacks, mislead attackers, or inject content designed to raise confidence levels for WAF detection mechanisms.

A WAF validates traffic and payloads by learning the way the application should work, prevents bad input or manipulations, and prevents dangerous query/responses. A WAF maintains HTTP RFC compliance on all aspects of the session, and enforces session rules and session flows. It is a multifaceted tool.

F5 Networks Application Security Manager (ASM), in my opinion, is the right tool for the job. It is a tool that complements the F5 Global Traffic Manager (GTM) and Local Traffic Manager (LTM) devices you already use. To illustrate this, let us look at the traffic flow.

First, the GTM picks up the DNS request. Utilizing GTM, you can create a high-speed query frontend with DNS Express and can secure that zone with DNSSEC. GTM also evaluates your DNS request and traffic-shapes your response based on a host of criteria and settings, sending your session on to the network.

Sure, you have a firewall at your internet edge. It might even be next-gen, performs packet inspection, and has some signatures to eliminate some bad traffic. The same might also be true of your IPS/IDS, but these are packet-by-packet inspections and not the whole HTTP conversation (for the most part) and bad traffic gets by.

Here is where the F5 picks up and starts defending. LTM gets the traffic first and blocks malicious IPs, sorts out countries you may or may not want, defends against DDoS, and mitigates ciphers that are too weak or broken, all while restricting IP/port/landing page. LTM also traffic shapes it handoff to the next level, ASM.

ASM starts slow and builds in levels based on policy. It receives that traffic and checks if it matches the defined site. Then it checks to see if it is a new session. From there, it starts checking everything. It checks against signatures, RFC compliance, session-tracking info, methods, request timing, number of requests, header information, etc. And this is only the initial request. We haven’t even gotten to response!

ASM comes with quick-start policy templates for a ton of popular application templates like Exchange, Sharepoint, PeopleSoft, SAP, etc. If one of those doesn’t fit your build, ASM ships with an auto-policy builder. Fire this up and you turn your ASM device into Sherlock Holmes. It watches traffic pass through and automatically starts writing its own suggestions. When those suggestions get enough hits, ASM makes them into policy. The longer it runs, the better the policy.

If you change the application or add to it, it automatically picks that up and starts the building piece again. You can even build policy without affecting users. By keeping it out of blocking mode, you can mature the policy and reduce the likelihood that false alarms will create negative impact for users.

The ASM comes with other cool features, too, such as preventing forceful browsing, where attackers try to gain access to pages not part of the site that might have admin access. You can keep users from bookmarking deep into the app and redirect them to login pages you defined first to define flow. This keeps the application more secure and enables the organization to track sessions to support security, problem resolution, and compliance use-cases.

With this information, you can restrict application access to secondary login pages or other admin-related content by enforcing application flows and protect against webscraping. Brute force protection will even keep those login pages safe by adding a layer of protection including limiting login attempts, identifying automated attacks and more for these critical security entry points for the application.

DataGuard is an awesome feature as well. It protects sensitive fields like credit card numbers, Social Security numbers, and other administrator-defined sensitive data from passing through clear text. Instead, it utilizes masking to overwrite these values in responses with ‘****’. ASM will also mask these in the logs so you don’t have to worry about admins having access to that info as well.

There are so many other features, including signatures and security responses for common web application security threats such as cross-site request forgery (CSRF), cross-site scripting (XSS), clickjacking, cookie manipulation, etc. Any of these topics, as well as the mechanisms ASM utilizes to protect against them, would be worthy of their own blog post.  

I hope this blog has sparked a little more interest in your traffic and maybe even a hard look into the available security measures you can take. If you are already a Guidepoint Security customer, reach out to your representative to learn more. If you are not a customer and would like to learn more, please feel free to reach out to us. We have several ASM certified engineers to answer your questions. For more information, email info@guidepointsecurity.com.

About GuidePoint Security
GuidePoint Security LLC provides innovative and valuable cyber security solutions and expertise that enable organizations to successfully achieve their mission. 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 is with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.

Use Cases Demonstrate How F5 Analytics Can Increase Visibility Into Your Applications

In a previous blog post, I introduced you to F5 Analytics and how it can enable you to gain more visibility into your F5 application delivery controller infrastructure. (If you missed part one, you can check it out here.) This blog post continues where I left off and provides two more exciting use cases for you to explore.

Viewing application page load times

This is a ground-breaking feature that really makes F5 stand out from its competition. Basically, this information is useful for tracking user experience by displaying how long it takes for your application web pages to load on client-side browsers.

Client-side browsers must meet the following requirements:

  • Support navigation timing by W3C
  • Accept cookies from visited application sites
  • Enable JavaScript® for the visited application sites

The BIG-IP Client Side Performance Monitoring (CSPM) feature generates the page load time data. According to F5 Networks, “To calculate the client-side load time for a web resource, the CSPM feature injects a piece of JavaScript code into the HTTP response that it sends to the client. When the client browser executes the JavaScript, it calculates the specific timing values needed by the CSPM feature, and reports those values back to the BIG-IP system in a cookie.”

There are three requirements for CSPM injection in an HTTP response. They are:

  • HTTP content is not compressed
  • HTTP content-type is text/html
  • HTTP content contains an HTML <head> tag

Application page load times are viewable in the F5 Analytics charts. Alerts are configured there as well. Page load time is measured by how long in milliseconds it takes for an end-user to make a request for a web page until the web page finishes loading on the client-side browser. Think of how amazing this is! You’re literally reaching out to your end-user, wherever he or she may be, and gathering statistics of their experience just by enabling a checkbox.

Troubleshooting applications by capturing traffic

This is typically used only for troubleshooting an active issue. I don’t recommend setting this up and leaving it on for eternity. This is not traffic capture like a tcpdump would do, but more of a layer-seven-type capture. I’ll explain that later.

The information captured is stored locally or remotely via syslog or a SIEM, like Splunk. If captured locally, the system stores the first 1,000 transactions. If using a VIPRION system, the system stores the first 1,000 transactions times the number of blades in the system. I recommend capturing the transactions remotely to syslog or Splunk where you are only limited by the storage of the remote destination.

So, what did I mean by layer-seven-type capture? Well, instead of capturing raw data like a tcpdump would, you can capture actual traffic, such as requests, responses, or both. The data contained by those may include:

  • None
  • Headers
  • Body
  • All

You can configure a traffic filter for captured traffic to include filtering by:

  • Virtual servers
  • Nodes
  • Response status codes
  • HTTP methods
  • URL
  • User agent
  • Client IP addresses
  • Request containing string
  • Response containing string

As you can see, this is different than doing a tcpdump and exporting to Wireshark for analysis, which may be fine for certain cases. My point here is to show you a new tool that you can use for troubleshooting an issue with your F5 BIG-IP application delivery controller environment that may rapidly provide you with more relevant data to solve an issue.

I hope this post stimulates your interest in F5 Analytics. It is a powerful (and free) tool to use in your F5 BIG-IP application delivery controller infrastructure.

In addition to F5 Analytics, there are many features available with F5’s application delivery controllers that can enhance your investment, increase your return on investment, and improve end-user experience. If you would like to learn more, GuidePoint’s security professionals have years of experience with F5 application delivery controllers, as well as integrating them with other solutions. We can help you develop a customized security plan to best meet your organization’s needs.

If you’re a GuidePoint client and have questions about F5 Analytics, please reach out directly to your personal contact or email us at info@guidepointsecurity.com. If your organization wants to learn more about F5 Analytics and if it’s the right tool for you, let us know. You can find out more about GuidePoint and our services at www.guidepointsecurity.com.

About GuidePoint Security

GuidePoint Security LLC provides innovative and valuable cyber security solutions and expertise that enable organizations to successfully achieve their mission. 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 is  with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.

F5 Analytics: Increasing Visibility Into Your Applications

Have you ever wanted to learn more about what your F5 BIG-IP application delivery infrastructure is doing? Sure, there are basic statistics like throughput, number of sessions, and active connections, but as layer four load balancers have evolved into layer seven application delivery controllers, shouldn’t the available performance metrics evolve as well?

In this blog post, I want to bring visibility to a great tool included in every F5 Networks BIG-IP platform. That tool is the F5 Analytics module (otherwise known as Application, Visibility, and Reporting or simply AVR). It’s already included with BIG-IP, you just need to provision it and set it up. (One quick note on provisioning, you should provision the AVR module with “minimum” resources.)

So, what is F5 Analytics? Well, it is a fantastic new way of discovering more information about your applications and infrastructure through graphical charts, and you can drill down for more specific details about performance-related statistics.

F5 Networks provides excellent documentation on the features and configuration of F5 Analytics on its support site, but I want to point out a few of the use cases. I hope to highlight its feature set so you can incorporate it into your own F5 BIG-IP application delivery controller infrastructure.

Troubleshooting applications by capturing statistics

This core F5 Analytics functionality is suitable for everyday use. F5 Analytics is configurable to capture a variety of great statistics. They include metrics, such as:

  • Max TPS and throughput
  • Page load time
  • User sessions

And entities, such as:

  • URLs
  • Countries
  • Client IP addresses
  • Client subnets
  • Response codes
  • User agents
  • HTTP methods

All of these metrics and entities are viewable in the administrative GUI. For instance, if a user calls in and says an application is broken, you can filter the transaction statistics by client IP address and then narrow the filter by virtual server and time period to view the actual request/response metadata. It is pretty cool to troubleshoot a problem with an application just by drilling down into some graphs to isolate the issue. In addition to collecting statistics locally on BIG-IP, you can collect data remotely via syslog or a SIEM, such as Splunk and view the data there.

Investigating server latency

This is F5 Analytics key feature and may provide valuable information to your server and application teams. F5 Analytics measures server latency in milliseconds from the time the request reaches the BIG-IP, for it to proceed to the application server, and return a response to the BIG-IP system.

In my experience as a BIG-IP administrator, one of the most common misconceptions was that the LTM was somehow adding latency to server response times. Fingerpointing was often directed at the LTM, and I frequently had to run tcpdumps to exonerate the LTM as the culprit of server latency.

In addition to providing server latency statistics, F5 Analytics provides the ability to set an alert threshold in milliseconds and issue an alert via syslog, SNMP, or via email. This information helps to proactively track latency issues with web servers, application servers, database servers, etc. This is a big deal because you can now isolate where slower components may exist in your web stack all from a simple GUI.

I hope this posts stimulates an interest in F5 Analytics. It is a powerful (and free) tool to use in your F5 BIG-IP application delivery controller infrastructure.

In addition to F5 Analytics, there are many features available with F5’s application delivery controllers that can enhance your investment, increase your return on investment, and improve end-user experience. If you would like to learn more, GuidePoint’s security professionals have years of experience with F5 application delivery controllers, as well as integrating them with other solutions. We can help you develop a customized security plan to best meet your organization’s needs.

If you’re a GuidePoint client and have questions about F5 Analytics, please reach out directly to your personal contact or email us at info@guidepointsecurity.com. If your organization wants to learn more about F5 Analytics and if it’s the right tool for you, let us know. You can find out more about GuidePoint and our services at www.guidepointsecurity.com.

Check out part two of this series on F5 Analytics here.

About GuidePoint Security

GuidePoint Security LLC provides innovative and valuable cyber security solutions and expertise that enable organizations to successfully achieve their mission. 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 is with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.

Extending Your Security Infrastructure to Include DNS

For years, F5 has been a key player in DNS with its BIG-IP Global Traffic Manager (GTM). Today, F5 continues the development that has made it an industry leader, focusing on GTM, making it feature-rich, and renaming it BIG-IP DNS. Now through the BIG-IP DNS product you can add speed, reliability, and security to your DNS infrastructure improving both your end-user experience and your company security stance.

Global availability is still an important feature for BIG-IP DNS, but serving and protecting your DNS infrastructure has also taken center stage within this module.

BIG-IP DNS is a proxy like Local Traffic Manager (LTM), but it only services DNS. It consumes incoming DNS queries, parses the request against its configuration, or sends the request on to another server. Like LTM, BIG-IP DNS leverages purpose-built hardware to enhance, accelerate, and secure your DNS service. BIG-IP also offers flexibility and scalability for small to large companies protecting against surges and sudden growth.

On the front line, BIG-IP DNS protects against DNS DDOS by answering queries faster than most traditional DNS installs. Most BIND installs tap out at about 50,000 requests per second (RPS). A good DNS install provides in the neighborhood of 200,000 to 250,000 RPS. A BIG-IP DNS appliance can handle 10,000,000. Add in geolocation and/or IP intelligence, and you can selectively answer queries based on IP, city, state, country, region etc. Deploy BIG-IP DNS in an active sync group and sleep better at night.

Once BIG-IP DNS sorts through incoming queries, it can safely and efficiently address requests.  This is where DNS Cache, DNS Express, and DNSSEC come into play

DNS caching is the initial level for increased DNS performance. BIG-IP DNS can be a transparent cache for your existing infrastructure, adding single point of control and reducing administration overhead. Since you won’t need to run a cache engine on each individual server, this frees up more resources and reduces load on DNS servers. BIG-IP DNS also decreases lookup times by using purpose-built hardware and serving records from memory. This decreases response times and increases end user experience.

In my opinion, DNS Express™ is the highlight feature of BIG-IP DNS. In a nutshell, DNS Express sets up a virtual DNS server in RAM, transfers your DNS zone into it, and provides high speed queries to all of your records. It does this by pulling in new records created in your infrastructure and constantly checking in with the DNS Master just like a secondary server.

DNS Express acts authoritatively for this zone and has unhandled query functions. DNS Express also handles Zone transfers and can be secured using TSIG keys. Additionally, it handles both IPv4 and IPv6 traffic. A key benefit to this is it runs only a subset of BIND, so it’s not susceptible to most vulnerabilities and makes your install even more secure.

If more security is requested or required, BIG-IP DNS supports DNSSEC. This nifty little industry standard allows signing of DNS responses and protections against things like cache poisoning and phishing. It does this by using zone signing keys and, yes, they can be HSM keys.

The signing key setup can be made to automatically roll over based on user-defined thresholds. This adds even more security. Both of these apply to the key-signing keys as well. You can run the HSM locally, in appliances, or offload to a network-based model. Lastly, performance is not an issue here since you use purpose-built hardware for the DNS piece and the keys stored locally.

Overall, BIG-IP DNS goes a long way to filling a strong security role in your infrastructure. For those of you using ‘Better’ or ‘Best’ licensing models, you should have the needed licensing to utilize these capabilities today. If you have an older SKU for GTM, you may need add-on licenses for these features.

GuidePoint’s team of professionals can review your use case and speak to you regarding your solution options. We have several F5 Certified Technology Specialists in GTM to assist you and can help you maximize your installs potential and secure your resources.

If you’re a GuidePoint client and have questions about BIG-IP DNS, please reach out directly to your personal contact or email us at info@guidepointsecurity.com. If your organization is interested in learning more about BIG-IP DNS and if it’s the right tool for you, let us know. You can find out more about GuidePoint and our services at www.guidepointsecurity.com.

About GuidePoint Security

GuidePoint Security LLC provides innovative and valuable cyber security solutions and expertise that enable organizations to successfully achieve their mission. 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: www.guidepointsecurity.com.

OneConnect: Saving Resources, Increasing Investment

In a previous blog post, I talked about some common Local Traffic Manager (LTM) features that get overlooked, which can easily increase security posture. In this post, I want to discuss one of the less-known features that is frequently neglected because you may not understand the benefits. This feature is OneConnect.

OneConnect is an awesome addition to any modern application that follows good code and RFC standards such as TCP or HTTP. OneConnect creates a pool of first time TCP connections to each pool member and makes them available for reuse by later connections. This is done by using TCP standards like idle timeouts, keepalives, etc.

When an initial connection is created to a pool member, the BIG-IP holds that connection open and uses it for other TCP flows that are destined for that member. This can drastically reduce the number of connections the web server has to process and allocate resources for, thereby improving the web server’s overall performance.

With an HTTP connection, OneConnect can manage HTTP connection flows and process them much the same way as TCP flows. It first manages the TCP flow for that connection like a TCP app. Because OneConnect is HTTP-aware, thanks to whichever HTTP profile you associated with the virtual server, it can read the HTTP flows and process state for them at the same time. If the TCP connection the HTTP flow was using ages out, when a new TCP flow is connected, it will continue that HTTP flow over the new TCP connection.

The LTM uses HTTP standards like keepalives to maintain state. In the case of non-HTTP/1.1 connections, there is no keepalive and the LTM will intercept “Connection:close headers” and transform them to “x-connection: close headers” so it can process connections the same way. This feature, OneConnect Transformations, has to be enabled in the HTTP profile.

By default, OneConnect makes every connection it processes available for reuse. You can restrict this in your OneConnect profile by changing the subnet mask. The subnet mask sets the groupings that OneConnect will make with the incoming IPs.

For example, maybe you don’t want external client IPs and internal client IPs sharing connections. In this case, you could change the mask to 255.0.0.0 so that your 192’s or 10’s will not mix with 25s or 100s. Of course, if you are using 172.16.x.x internally, you need to use 255.255.0.0 instead. Knowledge of your internal IP structure and your application requirements is important.

A note on SNAT: If you use SNAT Automap on your virtual server, OneConnect gets applied after SNAT; so no matter what your mask is, every flow will be reused regardless of the setting in the OneConnect profile. If you use a SNAT Pool, you could use a 32-bit mask to create more flows, but unless you have a really high connection count, there is no need to do this.

To help illustrate this, here is an example I worked on not long ago. One of the state governments I worked with had a web application that processed healthcare options for “Obamacare.” Day-to-day connections to the application hovered at about 4,000 to each server. When it came time for open enrollment, all of the web servers fell over trying to process more than 25,000 connections each. Users who got connected reported the server was so slow, it could not respond to page requests, and timed out. Once OneConnect was enabled with a default mask, the number of active connections dropped to about a 100 per server! The application bounced back completely, and the developers said the application worked better than in development.

There are some special considerations when utilizing OneConnect within your environment. The application has to use TCP standards for clearly defined flows. OneConnect will not work if your flows do not provide good headers for distinguishing source and destination. If your application is 20-years-old and home-grown, it might not work. Recent applications should not have issues.

Secondly, you are sharing TCP flows. If you are sniffing the wire to look at incoming web server traffic, you might not see the flow you are looking for because it was part of a reuse pool. In this case, try to match the client port. The port should remain the same most of the time, but since you are combining different flows from different IPs, the likelihood of overlap is higher. Also, if your application needs to see client IPs, you will need to enable “x-forward-for” and configure the web server to look at that header instead. Additionally, if you are doing SSL Passthru, this is not an option due to the traffic encryption. OneConnect requires termination. You would have to decrypt and then re-encrypt to the backend.

Lastly, one item of particular note is sizing. Since OneConnect can drastically mask a connection table, you need to incorporate the application’s client activity in with the web server connection load to get a feel for how many web servers you need. You might, over time, find out that you cannot turn OneConnect off because your load will be too much for the existing number of web servers you have.

I hope this post has piqued your interest in OneConnect and what your F5 LTM can do for you. There are many additional features beyond “load balancing” that can enhance your investment, increase your return on investment, and improve end-user experience. GuidePoint Security’s professionals, with years of multifaceted expertise, can meet with you to learn more about your organization’s requirements and help build a customized security plan to best meet your needs.

If you’re a GuidePoint client and have questions about OneConnect, please reach out directly to your personal contact or email us at info@guidepointsecurity.com. If your organization is interested in learning more about OneConnect and if it’s the right tool for you, let us know. You can find out more about GuidePoint and our services at www.guidepointsecurity.com.

About GuidePoint Security

GuidePoint Security LLC provides innovative and valuable cyber security solutions and expertise that enable organizations to successfully achieve their mission. 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: www.guidepointsecurity.com.

10 Steps to Optimize Your F5 Local Traffic Manager Implementation

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.

Updating Government Applications to Maintain Compliance and Security

The attack surface related to applications continues to shift. It seems like every day, sometimes every hour, a new security vulnerability needs to be mitigated. The dilemma is more challenging for government agencies because they are also charged with adhering to new and frequent mandates calling for additional security controls on applications. Keeping up with all the applications in an enterprise environment can be difficult even for applications that get updates issued by a vendor that only need to be applied. Add to the situation, custom applications or legacy applications that have been End Of Life’d (EOL) by the original vendor, but continue to be utilized. How do you apply security controls, like Multi-Factor Authentication (MFA), or moving from Secure Sockets Layer (SSL) to Transport Layer Security (TLS), on an application that does not support it, and was written by someone you don’t have access to?

This is the quandary that many government agencies face today.

The situation put forth is an extreme one. However, the same quandary can be found when dealing with applications that have support from either a vendor or Federal System Integrator (FSI), but still require significant efforts on the part of system administrators and security experts inside the government. The question doesn’t change, but now instead of being possible, it becomes nearly impossible with the labor available.

Changing the game with F5 and GuidePoint Security

These problems actually can be addressed fairly easily by deploying, or using already deployed F5 Local Traffic Managers (LTMs). GuidePoint Security has been finding that many government agencies have deployed F5 LTMs for the Web-Application Firewall (WAF) or performance and load balancing benefits, but are not using them for other security benefits inherent in the product.

A recent example is mentioned above. POODLE opened the eyes of the world to how SSL was too weak and old of an encryption standard to be trusted, no matter if it was SSLv1, SSLv2 or SSLv3. TLS was immediately declared the new standard. POODLE was an exploit of the SSLv3 cipher that opened up new vulnerabilities. The information that hackers could gain ranged from passwords and cookies, to other authentication tokens. The hacker could then utilize the information to impersonate the user and access sensitive data. When this security vulnerability was discovered, the mitigation technique most widely used was to disable the SSL ciphers on the application servers. The process to move from SSL to TLS on corporate application servers was very intrusive and arduous.

GuidePoint Security was able to mitigate this vulnerability between the client connections and server connections utilizing the F5 networks Local Traffic Manager’s SSL profiles and full proxy architecture. The full proxy design includes separate client and server connections handled on the same device. In this solution, the client side SSL profile eliminated the vulnerability when negotiating with the SSLv3 standard. The client, in turn, had to use the more secure TLS standard. The server side connections were still able to utilize the SSLv3 ciphers in the server side connection on the F5 LTM. The importance of this mitigation technique was that it allowed server administrators time to eliminate the SSLv3 negotiating ability from the application servers during planned maintenance activities. The servers were able to be patched during the planned maintenance windows and operations continued as normal.

Another important point is that this could be deployed across an entire enterprise comprised of various applications without separately patching each different application until later. Simply pushing out a global configuration update to all the F5 LTM’s in the environment immediately fixed all applications, regardless of the status of support for TLS, or even if they were EOL’d.

“Why do I still have to use pre-Windows 10 IE again???”

This same ease of upgrade can be used to add support for newer versions of web browsers. GuidePoint Security found that many customers were using multiple browsers and versions, some of which are woefully insecure, because they cannot make upgrades to the legacy application, or it is too difficult to do so. Using the F5 LTM, the most secure and recent browsers can be used to access these applications. This is important because the most commonly used browsers (Google Chrome, Mozilla Firefox, and Safari) are now negotiating with the more secure TLS encryption standard only. If a corporate web server is still using SSL standards, the connection will not complete as the web browser will not be able to negotiate an agreeable cipher.

Doing MFA without MFA support

The second example is similar. Many applications or appliances do not, or are not easy to add support for Multi-Factor Authentication (MFA or sometimes referred to as 2-Factor Authentication). The same way TLS support can be added via F5 LTM’s, MFA can be applied to applications or appliances that do not support it. This is important due to the directives released by OMB and the President.

GuidePoint Services

The landscape of security between client and server side connections is always being attacked. The attacks come in many forms ranging from severe to a minor annoyance. The need for an aggressive mitigation plan is essential in order to secure an organization’s applications, in a timely manner. GuidePoint Security can assist government agencies remain compliant and secure by leveraging the often already existing F5 Local Traffic Manager.

About GuidePoint Security

GuidePoint Security LLC provides innovative and valuable cybersecurity solutions and expertise that enable organizations to successfully achieve their mission. 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.

Vulnerabilities Found in Android Web Browsers Dolphin & Mercury; GuidePoint Security Making Ongoing Investment in Mobile Security Research & Commitment to Testing for Customers

Vulnerabilities within Android mobile browsers, Dolphin and Mercury, have been identified. Benjamin Watson, Mobile & Application Security Practice Lead at GuidePoint Security, has discovered these vulnerabilities. “I have been researching common vulnerability patterns in Android Web Browsers since the beginning of 2015. Since the beginning of my research efforts, I have found that quite a few of the most popular browsers available on Google Play are subject to these vulnerability patterns,” Watson explained. GuidePoint Security will continue to meticulously research vulnerability patterns in Android and iOS applications, as well as provide robust mobile security testing to customers to help prevent the consequences of a potential glitch.

lobotomy graphic

The flaws found within each respective application are different. Mobotap’s Dolphin Browser is customizable, allowing users to choose unique search bars or themes; it’s been found that the download and installation of a theme can result in exploitation or potentially full blown code execution. The Mercury browser was found to be susceptible to the arbitrary reading and writing of files in the browser’s data directory. While the teams at both Dolphin and Mercury have been made aware of the vulnerabilities and Dolphin has released an update, there’s an onus on the mobile security world to respond to the implications of having identified vulnerabilities in such commonly used browsers.

Mobile applications available today are often designed to solve some sort of user problem, but most have not been properly assessed for security issues, usually due to the aggressive quick-to-market philosophy used in the world of mobile application development. GuidePoint Security is investing continuous effort in researching mobile security and how potential vulnerabilities impact consumers at large. “We’re continuing to investigate Android web browsers and other largely consumed applications for vulnerabilities,” Watson said.

It’s imperative for organizations working on the development of mobile applications to understand the importance of testing. As made clear by Watson’s findings, common Android browsers and other applications used universally routinely have serious security vulnerabilities due to the lack of security input during their development lifecycle. GuidePoint is not only researching the implications of common vulnerability patterns in largely consumed Android and iOS mobile applications, but also offers services that help identify these problems before those applications are pushed to market.

Benjamin Watson, Mobile & Application Security Practice Lead – Ben Watson has over 7 dedicated years to application and mobile security. Prior to joining GuidePoint Security, Ben has solved application problems for cutting-edge companies in the financial services, ecommerce and medical industries. Ben has been frequently sought after for building application security programs from the ground up, due to his experience in not only developing testing methodologies, tools and techniques, but his understanding and perspective on what is required to build secure products. Ben has managed and lead efforts in large mobile application security managed services and is also an experienced mobile security researcher. He currently focuses his efforts around discovering new exploitable vulnerability patterns in Android and iOS. He also has multiple published zero day vulnerabilities effecting various Android web browsers, and is the creator and curator of an Android assessment toolkit called Lobotomy.

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: www.guidepointsecurity.com.

 

Lobotomy | The Android Assessment Toolkit

Through the years of assessing and reverse engineering Android applications, I consistently found a number of manual tasks overwhelmingly tedious and, at times, in desperate need of automation. I repeatedly found efficiency issues while working through my methodology for assessing Android applications, having to bounce from tool to tool in order to accomplish a specific goal. However, an idea that had been festering in the back of my mind for a while finally found its way into code, thus, Lobotomy was created.

Lobotomy, a new Android security toolkit, was developed to serve multiple purposes. The first objective was to build a framework that could easily be used to add in new features or functionality that would solve certain tasks when hacking up and reverse engineering Android applications. This was created on the notion that you will load once and work forever, meaning you can load your target Android application and work on the innards of that application through different modules without having to switch to other tools to perform operations on the same application. Another purpose of the framework was to become a wrapper for other well-known tools and their features sets.

Some of the tools Lobotomy provides wrappers for include:

• apktool
• bowser
• Dex2Jar
• Androguard
• Frida
• Adb

Perhaps the most important aspect of Lobotomy is its ability to find the important functionality and vulnerabilities within any target application quickly. There are many features that help motivate someone to look at the material that really matters. Whether that is an exported Broadcast Receiver, or the instrumentation of the Activity lifecycle, Lobotomy also helps minimize the amount of time spent looking at unnecessary components as well.

Features

Here are some of Lobotomy’s current features:

• APK loader
• APK Decompilation with apktool
• Conversion magic with Dex2Jar
• Attack surface enumeration
• Component enumeration
• Permission enumeration
• Permission to API mappings (BETA)
• Convert any APK into a debuggable APK
• APK Profiler
• Bowser | parseUri, loadUrl, addJavascriptInterface search and destroy
• Web services and frontend UI
• Logcat wrapper
• Frida implementation (BETA)
• SurgicalAPI | Find API usage for common vulnerabilities in targeted methods

Lobotomy is evolving as it continues to be developed by GuidePoint Security. We would love your help and input with the new features.

You can check out Lobotomy here:

https://github.com/guidepointsecurity/lobotomy

We will also be adding a Wiki to document all of the features and how to use them, as well as a list of new and upcoming features in the works for the tool.

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: www.guidepointsecurity.com.