Skip to main content

​
Problem

Security teams need predictable control over app and web usage to reduce policy bypass and data-risk exposure.

​
Benefits

You can enforce policy decisions consistently with SafeSquid while preserving legitimate business workflows.

​
Advantages

You keep actionable policy control close to operations, with verifiable outcomes in logs and policy behavior.

​
Call to action

Use the steps in this guide to implement the control, then validate behavior with a real user-flow test. There have been several instances where it has been reported that certain applications that the organizations use do not work through SafeSquid. This article describes a generalized way of identifying what is wrong with the application and solving it. There is more than one reason because of why the application may not work through SafeSquid. They can be listed as:
  1. The applications may have certain URLs that 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:
Where “192.168.0.17” is the IP of the machine accessing the application. You will be displayed with something like the following log line. The status code 403 describes the blocked URLs.
The logline 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”
  1. One of the other reasons may be, that 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)

Related topics

Access Mobile Applications Through SafeSquidAccess Remote Desktop Applications Through SafeSquidAllow Outlook to Work Through SafeSquidSystem-Wide Proxy SettingsWeb Categorization