Tag: bluecoat

Posted on

Bluecoat: Authentication Descriptions

This article provides an overview of all the authentication methods with descriptions for Bluecoat appliances.

Auto

The default; the mode is automatically selected, based on the request.  Auto can choose any of proxy, origin, origin-ip, or origin-cookie-redirect, depending on the kind of connection (explicit or transparent) and the transparent authentication cookie configuration.

 

Proxy

The ProxySG uses an explicit proxy challenge.  No surrogate credentials are used.  This is the typical mode for an authenticating explicit proxy.  In some situations proxy challenges do not work; origin challenges are then issued.

If you have many requests consulting the back-end authentication authority (such as LDAP, RADIUS, or the BCAAA service), you can configure the ProxySG (and possibly the client) to use persistent connections.  This dramatically reduces load on the back-end authentication authority and improves the all-around performance of the network.

 

Proxy-IP

The ProxySG uses an explicit proxy challenge and the client’s IP address as a surrogate credential.  Proxy-IP specifies an insecure forward proxy, possibly suitable for LANs of single-user workstations.  In some situations proxy challenges do not work; origin challenges are then issued.

 

Origin

The ProxySG acts like an OCS and issues OCS challenges.  The authenticated connection serves as the surrogate credential.

 

Origin-IP

The ProxySG acts like an OCS and issues OCS challenges.  The client IP address is used as a surrogate credential.  Origin-IP is used to support IWA authentication to the upstream device when the client cannot handle cookie credentials.  This mode is primarily used for automatic downgrading, but it can be selected for specific situations.

 

Origin-Cookie

The ProxySG acts like an origin server and issues origin server challenges.  A cookie is used as the surrogate credential.  Origin-cookie is used in forward proxies to support pass-through authentication more securely than origin-ip if the client understands cookies.  Only the HTTP and HTTPS protocols support cookies; other protocols are automatically downgraded to origin-ip.

This mode could also be used in reverse proxy situations if impersonation (where the proxy uses the user credentials to connect to another computer and access content that the user is authorized to see) is not possible and the origin server requires authentication.

 

Origin-Cookie-Redirect

The client is redirected to a virtual URL to be authenticated, and cookies are used as the surrogate credential.  The ProxySG does not support origin-redirects with the CONNECT method.  For forward proxies, only origin-*-redirect modes are supported for Kerberos/IWA authentication.  (Any other mode uses NTLM authentication).

NOTE:  During cookie-based authentication, the redirect request to strip the authentication cookie from the URL is logged as a 307 (or 302) TCP_DENIED.

 

Origin-IP-Redirect

The client is redirected to a virtual URL to be authenticated, and the client IP address is used as a surrogate credential.  The ProxySG does not support origin-redirects with the CONNECT method.  For forward proxies, only origin-*-redirect modes are supported for Kerberos/IWA authentication.  (Any other mode uses NTLM authentication.)

 

SG2

The mode is selected automatically, based on the request, and uses the SGOS 2.x-defined rules.

 

Form-IP

A form is presented to collect the user’s credentials.  The form is presented whenever the user’s credential cache entry expires.

 

Form-Cookie

A form is presented to collect the user’s credentials.  The cookies are set on the OCS domain only, and the user is presented with the form for each new domain.  This mode is most useful in reverse proxy scenarios where there are a limited number of domains.

 

Form-Cookie-Redirect

A form is presented to collect the user’s credentials. The user is redirected to the authentication virtual URL before the form is presented.  The authentication cookie is set on both the virtual URL and the OCS domain.  The user is only challenged when the credential cache entry expires.

 

Form-IP-Redirect

This is similar to form-ip except that the user is redirected to the authentication virtual URL before the form is presented.

No related posts.

Posted on

Bluecoat: The Difference Between Proxies

The Difference Between Proxies

This article describes the terminology and basic differences between proxies.

Forward proxy

The proxy is on the same networks as the clients

If a proxy manages all outbound traffic to the web, it is a forward proxy!

 

Reverse proxy

The proxy is on the same network as the servers (inbound)

If a proxy sits in front of several web servers and uses round robin to balance the load, it is a reverse proxy!

 

Explicit Proxy

In an explicit proxy, the client is configured to communicate with a proxy.

 

Transparent Proxy

In a transparent proxy, the client attempts to communicate directly with a site and the request is intercepted.

 

Neither of these options is configured on the Proxy SG.

 

Proxy Configuration Notes – Explicit Proxy

  • Requires client config (ie proxy settings in browser)
  • Src:client Ip    DST: SG IP    >     Src:SG IP    DST:Server IP
  • Application must be proxiable
  • One way to deploy explicit proxy can be to use a PAC file.
  • Another method is Proxy Auto-discovery.
  • Recommended method is group policy.
  • Traffic must match a service policy

 

In explicit proxy, when a connection is made for a service that is not running on ProxySG, the connection is rejected.

 

Proxy Configuration Notes – Transparent Proxy

  • The SG intercepts the requests.
  • Option: reflect Client IP can make the SG spoof the client IP – it is rarely used but can reflect accurate sources on servers where required. This is a global option.
  • Transparent proxy can use WCCP to redirect traffic or a layer 4 switch can be used to rewrite the MAC. Last but not least, Load Balancers can be used.
  • A transparent proxy also does its own DNS lookup but can be turned off (Trust Destination IP).
  • If the proxy is in bridging mode or acting as a gateway, a service group does not need to be matched.
  • Routing modes requires IP forwarding enabled

 

 

The proxysg can also be used as a default gateway but is not recommended.

 

No related posts.

Posted on

Bluecoat: SSL Proxy for the Proxy SG

This article describes functionality of SSL Proxy and SSL traffic interception.

Benefits of SSL Forwarding  Proxy

Security is increased by Server cert validation , including CRLs and Virus scanning and Url filtering. There is also an increase in log visibility and in addition, intercepted data can be cached.

The Proxy SG will act as a man in the middle. The client will get a digital cert that appears to be from the server but will really be from the Proxy SG, as follows:

  1. Client sends HELLO to ProxySG
  2. ProxySG sends HELLO to server
  3. Server sends server cert to ProxySG
  4. ProxySG sends its own certificate to client(either its own ca or self signed)

 

  • The cert from the ProxySG will look like a server cert but it will not be signed by Verisign or another  CA.
  • The proxy cannot handle client certs (bidirectional certs). Therefore sites that require client certs cannot be intercepted.
  • The default policy behavior is not to intercept SSL traffic.
  • You can selectively intercept traffic . For example, you may not want to intercept banking sites.
  • There is an ssl coprocessor that handles most of the work and does not add a lot of overhead.
  • The ssl proxy has the ability to distinguish between SSL and non-SSL on the same port.
  • Determining what HTTPS traffic to intercept:
  • The Proxy SG has the ability to make intercept decisions based on the certificate host name or site categorization.


Bluecoat Recommendations for Traffic Interception

  • Intercept Intranet Traffic
  • Intercept suspicious Internet sites, especially those categorized as NONE.
  • Intercept web mail based sites.

You can notify users of SSL intercepted traffic by using  the HTML Notify User object after the interception.


SSL Proxy detects the following certificate errors:

  • Expired certificates
  • Untrusted issuer
  • Certificate has been revoked

Selectively Intercepting SSL Traffic

  1. Launch VPM
  2. Add a new SSL Intercept Layer
  3. Right click on the destination and select New.
  4. Select the Certificate Category then choose your content filter (Bluecoat, Websense, etc).
  5. Select the categories you want to intercept.
  6. Click OK, then OK
  7. Right click on the ACTION field and select NEW.
  8. Select SSL Forward Proxy Object and then check the Intercept as HTTPS and Issuer Keyring.
  9. Select Ok then OK
  10. Apply the policy.

No related posts.

Exit mobile version
%%footer%%