WirelessPhreak.com

 

So the F5 is a tricky beast often refereed to as the swiss army knife of network appliances. The appliances primary role in many networks is to load balance and is a beast negotiating SSL. That being said its not always easy to determine how to configure the clients SSL profiles to be secure and still service the public. F5s documentation is helpful but designed to be vague because cipher suites and browser support is always changing. https://support.f5.com/csp/article/K8802

 

SSL Labs has become the de-facto to use tool that helps the public understand the nuances of SSL by giving an easy to understand letter grade, https://www.ssllabs.com . The website runs a multitude of tests from insuring your certificate is chained correctly to end device OS and browser simulations, to commonly found vulnerability testing. The down fall of having such a sophisticated tool issuing a simple letter score, is not every environment can be configured for an A or B plus.

 

So I wanted to through an F5 Client SSL Profile out there that at the time of testing got a solid A- and still supported a ton of OS and browser combinations. You will mostly want to keep the defaults but I will highlight what changes you will want to make to get an A. You will need to select Advanced to see some of these settings.

• The first step is to add your public certificate and the intermediate certificates if applicable as well as the key.
•  this is what create the certificates chain

• Next you will want to customize the Ciphers that will be used by the F5 to negotiate SSL with the client. This is where 99% of the magic will happen.
• DEFAULT:HIGH: (are pre canned cipher settings created by F5, the additional settings are additional customization.
  
• !RSA: Do not use RSA ciphers
  
• !SSLV3: Do not use SSL version 3
  
• !RC4: Do not use RC4 ciphers
  
• !EXP: Do not use Cipher length of 40 or 56 bits export strength
• !DES: Do not use Des or triple Des ciphers
  
• !TLSv1_1: Do not use TLS version 1.1
  
• !TLSv1: Do not use TlS version 1.0
  
• !ADH: Do not use ADH ciphers
• !EXPORT: Do not use EXPORT grade (weak) ciphers
• !SHA: Do not use Message Authentication Code SHA 128
  

• The complete string looks like this:
• DEFAULT:HIGH:!RSA:!SSLV3:!RC4:!EXP:!DES:!TLSv1_1:!TLSv1:!ADH:!EXPORT:!SHA

• Lastly you will want to set up strict SSL renegotiation:
• Check the  Renegotiation box
• Next set Secure Renegotiation to "Require Strict"

 

From here save your SSL client profile, apply it to a public accessible virtual server, and run SSL labs against your server. Its kind of fun testing and playing around to see what modifying the cipher settings.

 

Enjoy. 

Test your HTTP keep alive from the F5 CLI:
Using curl:
     curl -vvv -H "Host: domain.com" -H "Connection: Close" -H "User-Agent:" -H "Accept:" serverip:port/uripath.html
Using Telnet:
telnet serverip port
Then copy the first half of your keep alive
     GET /uripath.html

From the above listed commands you should see exactly what the F5 is receiving  when it sends a keep alive.  From the returned http request you can determine the best data to use for a receive string.

• Your F5 LTM and or ASM are logging HSL (high-speed logging) to Splunk. (ASM is not a requirement)
• Configure an HSL pool that includes the Splunk logging servers.
• Configure the newest iRule on your F5 for logging to Splunk.
• Associate the new logging iRule with virtual servers you want to monitor. 
• Lastly set up an ASM logging profile to sending to Splunk. 

 https://docs.splunk.com/Documentation/AddOns/released/F5BIGIP/Setup

Once that is complete you can create a new dashboard in Splunk. Then copy and paste the dashboard source code I have uploaded on my GitHub repository. Once you save the dashboard you should be able to type in the URL of the application you want to monitor, the corresponding F5 pool name and the time frame you are interested in.

GitHub link:
 https://github.com/wirelessphreak/F5-Dashboard-for-Splunk

If you have improvements or comments please let me know. This is a work in progress and I am always looking to make it better.

Two cool new exploits have been released complete with cool names and graphics. Welcome Meltdown and Spectre, these critical vulnerabilities exploit pretty much all modern processors. Even though these hardware vulnerabilities have been around forever, four independent groups of researchers discovered these vulnerabilities simultaneously. Meltdown and Spectre at a high level allow programs to steal data which is currently processed on the computer. While programs are typically not permitted to read data from other programs, a malicious program can exploit Meltdown and Spectre to get hold of secrets stored in the memory of other running programs.

Meltdown and Spectre work on personal computers, mobile devices, and in the cloud. But what about our network and security equipment using modern processors, are they vulnerable? Below is a list I put together of links to vendors sites and their responses to the vulnerabilities. I imagine most of them will keep these pages up to date as they discover new information. This is a complicated and low level issue so most vendors are going to need time to really evaluate their products and create patches.

Luckily in most cases it is an attack that is performed through the management access, so if you follow the best practice of limiting device management access from only trusted IPs or networks you should be good until the patches are released.

 PaloAlto Networks

"Our initial review of the vulnerabilities disclosed in the research concludes that all PAN-OS/Panorama platforms are not directly impacted by these attacks. There are no immediate plans to release a software update to PAN-OS in response to these issues at this time"

F5

"Impact
For products with None in the Versions known to be vulnerable column, there is no impact. For products with ** in the various columns, F5 is still researching the issue and will update this article after confirming the required information. F5 Technical Support has no additional information about this issue.

 BIG-IP
All three vulnerabilities require an attacker capable of providing and running binary code of their choosing on the BIG-IP platform. This raises a high bar for attackers attempting to target BIG-IP systems over a network and would require an additional, un-patched, user-space remote code execution vulnerability to exploit these new issues. The only administrative roles on a BIG-IP system that can execute binary code or exploitable analogs, such as JavaScript, are the Administrator and Resource Administrator roles. These users already have nearly complete access to the system and all secrets on the system not protected by hardware-based encryption. F5 believes that the attack with the highest impact may occur in multi-tenancy Virtual Clustered Multiprocessing (vCMP) configurations, running single-core guests owned by different administrative domains on a single BIG-IP system. In this scenario, Spectre Variant 2 may allow an attacker in one administrative domain to collect privileged information from the host or guests owned by another administrative domain, if the attacker's guest is configured as a single-core guest. The BIG-IP system always maps both hyper-threads of a given core to any guest with the "Cores Per Guest" configuration set to 2 or more, but single-core guests may execute on the same processor core as another single-core guest or host code. This threat may be mitigated by setting the "Cores Per Guest" configuration to 2 or more for all guests."

 Cisco

"Cisco is investigating its product line to determine which products may be affected by these vulnerabilities. As the investigation progresses, Cisco will update this advisory with information about affected products, including the Cisco bug ID for each affected product."

 Juniper

"Juniper SIRT is actively investigating the impact on Juniper Networks products and services.”

Brocade

 

Citrix/Netscaler

"Citrix NetScaler SDX: Citrix believes that currently supported versions of Citrix NetScaler SDX are not at risk from malicious network traffic. However, in light of these issues, Citrix strongly recommends that customers only deploy NetScaler instances on Citrix NetScaler SDX where the NetScaler admins are trusted."

Most of the people who have found this post on the internet are already familiar with Palo Alto Firewalls and everything they can do. One of the features I really like is the IPS functionality built into the firewall, but - and its a BIG BUT - if you're terminating SSL after the traffic ingresses your untrusted security zone you're loosing a lot of the PAN's IPS functionality because the traffic is encrypted.

1. The firewall looks to see if the packet is allowed by the security policy.
2. The firewall identifies the traffic as SSL
3. The firewall looks to see if the destination is configured with a SSL decryption policy
4. If the destination address matches a protected IP address, it is decrypted and processed through the security policies once again as web-browsing still on port 443. 
5. Bang! Connection is broken.

With HTML5 and other modern web technologies IE has not aged gracefully. If your client base is an enterprise many times clients are locked into an older version of IE, and aren't allowed to install an auto-updating browser like Chrome or Firefox.

This iRule is strait forward, I am redirecting clients accessing a website using an older versions of IE to a browser friendly version. This is done by evaluating the HTTP request and identifying the browsers user-agent string. As part of the redirect the F5 presents a web page that informs the users their browser is unsupported instead of blindly redirecting them. It will auto redirect after a pre determined count down, this example is set for 15 seconds.

Disclaimer Microsoft does not make this easy, Compatibility modes and Document modes in IE can send a different user-agent string.  For example IE 11 users running in Compatibility mode may still be redirected because their browser sends an MSIE 7.0 user-agent string. I am sure your could right variables that would check for compatibility in the user agent string, but iI chose not to.

Here is the iRule:

when RULE_INIT {
    set static::refresh_time 15
set static::notification_page {
        <html lang=\"en_US\">
<head><title>System Notification</title>
<meta http-equiv=\"Content-Type\" content=\"text/html; charset=us-ascii\">
<meta http-equiv=\"CACHE-CONTROL\" content=\"NO-CACHE\">
<meta http-equiv=\"PRAGMA\" content=\"NO-CACHE\">
<meta http-equiv=\"refresh\" content=\"15;URL=http://myspace.com">
</head>
<body>
<h1>System Notification</h1>
<hr>
<p>You are using an unsupported browser and will be redirected to Myspace.com</p>
<p>Wait $static::refresh_time seconds to continue, or click <a href=\"http://myspace.com\">here to continue.</a></p>
</body>
</html>
}
}
when HTTP_REQUEST {
 switch -glob [ string tolower [HTTP::header User-Agent]] {
   "*msie 10.0*" -
   "*msie 9.0*" -
   "*msie 8.0*" -
   "*msie 7.0*" -
   "*msie 6.*" {
     HTTP::respond 200 content [subst $static::notification_page] Mime-Type "text/html"
     log local0. "Client  IP:[IP::client_addr]  has been redirected with user agent :[HTTP::header User-Agent]"
   }
   default {
     # go to a default location if nothing matches
   }
 }
}

If your familiar with F5 you understand the need for a quick and dirty virtual lab on your lap top.  From testing code upgrades to writing and testing iRules you'll quickly learn how important a lab is.

To get started your going to need a few pieces that will make up your virtual lab.  Most of the following will work on a Mac or PC, but I am running a mac, so i apologize in advance if some of the configuration is different.

Software needed:

• F5 LTM Software: virtual lab edition is $99 you can also ask your F5 sales team for a trial lisc.
• Hypervisor: I am using VMWare Fusion
• Virtual Router: Vyatta (Brocade bought them but you can still find the open project iso.)
• Servers: Use what you feel comfortable with.

Step 4) Install and configure your Vyatta virtual router.  This will allow your PC to communicate with all of the networks as well as bridge the server network to the internet for updates and package installs.  Here is a great guide I found for vyatta commands.

Step 5)  Install and configure your servers configuring their nice to participate in the server VLAN.

Step 6) Build a Virtual server on the F5 using an IP address on the client network, and your pool member that exists in the server network.

You should be up and running and able to play with the F5.

# Geo-IP_Network_Whitelist_acl_rule
#
# v2.0 - May 9 2014
#
# BIG-IP versions 11.x (tested on 11.3.8)
#
# Purpose:
#   This rule should be added to a network virtual server to catch all requests
#   which  don't match an allowed GeoIP country code or IP network/host.  This
#   creates a white list of networks and hosts that are allowed to connect to
#   the virtual server. By default, log entries are written to /var/log/ltm.
#
#   The rule expects the following two data groups to define which allowed country
#   codes (example: ca, us), or defined allowed networks (example: 10.0.0.0/8)
#   are allowed to connect to the virtual server.
#
#   Clients that match on either the Network or GeoIP data group will be allowed
#   to connect to the default pool. Clients that do not match will be rejected and
#   see a web page not available.
#
#   The data group names should be:
#
#   geo_allowed_country (string Data Group List)
#   geo_allowed_network (network Data Group List)
#
#
#
#
# This event is triggered when a client - BIG-IP TCP connection is established
when CLIENT_ACCEPTED {
 if { [class match [whereis [IP::client_addr] country] equals geo_allowed_country] } {
    # do nothing
         log local0. "Geo-IP Code accepted from client: \
         [IP::client_addr]:[TCP::client_port] -> [IP::local_addr]:[TCP::local_port]"
 } elseif { [class match [IP::client_addr] equals geo_allowed_network] } {
    # do nothing
         log local0. "Network accepted from client: \
         [IP::client_addr]:[TCP::client_port] -> [IP::local_addr]:[TCP::local_port]"
  } else {
  reject
  log local0. "Client request rejected: \
         [IP::client_addr]:[TCP::client_port] -> [IP::local_addr]:[TCP::local_port]"
 }
}

*Update* Cisco has posted their Security Advisory for the Heartbeat vulnerability http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140409-heartbleed

It is curious to see how different company choose to incorporate and document opensource software in their products. But that is a different rant for a different time.

Today is the day engineers around the world hit the internet looking through pages and pages of documentation.  I have done some research and wanted to add what I found to hopefully shorten someones search.

Cisco ASA 8.4 code is running openssl 0.9.8f Safe

•  (http://www.cisco.com/c/en/us/td/docs/security/asa/asa84/license/open_source/opensrce.pdf)

F5 LTM 11.3, and 11.4 are running openssl 0.9.8y Safe

• To view for your self SSH to your LTM log in as root and run "openssl version"

F5 LTM 11.5 is running openssl 1.0.1e-fips Vulnerable

• SANS ISC
• HeartBleed.com
• F5 HeartBleed Forum Post

when RULE_INIT {
# This is the max requests allowed during "interval" specified below.
set static::maxRate 125;
# Below is the lifetime of the subtable record in seconds.
# This defines the interval during which requests are tallied. Example: Rate=10 and Timeout=3, allows 10 requests in 3 seconds
# Note: do not use very high timeout because it increases memory utilization especially under high load.
# Note: A rate of 100 in 50 seconds is the same is a rate of 20 in 1 second. But 1 second is a lot easier on memory,
# Because the records expire more quickly and the table does become too large.
set static::timeout 3;}
when HTTP_REQUEST {
set getCount [table lookup -notouch -subtable requests [IP::client_addr]]
    if { $getCount equals "" } {
       # log local0. "New one:  getCount=$getCount [IP::client_addr] [clock seconds]"
       table set -subtable requests [IP::client_addr] "1" $static::timeout $static::timeout
       } else {
    if { $getCount < $static::maxRate } {
       table incr -notouch -subtable requests [IP::client_addr]
       } else {
    if {$getCount == $static::maxRate } {
       log local0. "User @ [IP::client_addr] [clock seconds] has reached $getCount requests in $static::timeout seconds."
       table incr -notouch -subtable requests [IP::client_addr]
       }
   HTTP::respond 501 content "We apologize but your request/sec limit has exceeded the set threshold.  Please wait 30 seconds and refresh the page."
   #drop
   #return

Update coming soon a more advanced irule that accounts for rfc1918 ip space as well as data groups that allow multiple geoip country codes.

This iRule will allow you to block requests to your website from IP address that are not from the US. GeoIP blocking is flexible and a way of white listing traffic to your servers.  It does have it's limitations though.

GeoIP Databases change all the time.  To keep the F5   GeoIP database up to date wouldn't be practical.

Some may consider this a security measure. But to limit IP traffic from a limited geographic area is not an affective security measure. Real bad guys will proxy or use un willing victims to carry out their attacks.

when CLIENT_ACCEPTED {
if {not ([whereis [IP::client_addr] country] eq "US")}{
reject
}
}