What iRules are Supported by Silverline?
- iRules are custom pieces of code written in the programming language, based on TCL, that is also present in F5's BIG-IP series of Application Delivery Controllers.
- 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.
- Silverline DDoS
- Silverline WAF
iRules Scope of Support
- iRules submitted by the iRule Editor
- See How to Create iRules with iRule Editor in Silverline Portal
- Customer-submitted iRules (Custom iRules submitted by the customer)
- SOC-developed iRules (Custom iRules requested to be developed by the SOC)
- Selectively supported based on the criteria in the following sections:
The following criteria apply to iRules within Silverline:
1. The iRule must have undergone testing within the Silverline environment to ensure it does not pose a stability, performance or resource-consumption risk to the Silverline infrastructure.
2. The iRule must serve a security purpose appropriate for Silverline's service offering.
3. The iRule must not perform a function that is natively available in Silverline WAF or DDoS service offerings (must not "reinvent the wheel").
The main class of iRules that should not be deployed on Silverline are those which serve a fundamental application logic purpose rather than a security purpose.
Examples of iRules that are permitted:
- IP allow-list or deny-list, including on a trusted source header (XFF, True-Client-IP, etc)
- Deny or Allow listing based on other request content, e.g. User-Agent
- Rate-limiting or blackholing of traffic that exceeds certain thresholds - if the requirement cannot be met with native configurations in the Silverline platform
- Logging or monitoring of potentially suspicious requests
- Blocking traffic based on known or observed signatures that are not covered in WAF signatures
- Performing actions (block, drop, redirect etc) based on SSL cipher suites
- Granular WAF configurations that cannot be accomplished in other ways
Examples of iRules that are not permitted:
- Redirection of traffic based on HTTP request content (URI, Host header etc) to support desired application functionality
- Rewriting of HTTP request headers or content to support desired application logic
- Rewriting of HTTP response headers or content to support desired application logic
- Inspection of HTTP request payload unless for a specific security purpose
- Inspection of HTTP response payload unless for a specific security purpose
- HTTP content switching
- Changing the application functionality/behavior based on the HTTP method, URI, response code, etc.
- Performing functions that can be accomplished using core Silverline functionality
Exceptions to this policy may be accommodated depending on circumstances and justification. SOC Management pre-approval and engineering vetting process for feasibility are required.
Contact the SOC for details.
- For current configuration limits, see Q&A: What are the Silverline Portal Configuration Limits?
- How to Create iRules with iRule Editor in Silverline Portal
- Q&A: When to use Silverline iRule Data Tables?
- How To Configure "iRules" Option In Proxy/App Configuration