Web Filtering Overview
The Web filtering lets you to manage Internet usage by preventing access to inappropriate Web content. There are three types of Web filtering solutions:
Redirect Web filtering—The redirect Web filtering solution intercepts HTTP and HTTPS requests and sends them to an external URL filtering server, provided by Websense, to determine whether to block the requests.
Redirect Web filtering does not require a license.
Local Web filtering—The local Web filtering solution intercepts every HTTP request and the HTTPS request in a TCP connection. In this case, the decision making is done on the device after it looks up a URL to determine if it is in the allowlist or blocklist based on its user-defined category.
Local Web filtering does not require a license or a remote category server.
Enhanced Web filtering—The enhanced Web filtering solution intercepts the HTTP and the HTTPS requests and sends the HTTP URL or the HTTPS source IP to the Websense ThreatSeeker Cloud (TSC). The TSC categorizes the URL into one of the 151 or more categories that are predefined and also provides site reputation information. The TSC further returns the URL category and the site reputation information to the device. The device determines if it can permit or block the request based on the information provided by the TSC.
Starting in Junos OS Release 17.4R1, Websense redirect support IPv6 traffic.
You can bind either Web filtering profiles or antivirus profiles, or both, to a firewall policy. When both are bound to a firewall policy, Web filtering is applied first, then antivirus is applied. If a URL is blocked by Web filtering, the TCP connection is closed and no antivirus scanning is necessary. If a URL is permitted, the content of the transaction is then passed to the antivirus scanning process.
Web filtering is applied by TCP port number.
Web filtering supports HTTPS protocol. Web filtering solution uses the IP address of the HTTPS packet to make blocklist, allowlist, permit, or block decisions.
During a block decision, the Web filtering solution does not generate a block page because the clear text is not available for a HTTPS session. However, the solution terminates the session and sends resets to the client and the server for the blocked HTTPS sessions.
Web filtering configuration for HTTP is also applicable for the HTTPS sessions.
The sessions-per-client limit CLI command, which imposes a session throttle to prevent a malicious user from generating large amounts of traffic simultaneously, does not support Web filtering.
Starting with Junos OS Release 15.1X49-D100, IPv6 pass-through traffic for HTTP, HTTPS, FTP, SMTP, POP3, IMAP protocols is supported for Web filtering and Content filtering security features of Content Security.
Server Name Indication (SNI) Support
SNI is an extension of SSL/TLS protocol to indicate what server name the client is contacting over an HTTPS connection. SNI inserts the actual hostname of the destination server in "Client Hello" message in clear text format before the SSL handshake is complete. Web filtering includes SNI information in the query. In this implementation, the SNI includes only the server name, and not the full URL of the server. Support of SNI enhances the Web filtering feature as using only destination IP address in the query might lead to inaccurate results, because multiple HTTP servers might share the same host IP address.
With SNI support, Web filtering analyzes the first packet of the HTTPS traffic as a "Client Hello" message and extracts the server name from the SNI extension, and uses server name along with the destination IP address to maintain/run the query. If this packet has no SNI extension or if an error is encountered during parsing, Web filtering reverts to using only destination IP address.
In Web Filtering (EWF), if HTTPS session with SSL forward proxy is enabled, then the Server Name Indication (SNI) is obtained before Web filtering and used for pre-check query, site-reputation and category in response. If the cache is enabled, then these responses populates the cache without any action. EWF extracts the full path and checks if there is a cache. If the full path in the cache is not matched, then the EWF sends a query.
The SNI functionality is enabled by default for all types of Web filtering, and therefore, no additional configuration using the CLI is required.