Content Filtering
Content Filtering provides basic data loss prevention functionality. Content filtering filters traffic is based on MIME type, file extension, and protocol commands. You can also use the content filter module to block ActiveX, Java Applets, and other types of content. Content filtering does not require a separate license. For more information, see the following topics:
Content Filtering Overview
- Content Filtering Based on File Type
- Content Filtering Based on File Content
- Dynamic File Type Signatures
Content Filtering Based on File Type
Previously, content filtering was performed to block or permit certain types of traffic based on the MIME type, file extension, and protocol command. The content filter controls file transfers across the gateway by checking traffic against configured filter lists. This type of evaluation based on file type is supported only on Junos OS Releases before Junos OS Release 21.4R1.
Starting in Junos OS Release 21.4R1, content evaluation is done based of the file content. The file type-based evaluation of content is deprecated and the related configurations are hidden.
You can use the legacy functionality if you do not want to migrate to enhanced content filtering functionality. You will be allowed to use the legacy configurations, but all the legacy configuration knobs are deprecated and hidden. Also, you will receive system logs and error message warnings when you use the legacy configuration options.
In this type of evaluation the content filter module evaluates the traffic before all other Content Security modules, except Web Filtering. Therefore, if traffic meets criteria configured in the content-filter, the content-filter acts first upon this traffic.
You can configure the following types of content filters:
-
MIME Pattern Filter — MIME patterns are used to identify the type of traffic in HTTP and MAIL protocols. We have two lists of MIME patterns that are used by the content filter to determine the action to be taken. The block MIME list contains a list of MIME type traffic that is to be blocked by the content filter. The MIME exception list contains MIME patterns that are not to be blocked by the content filter and are generally subsets of items on the blocklist. Note that the exception list has a higher priority than the blocklist. If you have MIME entries that appear on both lists, those MIME types are not blocked by the content filter because the exception list takes priority. Therefore, when adding items to the exception list, it is to your advantage to be specific.
-
Block Extension List — Because the name of a file is available during file transfers, using file extensions is a highly practical way to block or allow file transfers. The content filter list contains a list of file extensions to be blocked. All protocols support the use of the block extension list.
-
Protocol Command Block and Permit Lists — Different protocols use different commands to communicate between servers and clients. By blocking or allowing certain commands, traffic can be controlled on the protocol command level.
The block and permit command lists are intended to be used in combination, with the permit list acting as an exception list to the blocklist.
If a protocol command appears on the both the permit list and the blocklist, that command is permitted.
Starting with Junos OS Release 15.1X49-D100, IPv6 pass-through traffic for HTTP, FTP, SMTP, POP3, IMAP protocols is supported for Web filtering and Content filtering security features of Content Security.
MIME type or the file extension cannot cover all harmful files or components. Hence, you can also use the content filter module to block ActiveX, Java Applets, and other types of content. The following types of content blocking are supported only for HTTP:
-
Block ActiveX
-
Block Java applets
-
Block cookies
-
Block EXE files
-
Block ZIP files
Content Filtering Based on File Content
Content filtering was previously performed based on file type, mime-type, content-type, and protocol command. File detection using the MIME type, protocol command filters, or by file extension filters is not reliable always. The easiest way to identify a file type is by filename extensions, but it is not authentic as any extension can be given to any kind of file.
Starting in Junos OS Release 21.4R1, Content Security performs content filtering to determine the file type based on the file content and not based on the file extensions. The file content is first analyzed to accurately determine the file type. This feature complements application identification (App ID). Content filtering based on file type enables you to configure the firewall for identifying, controlling, and protecting access to Web (HTTP and HTTPS) traffic. When the final application match is confirmed by App ID, the matching Content Security policy is considered for content filtering.
Content filtering based on file content is performed as follows:
-
File identification: Rules are defined to examine the content and determine the file type. Content Security process uses the file content and matches it against the rules defined to determine the file type.
-
Define content filtering rules for traffic direction: The Content Security process reads configuration from CLI, parses and interprets rule sets and rules. You can define the content filtering rules and enforce the rules to direct the traffic.
Rule set and rules configurations are added under the
[edit security utm utm-policy <utm-policy-name> content-filtering]hierarchy level.You can configure connection reset option in the content filter rule. When the content listed within the rule is detected, protocol handlers perform TCP connection reset with the client and server exactly as configured in the policy.
Note:Content filtering options based on mime-type, content-type, and protocol command is not supported. After you upgrade to Junos OS Release 21.4R1, previously existing file extension based content filtering options under the
[edit security utm utm-policy <utm-policy-name> content-filtering]and[edt security utm feature-profile content-filtering profile <profile-name>hierarchies are not supported. - Use the rules and rules sets defined for content filtering: You can use the rules
and rule sets defined above from the
[edit security utm default-configuration content-filteringhierarchy. These rules and rule-set allows you to configure direction specific content filters and connection reset. -
Content Security policy selection for content filtering: Once final application match is confirmed by APP ID, the matching potential Content Security policy in which content filtering rules are defined is chosen for processing.
For every Content Security policy, a chain is created with list of rule set nodes. All rules configured under a rule set are added to a list and then attached to the respective rule set node.
After all checks are passed, a unique ID is allocated for each rule set and rule configured to preserve and organize respective information in the local memory. This storage in the local memory is required to track the configuration changes you make and to synchronize the updates.
-
Verification: Use the following commands to view the content-filtering system statistics and errors.
-
To display content filtering statistics in a policy within root-logical-system use the
show security utm content-filtering statistics utm policy <utm policy name>andshow security utm content-filtering statistics root-logical-system utm-policy <utm policy name>commands. -
To display content filtering statistics in a policy within a specified logical system use the
show security utm content-filtering statistics logical-system <logical-system-name> utm-policy <utm policy name>command.
-
If you migrate to this new feature and the legacy options are available in your configurations, then you will receive the following error messages and commit will fail.
Deprecated features can't go together with enhanced content filtering (rule-set/rule)\n");Remove configuration marked as deprecated to get ahead (For details: show security utm)\n")You can use legacy content filtering functionality if you don’t want to migrate to the enhanced content filtering feature. The legacy configuration options are deprecated and are hidden. You will receive the following error message when you use the deprecated legacy options.
ERRMSG (“The config \'%s\' is deprecated”, “security utm utm-policy <> content-filtering http-profile")Benefits of Content Filtering Based on File Content
-
Provides safe web access and protects your network from attacks using accurately detected file-types in the content filtering rules.
-
Controls the traffic that traverses your network and enforces content filtering rules based on traffic direction.
-
Improved log messages to include user and source identity, session ID, and packet direction information.
Starting in Junos OS Release 22.4R1, Content Security content filtering module is integrated with the JDPI parser and the JDPI contexts are used to invoke the content filtering functionalities.
Content Security content filtering packet and stream plug-in are added to handle plain traffic.
While taking actions for mail protocols, TCP proxy dependency is removed.
notify-mail-sender CLI configuration support is removed for mail
protocols.
Dynamic File Type Signatures
Dynamic file type signatures introduce a flexible and efficient method for managing file type signatures data. Storing the file type signatures in a structured JSON format on a cloud-hosted server enables you to download, install, and update the file type signatures without modifying the underlying content filtering code. This functionality provides seamless adaptation to new file types, ensuring network security against evolving threats. The system supports automatic download scheduling, fallback mechanisms for installation failures, and local updates, providing robust options for maintaining current signature data.
The CLI commands facilitate managing the operations such as control over file type signatures downloads, installations, and rollbacks effectively:
When you deploy the device first time, it comes up with the default file type signatures. User can download and install the latest version using the download and install CLI commands. If the new signatures installation fails at any stage, the device reverts to the default file signatures.
After successful installation of a new signatures version, the device moves the existing version to last good version. When you give a manual rollback, the system reverts to last good signatures version.
If no last good signatures version is available, the manual rollback will give the error
Manual Rollback Failed; No backup available for rollback.
Automatic download scheduling enables your device to fetch and apply new signatures at
predefined intervals. This automation minimizes manual intervention, keeping the
signature data current. Use the edit security utm custom-objects
file-signatures CLI command to configure the parameters, which allows
configuration of URLs, proxy profiles, and routing instances. This flexibility is vital
for maintaining robust security measures across distributed network environments.
High Availability (HA) support is integral to the dynamic file type signatures management system, ensuring synchronized updates across all nodes in a distributed network environment. This capability is crucial for maintaining consistent threat protection, facilitating seamless download and installation of file signatures on all participating devices. The system employs mechanisms to ensure that file signature updates propagate correctly, even in the event of one node experiencing failure or connectivity issues.
Benefits of Dynamic File Type Signatures
-
Enable rapid adaptation to new file types by allowing updates without altering the system software, thus maintaining security against emerging threats.
-
Simplify the file type signatures update process with automatic download scheduling, ensuring that file signature data remains current without manual intervention.
-
Support operational continuity through local file type signatures update capabilities.
See Also
Understand Content Filtering Protocol Support
Each supported protocol may implement available content filters differently. Not all filtering capabilities are supported for each protocol. This topic contains the following sections:
HTTP Support
The HTTP protocol supports all content filtering features. With HTTP, the content filter remains in the gateway, checking every request and response between the HTTP client and server.
If an HTTP request is dropped due to content filtering, the client receives a response such as:
<custom drop message/user-configured drop message>.<src_port><dst_ip>:<dst_port>Download request was dropped due to <reason>
Therefore, a message may appear as follows:
Juniper Networks Firewall Content Filtering blocked request. 5.5.5.1:80->4.4.4.1:55247 Download request was dropped due to file extension block list
FTP Support
The FTP protocol does not support all content filtering features. It supports only the following: Block Extension List and Protocol Command Block List.
When content filtering blocks an FTP request, the following response is sent through the control channel:
550 <src_ip>:<src_port>-<dst_ip>:<dst_port><custom drop message/user-configured drop message> for Content Filtering file extension block list.>
Therefore, a message may appear as follows:
550 5.5.5.1:21->4.4.4.1:45237 Requested action not taken and the request is dropped for Content Filtering file extension block list
E-Mail Support
E-mail protocols (SMTP, IMAP, POP3) have limited content filtering support for the following features: Block Extension List, Protocol Command Block List, and MIME Pattern Filtering. Support is limited for e-mail protocols for the following reasons:
The content filter scans only one level of an e-mail header. Therefore recursive e-mail headers and encrypted attachments are not scanned.
If an entire e-mail is MIME encoded, the content filter can only scan for the MIME type.
If any part of an e-mail is blocked due to content filtering, the original e-mail is dropped and replaced by a text file with an explanation for why the e-mail was blocked.
Starting from Junos OS Release 19.4R1, the antivirus and content filtering feature supports implicit and explicit SMTPS, IMAPS, and POP3S protocol, and supports only explicit passive mode FTPS.
Implicit mode—Connect to SSL/TLS encrypted port using secure channel.
Explicit mode—First connect to unsecured channel, then secure the communication by issuing STARTTLS command. For POP3S, use STLS command.
See Also
Monitoring Content Filtering Configurations
Purpose
View content filtering statistics.
Action
To view content filtering statistics in the CLI, enter
the user@host > show security utm content-filtering
statistics command.
The content filtering show statistics command
displays the following information:
Base on command list: # Blocked Base on mime list: # Blocked Base on extension list: # Blocked ActiveX plugin: # Blocked Java applet: # Blocked EXE files: # Blocked ZIP files: # Blocked HTTP cookie: # Blocked
To view content filtering statistics using J-Web:
Select Clear Content filtering statistics Monitor>Security>UTM>Content Filtering Monitor>Security>UTM>Content Filtering.
The following statistics become viewable in the right pane.
Base on command list: # Passed # Blocked Base on mime list: # Passed # Blocked Base on extension list: # Passed # Blocked ActiveX plugin: # Passed # Blocked Java applet: # Passed # Blocked EXE files: # Passed # Blocked ZIP files: # Passed # Blocked HTTP cookie: # Passed # Blocked
You can click Clear Content filtering statistics to clear all current viewable statistics and begin collecting new statistics.
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.