Applies To:
Show Versions
BIG-IP LTM
- 12.1.6, 12.1.5, 12.1.4, 12.1.3, 12.1.2, 12.1.1, 12.1.0
Local Traffic Policies Examples
Example: Preventing a Nimda worm attack
You can create a local traffic policy that prevents the Nimda worm attack. If the URL contains certain strings that are known to be associated with the Nimda worm, then the local traffic policy can use a forwarding action that resets the connection.
Examples
Creating a policy to prevent a Nimda worm attack: video example
You can associate a BIG-IP® local traffic policy to prevent a Nimda worm attack. The policy forwards a URL containing strings associated with the Nimda worm, and resets the connection. Watch the following video for an example of creating a local traffic policy and associating it with a virtual server.
Watch how to create a policy to prevent a Nimda worm
attack
You can also visit our DevCentral™ YouTube™ channel to see this video. Use any of these ways:
- Click this URL: https://www.youtube.com/watch?v=0qe-iyt4Bwg .
- Copy and paste the above URL into your browser window.
- Use your browser to search for this video using the title F5: Creating a local traffic policy to prevent a Nimda worm attack.
Preventing a Nimda worm attack: tmsh example
This topic provides a tmsh command to list the configured settings for a Nimda policy. The policy directs that if certain strings are known to be associated with the Nimda worm, the local traffic policy uses a forwarding action that resets the connection. This topic also provides a tmsh command to list the configured virtual server settings.
(tmos)# list ltm policy Stop_Nimda ltm policy StopNimda{ controls { forwarding } description "This policy blocks the Nimda worm." last-modified 2016-03-02:11:46:00 requires { http } rules { ClobberNimda { actions { 0 { forward reset } } conditions { 0 { http-uri query-string values { root.exe admin.dll cmd.exe } } } } } status published strategy first-match } (tmos.ltm.virtual)# list HTTP-VS1 ltm.virtual.HTTP-VS1{ destination 10.10.0.21:http ip-protocol tcp mask 255.255.255.255 policies { StopNimda { } } profiles { http { } tcp { } } source 0.0.0.0/0 translate-address enabled translate-port enabled vs-index 2 }
Preventing a Nimda worm attack: iRules example
This topic provides an example of iRules® code that is equivalent to a policy that protects against a Nimda worm attack. The iRule directs that if certain strings are known to be associated with the Nimda worm, the local traffic policy uses a forwarding action that resets the connection.
when HTTP_REQUEST { set uri [string tolower [HTTP::uri]] if { ($uri contains "cmd.exe") or ($uri contains "root.exe") or ($uri contains "admin.dll") } { discard } }
Example: Using selective compression
You can create a local traffic policy to support selective compression for types of content that can benefit from compression. For example, common text types (HTML, XML, and CSS style sheets) can realize performance improvements, especially across slow connections, if you compress them.
Examples
Creating a policy to support selective compression: video example
You can associate a BIG-IP® local traffic policy with a virtual server to support selective compression for types of content that can benefit from compression. For example, common text types (HTML, XML, and CSS style sheets) can realize performance improvements, especially across slow connections, if you compress them. Watch the following video for an example of creating a local traffic policy and associating it with a virtual server.
Watch how to create a policy to support selective compression
You can also visit our DevCentral™ YouTube™ channel to see this video. Use any of these ways:
- Click this URL: https://youtu.be/d85swKvXS1w .
- Copy and paste the above URL into your browser window.
- Use your browser to search for this video using the title F5: Using Selective Compression.
Selective compression: tmsh example
This topic provides a tmsh command to list the configured settings for a Selective Compression policy, for types of content that can benefit from compression. For example, common text types (HTML, XML, and CSS style sheets) can realize performance improvements, especially across slow connections. This topic also provides a tmsh command to list the configured virtual server settings.
(tmos)# list ltm policy SelectiveCompression ltm policy SelectiveCompression{ controls { compression } description "This policy compresses specified file types." last-modified 2016-03-02:11:46:00 requires { http } rules { CompressFiles { actions { 0 { compress response enable } } conditions { 0 { http-header name Content-Type starts-with values { text/ } } 1 { cpu-usage last-1min less-or-equal values {5} } } } } status published strategy first-match } (tmos.ltm.virtual)# list ltm virtual HTTP-VS2 ltm.virtual.HTTP-VS2{ destination 10.10.0.31:http ip-protocol tcp mask 255.255.255.255 policies { SelectCompression { } } profiles { http { } httpcompression { } tcp { } } source 0.0.0.0/0 translate-address enabled translate-port enabled vs-index 3 }
Selective compression: iRules example
This topic provides an example of iRules® code that is equivalent to a policy to support selective compression for types of content that can benefit from compression.
when HTTP_REQUEST { COMPRESS::disable if { [HTTP::header Content-Type] contains "text" } { log "Enabling compression for this request" COMPRESS::enable } }
Example: Preventing a spoof of an x-forwarded-for request
You can create a local traffic policy to prevent a spoof of an x-forwarded-for request. This is a security issue where attackers might attempt to thwart security by falsifying the IP address in a header, and pass it through the BIG-IP® system.
Examples
Creating a policy to prevent a spoof of an x-forwarded-for request: video example
You can associate a BIG-IP® local traffic policy with a virtual server to prevent a spoof of an x-forwarded-for request. This is a security issue where attackers might attempt to thwart security by falsifying the IP address in a header, and pass it through the BIG-IP system. Watch the following video for an example of creating a local traffic policy and associating it with a virtual server.
Watch how to create a policy to prevent a
spoof of an x-forwarded-for request
You can also visit our DevCentral™ YouTube™ channel to see this video. Use any of these ways:
- Click this URL: https://youtu.be/QrQxjt4-e4k .
- Copy and paste the above URL into your browser window.
- Use your browser to search for this video using the title F5: Creating a local traffic policy to prevent a spoof of an x-forwarded-for request.
Preventing a spoof of an x-forwarded-for request: tmsh example
This topic provides a tmsh command to list the configured settings for a policy to prevent a spoof of an x-forwarded-for request. This is a request where attackers might attempt to thwart security by falsifying the IP address in a header, and pass it through the BIG-IP® system. This topic also provides a tmsh command to list the configured virtual server settings.
(tmos)# list ltm policy PreventSpoofOfXFF ltm policy SelectiveCompression{ controls { compression } description "This policy prevents a spoof of an x-forwarded-for request." last-modified 2016-03-02:11:46:00 requires { http } rules { StopSpoof { actions { 0 { http-header replace name X-foRWardED-for value tcl:[IP::client_addr] } } } } status published strategy first-match } (tmos.ltm.virtual)# list ltm virtual HTTP-VS3 ltm.virtual.HTTP-VS3{ destination 10.10.0.41:http ip-protocol tcp mask 255.255.255.255 policies { PreventSpoofOfXFF { } } profiles { http { } tcp { } } source 0.0.0.0/0 translate-address enabled translate-port enabled vs-index 4 }
Preventing a spoof of an x-forwarded-for request: iRules example
This topic provides an example of iRules code that is equivalent to a policy that prevents a spoof of an x-forwarded-for request. This is a situation where attackers might attempt to thwart security by falsifying the IP address in a header, and pass it through the BIG-IP® system. This example replaces a request that includes an x-forwarded-for header with the actual client IP address.
when HTTP_REQUEST { set xff 0 foreach x [HTTP::header names] { if { [string tolower $x] equals "x-forwarded-for" } { set xff 1 HTTP::header remove $x HTTP::header insert X-FORWARDED-FOR [IP::client_addr] } } if { $xff == 0 } { HTTP::header insert X-FORWARDED-FOR [IP::client_addr] } }
Example: Mitigating shellshock
You can create a local traffic policy to mitigate shellshock. In shellshock, an Internet service misuses bash shell functionality to process requests that execute arbitrary commands, potentially giving an attacker unauthorized access. This example policy examines requests for an uncommon pattern of "() {" in the URI, to minimize the possibility of false-positive matches.
Examples
Creating a policy to mitigate a shellshock attack: video example
A shellshock attack refers to a class of exploits that misuse the bash shell through a specifically crafted URL. You can associate a BIG-IP® local traffic policy with a virtual server to mitigate a shellshock attack, where the policy examines requests for a pattern of "() {" in the URI. Watch the following video for an example of creating a local traffic policy and associating it with a virtual server.
Watch how to create a policy to mitigate a shellshock attack
You can also visit our DevCentral™ YouTube™ channel to see this video. Use any of these ways:
- Click this URL: https://youtu.be/qL98Xn1zB5U .
- Copy and paste the above URL into your browser window.
- Use your browser to search for this video using the title F5: Creating a local traffic policy to mitigate a shellshock attack.
Mitigating shellshock: tmsh example
This topic provides a tmsh command to list the configured settings for a Mitigating Shellshock policy. During this type of attack, a class of exploits misuse the bash shell through a specifically crafted URL. This topic also provides a tmsh command to list the configured virtual server settings.
(tmos)# list ltm policy MitigatingShellshock ltm policy MitigatingShellshock{ controls { forwarding } description "This policy mitigates shellshock." last-modified 2016-03-02:11:46:00 requires { http } rules { StopShellshock { actions { 0 { log write facility local0 message "tcl:Shellshock detected from [IP::client_addr], blocked" priority info } 1 { forward reset } } conditions { 0 { http-uri query string contains values { "() {" } } } } } status published strategy first-match } (tmos)# list ltm virtual HTTP-VS4 ltm.virtual.HTTP-VS4{ destination 10.10.0.51:http ip-protocol tcp mask 255.255.255.255 policies { MitigatingShellshock { } } profiles { http { } tcp { } } source 0.0.0.0/0 translate-address enabled translate-port enabled vs-index 5 }
Mitigating shellshock: iRules example
This topic provides an example of iRules® code that is equivalent to a policy to mitigate shellshock, where the policy examines requests for a pattern of "() {" in the URI.
when HTTP_REQUEST { set pattern "*() \{*"; if { [string match $pattern [HTTP::uri]] } { log local0. "Detected CVE-2014-6271 attack from '[IP::client_addr]' in URI '[HTTP::uri]'"; reject; } else { foreach header_name [HTTP::header names] { foreach header_value [HTTP::header values $header_name] { if { [string match $pattern $header_value] } { log local0. "Detected CVE-2014-6271 attack from '[IP::client_addr]' in HTTP Header $header_ reject; break; } } } } } when HTTP_REQUEST { if { [string match "*() \{*" [HTTP::request]] } { log local0. "Detected CVE-2014-6271 attack from '[IP::client_addr]'; URI = '[HTTP::uri]'"; reject; } }