Full web proxy

‚ÄčSIA‚Äč Proxy can act as a SWG that performs URL filtering and anti-malware scanning in your current network configuration. This occurs when ‚ÄčSIA‚Äč Proxy is configured to scan all web traffic. You can configure ‚ÄčSIA‚Äč Proxy as a full web proxy with one of these methods:

  • Proxy chaining. Directs all HTTP and HTTPS traffic from your organization's on-premises proxy to ‚ÄčSIA‚Äč Proxy. For more information, see Proxy chaining.

  • Configure browser or system proxy settings. You can modify the browser or system proxy settings to connect a user‚Äôs browser or device to ‚ÄčSIA‚Äč Proxy. For more information, see Configure the proxy in browsers.

  • ‚ÄčETP Client‚Äč. When you configure the client as a local web proxy on the device or you configure it to perform transparent traffic interception, all HTTP and HTTPS traffic is forwarded to ‚ÄčSIA‚Äč Proxy. For more information, see About ‚ÄčETP Client‚Äč.

  • Security Connector as an HTTP Forwarder. With Security Connector version 2.7.5 or later, you can configure Security Connector as a proxy within your network that forwards traffic to ‚ÄčSIA‚Äč Proxy. You can configure it as an explicit proxy that forwards web traffic from enterprise devices or as a transparent proxy that forwards traffic directly from the router. For more information, see Configure HTTP Forwarder.

  • IPsec tunnels. Uses IPsec tunnels to direct traffic from an office branch to ‚ÄčSIA‚Äč Proxy. This feature is currently in beta. For more information, see Set up IPsec tunnels.

After enabling the proxy in a policy, you select the Full Proxy as the Operating Mode access control setting. This setting configures the default behavior for traffic. Unless otherwise specified in ‚ÄčSIA‚Äč policy with a bypass or block action, traffic is directed to the full web proxy. You can also select Full Proxy as the mode for mobile traffic.

You can further use these features to secure website access and prevent users from accessing malicious content:

  • Decrypt TLS traffic with trusted certificate. ‚ÄčSIA‚Äč Proxy uses a MITM CA TLS certificate to generate and sign origin certificates for HTTP or HTTPS websites. You need to generate an ‚ÄčAkamai‚Äč certificate or upload a certificate signed by your company's CA. For enterprise client computers to accept and trust these certificates, the trusted MITM CA root certificate needs to be deployed on all enterprise devices and TLS clients. For more information, see ‚ÄčSIA‚Äč Proxy MITM certificate.

  • User Authentication. You can define the users or user groups that can access websites or web applications after they authenticate. You can require that users authenticate before accessing a website or web application, or you can make authentication optional. Optional authentication may be a useful recovery mode for users who are unable to authenticate. For more information, see User authentication and group policies.

  • Inline payload analysis Allows ‚ÄčSIA‚Äč to scan files or website content before end users see the downloaded content. In ‚ÄčSIA‚Äč, this action is available for files that do not exceed 5 MB. For more information, see Inline payload analysis.

  • Static malware analysis for large files. Allows ‚ÄčSIA‚Äč to scan files that are 5 MB to 2 GB in size. ‚ÄčSIA‚Äč scans these files after they are downloaded. If ‚ÄčSIA‚Äč detects malware, a threat event is reported. In the ‚ÄčSIA‚Äč threat event on the Threat Events report, you can download a deep scan report in PDF format that includes more detailed information. To use this feature, in a policy, you need to enable Inline Payload Analysis and select the Allow and Scan option for large files. For more information, see Static malware analysis of large files.

  • Dynamic malware analysis in a Sandbox environment. Scans files in a secure sandbox environment that's isolated from your network. In this environment, file are executed and analyzed to determine whether malicious code or activity is detected. This feature:

    • Analyzes files that are 5 MB to 100 MB in size.

    • Automatically scans files offline (after they are downloaded).

    • Publishes a deep scan report in ‚ÄčSIA‚Äč when it detects a threat. You can download the report in PDF format from the corresponding event in ‚ÄčSIA‚Äč.

    To use this feature, in a policy, you need to enable Inline Payload Analysis, select the Allow and Scan option for large files, and enable Dynamic Analysis. This feature is available to organizations that are licensed for Advanced Sandbox. For more information, see Dynamic malware analysis.

To implement authentication, you need to also set up:

  • Identity providers. A service that creates, manages, and saves user and group identity information for authentication. You can create an IdP or integrate a third-party IdP such as Okta, Microsoft Azure AD, and AD FS. In an IdP configuration, you can enable MFA, define session settings, design the login page, and more. For more information on IdPs, see About identity providers.

  • Directories. A service that your enterprise uses to manage users and user groups. You need to associate a directory to an IdP. These directory services are supported:

    • Active Directory
    • Lightweight Directory Access Protocol
    • Active Directory Lightweight Directory Services

    ‚ÄčSIA‚Äč also offers Cloud Directory, an internal directory that you can use for testing purposes until an IdP is fully deployed. For more information, see About directories.

  • Identity connectors. An identity connector is a virtual appliance that you download in ‚ÄčSIA‚Äč and deploy behind the firewall in your data centers or hybrid cloud environments. You associate an identity connector to a directory. It allows ‚ÄčSIA‚Äč to synchronize with your directory service inside your data center. For more information, see About identity connectors.

‚ÄčSIA‚Äč includes reports where you can view detailed information about traffic, such as:

  • DNS Activity. Shows data on DNS traffic that's directed to ‚ÄčSIA‚Äč or ‚ÄčSIA‚Äč Proxy. This report allows you to:

    • Investigate suspicious activity.

    • Review requests made to a specific domain.

    • Check activity from a specific client internal IP address or machine name.

    • Troubleshoot a failed request based on connection ID or client request ID.

  • Proxy Activity. Shows the traffic that's directed to ‚ÄčSIA‚Äč Proxy. This report can show the requested domain, internal IP address of the user's machine, the username of the user who made the request, the action that was applied to traffic, and more.

These reports are available to super administrators and users who are assigned the etpRestrictedPageViewRole role permission. For more information, see ‚ÄčSecure Internet Access Enterprise‚Äč roles.

Request Flow

These sections describe the flow of a request in a specific full web proxy configuration:

Proxy chaining

This graphic shows the flow of a request when proxy chaining is configured in a network that's enabled for authentication and dynamic malware analysis. For more information about proxy chaining, see Set up proxy chaining.

In this graphic:

  1. All DNS, HTTP, and HTTPS requests are forwarded from the user's device to the on-premises proxy.

  2. As a result of a proxy chaining configuration, the on-premises proxy forwards requests to ‚ÄčSIA‚Äč Proxy. If enabled to do so, the on-premises proxy adds the X-Forwarded-For header to identify the client IP address on the corporate network.

  3. DNS requests are forwarded to ‚ÄčSIA‚Äč DNS server. Information about the domain and the HTTP or HTTPS request is recorded in ‚ÄčSIA‚Äč. If you select to trust the X-Forwarded-For header, ‚ÄčSIA‚Äč Proxy can identify the client IP address. The client IP address is included in the reported threat events.

  4. If authentication is required or optional in the associated policy, the user is prompted to authenticate based on the IdP configuration. The request proceeds as long as authentication is successful. Authentication requires that you configure the X-Forwarded-For header.

  5. Based on the policy, an action is applied to traffic. If the traffic is allowed, the request is directed to the origin and the user is granted access. Otherwise, it's blocked and an error page is shown to the user.

    ūüďė

    If the bypass action is configured, the request bypasses TLS MITM decryption and it's sent directly to the origin IP address or the destination web server.

  6. If the request is allowed and you enabled payload analysis for large files, you can scan website content after it's downloaded by your browser. If your organization is licensed for Advanced Sandbox and you also enabled Dynamic Analysis, this content is directed to a secure sandbox environment.

Configured system or browser proxy settings

You can provide the hostname of ‚ÄčSIA‚Äč Proxy in the browser or system proxy settings to forward traffic from a user‚Äôs browser or device. For more information, see Configure the proxy in browsers.

  1. As a result of the browser proxy setting configuration, all HTTP and HTTPS requests are forwarded from the user's device to ‚ÄčSIA‚Äč Proxy. DNS requests are forwarded to ‚ÄčSIA‚Äč DNS servers.

  2. If authentication is required or optional in the associated policy, the user is prompted to authenticate based on the IdP configuration. The request proceeds as long as authentication is successful.

  3. Based on the policy, an action is applied to traffic. If the traffic is allowed, the request is directed to the origin and the user is granted access. Otherwise, it is blocked and an error page is shown to the user.

‚ÄčETP Client‚Äč with an on-premises proxy

This graphic shows the flow of a request when ‚ÄčETP Client‚Äč forwards requests to an on-premises proxy. In this scenario, the on-premises proxy forwards requests to ‚ÄčSIA‚Äč Proxy. For more information, see ‚ÄčETP Client‚Äč for web traffic.

If your network has an existing on-premises proxy, you can configure that ‚ÄčETP Client‚Äč does not override these settings. ‚ÄčETP Client‚Äč detects that the on-premises proxy is chained to ‚ÄčSIA‚Äč Proxy and in turn, the client avoids intercepting web traffic. If ‚ÄčETP Client‚Äč detects that the on-premises proxy forwards traffic to ‚ÄčSIA‚Äč Proxy, the client shows a protected status.

In this graphic:

  1. Requests from the users in the corporate network are forwarded to the on-premises proxy. Off-network requests are directed to ‚ÄčSIA‚Äč Proxy. As configured in the network, all requests are sent to the on-premises proxy.

  2. As a result of the proxy chaining configuration, the on-premises proxy forwards traffic to ‚ÄčSIA‚Äč Proxy. DNS requests are forwarded to ‚ÄčSIA‚Äč DNS. ‚ÄčSIA‚Äč Proxy performs TLS MITM decryption.

  3. If authentication is required or optional in the associated policy, the user is prompted to authenticate based on the IdP configuration. The request proceeds as long as authentication is successful.

  4. Based on the policy, an action is applied to traffic. If the traffic is allowed, the request is directed to the origin and the user is granted access. Otherwise, it is blocked and an error page is shown to the user.

    ūüďė

    If the bypass action is configured, the request bypasses TLS MITM decryption and it's sent directly to the origin IP address or the destination web server.

  5. If the request is allowed and you enabled payload analysis for large files, you can scan website content after it's downloaded by your browser. If your organization is licensed for Advanced Sandbox and you also enabled Dynamic Analysis, this content is directed to a secure sandbox environment.

‚ÄčETP Client‚Äč with no on-premises proxy

This graphic shows the flow of a request when the ‚ÄčETP Client‚Äč machine is configured as a local web proxy or as a transparent proxy where transparent traffic interception is enabled. When this configuration is in place, web requests are directed from ‚ÄčETP Client‚Äč to ‚ÄčSIA‚Äč Proxy for analysis. For more information, see ‚ÄčETP Client‚Äč for web traffic.

In this graphic:

  1. Regardless if a user is on or off the corporate network, this applies:

    • All DNS requests are directed from ‚ÄčETP Client‚Äč to ‚ÄčSIA‚Äč DNS.

    • All HTTP and HTTPS requests are directed from ‚ÄčETP Client‚Äč to ‚ÄčSIA‚Äč Proxy.

  2. Depending on the request, this applies:

    • ‚ÄčETP Client‚Äč forwards web requests to ‚ÄčSIA‚Äč Proxy where the proxy performs TLS MITM decryption.

    • ‚ÄčETP Client‚Äč forwards internal requests to the internal network based on Local Bypass Settings or an exception list. Internal requests bypass ‚ÄčSIA‚Äč Proxy and are forwarded to their destination.

  3. If authentication is required or optional in the associated policy, the user is prompted to authenticate based on the IdP configuration. The request proceeds as long as authentication is successful.

  4. Based on the policy, an action is applied to traffic. If the traffic is allowed, the request is directed to the origin and the user is granted access. Otherwise, it is blocked and an error page is shown to the user.

    ūüďė

    If the bypass action is configured, the request bypasses TLS MITM decryption and it's sent directly to the origin IP address or the destination web server.

  5. If the request is allowed and you enabled payload analysis for large files, you can scan website content after it's downloaded by your browser. If your organization is licensed for Advanced Sandbox and you also enabled Dynamic Analysis, this content is directed to a secure sandbox environment.

HTTP Forwarder as an explicit proxy

You can configure HTTP Forwarder as an explicit proxy. For this configuration, you use a proxy auto-configuration (PAC) file or modify the system or browser proxy settings of the user‚Äôs device to forward traffic to HTTP Forwarder. Traffic is then forwarded to ‚ÄčSIA‚Äč Proxy where its is scanned for malware.

In this graphic:

  1. Traffic is forwarded from end user devices to Security Connector as an HTTP Forwarder. An administrator configures device operating systems or browsers to send traffic to HTTP Forwarder through a PAC file or a device management solution. The IP address and port of HTTP forwarder is configured on the OS or browser proxy settings.
  2. HTTP Forwarder accepts traffic from the port that was set up in the Security Console console. Traffic from other ports is dropped.
  3. Traffic is then directed to ‚ÄčSIA‚Äč Proxy where it‚Äôs scanned for malware.

HTTP Forwarder as a transparent proxy

You can configure HTTP Forwarder as a transparent proxy. For this configuration, the policy-based routing (PBR) rules on the router are modified to forward traffic to HTTP Forwarder. Unlike an explicit proxy configuration, this configuration does not require your organization to modify settings on user devices.

In this graphic:

  1. User traffic is directed to the router.
  2. An administrator configures policy-based routing rules on the router to direct traffic to HTTP Forwarder. HTTP Forwarder receives traffic on the port that‚Äôs configured in ‚ÄčSIA‚Äč policy.
  3. HTTP Forwarder directs traffic to ‚ÄčSIA‚Äč Proxy where it‚Äôs scanned for malware.

IPsec Tunnels

You can configure IPsec tunnels to direct traffic from your office branch to ‚ÄčSIA‚Äč Proxy. This method uses an organization's SD-WAN solution to create these tunnels. For more information, see Set up IPsec tunnels.

In this graphic:

  1. An SD-WAN appliance forwards traffic from the organization‚Äôs branch. Traffic from branches that are configured as known locations in ‚ÄčSIA‚Äč are forwarded and accepted by ‚ÄčSIA‚Äč.

    The SD-WAN Orchestrator or the portal used to manage the SD-WAN solution is where an administrator configures the primary and secondary tunnels that send and receive traffic. The secondary tunnel serves as a backup tunnel in case of failure. An ‚ÄčSIA‚Äč administrator configures specific settings in ‚ÄčSIA‚Äč to establish communication with the IPsec tunnel.

  2. The IPsec tunnels that are created direct traffic to ‚ÄčSIA‚Äč Proxy.

  3. ‚ÄčSIA‚Äč Proxy inspects traffic and handles it based on ‚ÄčSIA‚Äč policy. If traffic is allowed, it is directed to the origin.