[root@localhost:Active] config # b interface show
INTERFACE
Key     Speed    Pkts Pkts Drop Coll   Bits   Bits Errs Trunk
         Mbps      in  out               in    out
mgmt UP   100 FD  511    8    0    0 266144   5056    0

Solution

To resolve this define each interface as vmxnet3 by editing the .vmx file for the given Virtual Machine.

+ ethernet1.virtualDev = "vmxnet3"
+ ethernet2.virtualDev = "vmxnet3"

Once done ensure the the virtual machine is fully powered down (to ensure that the changes take effect). Once rebooted check the interfaces are now seen by the system and passing traffic.

[root@localhost:Active] config # b interface show
INTERFACE
Key     Speed    Pkts Pkts Drop Coll   Bits   Bits Errs Trunk
         Mbps      in  out               in    out
1.1  UP   100 FD 2340 2244    0    0 3.111M 12.65M    0
1.2  UP   100 FD  563   17    0    0 594264  10752    0
mgmt UP   100 FD  203   11    0    0 111928   8464    0 

Types of Monitoring

There 4 main types of monitoring:

• Address Check       - IP address (Node)
• Service Check        - IP : port
• Content Check        - IP : port & check data returned
• Interactive Check  - Interactive with servers. Multiple commands and multiple responses.

Address Check

This is the simplest type of check. An example of an address check is ICMP. This is used to ping an IP address and if there is no response within the specified time period the node is marked as down.

Service Check

Rather then just checking the IP Service Checks monitors the port. This is achieved by issuing a layer 4 connection to the node. The connection is opened and closed. If connection fails, the member is marked as as down and no traffic is distributed to the particular node.

Content Check

Content Checks check whether the server is also serving the correct content. Once the TCP connection is opened, a command is sent (such as a HTTP GET) and the response is examined and the connection closed. If the connection fails or the received string is not obtained the member is marked as down and no further connections are sent to the member.

Note : It is important that the receive string is not configured using a string that may be also used with any error pages (such as a 404 page), as this would prevent the monitor from correctly marking the the member as offline.

Interactive Check

Protocols such as FTP require interactive checks as additional commands such as username, password and directory are typically required.
Typically Interactive Checks consist of a TCP connection that is opened, command(s) are then sent, the responses examined and the connection closed.
If any condition fails the member is marked as down and no further connections are sent to the member.

Note : Most interactive checks are external monitors. External monitors external scripts (perl, shell etc) that the LTM calls to perform the required tests (and to aggregate the results).

Below describes the various interactive checks available:

Scripted Monitors - Scripted Monitors use the Expect method/"model" (send/expect) to determine a nodes health. Expect is a UNIX binary that sends a command and then expects are specific response back.
External Monitors - External Monitors are custom shell scripts that can be created to determine the health of a node.
Performance Monitors - As the name suggests Performance monitors deem the nodes health by querying the nodes performance. There are a number of methods in which this can be achieved. These are :
   - Dynamic Ratio LoadBalancing - Dynamic Ratio Load-Balancing queries the given agent on either a RealNetwork RealServer, WMI or SNMP based platform to determine a ratio value. This ratio value is then dynamically assigned to the node.
   - SNMP DCA - SNMP DCA determines performance via the data collected from the nodes SNMP agent.
   - SNMP DCA Base - SNMP DCA determines performance via only the user-data collected from the nodes SNMP agent.
   - WMI - WMI determines performance via the data collected from the nodes WMI agent.

Inband Passive Monitor - Rather than issue a connection to the server to determine its health, Inband Passive Monitors determine the health of the node by the monitoring of actual traffic being sent to and from the node. The main benefit of this monitor is that it requires little system resource. 

Creating Custom Monitors

Below shows the steps required to create a custom monitor:

1. Go to 'Local Traffic | Monitors | Create'.
2. Add the Name and select a template from the Type drop down menu.
3. Then define the Interval and Timeout.

Note :

Interval - Interval between checks.
Timeout - Defines how long F5 should wait before marking a node/member as down.
Recommended Setting - Timeout = (3 x Interval) + 1 sec.

Associating a Monitor

Nodes

To assign a monitor :

1. Default : Go to 'Local Traffic | Nodes | Default Monitor' then define the active health monitor.
2. Single Node : To set a monitor to one node go to 'Local Traffic | Nodes | Node List' and select the node. Then from the Health Monitor drop down select the monitor.

Pool

To assign a monitor to a pool.

1. Go to 'Local Traffic | Pools' and select the pool.
2. Within the configuration screen select the Health Monitor.

Pool Member

1. Go to 'Traffic | Pools' and select the Pool.
2. Then select the individual member.
3. Within the Configuration screen select Advanced.
4. Under Health Monitor select Member Specific and then select the necessary monitor.

Status due to monitors

Types

There are 4 main status types (with regards to monitors). These are :

• Up / Available - Means the most recent monitor check was successful.
• Down / Offline - Means no response equal to the configured timeout period.
• Unknown - Typically means no monitor is assigned nor the monitor has yet to return a result.
• Connection Limit / Unavailable - Previously defined connection limit has been reached. In turn no traffic is sent.

Inheritance

The status of each monitor is inherited from its children.
If a node is marked offline, then the member is marked offline. As long as there are other members still online in the pool the Pool would still be marked as up.

When trying to access your Django site within CSRF configured you receive the following via a Forbidden (403) HTTP error message:

CSRF verification failed. Request aborted.

Reason given for failure:

No CSRF or session cookie.

Solution

In my scenario I found that the order of settings.MIDDLEWARE_CLASSES was incorrect. Below shows you an example

settings.py

MIDDLEWARE_CLASSES = (
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
)

views.py

from django.shortcuts import render_to_response
from django.template import RequestContext

def input(request):
    return render_to_response('input.html', context_instance=RequestContext(request))

def output(request):
    if 'q' in request.POST:
        message = request.POST['q']
    else:
        message = 'error'
    return render_to_response('output.html', {'message': message}, context_instance=RequestContext(request))

template

<html>
 <body>

  <form action="/output/" method="POST">
  {% csrf_token %}
    <input type="text" name="q">
    <input type="submit" value="input">
  </form>

 </body>
</html>

Security Levels

Security levels are numeric values (between 0 and 100) which are assigned to the firewalls interfaces and used to control traffic flows. Traffic is allowed to pass from a higher security level to a lower security level but not vice-versa. To allow traffic from a lower security level to a higher security level an access-list is required. By default the security level for the outside interface is 0 and the inside interface 100.
Below provides an example on how to explicitly configure an interface security level.

asa(config)# interface eth2
asa(config-if)# nameif dmz
asa(config-if)# security-level 50

NAT Control

NAT Control mandates that any traffic transversing from a higher security level to a lower security level must match a NAT rule.
Belows provides an example on how to disable NAT Control

asa(config)# no nat-control

The OneConnect feature works with HTTP Keep-Alives to minimize the number of server-side TCP connections by reusing existing connections for further HTTP requests.
“OneConnect” has 2 methods. They are : OneConnect Profile and OneConnect transformations. Both of which are explained within this article.

HTTP Requests Overview

HTTP/1.1 requests - HTTP/1.1 dictates that HTTP Keep-Alive connections are enabled by default. With HTTP/1.1 the server doesn't close the connection once the initial request has been completed unless the client issues a ‘Connection: close header’ to the server. Otherwise the connection remains open so that the client can reuse the connection for any additional requests.
HTTP/1.0 requests - HTTP/1.0 does not dictate that HTTP Keep-Alive connections are enabled by default. With HTTP/1.0 the client issues a ‘Connection: close header’ to the server to ensure the connection is closed once the request is complete.

OneConnect Profile

‘The OneConnect Profile’ reuses idle server-side connections so that they can be used for further requests. If the connection is not idle then a new server-side TCP connection is made.
As idle connections are re-used it may appear that traffic is being unevenly balanced.
To enable the OneConnect Profile the necessary profile is selected within the ’Configuration / OneConnect Profile’ section of the Virtual Server.

OneConnect Transformations

‘OneConnect Transformation’ transforms the ‘Connection: close’ headers in HTTP/1.0 client-side requests to ‘X-Cnection: close’ headers on the server side. This ensures that the server does not close the connection once the request is completed, therefore allowing the server to reuse existing connections for additional requests when using HTTP/1.0.
OneConnect Transformations are enabled from within the HTTP profile.

Miscellaneous

HTTP Pipelining

HTTP pipelining is a feature of HTTP 1.1 that's allows multiple requests to be sent via single connection without waiting for each response.
OneConnect does not support Pipelining as each request must be initiated after the response from the previous requests have been received. 
Further details can be found at : http://support.f5.com/kb/en-us/solutions/public/7000/200/sol7208.html

Adaptive reapers provide the ability for the system to automatically clear connections at the point of a predefined threshold being reached. This provides both system and connection stability during the point of a Denial of Service attack.
At the point memory usage reaches the low water mark threshold (default %85) all half open connections are dropped.
If the memory usage is still in excess of the low water mark, connections that have a long idle period are dropped.
Finally if the high water mark is reached (95%) then no new connections are permitted until the memory usage reaches the low water mark.

SYN Check

To alleviate the effects of a SYN Flood attack the BIG-IP provides a feature called SYN Check. SYN Check works by recording the ISN (initial sequence number) from the embryonic connection. This embryonic connection is then removed from the SYN queue.
When the remainder of the connection is received BIG-IP rebuilds the connection entry using the previously recorded ISN data.

Configuration

To configure both Adaptive Reapers and SYN Check go to ‘System / Configuration /  Device / General / Local Traffic’ from within the Web UI'.

Unable to attach to PCI device 02:02.00 for Interface 1.1

This results in both interfaces forming the status of un-initialized and in turn failing to pass traffic.

Solution

To resolve this define each interface as e1000 by editing the .vmx file for the given Virtual Machine.

+ ethernet1.virtualDev = "e1000"
+ ethernet2.virtualDev = "e1000"

Once done ensure the the virtual machine is fully powered down (to ensure that the changes take effect). Once rebooted check the interfaces to ensure that they are now showing a status of initialized and passing traffic.

[root@F5-UNIT1:Active] config # b interface show
INTERFACE
Key     Speed    Pkts Pkts Drop Coll   Bits   Bits Errs Trunk
         Mbps      in  out               in    out
1.1  UP   100 FD 2340 2244    0    0 3.111M 12.65M    0
1.2  UP   100 FD  563   17    0    0 594264  10752    0
mgmt UP   100 FD  203   11    0    0 111928   8464    0

The main purpose of this document is to explain the PKI term ‘Chain of Trust’.

Summary

PKI (Public Key Infrastructure) is a framework built upon protocols, services and standards used to provide authentication, confidentiality, integrity, non-reproduction and access control to digital data.
The term ‘Chain of Trust’ is used to describe the trust relationship between identities when using Subordinate (intermediate) CA`s. The key benefit to this is to allow the delegation of certificates by Subordinate CA`s.

Components

To provide a ‘Chain of Trust’ a number of components are needed. They are:

CA (Certificate Authority) - A Certificate Authority is an authority that issues public key certificates and provides identification to the bearer.
Subordinate CA (Certificate Authority) - A Subordinate CA is a certificate authority (CA) that is at a level beneath the root CA.
Certificates - A digital certificate provides authenticity to a users or clients identity. A digital certificate contains a number of details relating to the client such as address, DN, email address etc. Each digital certificate is issued (and signed) by a CA (Certificate Authority) and is only valid for a specific period of time.
Key Pairs - A key pair consists of a public and private key. Any data that is encrypted with the public key can be decrypted with the private key and vice-versa. The public key can be provided to anyone who requests it and is typically formed as part of the public certificate. The private key (as the name suggests) is keep private and not shared.
Digital Signatures - A digital signature is generated by the hashing of a digital certificate. The hash is then encrypted using the CA`s private key. This encrypted md5 string is then appended to the public certificate as a digital signature.
As only the CA`s public key can decrypt the digital signature, authenticity is  provided to the users public certificate.
CSR - Though this is not directly considered a component within a ‘Chain of Trust’ its explanation is still beneficial due to its place within the certificate signing process. A Certificate Signing Request (CSR) is a base-64 encoded (PEM based) string which is generated using the users public key along with a number of attributes provided by the user such as DN, email, address etc. The CSR is then sent to the CA which it then uses to create a public certificate. The public certificate is then signed and sent back to the user. The benefit in using a CSR is that the private key never leaves the client.

Hierarchy

The over arching ‘Chain of Trust’ hierarchy lies within the trust relationships between each identity.
This can be seen within the diagram below.

Signing

During the signing process the Root CA digitally signs the intermediate certificate using its private key. This provide authenticity that the intermediate certificate is trusted by the Root CA.
Next the Sub CA (intermediate CA) signs the identity Certificate using its private key. This provides authenticity that the intermediate certificate is trusted by the Root CA.

Example

Using a typical scenario of a user connecting to an SSL web-page, we will walk through the steps required to provide a ‘Chain of Trust’.

1. The client wants to view an SSL website. For this he will use a web browser. By default each browser is preloaded with a number Root CA (public) certificates.
2. The client connects to the SSL website.
3. The website responds with the Identity and Intermediate certificates.
4. The client confirms authenticity of the Intermediate certificate by decrypting the digital signature using the Root CA`s public key.
5. Next the client confirms the authenticity of the identity certificate by decrypting the digital signature using the intermediates public key.
6. The client then clarifies that the URL that is being requested by matching the DN (Distinguished Name) within the Identity Certificate. If this does not match the browser displays a warning.
7. Traffic is then encrypted/decrypted by a) the 'client' using the public key b) the 'server' using the private key.

1. Layer 3

To Load-balance either Passive and Active FTP Layer 3 persistence is configured.
Below shows the required commands :

Commands

• port ftp concurrent  – Sticky and Concurrent ensures that Active and Passive FTP will work
• port ftp sticky – Sticky ensures that Active FTP will work

Note : The Round Robin predictor is configured as this provides the best level of equal distribution for FTP traffic.

Example

server virtual VIP-XX.XX.XX.1-FTP 192.168.100.1
 predictor round robin
 port ftp
 port ftp concurrent 
 port ftp sticky     
 bind ftp REALSERVER1 ftp
 bind ftp REALSERVER2 ftp

2. Layer 4-7

From version 12.3.1d (onwards) the ADX is able to inspect FTP traffic using the upper layers of the OSI stack (layers 4-7). Because of this the configuration of sticky and concurrent connections are no longer required.
Below details the required commands to balance both Active or Passive FTP.

Commands

• server ftp-pasv-concurrent – This command ensure that unique control connections are load balanced to different servers. Data connections from the client are associated to the correct Control connection by the inspection of the PORT command from within the FTP traffic stream.
• server no-reset-for-established-session – By default, the ADX sends a RST to the client if the FTP port fails on the server. If required this can be disabled.

Example

server ftp-pasv-concurrent
server no-reset-for-established-session

server virtual VIP-XX.XX.XX.1-FTP 192.168.100.1
 port ftp
 bind ftp REALSERVER1 ftp REALSERVER2 ftp

1. Transfer Image

1. Create a directory '[root@f5:Active] config # mkdir /shared/images'
2. Copy the iso image to the directory '/shared/images' using scp.
3. Move to the directory '[root@f5:Active] config # cd /shared/images'

2. Version Upgrade

Below shows you the commands required for a version 10 installation. Within this example the image will be installed onto slot HD1.2 (and made the default boot image) with a default config.

image2disk --instslot=HD1.2 --nosaveconfig --setdefault [software image].iso

3. Hotfix Installation

Below shows you the commands required to install a hotfix. Within this example the hotfix will be installed on the image in HD1.2. 

image2disk --instslot=HD1.2 --hotfix [hotfix image].iso

Installation via GUI

To install or upgrade the software version via the web interface goto 'System / Software Management'. This will also give you the option to import the software package rather then having to scp it across as described in the previous steps.