ChangeLog - Vesion 0.1 - 2013-06-07 This is the initial release of a Stingray Traffic Manager template for Cacti. I have been working on this for the past few days, but be warned that I am a complete Cacti n00b and so this may well be as useful as a chocolate teapot. However I unashamedly release it into the community, in the hope that (with your help) this template will grow and mature into something quite useful!   Watch out for the bugs! ... View more

There are two common methods of Authentication built into the HTTP Protocol: Basic and Digest. They both work by using the "WWW-Authenticate" server response header, and the "Authorization" client request header. The simpler and more common of the two is the Basic method. This simply encodes the username and password with Base64 encoding and submits it to the server in the Authorization header. By contrast the Digest method is far more secure and works without sending the username and password over the network. Instead the client is sent a nonce challenge by the server, which it must then hash with the password and other data to generate an authentication response. The hash is put in the Authorization header along with other data and sent back to the server. If the server calculates the same response value as the client did (by using information in the header, and the username and password), then the authentication is successful.   Fortunately (??) Digest Authentication is open to a Man-In-The-Middle attack if you control a proxy through which the client and server communicate. So should you find yourself in a situation where you need to convert authentication schemes, because your server will only accept Digest authentication, but  your client only knows how to do Basic, then Stingray can help!   The below rule will convert a Server request for Digest authentication into a request for Basic authentication. It will then convert a Basic authentication request from the client into a Digest authentication request to the server. The rule has been tested to work with Apaches auth_digest module, which uses a QOP of auth. Your mileage may vary with other Digest implementations.   sub parseResponse() { # Return if the response is not a 401 $code = http.getResponseCode(); if ( $code != 401 ) return; # Return if the auth is not Digest $authHeader = http.getResponseHeader("WWW-Authenticate"); if ( ! string.contains($authHeader, "Digest") ) return; # Parse the header... $auth = parseDigestHeader($authHeader); # We only support "auth", if it's not an option, log a warning... if ( ! string.contains($auth["qop"], "auth") ) log.warn("Rule only supports \"auth\". Server QOP options: " . $auth["qop"] ); return; } http.setResponseCookie("digest", string.base64encode($authHeader)); http.setResponseHeader("WWW-Authenticate", "Basic realm=" . $auth["realm"] ); } sub parseRequest() { # We only support Basic Auth conversion, return if this isn't one $authHeader = http.getHeader("Authorization"); if ( ! string.contains($authHeader, "Basic") ) return; # Decode the user and password $enc = string.skip($authHeader, 6); $user = string.split(string.base64decode( $enc ), ":"); # Get digest information from cookie or return $digest = string.base64decode(http.getCookie("digest")); if ( ! $digest ) return; # Parse the decoded cookie digest $auth = parseDigestHeader($digest); $digest = generateDigest($user, $auth); http.setHeader("Authorization", $digest ); } sub parseDigestHeader($header) { foreach ( $param in string.split( string.skip($header, 7), ",") ) { $param = string.trim($param); if ( string.regexmatch($param, "([^=]*)=\"(.*?)\"") ) { $auth[ $1 ] = $2; } } return $auth; } sub generateDigest($user, $auth) { $uri = http.getPath(); $method = http.getMethod(); $nc = 1; $now = sys.time(); $ha1 = string.lowercase(string.hexencode(string.hashMD5( $user[0] . ":" . $auth["realm"] . ":" . $user[1] ))); $ha2 = string.lowercase(string.hexencode(string.hashMD5( $method . ":" . $uri ))); $cnonce = string.lowercase(string.hexencode(string.hashMD5( request.getRemoteIP() . $now ))); $digest = $ha1 .":". $auth["nonce"] .":". string.sprintf("%08d", $nc) .":". $cnonce .":auth:". $ha2; $digest = string.lowercase(string.hexencode(string.hashMD5($digest))); $header = "Digest username=\"" . $user[0] . "\", realm=\"" . $auth["realm"] . "\", nonce=\"" . $auth["nonce"] . "\", uri=\"" . $uri . "\", response=\"" . $digest . "\"" . ", cnonce=\"" . $cnonce . "\", qop=auth, nc=" . string.sprintf("%08d", $nc) . ", algorithm=MD5"; return $header; } if ( rule.getstate() == "REQUEST" ) { parseRequest(); } else { parseResponse(); }   The rule should be applied to the Virtual Server as both a Request and a Response rule. It will automatically intercept any requests for Digest authentication from the server and convert them to/from Basic authentication.   Enjoy! ... View more

Stingray Traffic Manager is a pure software ADC , and as such has the ultimate flexibility of being able to migrate effortlessly between physical, virtual and cloud environments. Recently I have been taking a look at how easy it is to install and run Stingray within the Dimension Data (OpSource) cloud platform.   Clustering I’m running a HA pair of Stingrays (version 9.1) in OpSource without any problems. However I needed to switch the cluster communications method from multicast to unicast. Creating a new HA cluster should work fine for version 9.2 and beyond, because the default method is now unicast.   Traffic IP Groups Creating a Traffic IP group is simple enough and works as expected. Fail over works great too, so creating always available HA services in OpSource Cloud is straight forward.   Once you have created your TIP Group, you will need to set up an additional NAT rule in the Cloud settings. I tested failing over a TIP in a cluster while connecting through the public NAT address and it did so without any noticeable interruption in service. That's a big tick in the HA box from me.   Auto-Scaling I created an auto-scaling driver for OpSource and ran some tests using a simple Magento e-commerce demo site. The driver and installation instructions can be found here: Dimension Data (OpSource) Auto-Scaling Driver   So I created a Traffic IP Group, Virtual server, and Auto-Scaled Pool for magento. The auto-scaling system had its minimum nodes set to 1, so I always had at least 1 node available in my pool. To test the driver I generated a little load and watched for the auto-scaler to kick in and start provisioning a new node for me. My hysteresis value was 20 seconds, so the high load had to be sustained for 20 seconds before the Auto-Scaler would do anything. This is used to stop brief spikes causing unnecessary scaling actions. Soon a new node provisioning action was instigated, and OpSource began deploying my node. Once the node had been cloned and booted, the Auto-Scaler updated the pool and Stingray was load balancing across an additional node. I left the load generator running a little too long and ended up with three nodes in my pool. However that’s not a problem, because Stingray soon scaled back down to 1 node once the load stopped.   The OpSource Driver is a little unusual in that I have given it an additional “destroy” flag which determines what the driver should do on a scale down action.   I would recommend setting the destroy flag in the Auto-Scaler configuration to “false”. So rather than destroy the nodes, the driver simply powered them off. This will make for much quicker scale up actions for nodes which have been used previously.   The next time I needed to scale up the pool, the provisioning time was in seconds (for a simple power on), rather than then several minutes it can take for a full clone.   MSM and Global Load Balancing I haven’t played with either MSM or GLB in the OpSource cloud yet, but I see no reason why there should be any difficulty in doing so. Running a globally load balanced service in multiple OpSource Cloud regions should be relatively simply. If you make use of Stingrays Geo Load Balancing feature then you can ensure your clients are always serviced by their closest OpSource Cloud location. ... View more

Overview Traffic Manager is capable of managing node deployment automatically; it can scale up and down the number of nodes in a service pool by monitoring the response times of the nodes themselves. Traffic Manager will scale the pool depending on the number of requests (percentage) in compliance with a pre-set response time. When the compliance falls below the configured scale_up level for a sustained period, Traffic Manager will initiate node provisioning. When the compliance rises above the scale_down level for a sustained period, Traffic Manager will initiate de-provisioning. An upper and lower limit can be set on the number of nodes in service.   For More Information See Feature Brief: Traffic Manager's Autoscaling capability   This AutoScaling driver for OpSource provides an interface for managing node deployment within OpSource clouds using the OpSource RESTful API. This document will describe the steps necessary to install the driver onto a Traffic Manager, and configure an AutoScaled pool for use in the OpSource Cloud.   AutoScaling Driver Requirements The OpSource driver is written in Python and so will require that you have python installed and available in your Linux VM. You will also need to install the “requests” and “elementtree”. Both of these modules can be installed with easy_install if they’re not available in your Linux distro directly. Try installing “python-setuptools” to get access to easy_install, and then “easy_install requests”.   Installing the driver We will take it for granted that you have already deployed a Linux VM within the OpSource cloud and installed the Traffic Manager software. To install the driver, you will need to log in to the Stingray web UI and upload “DiData.OpSource.py” script to Catalogs -> Extra Files -> Miscellaneous. Do not forget to check the “Executable” box when you upload it.   Configuring the driver options The driver uses an additional configuration file to hold OpSource specific configuration. The settings and their values should be entered into a text file, as space/tab separated key/value pairs and then uploaded alongside the AutoScaling driver in extra files. In the screen shot above you can see my configuration is in a file called “DD-US-Cloud.cfg”. The configuration file will need to contain the following settings: user, apiHost, orgID, destroy, vlanID. The user should be a user within your organisation that has full permissions to manage nodes in the VLAN in which you intend to deploy nodes. The apiHost should be set to the FQDN of the API server for the region you are using. The orgID should be set to the organisation ID as displayed in the Account tab of the OpSource admin interface. The destroy flag should be set to “true” or “false” and indicates whether the driver should either destroy nodes or simply power them off. Obviously scaling up a node which is powered off is much faster than creating a new one from scratch. The vlanID should be set to the ID of the cloud into which the nodes are being deployed. This ID is displayed when you expand a cloud section under the “Clouds” tab of the OpSource UI.   Creating the Cloud Credentials The final step before your driver is ready for use in an Auto Scaled pool is to create a set of Cloud Credentials. A “Cloud Credential” is a configuration object which links the driver with its configuration options. In the Traffic Manager UI you must navigate to Catalogs -> Cloud Credentials and create a new set of credentials for your OpSource cloud. The first field in the CC configuration is a name, so chose something appropriate. Next you will need to select the “DiData.OpSource.py” script from the Cloud API drop down box. Inside credential1 enter the name of the configuration file which you uploaded previously. In credential2 enter the password for the user specified in the configuration file. Save the Cloud credentials.     Setting up an Auto-Scaled pool Your Cloud Credentials are now available for use within a pool. Navigate to the Services -> Pools tab in the UI and create a new pool. Leave the nodes box empty, but tick the Auto-Scaling check box.   You will need to set the “autoscale!enabled” option to “Yes”, and the “autoscale!external” option to “No”. Next you should be able to select your “Cloud Credentials” file from the CC drop down box.   Now we need an imageID. At this point you will need to have created a clone of the node which you intend to use in the pool, and it should be available in the “customer images” section in your cloud. Traffic Manager will provision nodes from this template. To find out the ID; click on the custom image and you should be able to see the ID displayed under image name in the pop up box.   OpSource Cloning Ref: How to Clone a Cloud Server to Create a Customer Image Using the Administrative UI   The machine type isn’t used in OpSource because the hardward configuration is all stored with the image ID. Set the name prefix to be something appropriate for the service, and ensure that “autoscale!ipstouse” is set to “private IP addresses” as your nodes will not be given public ones.   The remaining options control how and when stingray deploys nodes. They are not OpSource specific. Set them to appropriate values for your service. When you are finished click update.   The Traffic Manager autoscaler will now attempt to deploy nodes up to the autoscale!min_nodes setting. This defaults to 1, so you will probably see messages in the log on Traffic Manager, and you should see nodes being provisioned in the OpSource admin portal.   Next steps... You will now want to create a Virtual Server and Traffic IP Group to use with the AutoScaling pool. ... View more

Have you ever wanted to make use of LDAPs StartTLS functionality, or to restrict the search filters and attributes which external users can use when querying your directory service? How about simply rejecting or closing LDAP connections at will?   Although Stingray does not include a built-in LDAP protocol parser, you can use TrafficScript LDAP Library 1.1 to provide the TrafficScript functionality to decode and build up LDAP packets.  Then with a little TrafficScript logic, you can implement some sophisticated traffic management policies for LDAP traffic.   Example Uses     Restrict LDAP Operations   The script below will read in a packet from the client using getPacket(). The getPacket() function returns a hash containing the current request in a hash along with the protocolOp (Protocol Operation), Message ID (all LDAP packets have an ID), and some other data. Once we have the packet and we know what the protocolOp is we can decide what to do with it.   import libLdap.rts as ldap; $packet = ldap.getPacket(); $op = ldap.getOp($packet); $ip = request.getRemoteIP(); if( !string.ipmaskmatch( $ip,"10.0.0.0/8" )) { # Non LAN clients can only BIND, UNBIND, and SEARCH if( ( $op != “BindRequest” ) && ( $op != “SearchRequest” ) && ( $op != “UnbindRequest” )) { # Send back a Notice of Disconnection and close the socket ldap.close(); } }   In this case, we simply check if the client is on the LAN (in the 10.0.0.0/8 subnet), and if it is not, then we restrict the types of requests they can make to binding, searching, and unbinding from the server.   Please Note: It's important to remember to set LDAP TrafficScript rules you create to run on "every" request, not just "once" (unless you're only interested in the Bind of course).   Chose an LDAP server based on bindDN   Here's another scenario for you, this time we have multiple LDAP servers sitting on the network, and we want to direct users to a server based on their binding credentials. If the BindDN contains “dc=nbttech,dc=com” then we will use the nbttech ldap Servers. Alternatively if the BindDN contains “dc=riverbed,dc=com” then we will use the Riverbed ldap servers. Anonymous binds will be rejected.   import libLDAP.rts as ldap; $packet = ldap.getPacket(); $op = ldap.getOp( $packet ); if( $op == "BindRequest" ) { $details = ldap.getBindDetails( $packet ); if( $details["bindDN"] == “” ) { # Anonymous bind. I don't think so! ldap.rejectAnonBind( $packet["messageID"] ); } elseif( string.endswith( $details["bindDN"], “dc=nbttech,dc=com” )){ pool.use(“nbttech-ldap”); } elseif( string.endswith( $details["bindDN"], “dc=riverbed,dc=com” )){ pool.use(“riverbed-ldap”); } else { # Unknown bind domain. Log a warning and reject with invalid Credentials (49) log.warn( “UnknownBind:“. $details["bindDN"] ); ldap.rejectBind( $packet["messageID"], 49 ); } }   The getBindDetails() function also returns details of the authentication method (SIMPLE/SASL), the LDAP version, and the authentication data itself.   Override Attributes and filters   Another thing you may wish to do is to limit which attributes are sent out from the LDAP server, and possibly which parts of the LDAP tree are searchable. The libLdap library can be used to set attributes and filters on incoming requests to restrict which information the LDAP server returns.   In the TrafficScript below, we are going to override everything (mwah ha ha ha)....   First the script will detect the BindRequest and use connection.data.set() to store the bindDN in memory, If the bind is anonymous we will close the connection. If we then get a SearchRequest from the user we will retrieve the bindDN and limit the query base object to match the “dc” or “ou” used in the bind. We will also limit the attributes to “cn”, “uid”, and “gid”. Set the filter to match the bind users common name, and finally Set the search scope to a single level.   You are obviously unlikely to limit all of those things at once or all the time, but this sample script lets you see how they all work:   import libLDAP.rts as ldap; $packet = ldap.getPacket(); $op = ldap.getOp( $packet ); if( $op == "BindRequest" ){ $details = ldap.getBindDetails( $packet ); if( $details["bindDN"] == "") { ldap.rejectAnonBind( $packet["messageID"] ); } else { connection.data.set( "bindDN", $details["bindDN"] ); } } elseif ( $op == "SearchRequest" ) { $details = ldap.getSearchDetails( $packet ); $bindDN = connection.data.get( "bindDN" ); if( string.regexMatch( $bindDN, "(cn=.*?),(dc|ou=.*)" )) { # Set the Base object to be in the same domain as the binder $details[ "baseObject" ] = $2; # restrict the attributes returned to cn, uid and gid ldap.setSearchAttributes( $details, "cn uid gid" ); # Override the user supplied filter too. They can only search themselves. ldap.setSearchFilter( $details, "(". $1 .")" ); # Change the scope... why not ;-) $details[ "scope" ]=1; # Commit the changes request.set( ldap.updateSearch( $packet, $details )); }else{ # Oh dear failed to process search... Lets reject it ;-) ldap.rejectSearch( $packet["messageID"], "Failed to nobble search. So Denied. Sorry!" ); } }   StartTLS   At the time of writing, Stingray doesn't support StartTLS for LDAP out of the box, but with this TrafficScript you can implement it yourself quite simply. You will need to create two LDAP services, one plain ldap, and the other a ldaps service with SSL Offload enabled. Then you need a loop back pool to link the plain ldap service with the ldaps service.   Once you have that set up, you just need the script:   import libLDAP.rts as ldap; if( connection.data.get( "TLS" )) { # the connection is already in TLS mode, stop processing break; } $packet = ldap.getPacket(); $op = ldap.getOp( $packet ); if( $op == "ExtendedRequest" ) { if( ldap.isStartTLS( $packet )) { $ip = request.getRemoteIP(); # Only Accept StartTLS requests if the clients are not local if( !string.ipmaskmatch( $ip, "10.0.0.0/8" )) { # Set the TLS flag on the connection connection.data.set( "TLS", "yes" ); # Send the TSL acceptance packet ldap.acceptStartTLS( $packet ); # Use the ldaps loopback pool, and we're done :-) pool.use( "ldap-loop" ); } else { # LAN clients have TLS rejected and can carry on in clear text ldap.rejectStartTLS( $packet, "Use Plain Text please" ); } } }   The first thing this script does is check to see if a TLS flag has been set on the connection. If it exists then startTLS has already happened and we should exit, the packet is almost certainly encrypted. If the TLS flag is not set, we continue. The code checks for the startTLS command, and if the user is a remote user it sends back an accept, sets the TLS flag on the connection, and selects the loop back pool. Further LDAP processing can be performed in the LDAPS Virtual Server. If however we find the user is in the 10/8 subnet we reject the startTLS command and make them continue in plain text.   Use LDAP Simple Authentication for other Services   The libLDAPauth.rts library is a small library which uses libLDAP to verify user/passwords against an ldap server. At present it only does a simple BindRequest.  You may want to look at the built-in 'auth.query()' TrafficScript function now; that makes this legacy library somewhat redundant.   The simplest way to use is by using the checkLdapAuth() function. This function returns the LDAP result code, which should be 0 if the authentication was successful.   import libLDAPauth.rts as la; $auth = la.checkLdapAuth( "10.4.5.1", "389", "cn=user,dc=znbttech,dc=com", "password” ); if ( $auth == 0 ) { # success log.info( "UserAuthenticated" ); } else { # Failed log.warn( "User failed authentication:" . $auth); } ... View more

Introduction Riverbed Stingray Traffic Manager is the only pure software ADC (Application Delivery Controller) available in the market today. As such it is the only ADC which can move with your business across Physical, Virtual, and Cloud platforms, and give you the exact same features and performance in each. Today Riverbed provides Stingray in the form of Virtual Appliances for many of the popular Hypervisors (including VMWare, Xen, and Hyper-V). The Virtual Appliance can also be provided in the standard OVA (Open Virtualization Archive) format for importing into a number of other Virtual platforms. For systems such as IBM PureFlex, where the Virtual Appliances are more closely integrated with the underlying platform it can be beneficial to build a completely custom appliance using the software edition of Stingray. IBM provides a tool precisely for this purpose: The Image Construction and Composition Tool (ICCT). This document will take you through the process of building a customised Stingray appliance for deployment on PureFlex using the ICCT. A very similar process can be followed to deploy an image into IBMs Smart Cloud Enterprise. IBM Image Construction and Composition Tool ICCT is a tool which allows a user on a PureFlex or Smart Cloud Enterprise platform to create custom Virtual Appliances. A full description of the ICCT application is beyond the scope of this document. We will assume that the ICCT has already been configured to communicate directly with your PureFlex or SCE environment and we will concentrate solely on the configuration elements required to build a custom appliance. These include: Managing ISO Resources, Managing Software Bundles, and Managing Images. ISO Resources An ISO resource is simply an ISO containing a compatible Operation System image. The ISO can be used to deploy new images from scratch. In terms of Stingray, the only PureFlex/SCE supported Operating Systems are Red Hat Enterprise Linux, SuSE Enterprise Linux. Software Bundles Along with this document, you should have been provided a prebuilt Stingray Software Bundle (a RAS file). The RAS file contains a number of scripts which are used by PureFlex or SCE in building and deploying custom appliances. A software Bundle includes four main configuration items: the installation script, the configuration script, a reset script, and some firewall configuration. Images An image is essentially a Virtual Machine. An image appears in ICCT either when it is created by deployment from an ISO, when it is imported from a connected SCE or PureFlex system, or when an existing image is extended. Build Process The process of building a custom appliance will be explained in detail in the section “Creating a custom Stingray appliance” below. As a quick overview the process is as follows: Take an image of a BaseOS and extend it. Add the software bundle to the extended image and configure the installer parameters. Deploy the new image (installer script is executed). Log on to running virtual machine and check installation succeeded. Capture the image. Export/deploy the image into PureFlex Manager/Smart Cloud Entry as an appliance Deploy an instance from the appliance image (the configure script is executed). The Stingray Software Bundle (RAS) The software bundle provided has everything you need to build a custom Stingray appliance for use in PureFlex or (with a little tweaking) Smart Cloud Enterprise. The RAS file includes a number of scripts which we discuss in turn. Installation Script The installation script “install.sh” is executed when the image is deployed for the first time. Its purpose is to download the Stingray software and Kernel modules from a HTTP repository and install them in to the image. The installer takes two arguments: stmUrl The URI for the Stingray software installer. Default version 9.1 from support.riverbed.com modsUrl The URI for the Stingray Kernel Modules installer Default: Version 2.5 from splash.riverbed.com The stingray installation needs nothing more than a Base OS install, however you will need to ensure that you have the development tools and kernel headers available in order to install the kernel modules. Note: It is recommended that you check the installer output in /var/log/provision.log after the initial deployment to ensure that everything worked. This is also a good opportunity to apply the latest security patches and bug fixes to the underlying OS. Configure Script The configuration script “configure.sh” is executed each time an instance is deployed from the appliance image. The configure script has the task of configuring the Stingray software in the appliance according to the parameters provided in the deployment form. The configure script in the provided RAS takes the following arguments: password The password for the Stingray admin user. Set password to “RANDOM” to have one generated for you. Default: “” accept_license Set to “Accept” if you agree to Stingray licensing terms. The configure script will not continue if this has not been set. Default: “No” license_key Should be “none” or a HTTP URI from where a license can be downloaded. Default: “none” join_cluster Should be “No” or “Yes”. Default: “No” cluster_host Should be “none” or an IP address or hostname of a Stingray to cluster with. Default: “none” cluster_tips Should be “No” or “Yes”. Default: “No” cluster_location The id of the location to join if we are joining a MSM cluster. Default: 0 cluster_external_ip If we are joining a cluster on the other side of a NAT device, then this should be our external IP Address. Default: “none” Reset Script The reset script “reset.sh” is executed whenever the appliance needs to be cleaned up and returned to an unconfigured state. I don’t believe it is ever actually used, but a reset script is provided. It takes no arguments. Firewall Configuration The final piece of configuration in a software bundle is the firewall configuration. This allows you to specify which ports should be open on the firewall. The Stingray bundle currently opens port 9090 and 9080 for cluster communications and administration. You will want to add all of the service ports you expect to use on your Stingray appliance. For example HTTP (80), HTTPS (443), etc. Miscellaneous All scripts write their output to /var/log/provision.log so you can always check that to see if there were any problems with the install, configure or reset steps. The software bundle includes AutoScaling drivers for Smart Cloud Enterprise, and also Smart Cloud Entry provisioning APIs. If you do not join a cluster during the deployment of an instance then the configure script will drop them into the extra files catalogue. However if you do join a cluster, then they will be copied into the root users home directory “/root”. Creating a custom Stingray Appliance Step 1: Upload your ISO The first step is to provide ICCT with an ISO containing the Operating System you wish to use. At the time of writing PureFlex and SmartCloud support RedHat Enterprise Linux and SuSE Enterprise Linux Operating Systems. Navigate to the “Manage ISO Resources” section and upload the ISO you wish to use as the base OS of your appliance. Step 2: Upload the Stingray RAS file The next step is to upload the Software Bundle (RAS file) to the ICCT server. Navigate to the “Build and Manage software Bundles” section and click on the import icon. The RAS file will need to be available either at a URL accessible by the ICCT server, or uploaded to the local file system of the ICCT server itself. Step 3: Create your new BaseOS Image At this point we have an ISO and our software bundle imported. However before we can use the software bundle we must have an image imported into ICCT which we can extend. We’re going to create a new image from the ISO; however you may chose to import a pre-existing Linux image if you have one. If you import a pre-exising image then you can skip to step 4. Navigate to “Build and Manage Images”. Click on the “New Image” icon and then select create from ISO On the next screen you will need to enter some information about the new image we are creating. You can give it a name such as “RHEL BaseOS”, A universal ID such as com.riverbed.rhel62.baseOS, a version (eg 6.2.0), and a description. You will next need to provide the ISO resource which we uploaded earlier, and a kickstart or AutoYAST file. You can download the default KickStart file from ICCT and then extend it. If you intend to make use of the Stingray kernel modules then I would recommend adding the following applications:  gcc, make, perl, kernel-devel. Next you can pick the hardware parameters for the new image. A summary is displayed on the final screen, click done to complete the image creation process. Step 4: Extend the BaseOS Image Now that we have a Base OS configuration, the next step is to add our software bundle and set the installer parameters. Select your new Base OS image in the left hand pane and then click the Extend icon Enter appropriate information for your Stingray Virtual Appliance: Name, Universal ID, Version and Description, and then click Create. Select the new Image in the left hand pane. Click the “Start Editing” Button. Scroll down to the “Software Bundles” and click the “Add” button. Add the Stingray software bundle. Once you have added the bundle you have the option of chosing a different version of the software to install. Expand the properties and change the locations of the installers to the desired versions. The Deploy options can be ignored as they are used at instance deployment not in the initial install phase. Once you are happy with your installation options, Click “Done Editing” and “Save”. Click on the “Synchronize” button to have ICCT deploy your new image and run through the installation process. Once the image is synchronized you will be able to see the details in the “Virtual System” section of the image details pane. At this point you can log into the Virtual System via SSH and confirm that the installer completed successfully by viewing the “/var/log/provision.log” file. This is also a good time to apply any OS patches and/or add additional software. Note:  On RHEL 6.2 the modules may fail to install because the shipped gcc does not match the compiler used to build the kernel (not on the original disc). Feel free to run a yum update at this point and rerun the Stingray modules installer. The provision log will tell you the temporary directory where they were downloaded. Once you are happy with the system, return to ICCT and click “Capture”. ICCT will shut down the VM and capture it as an appliance image, once this step completes you can export the image into PureFlex System Manager or Smart Cloud Entry. Your custom Stingray appliance is ready. ... View more

What is Policy Based Routing?   Policy Based Routing (PBR) is simply the ability to choose a different routing policy based on various criteria, such as the last hop used, or the local IP address of the connection. As you may have guessed, PBR is only necessary where your Traffic Manager is multi-homed (ie multiple default routes) and asynchronous routing is either not possible or not desired.   There are only really two types of multi homing which we commonly deal with in vADC deployments. I am going to refer to them as "Multiple ISP", and "Multiple Link".   Multiple ISP   This is the simpler scenario, and it is seen when vADC is deployed in an infrastructure with two or more independent ISPs. The ISPs all provide different network ranges, and Traffic IP Groups are the end points for the addresses in those ranges. Pulse vADC must chose the default gateway based on the local Traffic IP Address of the connection.   Multiple Link   This is slightly more complicated because traffic destined for the vADC Traffic IP can come in via a number of different gateways. Pulse vADC must ensure that return traffic is sent out of the same gateway as it arrived through. This is also known as "Auto-Last-Hop", and is achieved by keeping track of the Layer 2 mac address associated with the connection.     Setting up Policy Based Routing on Pulse vADC   This guide will show you how to set up a process within Traffic Manager vTM such that a PBR policy is applied during software start up. The advantage of configuring vTM this way is that there are no changes to the underlying OS configuration, and as such it is fully compatible with the Virtual Appliance as well as the software (Linux) version. The steps to set up the PBR are as follows...   Configure gateways.conf for your environment Upload the gateways.conf to Catalogs -> Extra -> Misc Create a new action called "DynamicPBR" in System -> Alerting -> Actions This should be a program action, and execute the dynamic-pbr.sh script Create a new Event called "Dynamic PBR" in System -> Alerting -> Events You want to hook the software started event here   Step 1: Upload the dynamic-pbr.sh script   Navigate to Catalogs -> Extra Files -> Actions Programs and upload the dynamic-pbr.sh script found attached to this article.     Step 2: Configure the gateways.conf for your environment   When the dynamic-pbr.sh script is executed it will attempt to load and process a file called gateways.conf from miscellaneous files. You will need to create that configuration file.   The configuration is a simple text file with a number of fields separated by white space. The first column should be either MAC (to indicate a “Multiple Link” config) or SRC (to indicate “Multiple ISP”).   If you are using the MAC method, then you only need to supply the IP address of each of your gateways and their Layer 2 MAC address. Each MAC line should read “MAC <Gateway IP> <Gateway MAC>”.   If you are using the SRC method, then you should include: local source IP (this can be an individual Traffic IP, or a subnet), the Gateway IP. You should also include information on the local network if you need to be able to access local machines other than the gateway. Do this using two additional/optional columns: Local subnet and device.   Each SRC line should read: “SRC <Local IP> <Gateway IP> <Local subnet> <local device>”     Step 3: upload the gateways.conf   Once you have configured the gateways.conf for your environment, you should upload it to Catalogs -> Extra Files -> Miscellaneous   Step 4: Create Dynamic PBR Action   Now we have the script and configuration file uploaded to vTM, the next steps are to configure the alerting system to execute them at software start up. First we must create a new program action under System -> Alerting -> Manage Actions.   Create a new action called “Dynamic PBR” of type Program. In the edit action screen, you should then be able to select dynamic-pbr.sh from the drop down list.     Step 5: Create Dynamic PBR Event   Now that we have an action, we need to create an event which hooks the “software is running” event. Navigate to System -> Alerting -> Manage Event Types and create a new Event Type called “Dynamic PBR”.   In the event list select the software running event under General, Information Messages.     Step 6: Link the event to the action   Navigate back to the System -> Alerting page and link our new “Dynamic PBR” event type to the “Dynamic PBR” action.     Finished   Now every time the software is started, the configuration from the gateways.conf will be applied.   How do I check the policy?   If you want to check what policy has been applied to the OS, you can do so on the command line. Either open the console or SSH into the vTM machine. The policy is applied by setting up a rule and matching routing table for each of the lines in the gateways.conf configuration file.You can check the routing policy by using the iproute2 utility.   To check the routing rules, run: “ip rule list”.   There are three default rules/tables in Linux: rule 0 looks up the “local” table, rule 32766 looks up “main”, and 32767 looks up “default”. The rules are executed in order. The local rule (0) is maintained by the kernel, so you shouldn’t touch it. The main table (look up rule 32766) and default table (look up rule 32767) tables go last. The main table holds the main routing table of your machine and is the one returned by “netstat –rn”. The default table is usually empty. All other rules in the list are custom, and you should see a rule entry for each of the lines in your gateway configuration file.   So where are the routes? Well the rules are passed in order and the lookup points to a table. You can have upto 255 tables in linux. The “main” table is actually table 255. To see the routes in the table you would use the “ip route list” command. Executing “ip route list table main” and “ip route list table 254” should return the same routing information.   You will note that the rules added by vTM are referenced by their number only. So to look at one of your tables you would use its number. For example “ip route list table 10”. Enjoy!   Updates 20150317: Modified script to parse configuration files which use windows format line endings. ... View more

...Riverbed customers protected!   When I got in to the office this morning, I wasn't expecting to read about a new BIND 9 exploit!! So as soon as I'd had my first cup of tea I sat down to put together a little TrafficScript magic to protect our customers.   BIND Dynamic Update DoS   The exploit works by sending a specially crafted DNS Update packet to a zones master server. Upon receiving the packet, the DNS server will shut down. ISC, The creators of BIND, have this to say about the new exploit   "Receipt of a specially-crafted dynamic update message to a zone for which the server is the master may cause BIND 9 servers to exit. Testing indicates that the attack packet has to be formulated against a zone for which that machine is a master. Launching the attack against slave zones does not trigger the assert."   "This vulnerability affects all servers that are masters for one or more zones – it is not limited to those that are configured to allow dynamic updates. Access controls will not provide an effective workaround."   Sounds nasty, but how easy is it to get access to code to exploit this vulnerability? Well the guy who found the bug, posted a fully functional perl script with the Debian Bug Report.   TrafficScript to the Rescue   I often talk to customers about how TrafficScript can be used to quickly patch bugs and vulnerabilities while they wait for a fix from the vendor or their own development teams. It's time to put my money where my mouth is, so here's the work around for this particular vulnerability:   $data = request.get( 3 ); if ( string.regexmatch($data, "..[()]" ) ) { log.warn("FOUND UPDATE PACKET"); connection.discard(); }   The above TrafficScript checks the Query Type of the incoming request, and if it's an UPDATE, then we discard the connection. Obviously you could extend this script to add a white list of servers which you want to allow updates from if necessary. However, you should only have this script in place while your servers are vulnerable, and you should apply patches as soon as you can.   Be safe! ... View more

Popular news and blogging sites such as Slashdot and Digg have huge readerships. They are community driven and allow their members to post articles on various topics ranging from hazelnut chocolate bars to global warming. These sites, due to their massive readership, have the power to generate huge spikes in the web traffic to those (un)fortunate enough to get mentioned in their articles. Fortunately Traffic Manager and TrafficScript can help.   If the referenced site happens to be yours, you are faced with dealing with this sudden and unpredictable spike in bandwidth and request rate, causing:   a large proportion or all of your available bandwidth to be consumed by visitors referred to you by this popular site; and in extreme cases, a cascade failure across your web servers as each one becomes overloaded, fails and, in doing so, adds further load onto the remaining web servers.   Bandwidth Management and Rate Shaping   Traffic Manager has the ability to shape traffic in two important ways. Firstly, you can restrict the amount of bandwidth any client or group of clients are allowed to consume. This is commonly known as "Bandwidth Management" and in Traffic Manager it's configured by using a bandwidth class. Bandwidth classes are used to specify the maximum bits per second to make available. The alternative method is to limit the number of requests that those clients or group of clients can make per second and/or per minute. This is commonly known as "Rate Shaping" and is configured within a rate class.   Both Rate Shaping and Bandwidth Management classes are configured and stored within the catalog section of Traffic Manager. Once you have created a class it is ready for use and can be applied to one or more of your Virtual Servers. However the true power of these Traffic Shaping features really becomes apparent when you make use of them with TrafficScript.   What is an Abusive Referer?   I would class an Abusive Referer as any site on the internet that refers enough traffic to your server to overwhelm it and effectively deny service to other users. This abuse is usually unintentional, the problem lies in the sheer number of people wanting to visit your site at that one time. This slashdot effect can be detected and dealt with by a TrafficScript rule and either a Bandwidth or a Rate Class.   Detecting and Managing Abusive Referers   Example One   Take a look at the TrafficScript below for an example of how you could stop a site (in this instance slashdot) from from using a large proportion or all of your available bandwidth.   $referrer = http.getHeader( "Referer" ); if( string.contains( $referrer, "slashdot" ) ) { http.addResponseHeader( "Set-Cookie", "slashdot=1" ); response.setBandwidthClass( "slashdot" ); } if( http.getCookie( "slashdot" ) ) { response.setBandwidthClass( "slashdot" ); }   In this example we are specifically targeting slashdot users and preventing them from using more bandwidth than we have allotted them in our "slashdot" bandwidth class. This rule requires you to know the name of the site you want protection from, but this rule or similar could be modified to defend against other high traffic sites. Example Two The next example is a little more complicated, but will automatically limit all requests from any referer. I've chosen to use two rate classes here, BusyReferer for those sites I allow to send a large amount of traffic and StandardReferers for those I don't. At the top I specify a $whitelist, which contains sites I never want to rate shape, and $highTraffic which is a list of sites I'm going to shape with my BusyReferer class. By default, all traffic not in the white list is sent through one of my rate classes, but only on entry to the site. That's because subsequent requests will have myself as the referer and will be whitelisted. In times of high load, when a referer is sending more traffic than the rate class allows, a back log will build up, at that point we will also start issuing cookies to put the offending referers into a bandwidth class.   # Referer whitelist. These referers are never rate limited. $whitelist = "localhost 172.16.121.100"; # Referers that are allowed to pass a higher number of clients. $highTraffic = "google mypartner.com"; # How many queued requests are allowed before we track users. $shapeQueue = 2; # Retrieve the referer and strip out the domain name part. $referer = http.getheader("Referer"); $referer = String.regexsub($referer, ".*?://(.*?)/.*", "$1", "i" ); # Check to see if this user has already been given an abuse cookie. # If they have we'll force them into a bandwidth class if ( $cookie = http.getCookie("AbusiveReferer") ) { response.setBandwidthClass("AbusiveReferer"); } # If the referer is whitelisted then exit. if ( String.contains( $whitelist, $referer ) ) { break; } # Put the incoming users through the busy or standard rate classes # and check the queue length for their referer. if ( String.contains( $highTraffic, $referer ) ) { $backlog = rate.getbacklog("BusyReferer", $referer); rate.use("BusyReferer", $referer); } else { $backlog = rate.getbacklog("StandardReferer", $referer); rate.use("StandardReferer", $referer); } # If we have exceeded our backlog limit, then give them a cookie # this will enforce bandwidth shaping for subsequent requests. if ( $backlog > $shapeQueue ) { http.setResponseCookie("AbusiveReferer", $referer); response.setBandwidthClass("AbusiveReferer"); }   In order for the TrafficScript to function optimally, you must enter your servers own domainname(s) into the white list. If you do not, then the script will perform rate shaping on everyone surfing your website!   You also need to set appropriate values for the BusyReferer and StandardReferer shaping classes. Remember we're only counting the clients entry to the site, so Perhaps you want to set 10/minute as a maximum standard rate and then 20/minute for your BusyReferer rate.   In this script we also use a bandwidth class for when things get busy. You will need to create this class, called "AbusiveReferer" and assign it an appropriate amount of bandwidth. Users are only put into this class when their referer is exceeding the rate of referrals set by the relevant rate class.   Shaping with Context   Rate Shaping classes can be given a context so you can apply the class to a subset of users, based on a piece of key data. The second script uses context to create an instance of the Rate Shaping class for each referer. If you do not use context, then all referers will share the same instance of the rate class.   Conclusion   Traffic Manager can use bandwidth and rate shaping classes to control the number of requests that can be made by any group of clients. In this article, we have covered choosing the class based on the referer, which has allowed us to restrict the rate at which any one site can refer visitors to us. These examples could be modified to base the restrictions on other data, such as cookies, or even extended to work with other protocols. A good example would be FTP, where you could extract the username from the FTP logon data and apply a bandwidth class based on the username. ... View more