Juniper SRX SG ALG Security Technical Implementation Guide

V1R4 2019-06-28       U_Juniper_SRX_SG_ALG_V1R4_Manual-xccdf.xml
V1R1 2016-03-31       U_Juniper_SRX_SG_ALG_STIG_V1R1_Manual-xccdf.xml
This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via e-mail to the following address: [email protected]
Comparison
All 24
No Change 21
Updated 3
Added 0
Removed 0
V-66003 No Change
Findings ID: JUSX-AG-000019 Rule ID: SV-80493r1_rule Severity: medium CCI: CCI-000213

Discussion

Successful authentication must not automatically give an entity access to an asset or security boundary. The lack of authorization-based access control could result in the immediate compromise and unauthorized access to sensitive information. All DoD systems must be properly configured to incorporate access control methods that do not rely solely on authentication for authorized access.

Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset.

The Juniper Technical Library, Understanding User Role Firewalls, explains this Juniper SRX functionality in detail. This function integrates user-based firewall policies. Administrators can permit or restrict network access of employees, contractors, partners, and other users based on the roles they are assigned. User role firewalls enable greater threat mitigation, provide more informative forensic resources, improve record archiving for regulatory compliance, and enhance routine access provisioning. User role firewalls are more feasible with sites that do not have production workload and are used for employees to access network resources as opposed to large-scale datacenter environments.

User role firewalls trigger two actions, retrieval of user and/or role information associated with the traffic, and determine the action to take based on six match criteria within the context of the zone pair.

The source-identity field distinguishes a user role firewall from other types of firewalls. If the source identity is specified in any policy for a particular zone pair, it is a user role firewall. The user and role information must be retrieved before policy lookup occurs. If the source identity is not specified in any policy, user and role lookup is not required.

To retrieve user and role information, authentication tables are searched for an entry with an IP address corresponding to the traffic. If an entry is found, the user is classified as an authenticated user. If not found, the user is classified as an unauthenticated user.

The username and roles associated with an authenticated user are retrieved for policy matching. Both the authentication classification and the retrieved user and role information are used to match the source-identity field.

Characteristics of the traffic are matched to the policy specifications. Within the zone context, the first policy that matches the user or role and the five standard match criteria determines the action to be applied to the traffic."

Checks

If user-based firewall policies are not used, this is not applicable.

To verify the existence of user-based firewall policies, view a summary of all policies configured on the firewall.

[edit]
show security policies

If the source identity is not specified in any policy for a particular zone pair, this is a finding.

Fix

Configure attribute-based security policies to enforce approved authorizations for logical access to information and system resources using the following commands.

To configure redirection from the SRX Series device to the Access Control Service, from configuration mode, configure the UAC profile for the captive portal <acs-device>.

[edit]
set services unified-access-control captive-portal <acs-device-name> redirect-traffic unauthenticated

Configure the redirection URL for the Access Control Service or a default URL for the captive portal.

[edit]
set services unified-access-control captive-portal acs-device redirect-url https://%ic-url%/?target=%dest-url%&enforcer=%enforcer-id%

This policy specifies the default target and enforcer variables to be used by the Access Control Service to direct the user back after authentication. This ensures that changes to system specifications will not affect configuration results.

Configure a user role firewall policy that redirects HTTP traffic from zone trust to zone untrust if the source-identity is unauthenticated-user. The captive portal profile name is specified as the action to be taken for traffic matching this policy. The following is an example only since there the actual policy is dependent on the architecture of the organization's network.

[edit]
set security policies from-zone trust to-zone untrust policy user-role-fw1 match source-address any
set security policies from-zone trust to-zone untrust policy user-role-fw1 match destination-address any
set security policies from-zone trust to-zone untrust policy user-role-fw1 match application http
set security policies from-zone trust to-zone untrust policy user-role-fw1 match source-identity unauthenticated-user
set security policies from-zone trust to-zone untrust policy user-role-fw1 then permit app
V-66303 No Change
Findings ID: JUSX-AG-000036 Rule ID: SV-80793r1_rule Severity: medium CCI: CCI-000172

Discussion

Without generating log records that log usage of objects by subjects and other objects, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.

Security objects are data objects which are controlled by security policy and bound to security attributes.

By default, the Juniper SRX will not forward traffic unless it is explicitly permitted via security policy. Logging for Firewall security-related sources such as screens and security policies must be configured separately. To ensure firewall filters, security screens and security policies send events to a Syslog server and local logs, security logging must be configured one each firewall term.

Checks

To verify what is logged in the Syslog, view the Syslog server (Syslog server configuration is out of scope for this STIG); however, the reviewer must also verify that packets are being logged to the local log using the following commands.

From operational mode, enter the following command.

show firewall log

View the Action column; the configured action of the term matches the action taken on the packet: A (accept), D (discard).

If events in the log do not reflect the action taken on the packet, this is a finding.

Fix

Include the log and/or syslog action in all term to log packets matching each firewall term to ensure the term results are recorded in the firewall log and Syslog. To get traffic logs from permitted sessions, add "then log session-close" to each policy. To get traffic logs from denied sessions, add "then log session-init" to the policy.

Firewall filter:
[edit]
set firewall family <family name> filter <filter_name> term <term_name> then log

Examples:
set firewall family inet filter protect_re term tcp-connection then syslog
set firewall family inet filter protect_re term tcp-connection then log
set firewall family inet filter ingress-filter-v4 term deny-dscp then log
set firewall family inet filter ingress-filter-v4 term deny-dscp then syslog

Security policy and security screens:
set security policies from-zone <zone_name> to-zone <zone_name> policy <policy_name> then log

Example:
set security policies from-zone untrust to-zone trust policy default-deny then log
V-66305 No Change
Findings ID: JUSX-AG-000037 Rule ID: SV-80795r1_rule Severity: medium CCI: CCI-000172

Discussion

Without generating log records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.

Access for different security levels maintains separation between resources (particularly stored data) of different security domains.

The Juniper SRX Firewall implements security zones which are configured with different security policies based on risk and trust levels.

Checks

To verify what is logged in the Syslog, view the Syslog server (Syslog server configuration is out of scope for this STIG); however, the reviewer must also verify that packets are being logged to the local log using the following commands.

From operational mode, enter the following command.

show firewall log

View the Action column; the configured action of the term matches the action taken on the packet: A (accept), D (discard).

If events in the log do not reflect the action taken on the packet, this is a finding.

Fix

Include the log and/or syslog action in all zone configurations to log attempts to access zones. To get traffic logs from permitted sessions, add "then log session-close" to the policy. To get traffic logs from denied sessions, add "then log session-init" to the policy.

set security policies from-zone <zone_name> to-zone <zone_name> policy <policy_name> then log

Example:
set security policies from-zone untrust to-zone trust policy default-deny then log
V-66307 No Change
Findings ID: JUSX-AG-000057 Rule ID: SV-80797r1_rule Severity: medium CCI: CCI-001844

Discussion

Without the ability to centrally manage the content captured in the audit records, identification, troubleshooting, and correlation of suspicious behavior would be difficult and could lead to a delayed or incomplete analysis of an ongoing attack.

The DoD requires centralized management of all network component audit record content. Network components requiring centralized audit log management must have the capability to support centralized management. The content captured in audit records must be managed from a central location (necessitating automation). Centralized management of audit records and logs provides for efficiency in maintenance and management of records, as well as the backup and archiving of those records. Ensure at least one Syslog server and local files are configured to support requirements. However, the Syslog itself must also be configured to filter event records so it is not overwhelmed. A best practice when configuring the external Syslog server is to add similar log-prefixes to the log file names to help and researching of central Syslog server. Another best practice is to add a match condition to limit the recorded events to those containing the regular expression (REGEX). This requirement does not apply to audit logs generated on behalf of the device itself (management).

While the Juniper SRX inherently has the capability to generate log records, by default only the high facility levels are captured and only to local files.

Checks

To verify that traffic logs are being sent to the syslog server, check the syslog server files.

If traffic logs are not being sent to the syslog server, this is a finding.

Fix

Logging for security-related sources such as screens and security policies must be configured separately.

The following example specifies that security log messages in structured-data format (syslog format) are sent from the source <MGT IP address> (e.g., the SRX's loopback or other interface IP address) to an external syslog server.

[edit]
set security log cache
set security log format syslog
set security log source-address <MGT IP Address>
set security log stream <stream name> host <syslog server IP Address>

To get traffic logs from permitted sessions, add "then log session-close" to the policy.
To get traffic logs from denied sessions, add "then log session-init" to the policy. Enable Logging on Security Policies:

[edit]
set security policies from-zone <zone-name> to-zone <zone-name> policy <policy-name> then log <event>

Example to log session init and session close events:
set security policies from-zone trust to-zone untrust policy default-permit then log session-init
set security policies from-zone trust to-zone untrust policy default-permit then log session-close
V-66309 No Change
Findings ID: JUSX-AG-000063 Rule ID: SV-80799r1_rule Severity: medium CCI: CCI-000140

Discussion

It is critical that when the network element is at risk of failing to process audit logs as required, it take action to mitigate the failure. Audit processing failures include: software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. Responses to audit failure depend upon the nature of the failure mode.

Since availability is an overriding concern given the role of the Juniper SRX in the enterprise, the system must not be configured to shut down in the event of a log processing failure. The system will be configured to log events to local files which will provide a log backup. If communication with the syslog server is lost or the server fails, the network device must continue to queue log records locally. Upon restoration of the connection to the centralized collection server, action should be taken to synchronize the local log data with the collection server.

By default, both traffic log and system log events are sent to a local log file named messages. You can create a separate log file that contains only traffic log messages so that you do not need to filter for traffic log messages. This makes it easier to track usage patterns or troubleshoot issues for a specific policy.

A best practice is to add log-prefixes to the log file names to help in researching the events and filters to prevent log overload. Another best practice is to add a match condition to limit the recorded events to those containing the regular expression (REGEX).

Checks

Verify logging has been enabled and configured.

[edit]
show log <LOG-NAME> match "RT_FLOW_SESSION"

If a local log file or files is not configured to capture "RT_FLOW_SESSION" events, this is a finding.

Fix

The following example commands configure local backup files to capture DoD-defined auditable events.

[edit]
set system syslog file <LOG-NAME> any info
set system syslog file <LOG-NAME> match "RT_FLOW_SESSION "

Example:
set system syslog file<LOG-NAME> match "RT_FLOW_SESSION "
V-66311 No Change
Findings ID: JUSX-AG-000083 Rule ID: SV-80801r1_rule Severity: medium CCI: CCI-000381

Discussion

Network devices are capable of providing a wide variety of functions (capabilities or processes) and services. Some of these functions and services are installed and enabled by default. The organization must determine which functions and services are required to perform the content filtering and other necessary core functionality for each component of the SRX. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors.

Services that may be related security-related, but based on the role of the device in the architecture do not need to be installed. For example, the Juniper SRX can have an Antivirus, Web filter, IDS, or ALG license. However, if these functions are not part of the documented role of the SRX in the enterprise or branch architecture, then these the software and licenses should not be installed on the device. This mitigates the risk of exploitation of unconfigured services or services that are not kept updated with security fixes. If left unsecured, these services may provide a threat vector.

Only remove unauthorized services. This control is not intended to restrict the use of Juniper SRX devices with multiple authorized roles.

Checks

Review the documentation and architecture for the device.

<root>
show system license

If unneeded services and functions are installed on the device, but are not part of the documented role of the device, this is a finding.

Fix

Remove unnecessary services and functions. From operational mode, display the licenses available to be deleted; enter the following commands.

request system license delete license-identifier-list ?
request system license delete <license-identifier>

Note: Only remove unauthorized services. This control is not intended to restrict the use of Juniper SRX devices with multiple authorized roles.
V-66313 No Change
Findings ID: JUSX-AG-000084 Rule ID: SV-80803r1_rule Severity: medium CCI: CCI-000381

Discussion

Information systems are capable of providing a wide variety of functions (capabilities or processes) and services. Some of these functions and services are installed and enabled by default. The organization must determine which functions and services are required to perform the content filtering and other necessary core functionality for each component of the SRX. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors.

The Juniper SRX is a highly configurable platform that can fulfil many roles in the Enterprise or Branch architecture depending on the model installed. Some services are employed for management services; however, these services can often also be provided as a network service on the data plane. Examples of these services are NTP, DNS, and DHCP. Also, as a Next Generation Firewall (NGFW) and Unified Threat Management (UTM) device, the SRX integrate functions which have been traditionally separated.

The SRX may integrate related content filtering, security services, and analysis services and tools (e.g., IPS, proxy, malware inspection, black/white lists). Depending on licenses purchased, gateways may also include email scanning, decryption, caching, VPN, and DLP services. However, services and capabilities which are unrelated to this primary functionality must not be installed (e.g., DNS, email server, FTP server, or web server).

Checks

Check both the zones and the interface stanza to ensure NTP is not configured as a service option.

[edit]
show security zones

and, for each interface used, enter:

show security zones <zone-name> interface <interface-name>

If NTP is included in any of the zone or interface stanzas, this is a finding.

Fix

Delete NTP options from zones and interface commands. Re-enter the set security zone command without the "ntp" attribute. The exact command entered depends how the zone is configured with the authorized attributes, services, and options.

Examples:

[edit]
set security zones security-zone <zone-name> interfaces <interface-name> host-inbound-traffic
V-66315 No Change
Findings ID: JUSX-AG-000085 Rule ID: SV-80805r1_rule Severity: medium CCI: CCI-000381

Discussion

Information systems are capable of providing a wide variety of functions (capabilities or processes) and services. Some of these functions and services are installed and enabled by default. The organization must determine which functions and services are required to perform the content filtering and other necessary core functionality for each component of the SRX. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors.

The Juniper SRX is a highly configurable platform that can fulfil many roles in the Enterprise or Branch architecture depending on the model installed. Some services are employed for management services; however, these services can often also be provided as a network service on the data plane. Examples of these services are NTP, DNS, and DHCP. Also, as a Next Generation Firewall (NGFW) and Unified Threat Management (UTM) device, the SRX integrate functions which have been traditionally separated.

The SRX may integrate related content filtering, security services, and analysis services and tools (e.g., IPS, proxy, malware inspection, black/white lists). Depending on licenses purchased, gateways may also include email scanning, decryption, caching, VPN, and DLP services. However, services and capabilities which are unrelated to this primary functionality must not be installed (e.g., DNS, email server, FTP server, or web server).

Checks

Check both the zones and the interface stanza to ensure DNS proxy server services are not configured.

[edit]
show system services dns

If a stanza exists for DNS (e.g., forwarders option), this is a finding.

Fix

First, remove the DNS stanza. Then re-enter the set security zones and interfaces command without the "dns" attribute. The exact command entered depends how the zone is configured with the authorized attributes, services, and options.

Examples:

[edit]
delete system services dns
set security zones security-zone <zone-name> interfaces <interface-name> host-inbound-traffic
V-66317 No Change
Findings ID: JUSX-AG-000086 Rule ID: SV-80807r1_rule Severity: medium CCI: CCI-000381

Discussion

Information systems are capable of providing a wide variety of functions (capabilities or processes) and services. Some of these functions and services are installed and enabled by default. The organization must determine which functions and services are required to perform the content filtering and other necessary core functionality for each component of the SRX. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors.

The Juniper SRX is a highly configurable platform that can fulfil many roles in the Enterprise or Branch architecture depending on the model installed. Some services are employed for management services; however, these services can often also be provided as a network service on the data plane. Examples of these services are NTP, DNS, and DHCP. Also, as a Next Generation Firewall (NGFW) and Unified Threat Management (UTM) device, the SRX integrate functions which have been traditionally separated.

The SRX may integrate related content filtering, security services, and analysis services and tools (e.g., IPS, proxy, malware inspection, black/white lists). Depending on licenses purchased, gateways may also include email scanning, decryption, caching, VPN, and DLP services. However, services and capabilities which are unrelated to this primary functionality must not be installed (e.g., DNS, email server, FTP server, or web server).

Checks

Check both the zones and the interface stanza to ensure DHCP proxy server services are not configured.

[edit}
show system services dhcp

If a stanza exists for DHCP (e.g., forwarders option), this is a finding.

Fix

First, remove the DHCP stanza. Then re-enter the set security zones and interfaces command without the "dhcp" attribute. The exact command entered depends how the zone is configured with the authorized attributes, services, and options.

Examples:

[edit]
delete system services dhcp
set security zones security-zone <zone-name> interfaces <interface-name> host-inbound-traffic
V-66319 No Change
Findings ID: JUSX-AG-000087 Rule ID: SV-80809r1_rule Severity: medium CCI: CCI-000382

Discussion

In order to prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types); organizations must disable or restrict unused or unnecessary physical and logical ports/protocols on information systems.

DoD continually assesses the ports, protocols, and services that can be used for network communications. Some ports, protocols or services have known exploits or security weaknesses. Network traffic using these ports, protocols, and services must be prohibited or restricted in accordance with DoD policy. The PPSM CAL and vulnerability assessments provide an authoritative source for ports, protocols, and services that are unauthorized or restricted across boundaries on DoD networks.

The Juniper SRX must be configured to prevent or restrict the use of prohibited ports, protocols, and services throughout the network by filtering the network traffic and disallowing or redirecting traffic as necessary. Default and updated policy filters from the vendors will disallow older version of protocols and applications and will address most known non-secure ports, protocols, and/or services.

Checks

Entering the following commands from the configuration level of the hierarchy.

[edit]
show security services

If functions, ports, protocols, and services identified on the PPSM CAL are not disabled, this is a finding.

Fix

Ensure functions, ports, protocols, and services identified on the PPSM CAL are not used for system services configuration.

[edit]
show security services

Compare the services which are enabled, including the port, services, protocols and functions.

Consult the Juniper knowledge base and configuration guides to determine the commands for disabling each port, protocol, service or function that is not in compliance with the PPSM CAL and vulnerability assessments.
V-66321 No Change
Findings ID: JUSX-AG-000105 Rule ID: SV-80811r1_rule Severity: medium CCI: CCI-001133

Discussion

Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. In addition, quickly terminating an idle session will also free up resources committed by the managed network element.

This control does not imply that the device terminates all sessions or network access; it only ends the inactive session.

Since many of the inactivity timeouts pre-defined by Junos OS are set to 1800 seconds, an explicit custom setting of 900 must be set for each application used by the DoD implementation. Since a timeout cannot be set directly on the predefined applications, the timeout must be set on the any firewall rule that uses a pre-defined application (i.e., an application that begins with junos-), otherwise the default pre-defined timeout will be used.

Checks

Check both the applications and protocols to ensure session inactivity timeout for communications sessions is set to 900 seconds or less.

First get a list of security policies, then enter the show details command for each policy-name found.

[edit]
show security policies
show security policy <policy-name> details

Example:
Application: any
IP protocol: 0, ALG: 0, Inactivity timeout: 0

Verify an activity timeout is configured for either "any" application or, at a minimum, the pre-defined applications (i.e., application names starting with junos-).

To verify locally created applications, first get a list of security policies, then enter the show details command for each policy-name found.

[edit]
Show applications
show applications application <application-name>

If an inactivity timeout value of 900 seconds or less is not set for each locally created application and pre-defined applications, this is a finding.

Fix

Add or update the session inactivity timeout for communications sessions to 900 seconds or less.

Examples:
[edit]
set applications application <application-name> term 1 protocol udp inactivity-timeout 900
set applications application junos-http inactivity-timeout 900

Or

Create a service that matches any TCP/UDP:
[edit]
set applications application TCP-ALL source-port 1-65535 destination-port 1-65535 protocol tcp inactivity-timeout 900

Note: When pre-defined applications are used in firewall policies, the timeout value must be set in the policy stanza.
V-66323 Updated
Findings ID: JUSX-AG-000120 Rule ID: SV-80813r12_rule Severity: high CCI: CCI-002385

Discussion

If the network does not provide safeguards against DoS attacks, network resources will be unavailable to users. Installation of content filtering gateways and application layer firewalls at key boundaries in the architecture mitigates the risk of DoS attacks. These attacks can be detected by matching observed communications traffic with patterns of known attacks and monitoring for anomalies in traffic volume/type.

Juniper SRX Firewall DoS protections can be configured
by either withinusing a Screen or within the global flow options. Screens, also known as IDS-options, block various layer 3 and 4 attacks. Screen objects are configured with various screen-specific options and then assigned to a zone. The Juniper SRX can be configured with Screens to protect against the following statistics-based DoS attacks: IP sweeps, port scans, and flood attacks.

Checks

Run the following command to see the screen options currently configured:

[edit]
show security screen ids-option
show security zone match "screen"

If security screens are not configured or if the security zone is not configured with screen options, this is a finding.

Fix

The following example commands configure security screens under a profile named untrust-screen. Screen options, especially those with configurable thresholds, mustay be customized for your specific deploymentto minimize/prevent operational impact on traffic performance.

[edit]
set security screen ids-option <zone-name> <screen name> <option name> <value>

Based on 800-53 requirements and vendor recommendations, the following DoS screens are required, at a minimum, for use in DoD configurations.

set security screen ids-option untrust-screen icmp ip-sweep threshold 1000
set security screen ids-option untrust-screen tcp port-scan threshold 1000
set security screen ids-option untrust-screen tcp sin-flood alarm-threshold 1000
set security screen ids-option untrust-screen tcp syn-flood attack-threshold 1100
set security screen ids-option untrust-screen tcp syn-flood source-threshold 100
set security screen ids-option untrust-screen tcp syn-flood destination-threshold 2048
set security screen ids-option untrust-screen tcp syn-flood timeout 20
set security screen ids-option untrust-screen tcp tcp-sweep threshold 1000
set security screen ids-option untrust-screen udp flood threshold 5000
set security screen ids-option untrust-screen udp udp-sweep threshold 1000

To enable screen protection, the screen profile must be associated with individual security zones using the following command. Recommend assigning "untrust-screen" profile name to the default zone named "untrust".

[edit]
set security zone security-zone <zone-name> screen <screen-profile>
Example: set security zones security-zone untrust screen untrust-screen
V-66325 No Change
Findings ID: JUSX-AG-000121 Rule ID: SV-80815r1_rule Severity: medium CCI: CCI-002385

Discussion

If the network does not provide safeguards against DoS attacks, network resources will be unavailable to users. Load balancing provides service redundancy, which reduces the susceptibility of the ALG to many DoS attacks.

This requirement applies to the network traffic functionality of the device as it pertains to handling network traffic. Some types of attacks may be specialized to certain network technologies, functions, or services. For each technology, known and potential DoS attacks must be identified and solutions for each type implemented.

The Juniper SRX provides a number of methods for load balancing the traffic flow. The device can be configured for filter based forwarding, per flow load balancing, per-packet load balancing, or High Availability (HA) using additional hardware. Since the firewall is considered a critical security system, it is imperative that perimeter firewalls, at a minimum, be safeguarded with redundancy measures such as HA.

Checks

Since load balancing is a highly complex configuration that can be implemented using a wide variety of configurations, ask the site representative to demonstrate the method used and the configuration.

If load balancing is not implemented on the perimeter firewall, this is a finding.

Fix

Consult vendor configuration guides and knowledge base. Implement one or more methods of load balance (e.g., filter based forwarding, per flow load balancing, per-packet load balancing, or High Availability [HA]).
V-66327 Updated
Findings ID: JUSX-AG-000122 Rule ID: SV-80817r12_rule Severity: high CCI: CCI-002385

Discussion

If the network does not provide safeguards against DoS attacks, network resources will be unavailable to users. Installation of content filtering gateways and application layer firewalls at key boundaries in the architecture mitigates the risk of DoS attacks. These attacks can be detected by matching observed communications traffic with patterns of known attacks.

Juniper SRX Firewall DoS protections can be configured
by either withinusing a Screen or within the global flow options. Screens, also known as IDS-options, block various layer 3 and 4 attacks. Screen objects are configured with various screen-specific options and then assigned to a zone. The Juniper SRX can be configured with Screens to protect against the following signature-based DoS attacks: ICMP based attacks such as ping of death, IP based attacks such as IP spoofing and teardrop, and TCP based attacks such as TCP headers and land.

Checks

Run the following command to see the screen options currently configured:

[edit]
show security screen ids-option
show security zone match "screen"

If security screens are not configured or if the security zone is not configured with screen options, this is a finding.

Fix

The following example commands configure security screens under a profile named untrust-screen. Screen options, especially those with configurable thresholds, mustay be customized for your specific deploymentto minimize/prevent operational impact on traffic performance.

[edit]
set security screen ids-option <zone-name> <screen name> <option name> <value>

Based on 800-53 requirements and vendor recommendations, the following signature-based screens are required, at a minimum, for use in DoD configurations.

set security screen ids-option untrust-screen icmp ping-death
set security screen ids-option untrust-screen ip bad-option
set security screen ids-option untrust-screen ip record-route-option
set security screen ids-option untrust-screen ip timestamp-option
set security screen ids-option untrust-screen ip security-option
set security screen ids-option untrust-screen ip stream-option
set security screen ids-option untrust-screen ip spoofing
set security screen ids-option untrust-screen ip source-route-option
set security screen ids-option untrust-screen ip unknown-protocol
set security screen ids-option untrust-screen ip block-frag
set security screen ids-option untrust-screen ip tear-drop
set security screen ids-option untrust-screen ip ipv6-extension-header hop-by-hop-header
jumbo-payload-option
set security screen ids-option untrust-screen ip ipv6-extension-header hop-by-hop-header
router-alert-option
set security screen ids-option untrust-screen ip ipv6-extension-header hop-by-hop-header
quick-start-option
set security screen ids-option untrust-screen ip ipv6-extension-header routing-header
set security screen ids-option untrust-screen ip ipv6-extension-header fragment-header
set security screen ids-option untrust-screen ip ipv6-extension-header no-next-header
set security screen ids-option untrust-screen ip ipv6-extension-header shim6-header
set security screen ids-option untrust-screen ip ipv6-extension-header mobility-header
set security screen ids-option untrust-screen ip ipv6-malformed-header
set security screen ids-option untrust-screen tcp syn-fin
set security screen ids-option untrust-screen tcp fin-no-ack
set security screen ids-option untrust-screen tcp tcp-no-flag
set security screen ids-option untrust-screen tcp syn-frag
set security screen ids-option untrust-screen tcp land

To enable screen protection, the screen profile must be associated with individual security zones using the following command. Recommend assigning "untrust-screen" profile name to the default zone named "untrust".

[edit]
set security zone security-zone <ZONE NAME> screen <SCREEN PROFILE NAME>
Example: set security zones security-zone untrust screen untrust-screen
V-66329 No Change
Findings ID: JUSX-AG-000124 Rule ID: SV-80819r1_rule Severity: medium CCI: CCI-001094

Discussion

DoS attacks can take multiple forms but have the common objective of overloading or blocking a network or host to deny or seriously degrade performance. If the network does not provide safeguards against DoS attack, network resources will be unavailable to users. The Juniper SRX must include protection against DoS attacks that originate from inside the enclave, which can affect either internal or external systems. These attacks may use legitimate or rogue endpoints from inside the enclave. These attacks can be simple "floods" of traffic to saturate circuits or devices, malware that consumes CPU and memory on a device or causes it to crash, or a configuration issue that disables or impairs the proper function of a device. For example, an accidental or deliberate misconfiguration of a routing table can misdirect traffic for multiple networks.

The Juniper SRX Firewall uses Screens and Security Policies to detect known DoS attacks with known attack vectors. However, these Screens and policies must be applied to outbound traffic using zones and interface stanzas.

Traffic exits the Juniper SRX by way of interfaces. Security zones are configured for one or more interfaces with the same security requirements for filtering data packets. A security zone implements a security policy for one or multiple network segments. These policies must be applied to inbound traffic as it crosses both the network perimeter and as it crosses internal security domain boundaries.

Checks

Obtain and review the list of outbound interfaces and zones. This is usually part of the System Design Specification or Accreditation Package.

Review each of the configured outbound interfaces and zones. Verify zones that communicate outbound have been configured with DoS screens.

[edit]
show security zones <security-zone-name>

If the zone for the security screen has not been applied to all outbound interfaces, this is a finding.

Fix

To enable screen protection, the screen profile must be associated with individual security zones using the following command. Recommend assigning "untrust-screen" profile name.

Apply screen to each outbound interface example:

set security zones security-zone untrust interfaces <OUTBOUND-INTERFACE>
set security zones security-zone trust screen untrust-screen
V-66331 No Change
Findings ID: JUSX-AG-000126 Rule ID: SV-80821r1_rule Severity: medium CCI: CCI-002403

Discussion

Unrestricted traffic may contain malicious traffic which poses a threat to an enclave or to other connected networks. Additionally, unrestricted traffic may transit a network, which uses bandwidth and other resources.

Traffic enters the Juniper SRX by way of interfaces. Security zones are configured for one or more interfaces with the same security requirements for filtering data packets. A security zone implements a security policy for one or multiple network segments. These policies must be applied to inbound traffic as it crosses the network perimeter and as it crosses internal security domain boundaries.

Checks

Obtain and review the list of authorized sources and destinations. This is usually part of the System Design Specification or Accreditation Package.

Review each of the configured security policies in turn.

[edit]
show security policies <security-policy-name>

If any existing policies allow traffic that is not part of the authorized sources and destinations list, this is a finding.

Fix

Configure a security policy or screen to each outbound zone to implement continuous monitoring. The following commands configure a security zone called “untrust” that can be used to apply security policy for inbound interfaces that are connected to untrusted networks. This example assumes that interfaces ge-0/0/1 and ge-0/0/2 are connected to untrusted and trusted network segments.

Apply security policy a zone example:

set security zones security-zone untrust interfaces ge-0/0/1.0
set security zones security-zone trust interfaces ge-0/0/2.0
set security policies from-zone trust to-zone untrust policy default-deny match destination-address any
set security policies from-zone trust to-zone untrust policy default-deny then deny
V-66333 Updated
Findings ID: JUSX-AG-000127 Rule ID: SV-80823r12_rule Severity: medium CCI: CCI-001126

Discussion

If a boundary protection device fails in an unsecure manner (open), information external to the boundary protection device may enter, or the device may permit unauthorized information release.

Secure failure ensures when a boundary control device fails, all traffic will be subsequently denied.

Fail secure is a condition achieved by employing information system mechanisms to ensure in the event of operational failures of boundary protection devices at managed interfaces (e.g., routers, firewalls, guards, and application gateways residing on protected subnetworks commonly referred to as demilitarized zones), information systems do not enter into unsecure states where intended security properties no longer hold.

Checks

Request documentation of the architecture and Juniper SRX configuration drawings to determine which ports are configured for external/outbound traffic. Verify outbound interfaces have been configured with DoS screens.

[edit]
show security zones <security-zone-name>

If the zone for the security screen has not been applied to the outbound interfaces
. Verify the site has configured the SRX to fail closed, thus preventing traffic from flowing through without filtering and inspection.

If the site has not configured the SRX to fail closed
, this is a finding.

Fix

By default, the SRX device will not forward traffic unless it is explicitly permitted via security policy. This includes traffic between interfaces that are associated within the same security zone (intra-zone traffic). Traffic is permitted between security zones by configuring security policies from a source security zone to the destination security zone. The following configuration statements permit all traffic coming from the “trust” security zone where the destination security zone is “untrust”. These security policies are only provided as an example and should not be used in a production deployment unless they have been reviewed by a firewall administrator.

[edit]
set security policies from-zone trust to-zone trust policy allow-all match source-address any
set security policies from-zone trust to-zone trust policy allow-all match destination-address any
set security policies from-zone trust to-zone trust policy allow-all match application any
set security policies from-zone trust to-zone trust policy allow-all then permit

Although the SRX will not permit traffic from the “untrust” to the “trust” security zone without an explicit policy, you must configure a “deny” policy in order to log the denied traffic. The following configuration statements configure a security policy from the “untrust” zone to the “trust” zone, where all incoming traffic is denied and explicitly logged.

[edit]
set security policies from-zone untrust to-zone trust policy default-deny match source-address
any

set security policies from-zone untrust to-zone trust policy default-deny match destination-address any
set security policies from-zone untrust to-zone trust policy default-deny match application any
set security policies from-zone untrust to-zone trust policy default-deny then deny
set security policies from-zone untrust to-zone trust policy default-deny then log session-init

To allow traffic between network segments within the same security zone, you must also explicitly configure a security policy permitting the traffic. The following configuration statements permit all traffic that will stay within the “trust” security zone.

set security policies from-zone trust to-zone trust policy allow-all match source-address any
set security policies from-zone trust to-zone trust policy allow-all match destination-address any
set security policies from-zone trust to-zone trust policy allow-all match application any
set security policies from-zone trust to-zone trust policy allow-all then permit

The traffic requirements for each deployment are unique, therefore it is up to the firewall administrator to configure an appropriate security policy for your deploymen
Implement and configure the Juniper SRX to fail closed, thus preventing traffic from flowing through without filtering and inspection. In case of failure, document a process for the Juniper SRX to be configured to fail closed. Redundancy should be implemented if failing closed has a mission impact.
V-66335 No Change
Findings ID: JUSX-AG-000128 Rule ID: SV-80825r1_rule Severity: medium CCI: CCI-001109

Discussion

A deny-all, permit-by-exception network communications traffic policy ensures that only those connections which are essential and approved are allowed.

As a managed interface, the ALG must block all inbound and outbound network communications traffic to the application being managed and controlled unless a policy filter is installed to explicitly allow the traffic. The allow policy filters must comply with the site's security policy. A deny all, permit by exception network communications traffic policy ensures that only those connections which are essential and approved, are allowed.

By default, Junos denies all traffic through an SRX Series device using an implicit default security policy exists that denies all packets. Organizations must configure security policies that permits or redirects traffic in compliance with DoD policies and best practices. Sites must not change the factory-default security policies.

Checks

Verify the default-policy has not been changed and is set to deny all traffic.

[edit]
show security policies default-policy

If the default-policy is not set to deny-all, this is a finding.

Fix

By default, the SRX device will not forward traffic unless it is explicitly permitted via security policy. If the default-policy has been changed, then this must be corrected using the set security policies default-policy command.
V-66337 No Change
Findings ID: JUSX-AG-000132 Rule ID: SV-80827r1_rule Severity: medium CCI: CCI-001312

Discussion

Providing too much information in error messages risks compromising the data and security of the application and system.

Organizations carefully consider the structure/content of error messages. The required information within error messages will vary based on the protocol and error condition. Information that could be exploited by adversaries includes ICMP messages that reveal the use of firewalls or access-control lists.

Checks

Verify ICMP messages are configured to meet DoD requirements.

[edit]
show firewall family inet

If ICMP messages are not configured in compliance with DoD requirements, this is a finding.

Fix

Configure ICMP to meet DoD requirements. The following is an example which uses the filter name "protect_re" as the filter name with pre-configured address books (source-prefix-lists).

[edit]
set firewall family inet filter protect_re term permit-icmp from source-prefix-list ssh-addresses
set firewall family inet filter protect_re term permit-icmp from source-prefix-list bgp-addresses
set firewall family inet filter protect_re term permit-icmp from source-prefix-list loopback-addresses
set firewall family inet filter protect_re term permit-icmp from source-prefix-list local-addresses
set firewall family inet filter protect_re term permit-icmp from source-prefix-list ixiav4
set firewall family inet filter protect_re term permit-icmp from icmp-type echo-request
set firewall family inet filter protect_re term permit-icmp from icmp-type echo-reply
set firewall family inet filter protect_re term permit-icmp then log
set firewall family inet filter protect_re term permit-icmp then syslog
set firewall family inet filter protect_re term permit-icmp then accept
set firewall family inet6 filter protect_re-v6 term permit-ar from icmp-type neighboradvertisement
set firewall family inet6 filter protect_re-v6 term permit-ar from icmp-type neighborsolicit
set firewall family inet6 filter ingress-v6 term permit-ar from icmp-type neighboradvertisement
set firewall family inet6 filter ingress-v6 term permit-ar from icmp-type neighborsolicit
set firewall family inet6 filter ingress-v6 term permit-ar from icmp-type 134
set firewall family inet6 filter ingress-v6 term permit-ar then accept
set firewall family inet6 filter egress-v6 term permit-lr from icmp-type neighboradvertisement
set firewall family inet6 filter egress-v6 term permit-lr from icmp-type neighbor-solicit
set firewall family inet6 filter egress-v6 term permit-lr from icmp-type 134
set firewall family inet6 filter egress-v6 term permit-lr then accept
V-66339 No Change
Findings ID: JUSX-AG-000144 Rule ID: SV-80829r1_rule Severity: high CCI: CCI-002661

Discussion

If inbound communications traffic is not continuously monitored, hostile activity may not be detected and prevented. Output from application and traffic monitoring serves as input to continuous monitoring and incident response programs.

The Juniper SRX is a highly scalable system which, by default, provides stateful or stateless continuous monitoring when placed in the architecture at either the perimeter or internal boundaries.

Unusual/unauthorized activities or conditions may include unusual use of unusual protocols or ports and attempted communications from trusted zones to external addresses.

Interfaces with identical security requirements can be grouped together into a single security zone. By default, once a security policy is applied to a zone, the Juniper SRX continuously monitors the associated zone for unusual/unauthorized activities or conditions based on the firewall filter or screen associated with that zone.

Checks

For each inbound zone, verify a firewall screen or security policy is configured.

[edit]
show security zone
show security policies

If communications traffic for each inbound zone is not configured with a firewall screen and/or security policy, this is not a finding.

Fix

Configure a security policy or screen to each inbound zone to implement continuous monitoring. The following commands configure a security zone called “untrust” that can be used to apply security policy for inbound interfaces that are connected to untrusted networks. This example assumes that interfaces ge-0/0/1 and ge-0/0/2 are connected to untrusted and trusted network segments.

Apply policy or screen to a zone example:

set security zones security-zone untrust interfaces ge-0/0/1.0
set security zones security-zone trust interfaces ge-0/0/2.0
set security zones security-zone untrust screen untrust-screen
set security policies from-zone untrust to-zone trust policy default-deny match destination-address any
set security policies from-zone untrust to-zone trust policy default-deny then deny
V-66341 No Change
Findings ID: JUSX-AG-000145 Rule ID: SV-80831r1_rule Severity: high CCI: CCI-002662

Discussion

If outbound communications traffic is not continuously monitored, hostile activity may not be detected and prevented. Output from application and traffic monitoring serves as input to continuous monitoring and incident response programs.

The Juniper SRX is a highly scalable system which can provide stateful or stateless continuous monitoring when placed in the architecture at either the perimeter or internal boundaries. Unusual/unauthorized activities or conditions may include unusual use of unusual protocols or ports and attempted communications from trusted zones to external addresses.

Checks

For each outbound zone, verify a firewall screen or security policy is configured.

[edit]
show security zones
show security policies

If communications traffic for each outbound zone is not configured with a firewall screen or security policy, this is not a finding.

Fix

Configure a security policy or screen to each outbound zone to implement continuous monitoring. The following commands configure a security zone called “untrust” that can be used to apply security policy for inbound interfaces that are connected to untrusted networks. This example assumes that interfaces ge-0/0/1 and ge-0/0/2 are connected to untrusted and trusted network segments.

Apply policy or screen to a zone example:

set security zones security-zone untrust interfaces ge-0/0/1.0
set security zones security-zone trust interfaces ge-0/0/2.0
set security zones security-zone untrust screen untrust-screen
set security policies from-zone trust to-zone untrust policy default-deny match destination-address any
set security policies from-zone trust to-zone untrust policy default-deny then deny
V-66343 No Change
Findings ID: JUSX-AG-000146 Rule ID: SV-80833r1_rule Severity: medium CCI: CCI-002664

Discussion

Without an alert, security personnel may be unaware of major detection incidents that require immediate action and this delay may result in the loss or compromise of information.

Since these incidents require immediate action, these messages are assigned a critical or level 1 priority/severity, depending on the system's priority schema.

In accordance with CCI-001242, the ALG which provides content inspection services is a real-time intrusion detection system. These systems must generate an alert when detection events from real-time monitoring occur as required by CCI-2262 and CCI-2261. Alerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The ALG must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel. Alerts must be sent immediately to designated individuals. Alerts may be sent via NMS, SIEM, Syslog configuration, SNMP trap or notice, or manned console message.

Unusual/unauthorized activities or conditions may include large file transfers, long-time persistent connections, unusual protocols and ports in use, and attempted communications with suspected malicious external addresses.

Checks

For each zone, verify a log event, SNMP trap, or SNMP notification is generated and sent to be forwarded to, at a minimum, the ISSO and ISSM when unusual/unauthorized activities or conditions are detected during continuous monitoring of communications traffic as it traverses inbound or outbound across internal security boundaries.

[edit]
show security zones
show security polices

If each inbound and outbound zone policy does not generate an alert that can be forwarded to, at a minimum, the ISSO and ISSM when unusual/unauthorized activities or conditions are detected during continuous monitoring of communications traffic as it traverses inbound or outbound across internal security boundaries, this is a finding.

Fix

Configure the Juniper SRX to generate and send a notification or log message immediately that can be forwarded via an event monitoring system (e.g., via Syslog configuration, SNMP trap, manned console message, or other events monitoring system). The NSM, Syslog, or SNMP server must then be configured to send the message.

The following example configures the zone security policy to include the log and/or syslog action in all terms to log packets matching each firewall term to ensure the term results are recorded in the firewall log and Syslog. To get traffic logs from permitted sessions, add "then log session-close" to each policy. To get traffic logs from denied sessions, add "then log session-init" to the policy.

Security policy and security screens:
set security policies from-zone <zone_name> to-zone <zone_name> policy <policy_name> then log

Example:
set security policies from-zone untrust to-zone trust policy default-deny then log session-init
V-66345 No Change
Findings ID: JUSX-AG-000147 Rule ID: SV-80835r1_rule Severity: medium CCI: CCI-002664

Discussion

Without an alert, security personnel may be unaware of major detection incidents that require immediate action and this delay may result in the loss or compromise of information.

The ALG generates an alert that notifies designated personnel of the Indicators of Compromise (IOCs) which require real-time alerts. These messages should include a severity level indicator or code as an indicator of the criticality of the incident. These indicators reflect the occurrence of a compromise or a potential compromise.

Since these incidents require immediate action, these messages are assigned a critical or level 1 priority/severity, depending on the system's priority schema.

Alerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The ALG must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel. Alerts must be sent immediately to designated individuals. Alerts may be sent via NMS, SIEM, Syslog configuration, SNMP trap or notice, or manned console message.

Authoritative sources include USSTRATCOM warning and tactical directives/orders including Fragmentary Order (FRAGO), Communications Tasking Orders (CTOs), IA Vulnerability Notices, Network Defense Tasking Message (NDTM), DOD GIG Tasking Message (DGTM), and Operations Order (OPORD).

Checks

Obtain the list of threats identified by authoritative sources from the ISSM or ISSO. For each threat, ensure a security policy, screen, or filter that denies or mitigates the threat includes the log or syslog option. Verify a log event, SNMP trap, or SNMP notification is generated and sent to be forwarded to, at a minimum, the ISSO and ISSM when threats identified by authoritative sources are detected.

[edit]
show security zones
show security polices

If an alert is not generated that can be forwarded to, at a minimum, the ISSO and ISSM when threats identified by authoritative sources are detected, this is a finding.

Fix

Configure the Juniper SRX to generate and send a notification or log message that can be forwarded via an event monitoring system (e.g., via Syslog configuration, SNMP trap, manned console message, or other events monitoring system). The NSM, Syslog, or SNMP server must then be configured to send the message.

The following example configures the zone security policy to include the log and/or syslog action in all terms to log packets matching each firewall term to ensure the term results are recorded in the firewall log and Syslog. To get traffic logs from permitted sessions, add "then log session-close" to each policy. To get traffic logs from denied sessions, add "then log session-init" to the policy.

Security policy and security screens:
set security policies from-zone <zone_name> to-zone <zone_name> policy <policy_name> then log

Example:
set security policies from-zone untrust to-zone trust policy default-deny then log session-init
V-66347 No Change
Findings ID: JUSX-AG-000150 Rule ID: SV-80837r1_rule Severity: medium CCI: CCI-002664

Discussion

Without an alert, security personnel may be unaware of major detection incidents that require immediate action and this delay may result in the loss or compromise of information.

The ALG generates an alert that notifies designated personnel of the Indicators of Compromise (IOCs) which require real-time alerts. These messages should include a severity level indicator or code as an indicator of the criticality of the incident. These indicators reflect the occurrence of a compromise or a potential compromise.

Since these incidents require immediate action, these messages are assigned a critical or level 1 priority/severity, depending on the system's priority schema.

CJCSM 6510.01B, "Cyber Incident Handling Program", lists nine Cyber Incident and Reportable Event Categories. DoD has determined that categories identified by CJCSM 6510.01B Major Indicators (category 1, 2, 4, or 7 detection events) will require an alert when an event is detected.

Alerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The ALG must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel.

Checks

Verify a security policy with an associated screen that denies or mitigates the threat of DoS attacks includes the log or syslog option. Verify a log event, SNMP trap, or SNMP notification is generated and sent to be forwarded to, at a minimum, the ISSO and ISSM when threats identified by authoritative sources are detected.

[edit]
show security zones
show security polices

If an alert is not generated that can be forwarded to, at a minimum, the ISSO and ISSM when DoS incidents are detected, this is a finding.

Fix

Configure the Juniper SRX to generate for DoS attacks detected in CCI-002385. DoS attacks are detected using screens. The alert sends a notification or log message that can be forwarded via an event monitoring system (e.g., via Syslog configuration, SNMP trap, manned console message, or other events monitoring system). The NSM, Syslog, or SNMP server must then be configured to send the message.

The following example configures the zone security policy to include the log and/or syslog action in all terms to log packets matching each firewall term to ensure the term results are recorded in the firewall log and Syslog. To get traffic logs from permitted sessions, add "then log session-close" to each policy. To get traffic logs from denied sessions, add "then log session-init" to the policy.

Apply policy or screen to a zone example:

set security zones security-zone trust interfaces ge-0/0/2.0
set security zones security-zone untrust screen untrust-screen
set security policies from-zone untrust to-zone trust policy default-deny then log session-init