We’ve all seen one; an email falsified to appear as if it’s from a reputable bank or financial institution. Maybe it wasn’t a bank, maybe it claimed to be from the IRS or your online stock trader of choice. Regardless, the intent is the same. They want access to your account, and all they need you to do is provide some small piece of information. Sometimes it’s your Social Security number, other times it’s your account number or perhaps your username and password. They’ll ask for this by saying there’s been some major change, or that you need to update your account info or the like. Whatever information they’re phishing for; wouldn’t your users be a lot happier if you could help prevent this from happening?

With iRules, you can.

To perform these attacks, malicious code will replicate the site of the company whose customers they want to scam, then send unsuspecting customers to it to gather sensitive, personal information. With a BIG-IP in front of the site in question, you can help to prevent this type of attack from occurring.

The below example demonstrates not only how to check for suspicious requests that originate from a referrer that hasn’t been authorized to use your site’s content, but how to either stop them outright, or inject code into the HTTP response to help negate their ability to duplicate your site.

This is done in 3 separate steps.


1.) Define a list of valid referrers in the form of a class. This is a list of those sites that you expect to be linking to content on your site.
2.) Define a list (in the form of a class) of file types that should not be linked to, besides by the referrers listed in item #1.
3.) Check to see if an invalid referrer (not someone in class #1) is trying to serve data from your site and what kind of content they’re trying to serve. If it matches the file types in Class #2…block it. If not, insert some custom code to help prevent phishing attempts.

The example below illustrates each of these steps in code and shows how you can leverage your BIG-IP and iRules to offer a vast array of ways to secure and optimize your applications and data.

As always, this is just a single solution that iRules can provide.  The true power lies in the flexibility of the language which allows you to custom craft solutions to meet your exact needs.

Also, be sure to check out the DCTV video that dives into this rule Here!

class valid_referers {

class file_types {

rule no_phishing {
    # Don't allow data to be chunked.
    if {[HTTP::version] == "1.1"} {
      if {[HTTP::header is_keepalive]} {
        # Adjust the Connection header.
        HTTP::header replace "Connection" "Keep-Alive"
      HTTP::version "1.0"

    if { [matchclass [HTTP::header "Referer"] starts_with $::valid_referers] < 1 } {
      if { ([string tolower [HTTP::method] ] eq "get") && ([matchclass [HTTP::uri] contains $::file_types] > 0 )} {
      } elseif { ([HTTP::header exists "Content-Type"]) && ([HTTP::header "Content-Type"] starts_with "text" ) } {
        set respond 1

    if { $respond == 1 } {
      if { [HTTP::header exists "Content-Length"] } { 
        set content_len [HTTP::header "Content-Length"] 
      } else { 
        set content_len 1000000000 

      if { $content_len > 0 } { 
        HTTP::collect $content_len 

    set bypass [string first -nocase "<html>" [HTTP::payload] ]
    if { $bypass != -1 } {
      HTTP::payload replace $bypass 0 "<script
type=\"text/javascript\">\n if (top.frames.length!=0) {\n if
(window.location.href.replace)\n top.location.replace(self.location.href);\n
else\n top.location.href=self.document.href;\n }\n </script>\n"
  } else { HTTP::respond 500 } } }