Restrict Access via HTTP referer

Okay, so on initial request (open a new browser) and access the site, there would be no Referer header, so do you want it to show an empty page? Are you only expecting users to access this site linked from another site?

Thanks for your reply Kevin!

Essentially I only want the VIP to be accessible from a particular subdomain. The client in question has an application that resides on its own subdomain, such as:

app1.DOMAIN.com app2.DOMAIN.com etc.

So, I want the Virtual Server in question to be accessible when a link is clicked on *.DOMAIN.COM, and inaccessible when referenced directly (by IP address). Also, an empty header being passed should be denied as well.

Does this make sense?

Give this a shot:

when RULE_INIT {
     user-defined: enable/disable debug (1/0)
    set static::ref_debug 1
}
when HTTP_REQUEST {
    if { not ( [HTTP::uri] equals "/favicon.ico" ) } {
        if { $static::ref_debug } { log local0. "Incoming referer: [HTTP::header Referer]" }
        switch -glob [string tolower [HTTP::header Referer]] {
            "http://*.mydomain.com*" {
                if { $static::ref_debug } { log local0. "From allowed referrer - allow" }
                return
            } 
            "http://*.example.com*" {
                if { $static::ref_debug } { log local0. "local domain - allow" }
                return
            }
            default {
                if { $static::ref_debug } { log local0. "from disallowed referer - redirect" }
                HTTP::redirect [HTTP::header Referer]
            }
        }
    }
}

I threw the favicon.ico check in there as it never seemed to carry a Referer header and was getting redirected unnecessarily. The trick here is that you have to catch and accept the Referer headers from both the remote site and the local site.

Also note that if a browser goes from https:// to http:// it will not send a Referrer header. So your blacklisted site could easily get around the iRule logic if they use https:// on their site.

http://tools.ietf.org/html/rfc2616section-15.1.3

Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.

Aaron

I would just add to Aaron's addition that, generally speaking, blocking access based on a Referer header is trivially surmountable. Aside from browsers not passing the Referer header going from HTTPS to HTTP, it's VERY easy to spoof the header.

@hoolio - Yes, thank you for pointing this out. This is actually an issue with this particular implementation as we are going from https --> http. I'm looking into configuring the application (Etherpad) to use https instead of http.

@Kevin - I understand the concern with spoofing HTTP headers, however this particular implementation is not to address any security concerns. Rather, it's more of a forceful "training" of the end users to use the URL included in the application rather than accessing it directly.

Thank you everyone for your quick help!

As a general question if anyone feels like chiming in, would there be a way to restrict access via iRule using something included in the URL itself? Something like:

index.php?http-referrer=VALUE

Or using some sort of authorized token, or the md5 hash of the originating site's URL?

Have you considered using cookies? Either the app or the LTM can set/read them and they can cross from HTTP to HTTPS.

Well, the main issue here is that I would like minimal to zero modifications needed to the application. Ideally, all of the restriction would be done on the F5. Is this possible to dictate in the LTM or would the application need to be modified to interpret data set by the LTM?

It really depends on your overall requirement. Making sure that a user who accesses your site is coming from another site can be easy and insecure (Referer header), or very complex (auth tokens, auth protocols, etc.) and generally requires some coordination between the sites. Putting the Referer in the URI would make it easier to spoof, and adding an md5 hash doesn't really provide any security.