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;
}
}
