Follow

Q&A: When to use Silverline iRule Data Tables?

Description

When to use Silverline iRule Data Tables instead of a regular irule?

  • This article has examples of when iRules Data Tables would be useful to a Silverline customer, and what those data tables would look like
  • iRule Data Tables are located in the Silverline Portal under Config > iRule Data Tables
  • iRules may be utilized in Silverline to accomplish many tasks and provide an extension of functionality to core DDoS proxy and WAF services.
  • The suitability of an iRule for use in Silverline is at the SOC's sole discretion.  
  • See What iRules are Support by Silverline? 

Environment

  • Silverline DDoS
  • Silverline WAF
  • iRules

Answer

Example 1:

Customer wants to block specific URI requests to their servers.  Up until Data Tables, the SOC would work with the customer and create an iRule which worked for the specific URIs that had been agreed.

But what happens when those URIs change?  

With Data Tables, the iRule would be coded to use a specific identifier (like a variable in coding) which is exposed in the Silverline Portal such that the customer is able to specify what the URI means together with the ability to change it, or add to it in the future.

 

Example 2:

To combat automated bots, Silverline offers Shape Defense and Threat Intelligence.  However, additional defenses via iRules can also be built where connection requests appear to be out of place.

In this example, an iRule was built by the SOC and exposed to the customer in the iRule catalog to examine the user agent which is exposed in the HTTP header.

The iRule has been built using Data Tables and the field that is dynamic is called “bad_useragents”.  By itself the iRule will run, but will not perform any action until the Data Table is populated.  So, the customer must first navigate to the Data Tables section of the Portal under Config > iRule Data Tables

Here is an example of one that has already been completed, showing the name of the field variable “bad_useragents” and that it is defined by a String type.  To look more closely at this Data Table, the content is exposed by clicking the pencil icon (alternatively it may be added by clicking Add icon).

The type and format of the field variable for the iRule will be dependent on the iRule itself and the SOC will be able to provide that information to customers.  It will also be made available in the portal in a future revision.

In this example, the iRule is going to alert and log each time the user agent string in the HTTP header matches any one of the following:

  • mozilla/4.0 (compatible; msie 5.0; windows 98; ycomp 5.0.2.4)
  • mozilla/4.0 (compatible; msie 5.0; windows 98; digext; ycomp 5.0.2.5; ycomp 5.0.0.0)
  • mozilla/4.0 (compatible; msie 5.50; windows 98; sitekiosk 4.8)
  • mozilla/4.0 (compatible; msie 5.5; windows nt5)

This iRule is looking for unlikely clients which advertise themselves as Internet Explorer 5 or 5.5 on Windows 98 or NT5 – all of which are extremely unlikely to be used by any human.  This iRule is statically coded to alert and log when these strings have been matched, but other iRules may also use the “Value” field to allow even more customization.  This might include the ability to log for one type of string match, but block or redirect for another.  Again, it comes down to the specific iRule and its coded behavior.

 

Related Content

 

 

Was this article helpful?
2 out of 2 found this helpful
Have more questions? Submit a request