Blue Coat Proxy, iPhone’s multiple authentication issues.

Recently a colleague pointed me at the following Blue Coat KB about NTLM issues as basically the iPhones on the corp network were getting multiple authentication challenges even though the username & password are saved in the connection profile!

To resolve we created a second authentication realm on the bluecoat with Kerberos & NTLM authentication disabled ( i.e. only basic auth), we then created an authentication rule which matches user agent strings and authenticates against the new basic-only realm. Below is some command lines to point you in the right direction:

!- BEGIN authentication
security iwa create-realm uk 10.10.10.10 16101
security iwa edit-realm uk ;mode
alternate-server 10.10.10.11 16101
exit
security iwa create-realm ukBasicAuth 10.10.10.10 16101
security iwa edit-realm ukBasicAuth ;mode
alternate-server 10.10.10.11 16101
credentials-kerberos disable
credentials-ntlm disable
exit

I should point out that the KB is out of date; upon implementing we noticed a lot of windows users getting unwanted authentication challenges therefore I suggest you only match against iphone & ipad… in-fact I stuck Macintosh in as well and my macbook is getting less challenges too!

Enjoy the CPL goodness below!

;; Description: BlueCoat KB4741
define condition __CondList1BasicUserAgents
        request.header.User-Agent="iphone"
        request.header.User-Agent="ipad"
        request.header.User-Agent="Macintosh"
        request.header.User-Agent="CFNetwork"
end condition __CondList1BasicUserAgents

define condition BasicUserAgents
        condition=__CondList1BasicUserAgents
end condition BasicUserAgents

<Proxy>
        condition=BasicUserAgents authenticate(ukBasicAuth)  authenticate.force(no) authenticate.mode(proxy)    ; KB4741
        authenticate(uk)  authenticate.force(yes) authenticate.mode(proxy)      ; All Internet Traffic

Bluecoat, Gmail (Google Mail) & Your request is being scanned for security purposes

This issue wasted an hour of my life :)

Recently users visiting google mail via the bluecoat proxy started complaining of popups which said…

Your request is being scanned for security purposes

Instead of “botching” it on the blue coat I offered my users a work around… something that they should be doing anyway… switch on encryption…. So within gmail -> settings -> general, tick the box…

GMail - Always Use HTTPS

This did the trick, my users mail is now more confidential than it was before and there were no more pop-ups :cool:

Image Blocking & Re-Writing with Blue Coat.

Recently I’ve been helping out a customer with perhaps the strictest URL filtering policy I have seen in a while!

URL categorisation is in place and large sections of the internet such as “blogs / personal pages” & “social networking” were being blocked. What makes this unusual is that Google images is a popular tool, the mix of these two made it “appear” that Google images was broken.

Broken you ask? Yes, basically if you search for something harmless like “HP Laptop” or “Nokia Phone” some of the results are actually stored on personal pages (forbidden categories) , as the image is blocked your browser returns a broken image icon which makes it look like the page loading failed!

With the help of a very helpful Blue Coat guy I have a solution.

To start with you’ll need an image to insert into the page, something that shows the image was blocked, this open clip art denied sign worked nicely for me. Next you’ll need an Intranet web server to save the image on – IIS or Apache will do the trick, it doesn’t matter where the image is as long as your users can “see” it.

In the VPM you’ll need an object representing all your blocked categories and a to create a new rule..

Source = Any (or internal users, whatever)
Destination = Combined object (Call it something like Blocked_Images), in the top box you want your category object, in the bottom box you want a “HTTP Mime Types” object which matches all images – Screen Shot 1 should help.
Action = Combined object (Named something like Return_Blocked_Image), in the top box you want two actions a “Return Redirect Object” which redirects to your Image and then “Allow” which permits the HTTP request to your image. – Screen shot 2 should help

Install the policy and job done! I think you’ll find this is a very neat solution!

Bluecoat reverse proxy and health checks.

Bluecoat Reverse Proxy Health Check Diagram
Bluecoat Reverse Proxy
Health Check Diagram

Consider the attached diagram, a customer wants a fairly simple reverse HTTP proxy solution; behind the bluecoat is two servers one hosting pages for server1.domain.com and the other for server2.domain.com (both of these DNS names resolve to the IP address of the bluecoat).

The requirement comes with a twist, in the event that either server goes down they want requests sent to another “we’re sorry the site is down” server, below is some pseudo-code explaining what we want the bluecoat to do when it receives a HTTP request.


If (URL = http://server1.domain.com ) then
If ( webserver1 = healthy) then
Forward webserver1
Else
Forward backupserver
Fi
Fi
If (URL = http://server2.domain.com) then
If ( webserver2 = healthy) then
Forward webserver2
Else
Forward backupserver
Fi
Fi

Now it took me some time to find out how to do this, some can be applied in the GUI, the rest has to be applied in Content Policy Language (CPL). If you want to do something similar start by defining some forwarding hosts in the GUI click: Configure -> Forwarding Hosts -> New . In this example only use IP addresses, it makes things simple later, so server1.domain.com =

  • alias = 192.168.1.1
  • host = 192.168.1.1
  • type = server
  • ports = HTTP 80

then server2.doamin.com is…

  • alias = 192.168.1.2
  • host = 192.168.1.2
  • type = server
  • ports = HTTP 80

and the backup webserver is…

  • alias = 192.168.1.3
  • host = 192.168.1.3
  • type = server
  • ports = HTTP 80

If you now click: Heath Checks -> General you’ll see that some health checks like fwd.192.168.1.3 have been created for you.

Next In the VPM (Policy -> Visual Policy Manager -> Launch) create a web access layer permitting “any” to your webserver hosts server1.domain.com & server2.domain.com

Finally you need to upload come CPL ( Policy -> Policy Files -> Under: Install Local File from -> Select: Text Editor -> Install)

<Forward>
	; Forward to server1.domain.com
	server_url.host.exact="server1.domain.com" is_healthy.fwd.192.168.1.1=yes forward(192.168.1.1)
	server_url.host.exact="server1.domain.com" is_healthy.fwd.192.168.1.1=no forward(192.168.1.3)
	; Forward to server2.domain.com
	server_url.host.exact="server2.domain.com" is_healthy.fwd.192.168.1.2=yes forward(192.168.1.2)
	server_url.host.exact="server2.domain.com" is_healthy.fwd.192.168.1.2=no forward(192.168.1.3)

Change as necessary, but now if server1.domain.com goes down the page on 192.168.1.3 is displayed (and the same happens for server2) neat!

(Correct as of SGOS 5.4.1.3 as usual YMMV!)

Better Proxy Settings… Bluecoat, wpad, proxy.pac & dhcp option 252

Recently I’ve been involved with a bluecoat install; one of the requirements I’ve been faced with was helping the client with was removing fixed proxy settings within their browsers.

For how-to references a combination of google, wikipedia and this post are good places to start; I intend to document my experience you may find some overlap.

The 1st thing to understand is that Firefox (FF) and Internet Explorer (IE) both support an “automatically detect proxy” setting, but they are implement in different ways. Both FF & IE use a proxy.pac (also known as wpad.dat) for their configuration, they just “look for it” in different ways.

The proxy pac file is a java script that tells the browsers (both FF & IE) how to connect, there’s some good pac file examples here, this is what I did…

function FindProxyForURL(url, host)
{
	// The 1st if function tests if the URI should be by-passed…
	// Proxy By-Pass List
	if (
		// ignore RFC 1918 internal addreses
		isInNet(host, "10.0.0.0", "255.0.0.0") ||
		isInNet(host, "172.16.0.0", "255.240.0.0") ||
		isInNet(host, "192.168.0.0", "255.255.0.0") ||

		// is url is like http://server by-pass
		isPlainHostName(host) ||

		// localhost!!
		localHostOrDomainIs(host, "127.0.0.1") ||

		// by-pass internal URLS
		dnsDomainIs(host, ".mycompany.com") ||
		dnsDomainIs(host, ".mycompany.local")
		)

		// If True, tell the browser to go direct…
		return "DIRECT";

		// If False, it’s not on the by-pass then Proxy the request… if you fail to connect to the proxy, try direct.

return "PROXY 10.10.10.10:8080;DIRECT";

}

Once you’re happy with what you’ve written you need to “publish” the pac file on a webserver for your clients to download it… I’ve decided to use the bluecoat proxy SG.

Now you can’t upload the pac file via the GUI, you need to get down and dirty with the command line, below is an example ssh session…

Proxy> enable
Proxy# conf t
Proxy# inline accelerated-pac 123
....... Paste the contents of proxy.pac .......
123
Proxy#

Before going any further log into you’re bluecoat, make sure that under Services -> Proxy Services, HTTP 80 & 8080 are set to Intercept. Next check that Services -> Management services, HTTP-Console 8081 is enabled… this service will be used to get the pac file, leave HTTPS-Console 8082 on as using the 8081 for administrator access would be a bad idea.

You will now hopefully be able to download your pac file from the following url http://10.10.10.10:8081/accelerated_pac_base.pac .. change the IP as necessary.

Once that works we’re going to add some proxy policy to make that url (a) nicer (b) compatible with Firefox. In the Bluecoat GUI under policy (not the visual policy manager) make sure that the local policy is read 1st… at the top of the file list. The following ssh session of policy, re-writes the pac file for a variety of names, basically I’ve tried to capture every combination that a user might try…..

Proxy> enable
Proxy# conf t
Proxy# inline policy local 123
<proxy>
url=http://proxy.mycompany.local/proxy.pac authenticate(no)
url=http://proxy.mycompany.local/wpad.dat authenticate(no)
url=http://wpad.mycompany.local/wpad.dat authenticate(no)
url=http://www.wpad.com/wpad.dat authenticate(no)
url=http://proxy.mycompany.local:8081/accelerated_pac_base.pac authenticate(no)
url=http://10.10.10.10:8081/accelerated_pac_base.pac authenticate(no)

<cache>
url.domain=http://proxy.mycompany.local/proxy.pac cache(no)
url.domain=http://proxy.mycompany.local/wpad.dat cache(no)
url.domain=http://wpad.mycompany.local/wpad.dat cache(no)
url.domain=http://www.wpad.com/wpad.dat cache(no)
url.domain=http://proxy.mycompany.local:8081/accelerated_pac_base.pac cache(no)
url.domain=http://10.10.10.10:8081/accelerated_pac_base.pac cache(no)

<proxy>
url=http://proxy.mycompany.local/proxy.pac action.rewrite_pac(yes)
url=http://proxy.mycompany.local/wpad.dat action.rewrite_pac(yes)
url=http://wpad.mycompany.local/wpad.dat action.rewrite_pac(yes)
url=http://www.wpad.com/wpad.dat action.rewrite_pac(yes)
url=/wpad.dat action.rewrite_pac(yes)

define action rewrite_pac
rewrite(url,"(.*)","http://10.10.10.10:8081/accelerated_pac_base.pac")
end

123
Proxy#

Phew, thats the bluecoat side of things sorted, now we need to get clients to download the file! This is where the browser have different approaches….

Internet explorer uses DCHP Option 252 to detect the proxy, you can set the option of any of the URLS you’re re-writing on the bluecoat, I chose http://wpad.mycompany.local/wpad.dat .

Firefox uses DNS to detect the proxy, so you’re going to need to create some records… The bluecoat was called “proxy” so an A record for proxy.mycompany.local already existed, we created a CNAME record for wpad.mycompany.local pointing to proxy.mycompany.local … if your dns domain is something like uk.mycomany.local you’ll need to add cname records wpad.uk.mycompany.local & wpad.mycompany.local and add the necessary lines to the bluecoat rewire code above.

Once done you can set either browser to “automatically detect” and finger’s cross all will work!