Content Gateway deployment issues

Applies to: In this topic
  • Forcepoint Web Security, v8.5.x
  • Proxy deployment options
  • User authentication
  • HTTPS content inspection
  • Handling special cases
Planning to deploy Content Gateway as a proxy in your network should include physical requirements, such as:
  • Data center location and space
  • Power and cooling requirements for hardware
  • Required rack space
  • Connectivity to existing or extended network topology

    Also consider:

  • Content Gateway system requirements (hardware and operating system)
  • Advantages and disadvantages of proxy network configuration options
  • User authentication and identification options
  • How to configure and use HTTPS content inspection
  • A plan for handling special proxy/client issues

Internet connectivity

It is recommended that the Content Gateway host machine have Internet connectivity before starting the installation procedure. The software will install without Internet connectivity, but analytic database updates cannot be performed until Internet connectivity is available.

Security of the Content Gateway machine

Consider the following security issues prior to installing Content Gateway:

Physical security

Physical access to the system can be a security risk. Unauthorized users could gain access to the file system, and under more extreme circumstances, examine traffic passing through Content Gateway. It is strongly recommended that the Content Gateway server be locked in an IT closet and that a BIOS password be enabled.

Root permissions

Ensure that root permissions are restricted to a select few persons. This important restriction helps preclude unauthorized access to the Content Gateway file system.

Ports

For a list of default Content Gateway ports, see the ports spreadsheet for on-premises Web protection solutions. These ports must be open to support the full set of Forcepoint Web Security features.
Note: If you customized any ports that Forcepoint Web Security uses for communication, replace the default port with the custom port you implemented.

Restrict inbound traffic to as few other ports as possible on the Content Gateway server. In addition, if your subscription does not include certain features, you can restrict inbound traffic to the unneeded ports. For example, if your subscription does not include Forcepoint DLP or the Forcepoint Web Security DLP module, you may choose to restrict inbound traffic to those ports related to Forcepoint DLP.

IPTables Firewall

If your server is running the Linux IPTables firewall, you must configure the rules in a way that enables Content Gateway to operate effectively. See the IP Tables for Content Gateway article in the Technical Library.

Proxy deployment options

Content Gateway is used in either explicit or transparent proxy deployments.

With an explicit proxy deployment, client software, typically a web browser, is configured to send requests for Internet content directly to Content Gateway.

In a transparent proxy deployment, client requests for Internet content are intercepted (usually by a router) and sent to the proxy. The client is unaware that it is communicating with a proxy.

Both options have advantages and disadvantages. See Content Gateway explicit and transparent proxy deployments for more information.

Management clustering

A Content Gateway deployment can scale from a single node to multiple nodes to form a management cluster. With management clustering, all nodes in the cluster share configuration information. A configuration change on one node is automatically propagated all other nodes. Transparent proxy deployments with WCCP can disable cluster synchronization of WCCP configuration settings.

See Clusters in the Content Gateway Manager Help for information about configuring Content Gateway clusters.

IP spoofing

By default, when communicating with origin servers Content Gateway proxies client requests substituting its own IP address. This is standard forward proxy operation.

With both transparent and explicit proxy deployments, Content Gateway also supports IP spoofing.

IP spoofing configures the proxy to use either of the following:
  • The IP address of the client when communicating with the origin server (basic IP spoofing)
  • A specified IP address when communicating with the origin server (range-based IP spoofing)

IP spoofing is sometimes used to support upstream activities that require the client IP address or a specific IP address. It also results in origin servers seeing the client or specified IP address instead of the proxy IP address (although the proxy IP address can be a specified IP address).

IP spoofing:
  • When enabled, is applied to both HTTP and HTTPS traffic; it cannot be configured to apply to only one protocol
  • Is applied to HTTPS requests whether SSL support is enabled or not
  • Relies on the ARM, which is always enabled
  • Is not supported with edge devices such as a Cisco ASA or PIX firewall; When this is attempted, requests made by Content Gateway using the client IP address are looped back to Content Gateway
    Warning:

    Deploying IP spoofing requires precise control of the routing paths on your network, overriding the normal routing process for traffic running on TCP ports 80 and 443.

    With IP spoofing enabled, traditional debugging tools such as traceroute and ping have limited utility.

For complete information, see IP Spoofing in Content Gateway Manager Help.

User authentication

User authentication is the process of verifying a user via a username and password. Several types of user authentication are supported by Content Gateway.

User identification is the process of identifying a user based on the client IP address. Forcepoint Web Security offers a robust set of user identification agents.

Content Gateway user authentication

Content Gateway can be configured for transparent user authentication—with Integrated Windows™ Authentication (IWA) or Legacy NTLM—in which users are not prompted for credentials. Alternatively, Content Gateway can be configured for prompted (or manual) authentication, in which users are required to enter a username and password to obtain network access.

In the manual authentication process, Content Gateway prompts a user for proxy login credentials when that user requests Internet content. After the user enters those credentials, the proxy sends them to a directory server that validates the data. If the directory server accepts the user’s credentials, the proxy delivers the requested content. Otherwise, the user’s request is denied.

The issue of proxy user authentication is important in a deployment in which multiple proxies are chained. Authentication by the proxy closest to the client is preferred, but may not be possible given a particular network’s configuration. Other issues include whether Content Gateway is chained with a third-party proxy and which proxy is designated to perform authentication. See In a proxy chain for more information.

Content Gateway supports the following user authentication methods:
  • Integrated Windows Authentication (with Kerberos)
  • Legacy NTLM (Windows NT™ LAN Manager, NTLMSSP)
  • LDAP (Lightweight Directory Access Protocol)
  • RADIUS (Remote Authentication Dial-In User Service)

Content Gateway supports both transparent and prompted authentication for Integrated Windows Authentication and Legacy NTLM. LDAP and RADIUS support prompted authentication.

Content Gateway also supports rule-based authentication. Rule-based authentication uses an ordered list of rules to support multiple realm, multiple domain, and other authentication requirements. When a request is processed, the rule list is traversed top to bottom, and the first match is applied.

Authentication rules specify:
  1. How to match a user. By:
    • IP address
    • Inbound proxy port (explicit proxy only)
    • User-Agent value
    • A combination of the above
  2. The domain or ordered list of domains to authenticate against.

    With a list of domains, the first successful authentication is cached and used in subsequent authentications. If IP address caching is configured, the IP address is cached. If Cookie Mode is configured, the cookie (user) is cached.

    Rule-based authentication is designed to meet several special requirements:
    • Multiple realm networks in which domains do not share trust relationships and therefore require that each domain’s members be authenticated by a domain controller within their domain. In this environment rules are created that specify:
      • Members of the realm (untrusted domain) by IP address or proxy port
      • The realm (domain) they belong to
    • Authentication when domain membership is unknown: Some organizations do not always know what domain a user belongs to. For example, this can happen when organizations acquire new businesses and directory services are not mapped or consolidated. The unknown domain membership problem can be handled in rule-based authentication by creating a rule for IP address lists or ranges that specifies an ordered list of domains to attempt to authenticate against. The first successful authentication is remembered and used in later authentications. If authentication is not successful or the browser times out, no authentication is performed.
    • Authentication based on User-Agent value: One or more User-Agent values can be specified in an authentication rule. Often this is a list of browsers. When the User-Agent value matches a rule, authentication is performed against the specified domain or domains. If the User-Agent value doesn’t match any rule and no rule matches based on other values, no authentication is performed (this is always true in rule-based authentication; if no rule matches, no authentication is performed).

    See Content Gateway user authentication in Content Gateway Manager Help for detailed information.

Other methods of user identification

You can configure user identification in the Forcepoint Web Security module of the Forcepoint Security Manager rather than use user authentication on the proxy. Methods of user identification include both transparent identification via a transparent identification agent (such as Logon Agent or DC Agent) and manual (prompted) authentication. See the User Identification topic in the Forcepoint Web Security Administrator Help for more information.

HTTPS content inspection

When you use Content Gateway SSL support, HTTPS traffic is decrypted, inspected, and re-encrypted as it travels from the client to the origin server and back. Enabling this feature also means that HTTPS traffic from the server to the client can be inspected for uncategorized sites and sites with dynamic content. The SSL feature includes a complete set of certificate-handling capabilities. See Certificates in the Content Gateway Manager Help for more information.

When you run Content Gateway with Forcepoint DLP to inspect HTTPS traffic, you must enable SSL support. See Content Gateway Manager Help for a complete description of SSL support.

Deploying Content Gateway with SSL support enabled may require the following modifications to your system:
  • Creation of trusted Certificate Authority (CA) certificates for each proxy to use for SSL traffic interception, and the installation of those certificates in each trusted root certificate store used by proxied applications and browsers on each client
  • In explicit proxy deployments, additional client configuration in the form of Proxy Auto-Configuration (PAC) files or Web Proxy Auto-Discovery (WPAD)
  • In transparent proxy deployments, integration with WCCP v2-enabled network devices, or Policy Based Routing.
    Note: HTTPS content inspection can also affect system hardware resources like processing capacity and memory requirements.

    When Content Gateway is configured to handle HTTPS traffic, you can specify categories of websites, individual websites, and clients for which decryption and inspection are bypassed. See SSL Decryption Bypass in Forcepoint Web Security Administrator Help.

Handling special cases

Any Content Gateway deployment must be able to handle web requests and web applications that are not compatible with the proxy or that should bypass the proxy. For example, requests for data from some internal, trusted sites could be configured to bypass the proxy, for system performance reasons. In explicit proxy deployments, a PAC file can be used to list the traffic that is allowed to bypass proxy inspection. In transparent proxy deployments, the proxy must be installed in a way that allows static bypass. See Static bypass rules in Content Gateway Manager Help.

See, also: Websites that have difficulty transiting Content Gateway.