Accessing business applications through SafeSquid

From Secure Web Gateway

Accessing business applications through SafeSquid

There have been several instances where it has been reported that certain applications which the organizations use doesn't work through SafeSquid. This article describes a generalized way of identifying what's wrong with the application and solving it.

There are more than one reasons because of which the application may not work through SafeSquid. They can be listed as:

1) The applications may have certain URLs which are getting blocked by SafeSquid. You need to allow those URLs by creating policies so that the application works properly. To identify whether URLs are getting blocked, you need to carefully observe the extended log of SafeSquid by verifying if the status code is '403' (which means blocked) for any of the requests sent by the application. To view the logs, you can run the following command by taking the SSH access of the SafeSquid server:

 tail -F /var/log/safesquid/extended/extended.log | grep "" | grep '403'


Where, "" is the IP of the machine accessing the application. You will be displayed with something similar to the following log line. The status code 403 describes the blocked URLs.


"1496477492.50.1.2386.zx5NhVkA9enUdJEC"    "50"    "1"    "03/Jun/2017:13:41:32"    "78"    "403"    "0"    "0"    "0"    "-"    ""    "anonymous@"    "GET"    ""    ""    "Mozilla
/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0"    "text/html"    "Profiles"    "-"    ""    "TCP_DENIED"    "DIRECT"    "safesquid"    ""    ""    ""    ""    "0"    "LUNCH"    "ADMINS"    ""    "Firefox Browser,Browsers,Bing,Search Engine,Bing Search,Bing UnSafe Search"    "pornography,searchengines"    ""    "-"    "-"    "GLOBAL BLOCK"


The log line legend mentioning what each field means is shown below:


"record_id"    "client_id"    "request_id"    "date_time"    "elapsed_time"    "status"    "size"    "upload"    "download"    "bypassed"    "client_ip"    "username"    "method"    "url"    "http_referer"    "useragent"    "mime"    "filter_name"    "filtering_reason"    "interface"    "cachecode"    "peercode"    "peer"    "request_host"    "request_tld"    "referer_host"    "referer_tld"    "range"    "time_profiles"    "user_groups"    "request_profiles"    "application_signatures"    "categories"    "response_profiles"    "upload_content_types"    "download_content_types"    "profiles"


2) One of the other reasons may be, you have authentication and/or HTTPS inspection enabled and the application may not support the authentication (Negotiate/Basic) and/or HTTPS inspection. Authentication failure can be verified by observing the logs and checking for a status code of '407' which indicates "Invalid SSO Auth" (if you have enabled Negotiate authentication)