{"stig":{"title":"Juniper SRX SG NDM Security Technical Implementation Guide","version":"1","release":"3"},"checks":[{"vulnId":"V-66015","ruleId":"SV-80505r1_rule","severity":"medium","ruleTitle":"If the loopback interface is used, the Juniper SRX Services Gateway must protect the loopback interface with firewall filters for known attacks that may exploit this interface.","description":"The loopback interface is a logical interface and has no physical port. Since the interface and addresses ranges are well-known, this port must be filtered to protect the Juniper SRX from attacks.","checkContent":"If the loopback interface is not used, this is not applicable.\n\nVerify the loopback interface is protected by firewall filters.\n\n[edit]\nshow interfaces lo0\n\nIf the loopback interface is not configured with IPv6 and IPv4 firewall filters, this is a finding.","fixText":"If the loopback interface is used, configure firewall filters. The following is an example of configuring a loopback address with filters on the device. It shows the format of both IPv4 and IPv6 addresses being applied to the interface. The first two commands show firewall filters being applied to the interface.\n\n[edit]\nset interfaces lo0 unit 0 family inet filter input protect_re\nset interfaces lo0 unit 0 family inet6 filter input protect_re-v6\nset interfaces lo0 unit 0 family inet address 1.1.1.250/32\nset interfaces lo0 unit 0 family inet6 address 2100::250/128","ccis":["CCI-000366"]},{"vulnId":"V-66443","ruleId":"SV-80933r1_rule","severity":"medium","ruleTitle":"For local accounts, the Juniper SRX Services Gateway must generate an alert message to the management console and generate a log event record that can be forwarded to the ISSO and designated system administrators when local accounts are created.","description":"An authorized insider or individual who maliciously creates a local account could gain immediate access from a remote location to privileged information on a critical security device. Sending an alert to the administrators and ISSO when this action occurs greatly reduces the risk that accounts will be surreptitiously created.\n\nAutomated mechanisms can be used to send automatic alerts or notifications. Such automatic alerts or notifications can be conveyed in a variety of ways (e.g., telephonically, via electronic mail, via text message, or via websites). 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.\n\nAlthough, based on policy, administrator accounts must be created on the AAA server, thus this requirement addresses the creation of unauthorized accounts on the Juniper SRX itself. This does not negate the need to address this requirement on the AAA server and the event monitoring server (e.g., Syslog, Security Information and Event Management [SIEM], or SNMP servers).","checkContent":"Verify the device is configured to display change-log events of severity info.\n\n[edit]\nshow system syslog\n\nIf the system is not configured to display account creation actions on the management console and generate an event log message to the Syslog server and a local file, this is a finding.","fixText":"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.\n\nThe following commands configure the device to immediately display a message to any currently logged on administrator's console when changes are made to the configuration. This is an example method. Alerts must be sent immediately to the designated individuals (e.g., via Syslog configuration, SNMP trap, manned console message, or other events monitoring system). \n\n[edit]\nset system syslog users * change-log <info | any> \nset system syslog host <IP-syslog-server> any any\nset system syslog file account-actions change-log any any","ccis":["CCI-001683"]},{"vulnId":"V-66445","ruleId":"SV-80935r1_rule","severity":"medium","ruleTitle":"The Juniper SRX Services Gateway must generate an alert message to the management console and generate a log event record that can be forwarded to the ISSO and designated system administrators when the local accounts (i.e., the account of last resort or root account) are modified.","description":"An authorized insider or individual who maliciously modifies a local account could gain immediate access from a remote location to privileged information on a critical security device. Sending an alert to the administrators and ISSO when this action occurs greatly reduces the risk that accounts will be surreptitiously modified.\n\nAutomated mechanisms can be used to send automatic alerts or notifications. Such automatic alerts or notifications can be conveyed in a variety of ways (e.g., telephonically, via electronic mail, via text message, or via websites). 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.\n \nAlthough, based on policy, administrator accounts must be modified on the AAA server, thus this requirement addresses the modification of unauthorized accounts on the Juniper SRX itself. This does not negate the need to address this requirement on the AAA server and the event monitoring server (e.g., Syslog, Security Information and Event Management [SIEM], or SNMP servers).","checkContent":"Verify the device is configured to display change-log events of severity info.\n\n[edit]\nshow system syslog\n\nIf the system does not display account modification actions on the management console and generate an event log message to the Syslog server and a local file, this is a finding.","fixText":"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.\n\nThe following commands configure the device to immediately display a message to any currently logged on administrator's console when changes are made to the configuration. This is an example method. Alerts must be sent immediately to the designated individuals (e.g., via Syslog configuration, SNMP trap, manned console message, or other events monitoring system). \n\n[edit]\nset system syslog users * change-log <info | any> \nset system syslog host <IP-syslog-server> any any\nset system syslog file account-actions change-log any any","ccis":["CCI-001684"]},{"vulnId":"V-66447","ruleId":"SV-80937r1_rule","severity":"medium","ruleTitle":"The Juniper SRX Services Gateway must generate alerts to the management console and generate a log record that can be forwarded to the ISSO and designated system administrators when the local accounts (i.e., the account of last resort or root account) are deleted.","description":"An authorized insider or individual who maliciously delete a local account could gain immediate access from a remote location to privileged information on a critical security device. Sending an alert to the administrators and ISSO when this action occurs greatly reduces the risk that accounts will be surreptitiously deleted.\n\nAutomated mechanisms can be used to send automatic alerts or notifications. Such automatic alerts or notifications can be conveyed in a variety of ways (e.g., telephonically, via electronic mail, via text message, or via websites). 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.\n\nAlthough, based on policy, administrator accounts must be deleted on the AAA server, this requirement addresses the deletion of unauthorized accounts on the Juniper SRX itself. This does not negate the need to address this requirement on the AAA server and the event monitoring server (e.g., Syslog, Security Information and Event Management [SIEM], or SNMP servers).\n\nAccounts can be disabled by configuring the account with the built-in login class \"unauthorized\". When the command is reissued with a different login class, the account is enabled.","checkContent":"Verify the device is configured to display change-log events of severity info.\n\n[edit]\nshow system syslog\n\nIf the system is not configured to display account deletion actions on the management console and generate an event log message to the Syslog server and a local file, this is a finding.","fixText":"The following commands configure the device to immediately display a message to any currently logged on administrator's console when changes are made to the configuration. This is an example method. Alerts must be sent immediately to the designated individuals (e.g., via Syslog configuration, SNMP trap, manned console message, or other events monitoring system). \n\n[edit]\nset system syslog users * change-log <info | any> \nset system syslog host <IP-syslog-server> any any\nset system syslog file account-actions change-log any any","ccis":["CCI-001686"]},{"vulnId":"V-66449","ruleId":"SV-80939r1_rule","severity":"high","ruleTitle":"The Juniper SRX Services Gateway must be configured to use a centralized authentication server to authenticate privileged users for remote and nonlocal access for device management.","description":"Centralized management of authentication settings increases the security of remote and nonlocal access methods. This control is a particularly important protection against the insider threat. Audit records for administrator accounts access to the organization's network devices can be more readily analyzed for trends and anomalies. The alternative method of defining administrator accounts on each device exposes the device configuration to remote access authentication attacks and system administrators with multiple authenticators for each network device.\n\nThe Juniper SRX supports three methods of user authentication: local password authentication, Remote Authentication Dial-In User Service (RADIUS), and Terminal Access Controller Access Control System Plus (TACACS+). RADIUS and TACACS+ are remote access methods used for management of the Juniper SRX. The local password method will be configured for use only for the account of last resort; however, it will not be used for remote and nonlocal access or this will result in a CAT 1 finding (CCI-000765).\n\nThis requirement references identification and authentication and does not prevent the configuration of privileges using the remote template account (CCI-000213).","checkContent":"Verify the Juniper SRX is configured to forward logon requests to a RADIUS or TACACS+. \n\nFrom the CLI operational mode enter: \nshow system radius-server \nor \nshow system tacplus-server\n\nIf the Juniper SRX is not configured to use at least one RADIUS or TACACS+ server, this is a finding.","fixText":"Configure the Juniper SRX to forward logon requests to a RADIUS or TACACS+. Remove local users configured on the device (CCI-000213) so the AAA server cannot default to using a local account. \n\n[edit]\nset system tacplus-server address <server ipaddress> port 1812 secret <shared secret> \n\nor \n\n[edit]\nset system radius-server address <server ipaddress> port 1812 secret <shared secret> \n\nNote: DoD policy is that redundant AAA servers are required to mitigate the risk of a failure of the primary AAA device.","ccis":["CCI-000366"]},{"vulnId":"V-66451","ruleId":"SV-80941r1_rule","severity":"high","ruleTitle":"If SNMP is enabled, the Juniper SRX Services Gateway must use and securely configure SNMPv3.","description":"To prevent non-secure protocol communications with the organization's local SNMPv3 services, the SNMP client on the Juniper SRX must be configured for proper identification and strong cryptographically-based protocol for authentication.\n\nSNMPv3 defines a user-based security model (USM), and a view-based access control model (VACM). SNMPv3 USM provides data integrity, data origin authentication, message replay protection, and protection against disclosure of the message payload. SNMPv3 VACM provides access control to determine whether a specific type of access (read or write) to the management information is allowed.\n\nThe Junos operating system allows the use of SNMPv3 to monitor or query the device for management purposes. Junos does not allow SNMPv3, of any type, to be used to make configuration changes to the device. SNMPv3 is disabled by default and must be enabled for use. SNMPv3 is the DoD-preferred method for monitoring the device securely. If SNMPv3 is not being used, it must be disabled. The following commands will configure SNMPv3. The Junos operating system allows the use of FIPS approved protocols for both authentication (SHA1) and for privacy (AES128). These protocols should be used to ensure secure management connections.","checkContent":"Verify SNMPv3 is enabled and configured.\n\n[edit]\nshow snmp\n\nIf an SNMP stanza does not exist, this is not a finding.\n\nIf SNMPv3 is not configured to meet DoD requirements, this is a finding.\n\nIf versions earlier than SNMPv3 are enabled, this is a finding.","fixText":"Enable and configure SNMPv3 and configure a trap and community string.\n\n[edit]\nset snmp location <LOCATION-NAME>\nset snmp v3 usm local-engine user <USER-NAME> privacy-AES128\nset snmp v3 vacm security-to-group security-model usm security-name <SECURITY-NAME> group <GROUP-NAME>\nset snmp v3 vacm access group <GROUP-NAME> default-context-prefix security-model usm\nsecurity-level privacy read-view all\nset snmp v3 vacm access group <GROUP-NAME> default-context-prefix security-model usm\nsecurity-level privacy notify-view all\nset snmp v3 target-address <target-address-name> tag-list <SNMP-trap-receiver>\nset snmp v3 target-address <TARGER-ADDRESS-NAME> target-parameters <PARMS-NAME>\nset snmp v3 target-parameters <PARMS-NAME> parameters message-processing-model v3\nset snmp v3 target-parameters <PARMS-NAME> parameters security-model usm\nset snmp v3 target-parameters <PARMS-NAME> parameters security-level privacy\nset snmp v3 target-parameters <PARMS-NAME> parameters security-name <SECURITY-NAME>\nset snmp v3 target-parameters <PARMS-NAME> notify-filter device-traps\nset snmp v3 notify <SNMP-TRAPS> type trap\nset snmp v3 notify <SNMP-TRAPS> tag <SNMP-TRAP-RECEIVER>\nset snmp v3 notify-filter device-traps oid jnxChassisTraps include\nset snmp v3 notify-filter device-traps oid jnxChassisOKTraps include\nset snmp v3 notify-filter device-traps oid system include\nset snmp v3 notify-filter device-traps oid .1 include\nset snmp v3 notify-filter device-traps oid snmpMIBObjects include\nset snmp engine-id use-mac-address\nset snmp view all oid .1 include\nset snmp view all oid system include\nset snmp view all oid jnxBoxAnatomy include\nset snmp view all oid snmpMIBObjects include","ccis":["CCI-000382"]},{"vulnId":"V-66453","ruleId":"SV-80943r1_rule","severity":"high","ruleTitle":"For nonlocal maintenance sessions using SNMP, the Juniper SRX Services Gateway must use and securely configure SNMPv3 with SHA to protect the integrity of maintenance and diagnostic communications.","description":"Without cryptographic integrity protections, information can be altered by unauthorized users without detection.\n\nNonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. \n \nThe Juniper SRX allows the use of SNMP to monitor or query the device in support of diagnostics information. SNMP cannot be used to make configuration changes; however, it is a valuable diagnostic tool. SNMP is disabled by default and must be enabled for use. SNMPv3 is the DoD-required version, but must be configured to be used securely.","checkContent":"Verify SNMP is configured for version 3.\n\n[edit]\nshow snmp v3\n \nIf SNMPv3 is not configured for version 3 using SHA, this is a finding.","fixText":"Configure snmp to use version 3 with SHA authentication.\n\n[edit]\nset snmp v3 usm local-engine user <NAME> authentication-sha","ccis":["CCI-002890"]},{"vulnId":"V-66455","ruleId":"SV-80945r1_rule","severity":"high","ruleTitle":"For nonlocal maintenance sessions using SNMP, the Juniper SRX Services Gateway must securely configure SNMPv3 with privacy options to protect the confidentiality of maintenance and diagnostic communications for nonlocal maintenance sessions.","description":"Without confidentiality protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session.\n\nNonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. \n \nTo protect the confidentiality of nonlocal maintenance sessions, SNMPv3 with AES encryption to must be configured to provide confidentiality. The Juniper SRX allows the use of SNMPv3 to monitor or query the device in support of diagnostics information. SNMP cannot be used to make configuration changes; however, it is a valuable diagnostic tool. SNMP is disabled by default and must be enabled for use. SNMPv3 is the DoD-required version, but must be configured to be used securely.","checkContent":"Verify SNMPv3 is configured with privacy options.\n\n[edit]\nshow snmp v3\n \nIf SNMPv3, AES encryption, and other privacy options are not configured, this is a finding.","fixText":"Configure SNMP to use version 3 with privacy options. The following is an example.\n\n[edit]\nset snmp location <NAME>\nset snmp v3 usm local-engine user <NAME> privacy-AES128\nset snmp v3 vacm security-to-group security-model usm security-name <NAME> group <NAMEGROUP>\nset snmp v3 vacm access group <NAME-GROUP> default-context-prefix security-model usm\nsecurity-level privacy read-view all\nset snmp v3 vacm access group <NAME-GROUP> default-context-prefix security-model usm\nsecurity-level privacy notify-view all","ccis":["CCI-003123"]},{"vulnId":"V-66457","ruleId":"SV-80947r1_rule","severity":"medium","ruleTitle":"The Juniper SRX Services Gateway must automatically terminate a network administrator session after organization-defined conditions or trigger events requiring session disconnect.","description":"Automatic session termination addresses the termination of administrator-initiated logical sessions in contrast to the termination of network connections that are associated with communications sessions (i.e., network disconnect). \n\nConditions or trigger events requiring automatic session termination can include, for example, organization-defined periods of user inactivity, targeted responses to certain types of incidents, and time-of-day restrictions on information system use. These conditions will vary across environments and network device types.\n\nThe Juniper SRX can be configured to limit login times or to logout users after a certain time period if desired by the organization. These setting are configured as options on the login class to which they apply.","checkContent":"If the organization does not have a requirement for triggered, automated logout, this is not a finding.\n\nObtain a list of organization-defined triggered, automated requirements that are required for the Juniper SRX. \n\nTo verify configuration of special user access controls.\n\n[edit]\nshow system login\n\nView time-based or other triggers which are configured to control automated logout.\n\nIf the organization has documented requirements for triggered, automated termination and they are not configured, this is a finding.","fixText":"To configure user access on specific days of the week for a specified duration, include the allowed-days, access-start, and access-end statements. The following is an example of a configuration for a class which would automatically log out users. Consult the Juniper SRX documentation for other options.\n\n[edit system login]\nclass class-name allowed-days [ days-of-the-week ];\nclass class-name access-start HH:MM;\nclass class-name access-end HH:MM;","ccis":["CCI-002361"]},{"vulnId":"V-66459","ruleId":"SV-80949r1_rule","severity":"medium","ruleTitle":"For local accounts created on the device, the Juniper SRX Services Gateway must automatically generate log records for account creation events.","description":"Upon gaining access to a network device, an attacker will often first attempt to create a persistent method of reestablishing access. One way to accomplish this is to create a new account. Notification of account creation helps to mitigate this risk. Auditing account creation provides the necessary reconciliation that account management procedures are being followed. Without this audit trail, personnel without the proper authorization may gain access to critical network nodes.\n\nAn AAA server is required for account management in accordance with CCI-000370. Only a single account of last resort is permitted on the local device. However, since it is still possible for administrators to create local accounts either maliciously or to support mission needs, the SRX must be configured to log account management events.\n\nTo log local account management events, ensure at least one external syslog server is configured to log facility any or facility change-log, and severity info or severity any.","checkContent":"Verify the device logs change-log events of severity info or any to an external syslog server.\n\n[edit]\nshow system syslog\n\nhost <syslog server address> {\n  any <info | any>;\n  source-address <device address>;\n}\n\n-OR-\n\nhost <syslog server address> {\n  change-log <info | any>;\n  source-address <device address>;\n}\n\nIf an external syslog host is not configured to log facility change-log severity <info | any>, or configured for facility any severity <info | any>, this is a finding.","fixText":"Configure at least one external syslog host is configured to log facility change-log or any, and severity info or any. \n\n[edit system syslog]\nset host <syslog server address> any <info | any> \n\n -OR-\n\n[edit]\nset host <syslog server address> change-log <info | any>","ccis":["CCI-000018"]},{"vulnId":"V-66461","ruleId":"SV-80951r1_rule","severity":"medium","ruleTitle":"For local accounts created on the device, the Juniper SRX Services Gateway must automatically generate log records for account modification events.","description":"Upon gaining access to a network device, an attacker will often first attempt to modify existing accounts to increase/decrease privileges. Notification of account modification events help to mitigate this risk. Auditing account modification events provides the necessary reconciliation that account management procedures are being followed. Without this audit trail, personnel without the proper authorization may gain access to critical network nodes.\n\nAn AAA server is required for account management in accordance with CCI-000370. Only a single account of last resort is permitted on the local device. However, since it is still possible for administrators to create local accounts either maliciously or to support mission needs, the SRX must be configured to log account management events.\n\nTo log local account management events, ensure at least one external syslog server is configured to log facility any or facility change-log, and severity info or severity any.","checkContent":"Verify the device logs change-log events of severity info or any to an external syslog server.\n\n[edit]\nshow system syslog\n\nhost <syslog server address> {\n  any <info | any>;\n  source-address <device address>;\n}\n\n-OR-\n\nhost <syslog server address> {\n  change-log <info | any>;\n  source-address <device address>;\n}\n\nIf an external syslog host is not configured to log facility change-log severity <info | any>, or configured for facility any severity <info | any>, this is a finding.","fixText":"Configure at least one external syslog host is configured to log facility change-log or any, and severity info or any. \n\n[edit system syslog]\nset host <syslog server address> any <info | any> \n\n -OR-\n\n[edit]\nset host <syslog server address> change-log <info | any>","ccis":["CCI-001403"]},{"vulnId":"V-66463","ruleId":"SV-80953r1_rule","severity":"medium","ruleTitle":"For local accounts created on the device, the Juniper SRX Services Gateway must automatically generate log records for account disabling events.","description":"When device management accounts are disabled, user or service accessibility may be affected. Auditing also ensures authorized, active accounts remain enabled and available for use when required. Without this audit trail, personnel without the proper authorization may gain access to critical network nodes.\n\nAn AAA server is required for account management in accordance with CCI-000370. Only a single account of last resort is permitted on the local device. However, since it is still possible for administrators to create local accounts either maliciously or to support mission needs, the SRX must be configured to log account management events.\n\nTo log local account management events, ensure at least one external syslog server is configured to log facility any or facility change-log, and severity info or severity any.","checkContent":"Verify the device logs change-log events of severity info or any to an external syslog server.\n\n[edit]\nshow system syslog\n\nhost <syslog server address> {\n  any <info | any>;\n  source-address <device address>;\n}\n\n-OR-\n\nhost <syslog server address> {\n  change-log <info | any>;\n  source-address <device address>;\n}\n\nIf an external syslog host is not configured to log facility change-log severity <info | any>, or configured for facility any severity <info | any>, this is a finding.","fixText":"Configure at least one external syslog host is configured to log facility change-log or any, and severity info or any. \n\n[edit system syslog]\nset host <syslog server address> any <info | any> \n\n -OR-\n\n[edit]\nset host <syslog server address> change-log <info | any>","ccis":["CCI-001404"]},{"vulnId":"V-66465","ruleId":"SV-80955r1_rule","severity":"medium","ruleTitle":"For local accounts created on the device, the Juniper SRX Services Gateway must automatically generate log records for account removal events.","description":"Auditing account removal actions will support account management procedures. When device management accounts are terminated, user or service accessibility may be affected. Auditing also ensures authorized active accounts remain enabled and available for use when required. Without this audit trail, personnel without the proper authorization may gain access to critical network nodes.\n\nAn AAA server is required for account management in accordance with CCI-000370. Only a single account of last resort is permitted on the local device. However, since it is still possible for administrators to create local accounts either maliciously or to support mission needs, the SRX must be configured to log account management events.\n\nTo log local account management events, ensure at least one external syslog server is configured to log facility any or facility change-log, and severity info or severity any.","checkContent":"Verify the device logs change-log events of severity info or any to an external syslog server.\n\n[edit]\nshow system syslog\n\nhost <syslog server address> {\n  any <info | any>;\n  source-address <device address>;\n}\n\n-OR-\n\nhost <syslog server address> {\n  change-log <info | any>;\n  source-address <device address>;\n}\n\nIf an external syslog host is not configured to log facility change-log severity <info | any>, or configured for facility any severity <info | any>, this is a finding.","fixText":"Configure at least one external syslog host is configured to log facility change-log or any, and severity info or any. \n\n[edit system syslog]\nset host <syslog server address> any <info | any> \n\n -OR-\n\n[edit]\nset host <syslog server address> change-log <info | any>","ccis":["CCI-001405"]},{"vulnId":"V-66467","ruleId":"SV-80957r1_rule","severity":"medium","ruleTitle":"The Juniper SRX Services Gateway must generate an alert message to the management console and generate a log event record that can be forwarded to the ISSO and designated system administrators when accounts are disabled.","description":"An authorized insider or individual who maliciously disables a local account could gain immediate access from a remote location to privileged information on a critical security device. Sending an alert to the administrators and ISSO when this action occurs greatly reduces the risk that accounts will be surreptitiously disabled.\n\nAutomated mechanisms can be used to send automatic alerts or notifications. Such automatic alerts or notifications can be conveyed in a variety of ways (e.g., telephonically, via electronic mail, via text message, or via websites). 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.\n\nAlthough, based on policy, administrator accounts must be disabled on the AAA server,  this requirement addresses the disabling of unauthorized accounts on the Juniper SRX itself. This does not negate the need to address this requirement on the AAA server and the event monitoring server (e.g., Syslog, Security Information and Event Management [SIEM], or SNMP servers).","checkContent":"Verify the device is configured to display change-log events of severity info.\n\n[edit]\nshow system syslog\n\nIf the system does not display account disabling actions on the management console and generate an event log message to the Syslog server and a local file, this is a finding.","fixText":"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.\n\nThe following commands configure the device to immediately display a message to any currently logged on administrator's console when changes are made to the configuration. This is an example method. Alerts must be sent immediately to the designated individuals (e.g., via Syslog configuration, SNMP trap, manned console message, or other events monitoring system).\n\n[edit]\nset system syslog users * change-log <info | any> \nset system syslog host <IP-syslog-server> any any\nset system syslog file account-actions change-log any any","ccis":["CCI-001685"]},{"vulnId":"V-66469","ruleId":"SV-80959r1_rule","severity":"medium","ruleTitle":"The Juniper SRX Services Gateway must automatically generate a log event when accounts are enabled.","description":"Once an attacker establishes initial access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to simply enable a new or disabled account. Notification of account enabling is one method for mitigating this risk. A comprehensive account management process will ensure an audit trail which documents the creation of application user accounts and notifies administrators and Information System Security Officers (ISSO). Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes.\n\nAccounts can be disabled by configuring the account with the build-in login class \"unauthorized\". When the command is reissued with a different login class, the account is enabled.","checkContent":"Verify the device is configured to display change-log events of severity info.\n\n[edit]\nshow system syslog\n\nIf the system is not configured to generate a log record when account enabling actions occur, this is a finding.","fixText":"The following commands configure the device to immediately display a message to any currently logged on administrator's console when changes are made to the configuration.\n\n[edit]\nset system syslog host <IP-syslog-server> any any\nset system syslog file account-actions change-log any any","ccis":["CCI-002130"]},{"vulnId":"V-66471","ruleId":"SV-80961r1_rule","severity":"medium","ruleTitle":"The Juniper SRX Services Gateway must generate an immediate alert message to the management console for account enabling actions.","description":"In order to detect and respond to events that affect network administrator accessibility and device processing, network devices must audit account enabling actions and, as required, notify the appropriate individuals so they can investigate the event.\n\nAlerts must be sent immediately to the designated individuals (e.g., via Syslog configuration, SNMP trap, manned console message, or other events monitoring system). \n\nAccounts can be disabled by configuring the account with the built-in login class \"unauthorized\". When the command is reissued with a different login class, the account is enabled.","checkContent":"Verify the device is configured to display change-log events of severity info.\n\n[edit]\nshow system syslog\n\nIf the system is not configured to display account enabling actions on the management console, this is a finding.","fixText":"The following commands configure the device to immediately display a message to any currently logged on administrator's console when changes are made to the configuration. This is an example method. Alerts must be sent immediately to the designated individuals (e.g., via Syslog configuration, SNMP trap, manned console message, or other events monitoring system). \n\n[edit]\nset system syslog users * change-log <info | any>","ccis":["CCI-002132"]},{"vulnId":"V-66473","ruleId":"SV-80963r1_rule","severity":"medium","ruleTitle":"The Juniper SRX Services Gateway must enforce the assigned privilege level for each administrator and authorizations for access to all commands by assigning a login class to all AAA-authenticated users.","description":"To mitigate the risk of unauthorized privileged access to the device, administrators must be assigned only the privileges needed to perform the tasked assigned to their roles. \n\nAlthough use of an AAA server is required for non-local access for device management, the SRX must also be configured to implement the corresponding privileges upon user login. Each externally authenticated user is assigned a template that maps to a configured login class.\n\nAAA servers are usually configured to send a Vendor Specific Attribute (VSA) to the Juniper SRX. The device uses this information to determine the login class to assign to the authenticated user. Unless a VSA is returned from the AAA server, externally-authenticated users are mapped to the “remote” user by default. Remote user is a special default account in Junos OS. If this default account, or another designated remote user account, is not configured, then only externally-authenticated users with a returned VSA of a local template account are permitted login. If the remote user is configured, all externally-authenticated users without a returned VSA default to the remote user account's configured login class. All externally-authenticated users with a returned VSA inherit the login class configured for each respective template account.\n\nJunos OS provides four built-in login classes: super-user (all permissions), operator (limited permissions), read-only (no change permissions), and unauthorized (prohibits login). Because these classes are not configurable by the system administrator, they should not be used except for the unauthorized class which may be used for the remote user to deterministically prohibit logins from externally-authenticated users without a returned VSA. Therefore, all template user accounts, and the local account of last resort, should use custom, user-defined, login classes.\n\nExternally-authenticated users maintain two account names in Junos OS: the user and login names. The user name is the local template account name and the login name is the authenticated user’s external account name. Junos OS links the names to determine permissions, based upon login class, but uses the external account name for logging. Doing so permits multiple, individually-authenticated users, to be mapped to the same template account, and therefore enforce uniform permissions for each group of administrators, while also attributing any logged changes to the appropriate individual user.\n\nTemplate accounts are differentiated from local accounts by the presence of an authentication stanza; only the local account of last resort should have an authentication stanza.","checkContent":"Verify all accounts are assigned a user-defined (not built-in) login class with appropriate permissions configured. If the remote user is configured, it may have a user-defined, or the built-in unauthorized login class.\n\n[edit]\nshow system login\n\n Junos OS supports groups, which are centrally located snippets of code. This allows common configuration to be applied at one or more hierarchy levels without requiring duplicated stanzas. If there are no login-classes defined at [edit system login], then check for an apply-groups statement and verify appropriate configuration at the [edit groups] level.\n\n[edit]\nshow groups\n\nIf one or more account templates are not defined with an appropriate login class, this is a finding.\n\nIf more than one local account has an authentication stanza and is not documented, this is a finding.\n\nNote: Template accounts are differentiated from local accounts by the presence of an authentication stanza.","fixText":"User accounts, including the account of last resort must be assigned to a login class. \n\nConfigure the class parameters and privileges.\n\n[edit]\nSet system login class <class name> idle-timeout 10\nset system login class <class name> permissions <appropriate permissions>\n\nCommit for the changes to take effect.\n\nCreate and configure template user (s).\n\n[edit]\nset system login user <template account name> login-class <appropriate class>\n\nNote: Junos does not permit account creation without login-class assignment.\n\nNote: There are 4 pre-defined classes which should not be uses used for <class name>: Super-user, Operator, Read-only, and unauthorized. However, the Unauthorized class may be used for the remote user account to prevent logins from externally-authenticated users when a VSA is not returned from the AAA server.","ccis":["CCI-000213"]},{"vulnId":"V-66475","ruleId":"SV-80965r1_rule","severity":"medium","ruleTitle":"The Juniper SRX Services Gateway must enable log record generation for DoD-defined auditable events within the Juniper SRX Service Gateway.","description":"Without the capability to generate log records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. \n\nDoD has defined the list of events for which the device will provide an audit record generation capability. These events as the following which are individually called out in other CCIs: \n\n(i) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);\n(ii) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; and\n(iii) All account creation, modification, disabling, and termination actions.\n\nWhile the Juniper SRX inherently has the capability to generate log records, by default only the high facility levels are captured by default to local files. \n\nEnsure the Syslog server and local files are configured to support requirements. 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).","checkContent":"Verify logging has been enabled and configured.\n\n[edit] show system syslog\n\nIf a syslog host server has not been configured to capture DoD-defined auditable events, this is a finding.","fixText":"The following example commands configure Syslog and local backup files to capture DoD-defined auditable events. \n\n[edit]\nset system syslog user * any emergency\nset system syslog host <IP-syslog-server> any any\nset system syslog host <IP-syslog-server> source-address <MGT-IP-Address>\nset system syslog host <IP-syslog-server> log-prefix <host-name>\nset system syslog file messages any info\nset system syslog file messages authorization info\nset system syslog file User-Auth authorization any\nset system syslog file User-Auth interactive-commands any\nset system syslog file audit interactive-commands any\nset system syslog file processes daemon any\nset system syslog console any any\nset system syslog file account-actions change-log any any\nset system syslog file account-actions match “system login user”","ccis":["CCI-000169"]},{"vulnId":"V-66477","ruleId":"SV-80967r1_rule","severity":"medium","ruleTitle":"For local log files, the Juniper SRX Services Gateway must allocate log storage capacity in accordance with organization-defined log record storage requirements so that the log files do not grow to a size that causes operational issues.","description":"In order to ensure network devices have a sufficient storage capacity in which to write the logs, they need to be able to allocate audit record storage capacity. The task of allocating audit record storage capacity is usually performed during initial device setup if it is modifiable. \n\nThe amount allocated for the organization-defined audit record storage requirement will depend on the amount of storage available on the network device, the anticipated volume of logs, and how long the logs are kept on the device. Since the Syslog is the primary audit log, the local log is not essential to keep archived for lengthy periods, thus the allocated space on the device should be low.","checkContent":"To verify the file size for the local system log is set.\n\n[edit]\nshow system syslog\n\nView the archive size setting of the local log files.\n\nIf all local log files are not set to an organizational-defined size, this is a finding.","fixText":"Enter the following commands in the [edit system syslog] hierarchy.\n\n[edit system syslog] \nset file <log filename> any any archive size <file size> file <number of archives>","ccis":["CCI-001849"]},{"vulnId":"V-66479","ruleId":"SV-80969r1_rule","severity":"medium","ruleTitle":"The Juniper SRX Services Gateway must generate an immediate system alert message to the management console when a log processing failure is detected.","description":"It is critical for the appropriate personnel to be aware if a system is at risk of failing to process logs as required. Without an immediate alert for critical system issues, security personnel may be unaware of an impending failure of the audit capability and system operation may be adversely affected.\n\nAlerts provide organizations with urgent messages. Real-time alerts provide these messages at information technology speed (i.e., the time from event detection to alert occurs in seconds or less). Automated alerts can be conveyed in a variety of ways, including, for example, telephonically, via electronic mail, via text message, or via websites.\n\nAlerts must be sent immediately to the designated individuals (e.g., via Syslog configuration, SNMP trap, manned console message, or other events monitoring system). \n\nLog processing failures include software/hardware errors, failures in the log capturing mechanisms, and log storage capacity being reached or exceeded.\n\nWhile this requirement also applies to the configuration of the event monitoring system (e.g., Syslog, Security Information and Event Management [SIEM], or SNMP servers), the Juniper SRX can also be configured to generate a message to the administrator console or send via email for immediate messages.\n\nSyslog and SNMP trap events with a facility of \"daemon\" pertaining to errors encountered by system processes.","checkContent":"Verify the system Syslog has been configured to display an alert on the console for the emergency and critical levels of the daemon facility.\n\n[edit] \nshow system syslog\n\nIf the system is not configured to generate a system alert message when a component failure is detected, this is a finding.","fixText":"The following commands configure syslog to immediately display any emergency level or daemon alert events to the management console. The message will display on any currently logged on administrator's console. This is an example method. Alerts must be sent immediately to the designated individuals (e.g., via Syslog configuration, SNMP trap, manned console message, or other events monitoring system). \n\n[edit]\nset system syslog user * any emergency\nset system syslog user * daemon alert\nset system syslog user * daemon critical","ccis":["CCI-001858"]},{"vulnId":"V-66481","ruleId":"SV-80971r1_rule","severity":"medium","ruleTitle":"In the event that communications with the events server is lost, the Juniper SRX Services Gateway must continue to queue log records locally.","description":"It is critical that when the network device is at risk of failing to process logs as required, it take action to mitigate the failure. Log processing failures include: software/hardware errors; failures in the log capturing mechanisms; and audit storage capacity being reached or exceeded. Responses to log failure depend upon the nature of the failure mode. \n\nSince 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.\n\nA 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). Thus, the Juniper SRX will inherently and continuously capture events to local files to guard against the loss of connectivity to the primary and secondary events server.","checkContent":"Verify logging has been enabled and configured to capture to local log files in case connection with the primary and secondary log servers is lost.\n\n[edit] \nshow system syslog\n\nIf local log files are not configured to capture events, this is a finding.","fixText":"The following example commands configure local backup files to capture DoD-defined auditable events. \n\n[edit]\nset system syslog file messages any info\nset system syslog file messages authorization none\nset system syslog file messages interactive-commands none \nset system syslog file messages daemon none \nset system syslog file User-Auth authorization any\nset system syslog file interactive-commands interactive-commands any\nset system syslog file processes daemon any\nset system syslog file account-actions change-log any any\nset file account-actions match “system login user”\nset system syslog console any any","ccis":["CCI-000140"]},{"vulnId":"V-66483","ruleId":"SV-80973r1_rule","severity":"medium","ruleTitle":"The Juniper SRX Services Gateway must record time stamps for log records using Coordinated Universal Time (UTC).","description":"If time stamps are not consistently applied and there is no common time reference, it is difficult to perform forensic analysis. UTC is normally used in DoD; however, Greenwich Mean Time (GMT) may be used if needed for mission requirements.","checkContent":"Verify the time zone is set to UTC.\n\n[edit]\nshow system time-zone\n\nIf the time zone is not set to UTC, this is a finding.","fixText":"The following command sets the time zone to UTC.\n\n[edit]\nset system time-zone UTC","ccis":["CCI-001890"]},{"vulnId":"V-66485","ruleId":"SV-80975r1_rule","severity":"medium","ruleTitle":"The Juniper SRX Services Gateway must implement logon roles to ensure only authorized roles are allowed to install software and updates.","description":"Allowing anyone to install software, without explicit privileges, creates the risk that untested or potentially malicious software will be installed on the system. This requirement applies to code changes and upgrades for all network devices.\n\nFor example audit admins and the account of last resort are not allowed to perform this task.","checkContent":"To verify role-based access control has been configured, view the settings for each login class defined.\n\n[edit]\nshow system login\n\nView all login classes to see which roles are assigned the \"Maintenance\" or \"request system software add\" permissions. \n\nIf login classes for user roles that are not authorized to install and update software are configured, this is a finding.","fixText":"Configure the Juniper SRX to allow only the ISSM user account (or administrators/roles appointed by the ISSM) to select which auditable events are to be audited. To ensure this is the case, each ISSM-appointed role on the AAA must be configured for least privilege using the following stanzas for each role.\n\n[edit]\nshow system login\n\nUse the delete command or retype the command to remove the permission \"Maintenance\" or \"request system software add\" from any class that is not authorized to upgrade software on the device. An explicitly Deny for the command \"request system software add\" can also be used if some Maintenance commands are permitted.","ccis":["CCI-001812"]},{"vulnId":"V-66487","ruleId":"SV-80977r1_rule","severity":"medium","ruleTitle":"The Juniper SRX Services Gateway must be configured to synchronize internal information system clocks with the primary and secondary NTP servers for the network.","description":"The loss of connectivity to a particular authoritative time source will result in the loss of time synchronization (free-run mode) and increasingly inaccurate time stamps on log events and other functions. \n\nMultiple time sources provide redundancy by including a secondary source. Time synchronization is usually a hierarchy; clients synchronize time to a local source while that source synchronizes its time to a more accurate source. The network device must utilize an authoritative time server and/or be configured to use redundant authoritative time sources.","checkContent":"Verify the Juniper SRX is configured to synchronize internal information system clocks with the primary and secondary NTP sources.\n\n[edit]\nshow system ntp\n\nIf the Juniper SRX is not configured to synchronize internal information system clocks with an NTP server, this is a finding.","fixText":"The following commands allow the device to keep time synchronized with the network. To designate a primary NTP server, add the “prefer” keyword to the server statement.\n\n[edit]\nset system ntp server <NTP-server1-IP> prefer\nset system ntp source-address <MGT-IP-Address>\nset system ntp server <NTP-server2-IP>\nset system ntp source-address <MGT-IP-Address>","ccis":["CCI-000366"]},{"vulnId":"V-66489","ruleId":"SV-80979r1_rule","severity":"medium","ruleTitle":"The Juniper SRX Services Gateway must be configured to use an authentication server to centrally manage authentication and logon settings for remote and nonlocal access.","description":"Centralized management of authentication settings increases the security of remote and nonlocal access methods. This control is a particularly important protection against the insider threat. Audit records for administrator accounts access to the organization's network devices can be more readily analyzed for trends and anomalies. The alternative method of defining administrator accounts on each device exposes the device configuration to remote access authentication attacks and system administrators with multiple authenticators for each network device. \n\nThe Juniper SRX supports three methods of user authentication: local password authentication, Remote Authentication Dial-In User Service (RADIUS), and Terminal Access Controller Access Control System Plus (TACACS+). RADIUS and TACACS+ are remote access methods used for management of the Juniper SRX. The local password method will be configured for use only for the account of last resort.\n\nTo completely set up AAA authentication, create a user template account (the default name is remote) and specify a system authentication server and an authentication order. See CCI-000213 for more details. The remote user template is not a logon account. Once the AAA server option is configured, any remote or nonlocal access attempts are redirected to the AAA server. Since individual user accounts are not defined on the SRX, the authentication server must be used to manage individual account settings.","checkContent":"Verify the Juniper SRX is configured to support the use of AAA services to centrally manage user authentication and logon settings. \n\nFrom the CLI operational mode enter: \nshow system radius-server \nor \nshow system tacplus-server\n\nIf the Juniper SRX has not been configured to support the use RADIUS and/or TACACS+ servers to centrally manage authentication and logon settings for remote and nonlocal access, this is a finding.","fixText":"Configure the Juniper SRX to support the use of AAA services to centrally manage user authentication and logon settings. To completely set up AAA authentication, use a user template account (the default name is remote) and specify a system authentication server and an authentication order. \n\n[edit]\nset system tacplus-server address <server ipaddress> port 1812 secret <shared secret> \n\nor \n\n[edit]\nset system radius-server address <server ipaddress> port 1812 secret <shared secret> \n\nNote: DoD policy is that redundant AAA servers are required to mitigate the risk of a failure of the primary AAA device. Also see CCI-000213 for  further details.","ccis":["CCI-000366"]},{"vulnId":"V-66491","ruleId":"SV-80981r1_rule","severity":"medium","ruleTitle":"The Juniper SRX Services Gateway must be configured to use an authentication server to centrally apply authentication and logon settings for remote and nonlocal access for device management.","description":"Centralized application (e.g., TACACS+, RADIUS) of authentication settings increases the security of remote and nonlocal access methods. This control is a particularly important protection against the insider threat. Audit records for administrator accounts access to the organization's network devices can be more readily analyzed for trends and anomalies. The alternative method of defining administrator accounts on each device exposes the device configuration to remote access authentication attacks and system administrators with multiple authenticators for each network device.\n\nThis requirement references identification and authentication and does not prevent the configuration of privileges using the remote template account (CCI-000213).","checkContent":"Verify the Juniper SRX is configured to support the use of AAA services to centrally apply user authentication and logon settings. \n\nFrom the CLI operational mode enter: \nshow system radius-server \nor \nshow system tacplus-server\n\nIf the Juniper SRX has not been configured to support the use of RADIUS and/or TACACS+ servers to centrally apply authentication and logon settings for remote and nonlocal access, this is a finding.","fixText":"Configure the Juniper SRX to support the use of AAA services to centrally apply user authentication and logon settings. \n\n[edit]\nset system tacplus-server address <server ipaddress> port 1812 secret <shared secret> \n\nor \n\n[edit]\nset system radius-server address <server ipaddress> port 1812 secret <shared secret>","ccis":["CCI-000366"]},{"vulnId":"V-66493","ruleId":"SV-80983r1_rule","severity":"medium","ruleTitle":"The Juniper SRX Services Gateway must use DoD-approved PKI rather than proprietary or self-signed device certificates.","description":"To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DoD-approved PKIs.\n\nThe SRX generates a key-pair and a CSR. The CSR is sent to the approved CA, who signs it and returns it as a certificate. That certificate is then installed. \n\nThe process to obtain a device PKI certificate requires the generation of a Certificate Signing Request (CSR), submission of the CSR to a CA, approval of the request by an RA, and retrieval of the issued certificate from the CA.","checkContent":"To validate that the certificate was loaded, type the following command:\n\nshow security pki local-certificate\n\nView the installed device certificates.\n\nIf any of the certificates have the name or identifier of a non-approved source in the Issuer field, this is a finding.","fixText":"Generate a new key-pair from a DoD-approved certificate issuer. Sites must consult the PKI/PKI pages on the http://iase.disa.mil/ website for procedures for NIPRNet and SIPRNet.\n\nRSA:\nrequest security pki generate-key-pair certificate-id <cert name> type rsa size <512 | 1024 | 2048 | 4096>\n\nECDSA:\nrequest security pki generate-key-pair certificate-id <cert_name> type ecdsa size <256 | 384>\n\nGenerate a CSR from RSA key-pair using the following command and options.\n\nrequest security generate-certificate-request certificate-id <cert_name_from_key_file> digest <sha1 | sha256> domain <FQDN> email <admin_email> ip-address <ip_address> subject “CN=<hostname>,DC=<domain_part>,DC=<TLD_domain>,O=<organization>,OU=<organization_dept>,\nL=<city>,ST=<state>,C=<us>” filename <path/filename>\n\nGenerate a CSR from ECDSA key-pair use the following command and options.\n\nrequest security generate-certificate-request certificate-id <cert_name_from_key_file> digest <sha256 | sha384> domain <FQDN> email <admin_email> ip-address <ip_address> subject “CN=<hostname>,DC=<domain_part>,DC=<TLD_domain>,O=<organization>,OU=<organization_dept>,\nL=<city>,ST=<state>,C=<us>” filename <path/filename>\n\nIf no filename is specified, the CSR is displayed on the standard out (terminal)\n\nAfter receiving the approved certificate from the CA, enter the following command and options to upload the certificate.\n\nrequest security pki local-certificate certificate-id <cert_name_from_key_file> filename <path/filename_of_uploaded_certificate>\n\nFrom the operational mode of the hierarchy:\n\nset security certificates local new load-key-file /var/tmp/new.pem \n\nType the following command to load the X.509 certificate into the certificate store in operations mode.\n\n>request security pki local-certificate load certificate-id <ID> filename <PATH TO CERTIFICATE FILE>\n\nFor this example, assume the transferred the X.509 certificate called \"device-cert.crt\" to the /var/tmp directory on the SRXD. The following command will load the device-cert.crt certificate file and associate it with the public/private keypair named “device-keypair” generated in a previous step.\n\n>request security pki local-certificate load certificate-id device-keypair filename /var/tmp/device-cert.crt","ccis":["CCI-000366"]},{"vulnId":"V-66495","ruleId":"SV-80985r1_rule","severity":"medium","ruleTitle":"The Juniper SRX Services Gateway must generate an alarm or send an alert message to the management console when a component failure is detected.","description":"Component (e.g., chassis, file storage, file corruption) failure may cause the system to become unavailable, which could result in mission failure since the network would be operating without a critical security traffic inspection or access function.\n\nAlerts provide organizations with urgent messages. Real-time alerts provide these messages at information technology speed (i.e., the time from event detection to alert occurs in seconds or less). Automated alerts can be conveyed in a variety of ways, including, for example, telephonically, via electronic mail, via text message, or via websites.\n\nWhile this requirement also applies to the event monitoring system (e.g., Syslog, Security Information and Event Management [SIEM], or SNMP servers), the Juniper SRX must also be configured to generate a message to the administrator console.\n\nSyslog and SNMP trap events with a facility of \"daemon\" pertain to errors encountered by system processes.","checkContent":"Verify the system Syslog has been configured to display an alert on the console for the emergency and critical levels of the daemon facility.\n\n[edit] \nshow system syslog\n\nIf the system is not configured to generate a system alert message when a component failure is detected, this is a finding.","fixText":"The following commands configure syslog to immediately display any emergency level or daemon alert events to the management console. The message will display on any currently logged on administrator's console.\n\n[edit]\nset system syslog user * any emergency\nset system syslog user * daemon critical\nset system syslog user * daemon alert","ccis":["CCI-000366"]},{"vulnId":"V-66497","ruleId":"SV-80987r1_rule","severity":"medium","ruleTitle":"The Juniper SRX Services Gateway must be configured to prohibit the use of unnecessary and/or nonsecure functions, ports, protocols, and/or services, as defined in the PPSM CAL and vulnerability assessments.","description":"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 unused or unnecessary physical and logical ports/protocols on information systems.\n\nThe control plane is responsible for operating most of the system services on the SRX. The control plane is responsible not only for acting as the interface for the administrator operating the device, but also for controlling the operation of the chassis, pushing the configuration to the data plane, and operating the daemons that provide functionality to the system. The control plane operates the Junos OS, which is a FreeBSD variant. \n\nThe Juniper SRX control plane services include, but are not limited to, the following: Management Daemon (MGD), Routing Protocol Daemon (RPD) (e.g., RIP, OSPF, IS-IS, BGP, PIM, IPv6 counterparts), User interfaces (SSH, J-Web, NetConf), File system interfaces (SCP), Syslogd (DNS, DHCP, NTP, ICMP, ARP/ND, SNMP), Chassisd, JSRPD (HA clustering).","checkContent":"Entering the following commands from the configuration level of the hierarchy.\n\n[edit]\nshow system services\n\nIf functions, ports, protocols, and services identified on the PPSM CAL are not disabled, this is a finding.","fixText":"Ensure functions, ports, protocols, and services identified on the PPSM CAL are not used for system services configuration.\n\n[edit]\nshow system services\n\nCompare the services that are enabled, including the port, services, protocols, and functions.\n\nConsult 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.","ccis":["CCI-000382"]},{"vulnId":"V-66499","ruleId":"SV-80989r1_rule","severity":"medium","ruleTitle":"For nonlocal maintenance sessions, the Juniper SRX Services Gateway must remove or explicitly deny the use of nonsecure protocols.","description":"If unsecured protocols (lacking cryptographic mechanisms) are used for sessions, the contents of those sessions will be susceptible to manipulation, potentially allowing alteration and hijacking of maintenance sessions.\n\nNonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. \n\nTools used for nonlocal management and diagnostics with the Juniper SRX include SSH but may also include compatible enterprise maintenance and diagnostics servers. Regardless of the tool used, the Juniper SRX must permit only the use of protocols with the capability to be configured securely with integrity protections. Specifically, use SSH instead of Telnet, SCP instead of FTP, and SNMPv3 rather than other versions SNMP.","checkContent":"Verify nonsecure protocols are not enabled for management access by viewing the enabled system services.\n\nFrom the operational hierarchy:\n\n> show config | match \"set system services\" | display set \n\nFrom the configuration hierarchy:\n\n[edit]\nshow snmp\nshow system services telnet\nshow system services ftp\nshow system services ssh\n\nIf nonsecure protocols and protocol versions such as Telnet, FTP, SNMPv1, SNMPv2c, or SSHv1 are enabled, this is a finding.","fixText":"Remove or deny nonsecure protocols to prevent their usage for nonlocal management and diagnostic communications.\n\nUse the delete command to disable services that should not be enabled.\n\nExample deletion commands:\n\n[edit]\ndelete system services telnet\ndelete system services ftp\ndelete snmp v1\ndelete snmp v2c\ndelete set system services ssh protocol-version v1","ccis":["CCI-000382"]},{"vulnId":"V-66501","ruleId":"SV-80991r1_rule","severity":"medium","ruleTitle":"The Juniper SRX Services Gateway must authenticate NTP servers before establishing a network connection using bidirectional authentication that is cryptographically based.","description":"Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. Bidirectional authentication provides stronger safeguards to validate the identity of other devices for connections that are of greater risk, such as remote connections.\n\nThe Juniper SRX can only be configured to use MD5 authentication keys. This algorithm is not FIPS 140-2 validated; thus, a CAT 1 finding is allocated in CCI-000803. However, MD5 is preferred to no authentication at all.\n\nThe trusted-key statement permits authenticating NTP servers. The Juniper SRX supports multiple keys, multiple NTP servers, and different keys for each server; add the “key <key number>” parameter to the server statement to associate a key with a specific server.","checkContent":"Verify the Juniper SRX is configured to synchronize internal information system clocks with the primary and secondary NTP sources.\n\n[edit]\nshow system ntp\n\nIf the NTP configuration is not configured to use authentication, this is a finding.","fixText":"The Juniper SRX can only be configured to use MD5 authentication keys. This algorithm is not FIPS 140-2 validated; therefore, it violates CCI-000803, which is a CAT 1. However, MD5 is preferred to no authentication at all. The following commands configure the Juniper SRX to use MD5 authentication keys. \n\nset system ntp authentication-key 1 type md5\nset system ntp authentication-key 1 value \"$9$EgfcrvX7VY4ZEcwgoHjkP5REyv87\"\nset system ntp authentication-key 2 type md5\nset system ntp authentication-key 2 value \"kP5$EgvVfcrwgoY4X7ZEcH$9j RExz50\"\nset system ntp server <NTP_server_IP> key 1\nset system ntp server <NTP_server_IP> prefer\nset system ntp server <NTP_server_IP> key 2\nset system ntp trusted-key 1\nset system ntp trusted-key 2","ccis":["CCI-001967"]},{"vulnId":"V-66503","ruleId":"SV-80993r1_rule","severity":"medium","ruleTitle":"The Juniper SRX Services Gateway must ensure SSH is disabled for root user logon to prevent remote access using the root account.","description":"Since the identity of the root account is well-known for systems based upon Linux or UNIX and this account does not have a setting to limit access attempts, there is risk of a brute force attack on the password. Root access would give superuser access to an attacker. Preventing attackers from remotely accessing management functions using root account mitigates the risk that unauthorized individuals or processes may gain superuser access to information or privileges.\n\nA separate account should be used for access and then the administrator can sudo to root when necessary.","checkContent":"Use the CLI to view this setting for disabled for SSH. \n\n[edit]\nshow system services ssh root-login\n\nIf SSH is not disabled for the root user, this is a finding.","fixText":"From the configuration mode, enter the following commands to disable root-login using SSH.\n\n[edit]\nset system services ssh root-login deny","ccis":["CCI-000382"]},{"vulnId":"V-66507","ruleId":"SV-80997r1_rule","severity":"medium","ruleTitle":"The Juniper SRX Services Gateway must ensure access to start a UNIX-level shell is restricted to only the root account.","description":"Restricting the privilege to create a UNIX-level shell limits access to this powerful function. System administrators, regardless of their other permissions, will need to also know the root password for this access, thus limiting the possibility of malicious or accidental circumvention of security controls.","checkContent":"Verify each login class is configured to deny access to the UNIX shell.\n\n[edit]\nshow system login\n\nIf each configured login class is not configured to deny access to the UNIX shell, this is a finding.","fixText":"For each login class, add the following command to the stanza.\n\n[edit]\nset system login class <class name> deny-commands \"(start shell)\"","ccis":["CCI-000382"]},{"vulnId":"V-66509","ruleId":"SV-80999r1_rule","severity":"medium","ruleTitle":"The Juniper SRX Services Gateway must ensure TCP forwarding is disabled for SSH to prevent unauthorized access.","description":"Use this configuration option to prevent a user from creating an SSH tunnel over a CLI session to the Juniper SRX via SSH. This type of tunnel could be used to forward TCP traffic, bypassing any firewall filters or ACLs, allowing unauthorized access.","checkContent":"Use the CLI to view this setting for disabled for SSH. \n\n[edit]\nshow system services ssh\n\nIf TCP forwarding is not disabled for the root user, this is a finding.","fixText":"From the configuration mode, enter the following commands to disable TCP forwarding for the SSH protocol.\n\n[edit]\nset system services ssh no-tcp-forwarding","ccis":["CCI-000382"]},{"vulnId":"V-66511","ruleId":"SV-81001r1_rule","severity":"medium","ruleTitle":"The Juniper SRX Services Gateway must be configured with only one local user account to be used as the account of last resort.","description":"Without centralized management, credentials for some network devices will be forgotten, leading to delays in administration, which itself leads to delays in remediating production problems and in addressing compromises in a timely fashion. Maintaining local administrator accounts for daily usage on each network device without centralized management is not scalable or feasible. \n\nLocal accounts are configured using the local password authentication method which does not meet the multifactor authentication criteria. The account of last resort is a group authenticator which does not provide nonrepudiation, thus must be used only rare cases where the device must be accessed using the local console and an individual authenticator is not possible, including when network access is not available.","checkContent":"Verify only a single local account has an authentication stanza and that the name is the account of last resort.\n\n[edit]\nshow system login\n\nuser <account of last resort> {\n  uid 2001;\n  class <appropriate class name>;\n  authentication { <--- This stanza permits local login\n    encrypted-password \"$sha2$22895$aVBPaRVa$o6xIqNSYg9D7yt8pI47etAjZV9uuwHrhAFT6R021HNsy\"; ## SECRET-DATA\n  }\n}\n\nOR\n\nuser <template account> {\n  uid 2001;\n  class <appropriate class name>;\n}\n\nIf accounts other than the account of last resort contain an authentication stanza, and that account is not documented, this is a finding.","fixText":"If more than one account has an authentication stanza, and it is not documented, delete the authentication stanza (if the account is a template account) or the entire account (if the account is unauthorized or no longer needed).\n\nTo delete a template account:\n\n[edit]\ndelete system login user <account name> authentication\ncommit\n\nTo delete an unneeded or unauthorized account:\n\n[edit]\ndelete system login user <account name>","ccis":["CCI-000382"]},{"vulnId":"V-66513","ruleId":"SV-81003r1_rule","severity":"medium","ruleTitle":"The Juniper SRX Services Gateway must implement replay-resistant authentication mechanisms for network access to privileged accounts.","description":"A replay attack may enable an unauthorized user to gain access to the application. Authentication sessions between the authenticator and the application validating the user credentials must not be vulnerable to a replay attack.\n\nAn authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. \n\nThere are 2 approved methods for accessing the Juniper SRX which are, in order of preference, the SSH protocol and the console port.","checkContent":"Verify SSH is configured to use a replay-resistant authentication mechanism.\n\n[edit]\nshow system services ssh\n\nIf SSH is not configured to use the MAC authentication protocol, this is a finding.","fixText":"Configure SSH to use a replay-resistant authentication mechanism. The following is an example stanza.\n\n[edit]\nset system services ssh macs hmac-sha2-512\nset system services ssh macs hmac-sha2-256\nset system services ssh macs hmac-sha1\nset system services ssh macs hmac-sha1-96","ccis":["CCI-001941"]},{"vulnId":"V-66515","ruleId":"SV-81005r1_rule","severity":"medium","ruleTitle":"For local accounts using password authentication (i.e., the root account and the account of last resort), the Juniper SRX Services Gateway must enforce a minimum 15-character password length.","description":"Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised. Use of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password.\n\nCompliance with this requirement also prevents the system from being configured with default or no passwords.","checkContent":"Verify the SRX password enforces this complexity requirement. In configuration mode, enter the following command.\n\n[edit]\nshow system login password\n\nIf the minimum password length for local accounts is not set to at least a 15-character length, this is a finding.","fixText":"Set the global password option for all accounts created on the Juniper SRX.\n\n[edit]\nset system login password minimum-length 15\n\nNote: This setting only enforces the minimum character password length for newly created passwords. The password of the existing account must be changed if it is not already complaint.\n\nTo set or change the root user password, in configuration mode enter the following command.\n\n[edit]\nset system root-authentication plain-text-password\n\nWhen prompted, enter the password for the root user. \nRetype new password to confirm\n\nTo set or change the account of last resort, in configuration mode enter the following command.\n\n[edit]\nset system login user <name of the account of last resort> plain-text-password\n\nWhen prompted, enter the password for the root user. \nRetype new password to confirm","ccis":["CCI-000205"]},{"vulnId":"V-66517","ruleId":"SV-81007r1_rule","severity":"medium","ruleTitle":"For local accounts using password authentication (i.e., the root account and the account of last resort), the Juniper SRX Services Gateway must enforce password complexity by setting the password change type to character sets.","description":"Use of a complex passwords helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. \n\nThe password change-type command specifies whether a minimum number of character-sets or a minimum number of character-set transitions are enforced. The DoD requires this setting be set to character-sets.","checkContent":"Verify the default local password enforces password complexity by setting the password change type to character sets\n\n[edit]\nshow system login password\n\nIf the password change-type is not set to character-sets, this is a finding.","fixText":"Configure the default local password to enforce password complexity by setting the password change type to character sets\n\n[edit]\nset system login password change-type character-sets","ccis":["CCI-000192"]},{"vulnId":"V-66519","ruleId":"SV-81009r1_rule","severity":"medium","ruleTitle":"For local accounts using password authentication (i.e., the root account and the account of last resort), the Juniper SRX Services Gateway must enforce password complexity by requiring at least one upper-case character be used.","description":"Use of a complex passwords helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. \n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised.","checkContent":"Verify the default local password enforces password complexity by requiring at least one upper-case character be used.\n\n[edit]\nshow system login password\n\nIf the minimum-upper-cases is not set to at least 1, this is a finding.","fixText":"Configure the default local password to enforce password complexity by requiring at least one upper-case character be used.\n\n[edit]\nset system login password minimum-upper-cases 1","ccis":["CCI-000192"]},{"vulnId":"V-66521","ruleId":"SV-81011r1_rule","severity":"medium","ruleTitle":"For local accounts using password authentication (i.e., the root account and the account of last resort), the Juniper SRX Services Gateway must enforce password complexity by requiring at least one lower-case character be used.","description":"Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. \n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.","checkContent":"Verify the default local password enforces password complexity by requiring at least one lower-case character be used.\n\n[edit]\nshow system login password\n\nIf the minimum-lower-cases is not set to at least 1, this is a finding.","fixText":"Configure the default local password to enforce password complexity by requiring at least one lower-case character be used.\n\n[edit]\nset system login password minimum-lower-cases 1","ccis":["CCI-000193"]},{"vulnId":"V-66523","ruleId":"SV-81013r2_rule","severity":"medium","ruleTitle":"For local accounts using password authentication (i.e., the root account and the account of last resort), the Juniper SRX Services Gateway must enforce password complexity by requiring at least one numeric character be used.","description":"Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. \n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.","checkContent":"Verify the default local password enforces password complexity by requiring at least one numeric character be used.\n\n[edit]\nshow system login password\n\nIf the minimum numerics are not set to at least 1, this is a finding.","fixText":"Configure the default local password to enforce password complexity by requiring at least one numeric character be used.\n\n[edit]\nset system login password minimum -numerics to 1\n","ccis":["CCI-000194"]},{"vulnId":"V-66525","ruleId":"SV-81015r1_rule","severity":"medium","ruleTitle":"For local accounts using password authentication (i.e., the root account and the account of last resort), the Juniper SRX Services Gateway must enforce password complexity by requiring at least one special character be used.","description":"Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. \n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.","checkContent":"Verify the default local password enforces password complexity by requiring at least one special character be used.\n\n[edit]\nshow system login password\n\nIf the minimum-punctuation is not set to at least 1, this is a finding.","fixText":"Configure the default local password to enforce password complexity by requiring at least one special character be used.\n\n[edit]\nset system login password minimum-punctuations 1","ccis":["CCI-001619"]},{"vulnId":"V-66527","ruleId":"SV-81017r1_rule","severity":"medium","ruleTitle":"For local accounts using password authentication (i.e., the root account and the account of last resort) the Juniper SRX Services Gateway must use the SHA1 or later protocol for password authentication.","description":"Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised.\n\nThe password format command is an optional command that specifies the hash algorithm used for authenticating passwords. The options are MD5, SHA1, or DES. SHA1 is recommended because it is a FIPS-approved algorithm and provides stronger security.","checkContent":"Verify the default local password enforces this requirement by entering the following in configuration mode.\n\n[edit]\nshow system login password\n\nIf the password format is not set to SHA-1, this is a finding.","fixText":"Enter the configuration mode on the Juniper SRX, set the password option for the local user account of last resort using the following command. \n\n[edit]\nset system login password format sha1","ccis":["CCI-000197"]},{"vulnId":"V-66529","ruleId":"SV-81019r1_rule","severity":"medium","ruleTitle":"For nonlocal maintenance sessions using SSH, the Juniper SRX Services Gateway must securely configure SSHv2 Message Authentication Code (MAC) algorithms to protect the integrity of maintenance and diagnostic communications.","description":"To protect the integrity of nonlocal maintenance sessions, SSHv2 with MAC algorithms for integrity checking must be configured. \n\nNonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. \n\nThe SSHv2 protocol suite includes Layer 7 protocols such as SCP and SFTP which can be used for secure file transfers.","checkContent":"Verify SSHv2 and MAC algorithms for integrity checking.\n\n[edit]\nshow system services ssh\n\nIf SSHv2 and integrity options are not configured in compliance with DoD requirements, this is a finding.","fixText":"Configure SSH integrity options to comply with DoD requirements.\n\n[edit]\nset system services ssh protocol-version v2\nset system services ssh macs hmac-sha2-512\nset system services ssh macs hmac-sha2-256\nset system services ssh macs hmac-sha1\nset system services ssh macs hmac-sha1-96","ccis":["CCI-002890"]},{"vulnId":"V-66531","ruleId":"SV-81021r1_rule","severity":"medium","ruleTitle":"For nonlocal maintenance sessions using SSH, the Juniper SRX Services Gateway must securely configured SSHv2 with privacy options to protect the confidentiality of maintenance and diagnostic communications for nonlocal maintenance sessions.","description":"To protect the confidentiality of nonlocal maintenance sessions when using SSH communications, SSHv2, AES ciphers, and key-exchange commands are configured. \n\nNonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. \n\nThe SSHv2 protocol suite includes Layer 7 protocols such as SCP and SFTP which can be used for secure file transfers. The key-exchange commands limit the key exchanges to FIPS and DoD-approved methods.","checkContent":"Verify SSHv2, AES ciphers, and key-exchange commands are configured to protect confidentiality.\n\n[edit]\nshow system services ssh\n\nIf SSHv2, AES ciphers, and key-exchange commands are not configured to protect confidentiality, this is a finding.","fixText":"Configure SSH confidentiality options to comply with DoD requirements.\n\n[edit]\nset system services ssh protocol-version v2\nset system services ssh ciphers aes256-ctr\nset system services ssh ciphers aes256-cbc\nset system services ssh ciphers aes192-ctr\nset system services ssh ciphers aes192-cbc\nset system services ssh ciphers aes128-ctr\nset system services ssh ciphers aes128-cbc\nset system services ssh key-exchange dh-group14-sha1\nset system services ssh key-exchange group-exchange-sha2\nset system services ssh key-exchange ecdh-sha2-nistp256\nset system services ssh key-exchange ecdh-sha2-nistp384\nset system services ssh key-exchange ecdh-sha2-nistp521","ccis":["CCI-003123"]},{"vulnId":"V-66533","ruleId":"SV-81023r2_rule","severity":"medium","ruleTitle":"For nonlocal maintenance sessions, the Juniper SRX Services Gateway must ensure only zones where management functionality is desired have host-inbound-traffic system-services configured.","description":"Add a firewall filter to protect the management interface. Note: The dedicated management interface (if present), and an interface placed in the functional zone management, will not participate in routing network traffic. It will only support device management traffic.\n\nThe host-inbound-traffic feature of the SRX is an additional layer of security for system services. This function can be configured on either a per zone or a per interface basis within each individual security zone. By default, a security zone has all system services disabled, which means that it will not accept any inbound management or protocol requests on the control plane without explicitly enabling the service at either the interface or zone in the security zone stanzas.","checkContent":"Verify only those zones where management functionality is allowed have host-inbound-traffic system-services configured and that protocols such as HTTP and HTTPS are not assigned to these zones.\n\n[edit]\nshow security zones functional-zone management\n\nIf zones configured for host-inbound-traffic system-services have protocols other than SSH configured, this is a finding.","fixText":"Remove host-inbound-traffic systems-services option from zones not authorized for management traffic.\n\nRemove unauthorized protocols (e.g., HTTP, HTTPS) from management zones that are configured to allow host-inbound-traffic system-services.","ccis":["CCI-003123"]},{"vulnId":"V-66535","ruleId":"SV-81025r1_rule","severity":"medium","ruleTitle":"The Juniper SRX Services Gateway must immediately terminate SSH network connections when the user logs off, the session abnormally terminates, or an upstream link from the managed device goes down.","description":"This setting frees device resources and mitigates the risk of an unauthorized user gaining access to an open idle session. \n\nWhen sessions are terminated by a normal administrator log off, the Juniper SRX makes the current contents unreadable and no user activity can take place in the session. However, abnormal terminations or loss of communications do not signal a session termination, thus a keep-alive count and interval must be configured so the device will know when communication with the client is no longer available. The keep-alive value and the interval between keep-alive messages must be set to an organization-defined value based on mission requirements and network performance.","checkContent":"[edit]\nshow system services ssh\n\nIf the keep-alive count and keep-alive interval are not set to an organization-defined value, this is a finding.","fixText":"Configure the SSH keep-alive value.\n\n[edit]\nset system services ssh client-alive-count-max <organization-defined value>\nset system services ssh client-alive-interval <organization-defined value>\n\nNote: The keep-alive value and the interval between keep-alive messages must be set based on mission requirements and network performance for each local network.","ccis":["CCI-000879"]},{"vulnId":"V-66537","ruleId":"SV-81027r1_rule","severity":"medium","ruleTitle":"The Juniper SRX Services Gateway must terminate a device management session after 10 minutes of inactivity, except to fulfill documented and validated mission requirements.","description":"Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session. Quickly terminating an idle session also frees up resources. \n\nThis requirement does not mean that the device terminates all sessions or network access; it only ends the inactive session.\n\nUser accounts, including the account of last resort must be assigned to a login class. Configure all login classes with an idle timeout value. Pre-defined classes do not support configurations, therefore should not be used for DoD implementations. The root account cannot be assigned to a login-class which is why it is critical that this account be secured in accordance with DoD policy.","checkContent":"Verify idle-timeout is set for 10 minutes.\n\n[edit]\nshow system login\n\nIf a timeout value of 10 or less is not set for each class, this is a finding.","fixText":"Configure all login classes with an idle timeout value. \n\n[edit]\nset system login-class <class name> idle-timeout 10\n\nAll users must be set to a login-class; however, to ensure that the CLI is set to a default timeout value, enter the following in operational mode: \n\nset cli idle-timeout 10","ccis":["CCI-001133"]},{"vulnId":"V-66539","ruleId":"SV-81029r1_rule","severity":"medium","ruleTitle":"The Juniper SRX Services Gateway must terminate a device management session if the keep-alive count is exceeded.","description":"Configuring the keep-alive for management protocols mitigates the risk of an open connection being hijacked by an attacker.\n\nThe keep-alive messages and the interval between each message are used to force the system to disconnect a user that has lost network connectivity to the device. This differs from inactivity timeouts because the device does not wait the 10 minutes to log the user out but, instead, immediately logs the user out if the number of keep-alive messages are exceeded. The interval between messages should also be configured. These values should be set to an organization-defined value based on mission requirements and network performance.","checkContent":"Verify this setting by entering the following commands in configuration mode.\n\n[edit]\nshow system services ssh\n\nIf the keep-alive count and keep-alive interval is not set to an organization-defined value, this is a finding.","fixText":"Configure this setting by entering the following commands in configuration mode.\n\n[edit]\nset system services ssh client-alive-count-max <organization-defined value>\nset system services ssh client-alive-interval <organization-defined value>","ccis":["CCI-001133"]},{"vulnId":"V-66541","ruleId":"SV-81031r1_rule","severity":"medium","ruleTitle":"The Juniper SRX Services Gateway must configure the control plane to protect against or limit the effects of common types of Denial of Service (DoS) attacks on the device itself by configuring applicable system options and internet-options.","description":"DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity.\n\nJuniper SRX uses the system commands, system internet-options, and screens to mitigate the impact of DoS attacks on device availability.","checkContent":"Verify the system options are configured to protect against DoS attacks.\n\n[edit]\nshow system\nshow system internet-options\n\nIf the system and system-options which limit the effects of common types of DoS attacks are not configured in compliance with DoD requirements, this is a finding.","fixText":"Configure the system and system-options to protect against DoS attacks.\n\n[edit]\nset system no-redirects\nset system no-ping-record-route\nset system no-ping-time-stamp\nset system internet-options icmpv4-rate-limit packet-rate 50\nset system internet-options icmpv6-rate-limit packet-rate 50\nset system internet-options no-ipip-path-mtu-discovery\nset system internet-options no-source-quench\nset system internet-options tcp-drop-synfin-set\nset system internet-options no-ipv6-path-mtu-discovery\nset system internet-options no-tcp-reset drop-all-tcp","ccis":["CCI-002385"]},{"vulnId":"V-66543","ruleId":"SV-81033r1_rule","severity":"medium","ruleTitle":"The Juniper SRX Services Gateway must limit the number of sessions per minute to an organization-defined number for SSH to protect remote access management from unauthorized access.","description":"The rate-limit command limits the number of SSH session attempts allowed per minute which helps limit an attacker's ability to perform DoS attacks. The rate limit should be as restrictive as operationally practical.\n\nJuniper Networks recommends a best practice of 4 for the rate limit, however the limit should be as restrictive as operationally practical. \n\nUser connections that exceed the rate-limit will be closed immediately after the connection is initiated. They will not be in a waiting state.","checkContent":"Verify the Juniper SRX sets a connection-limit for the SSH protocol.\n\nShow system services ssh\n\nIf the SSH connection-limit is not set to 4 or an organization-defined value, this is a finding.","fixText":"Configure the SSH protocol with a rate limit.\n\n[edit]\nset system services ssh rate-limit 4\n\nNote: Juniper Networks recommends a best practice of 4 for the rate limit; however, the limit should be as restrictive as operationally practical.","ccis":["CCI-002385"]},{"vulnId":"V-66545","ruleId":"SV-81035r1_rule","severity":"medium","ruleTitle":"The Juniper SRX Services Gateway must reveal log messages or management console alerts only to the ISSO, ISSM, and SA roles).","description":"Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state. Additionally, sensitive account information must not be revealed through error messages to unauthorized personnel or their designated representatives.\n\nAlthough, based on policy, administrator accounts must be created on the AAA server, thus this requirement addresses the creation of unauthorized accounts on the Juniper SRX itself. This does not negate the need to address this requirement on the AAA server and the event monitoring server (e.g., Syslog, Security Information and Event Management [SIEM], or SNMP servers).","checkContent":"Obtain a list of authorized user names that are authorized to view the audit log and console notification messages. Verify classes are created that separate administrator roles based on authorization. View user classes and class members by typing the following commands.\n\n[edit]\nshow system login\n\nView class assignment for all users and template users configured on the Juniper SRX. Users with login classes audit-admin, security-admin, and system-admin have permission to view error message in logs and/or notifications. \n\nIf classes or users that are not authorized to have access to the logs (e.g., crypto-admin) have permissions to view or access error message in logs and/or notifications, this is a finding.","fixText":"Configure login classes and permissions and assign only authorized users to each class.\n\n[edit]\nshow system login\n\nIf any classes  are mapped to the audit-admin, security-admin, or system-admin login templates, delete the command from the class by typing delete in front of the command or retyping the command with the permission removed from the list.\n\nExample configuration:\nset system login class audit-admin allow-commands \"(show log *)|(clear log *)|(monitor\nlog *)\"\nset system login class audit-admin allow-configuration \"(system syslog)\"\nset system login class emergency permissions all\nset system login class emergency login-alarms\nset system login class security-admin login-alarms\nset system login class system-admin login-alarms","ccis":["CCI-001314"]},{"vulnId":"V-66547","ruleId":"SV-81037r1_rule","severity":"medium","ruleTitle":"The Juniper SRX Services Gateway must be configured to use Junos 12.1 X46 or later to meet the minimum required version for DoD.","description":"Earlier versions of Junos may have reached the end of life cycle support by the vendor. Junos 12.1X46 is not a UC APL certified version, while 12.1X46 is UC APL Certified. The SRX with Junos 12.1X46 has been NIAP certified as a firewall and VPN. Junos 12.1X46 contains a number of enhancements, particularly related to IPv6, that are relevant to the STIG.","checkContent":"Verify the version installed is Junos 12.1 X46 or later. In operational mode, type the following:\n\nshow version\n\nIf the Junos version installed is not 12.1 X46 or later, this is a finding.","fixText":"Follow the manufacturer's instructions for upgrading the Junos version. Software updates must be from an approved site and follow approved DoD procedures and verification processes in accordance with site testing procedures.","ccis":["CCI-000366"]},{"vulnId":"V-66549","ruleId":"SV-81039r1_rule","severity":"low","ruleTitle":"The Juniper SRX Services Gateway must limit the number of concurrent sessions to a maximum of 10 or less for remote access using SSH.","description":"The connection-limit command limits the total number of concurrent SSH sessions. To help thwart brute force authentication attacks, the connection limit should be as restrictive as operationally practical\n\nJuniper Networks recommends the best practice of setting 10 (or less) for the connection-limit.\n\nThis configuration will permit up to 10 users to log in to the device simultaneously, but an attempt to log an 11th user into the device will fail. The attempt will remain in a waiting state until a session is terminated and made available.","checkContent":"Verify the Juniper SRX sets a connection-limit for the SSH protocol.\n\nShow system services ssh\n\nIf the SSH connection-limit is not set to 10 or less, this is a finding.","fixText":"Configure the SSH protocol to limit connection and sessions per connection.\n\n[edit]\nset system services ssh connection-limit 10\nset system services ssh max-sessions-per-connection 1","ccis":["CCI-000054"]},{"vulnId":"V-66551","ruleId":"SV-81041r1_rule","severity":"low","ruleTitle":"The Juniper SRX Services Gateway must generate a log event when privileged commands are executed.","description":"Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised information system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider threats and the advanced persistent threat.\n\nAll commands executed on the Juniper SRX are privileged commands. Thus, this requirement is configured using the same syslog command as CCI-000172.","checkContent":"Verify the device generates a log event when privileged commands are executed.\n\n[edit] \nshow system syslog\n\nIf a valid syslog host server and the syslog file names are not configured to capture \"any\" facility and \"any\" event, this is a finding.","fixText":"Along with the other commands that constitute a complete DoD syslog configuration, the following command must be ensure privileged commands are sent to the Syslog Server. \n\n[edit]\nset system syslog host <IP-syslog-server> any any","ccis":["CCI-002234"]},{"vulnId":"V-66553","ruleId":"SV-81043r1_rule","severity":"low","ruleTitle":"For local accounts created on the device, the Juniper SRX Services Gateway must enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period.","description":"By limiting the number of failed logon attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute-forcing, is reduced.\n\nJuniper SRX is unable to comply with the 15-minute time period part of this control.","checkContent":"Verify the number of unsuccessful logon attempts is set to 3.\n\n[edit]\nshow system login retry-options \n\nIf the number of unsuccessful logon attempts is set to 3, this is a finding.","fixText":"Configure the number of unsuccessful logon attempts for all login account, globally.\n\n[edit]\nset system login retry-options tries-before-disconnect 3","ccis":["CCI-000044"]},{"vulnId":"V-66555","ruleId":"SV-81045r1_rule","severity":"low","ruleTitle":"The Juniper SRX Services Gateway must display the Standard Mandatory DoD Notice and Consent Banner before granting access.","description":"Display of the DoD-approved use notification before granting access to the network device ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.\n\nSystem use notifications are required only for access via logon interfaces with human users.\n\nThe Standard Mandatory DoD Notice and Consent Banner must be displayed before the user has been authenticated.","checkContent":"Verify the Standard Mandatory DoD Notice and Consent Banner is displayed before the user has been authenticated either locally or by the AAA server by typing the following command at the [edit system login] hierarchy level.\n\n[edit]\nshow system login message\n\nIf the Standard Mandatory DoD Notice and Consent Banner is not displayed before the user has been authenticated, this is a finding.","fixText":"To configure a system login message, include the message statement at the [edit] hierarchy level.\nThis is the approved verbiage for applications that can accommodate banners of 1300 characters:\n\n[edit]\nset system login message \"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.\\by using this IS (which includes any device attached to this IS), you consent to the following conditions:\\n-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.\\n-At any time, the USG may inspect and seize data stored on this IS.\\n-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.\\n-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.\\n-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.\\n\\n\"\n\nOR\n\n[edit]\nUse the following verbiage for operating systems that have severe limitations on the number of characters that can be displayed in the banner:\n\nset system login message \"I've read & consent to terms in IS user agreem't>\\n\\n\"\n\nNote: Use \\n to insert a line between paragraphs where needed.","ccis":["CCI-000048"]},{"vulnId":"V-66557","ruleId":"SV-81047r1_rule","severity":"low","ruleTitle":"The Juniper SRX Services Gateway must allow only the ISSM (or administrators/roles appointed by the ISSM) to select which auditable events are to be generated and forwarded to the syslog and/or local logs.","description":"Without the capability to restrict which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.\n\nThe primary audit log permissions are set on the Syslog server, not the Juniper SRX. However, it is a best practice to also keep local logs for troubleshooting and backup. These logs are subject to access control requirements.\n\nThis configuration is a two-step process. Part of the configuration must be performed on the AAA server. After a user successfully logs on, the AAA sever passes the template or role of the user to the Juniper SRX. Each AAA template or role is mapped to a login class on the Juniper SRX. \n\nOn the Juniper SRX, the class name, audit-admin, is recommended as a best practice because it follows the naming convention used in NIAP testing and is self-documenting.","checkContent":"Verify only the ISSM (or administrators or roles appointed by the ISSM) have permission to configure and control audit events.\n\n[edit]\nshow system login class\nshow system login\n\nView permissions for the audit-admin class (audit-admin is an example class name; local policy may dictate another name). View class assignment for all users and template users configured on the Juniper SRX.\n\nIf user templates or users are other than the ISSM (or administrators or roles appointed by the ISSM) have permission to select which auditable events are to be audited, this is a finding.","fixText":"Configure the Juniper SRX to allow only the ISSM user account (or administrators/roles appointed by the ISSM) to select which auditable events are to be audited. To ensure this is the case, each ISSM-appointed role on the AAA must be configured for least privilege using the following stanzas for each role.\n\nFor audit-admin role:\n\n[edit]\nset system login class audit-admin permissions [ security trace maintenance ]\nset system login class audit-admin allow-commands \"^clear (log|security log)\" \nset system login class audit-admin deny-commands \"^clear (security alarms|system login lockout)|^file (copy|delete|rename)|^request (security|system set-encryption-key)|^rollback|^set date|^show security (alarms|dynamic-policies|match-policies|policies)|^start shell\"\nset system login class audit-admin security-role audit-administrator \nset system login user audit-officer class audit-admin \n\nFor the crypto admin role:\n\n[edit]\nset system login class crypto-admin permissions [ admin-control configure maintenance security-control system-control trace ]\nset system login class crypto-admin allow-commands \"^request system set-encryption-key\" \nset system login class crypto-admin deny-commands \"^clear (log|security alarms|security log|system login lockout)|^file (copy|delete|rename)|^rollback|^set date|^show security (alarms|dynamic-policies|match-policies|policies)|^start shell\"\nset system login class crypto-admin allow-configuration-regexps \"security (ike|ipsec) (policy|proposal)\" \"security ipsec ^vpn$ .* manual (authentication|encryption|protocol|spi)\" \"system fips self-test after-key-generation\" \nset system login class crypto-admin security-role crypto-administrator \n\nFor the security-admin role:\n\n[edit]\nset system login class security-admin permissions all \nset system login class security-admin deny-commands \"^clear (log|security log)|^(clear|show) security alarms alarm-type idp|^request (security|system set-encryption-key)|^rollback|^start shell\"\nset system login class security-admin deny-configuration-regexps \"security alarms potential-violation idp\" \"security (ike|ipsec) (policy|proposal)\" \"security ipsec ^vpn$ .* manual (authentication| encryption|protocol|spi)\" \"security log cache\" \"security log exclude .* event-id IDP_.*\" \"system fips self-test after-key- generation\" \nset system login class security-admin security-role security-administrator \n\nFor the ids-admin role:\n\n[edit]\nset system login class ids-admin permissions [ configure maintenance security-control trace ]\nset system login class ids-admin allow-configuration-regexps \"security alarms potential-violation idp\" \"security log exclude .* event-id IDP_.*\" \nset system login class ids-admin deny-commands \"^clear log|^(clear|show) security alarms (alarm-id|all|newer-than|older- than|process|severity)|^(clear|show) security alarms alarm-type (authentication|cryptographic-self-test|decryption-failures|encryption-failures| ike-phase1-failures|ike-phase2-failures|key-generation-self-test| non-cryptographic-self-test|policy|replay-attacks)|^file (copy|delete|rename)|^request (security|system set-encryption-key)|^rollback|^set date|^show security (dynamic-policies|match-policies|policies)|^start shell\"\nset system login class ids-admin deny-configuration-regexps \"security alarms potential-violation (authentication|cryptographic-self-test|decryption-failures|encryption-failures|ike-phase1-failures|ike-phase2-failures|key-generation-self-test|non-cryptographic-self-test|policy|replay-attacks)\" \nset system login class ids-admin security-role ids-admin \n\nFor the crypto-officer class:\n\n[edit]\nset system login user crypto-officer class crypto-admin \nset system login user security-officer class security-admin\nset system login user ids-officer class ids-admin","ccis":["CCI-000171"]},{"vulnId":"V-66559","ruleId":"SV-81049r1_rule","severity":"low","ruleTitle":"The Juniper SRX Services Gateway must generate log records when successful attempts to configure the device and use commands occur.","description":"Without generating log records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. \n\nWhile the Juniper SRX inherently has the capability to generate log records, by default only the high facility levels are captured by default to local files. \n\nEnsure 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).","checkContent":"Verify logging has been enabled and configured.\n\n[edit] \nshow system syslog\n\nIf a valid syslog host server and the syslog file names are not configured to capture \"any\" facility and \"any\" event, this is a finding.","fixText":"The following example commands configure Syslog and local backup files to capture DoD-defined auditable events. \n\n[edit]\nset system syslog user * any emergency\nset system syslog host <IP-syslog-server> any any\nset system syslog host <IP-syslog-server> source-address <MGT-IP-Address>\nset system syslog host <IP-syslog-server> log-prefix <host-name>\nset system syslog file messages any info\nset system syslog file messages authorization none\nset system syslog file messages interactive-commands none \nset system syslog file messages daemon none \nset system syslog file User-Auth authorization any\nset system syslog file interactive-commands interactive-commands any\nset system syslog file processes daemon any\nset system syslog file account-actions change-log any any\nset file account-actions match “system login user”\nset system syslog console any any","ccis":["CCI-000172"]},{"vulnId":"V-66561","ruleId":"SV-81051r1_rule","severity":"low","ruleTitle":"The Juniper SRX Services Gateway must generate log records when changes are made to administrator privileges.","description":"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.","checkContent":"Verify the device logs change-log events of severity info or any to an external syslog server.\n\n[edit]\nshow system syslog\n\nhost <syslog server address> {\n  any <info | any>;\n  source-address <device address>;\n}\n\n-OR-\n\nhost <syslog server address> {\n  change-log <info | any>;\n  source-address <device address>;\n}\n\nIf an external syslog host is not configured to log facility change-log severity <info | any>, or configured for facility any severity <info | any>, this is a finding.","fixText":"Configure at least one external syslog host is configured to log facility change-log or any, and severity info or any. \n\n[edit system syslog]\nset host <syslog server address> any <info | any> \n\n -OR-\n\n[edit]\nset host <syslog server address> change-log <info | any>","ccis":["CCI-000172"]},{"vulnId":"V-66563","ruleId":"SV-81053r1_rule","severity":"low","ruleTitle":"The Juniper SRX Services Gateway must generate log records when administrator privileges are deleted.","description":"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.","checkContent":"Verify the device logs change-log events of severity info or any to an external syslog server.\n\n[edit]\nshow system syslog\n\nhost <syslog server address> {\n  any <info | any>;\n  source-address <device address>;\n}\n\n-OR-\n\nhost <syslog server address> {\n  change-log <info | any>;\n  source-address <device address>;\n}\n\nIf an external syslog host is not configured to log facility change-log severity <info | any>, or configured for facility any severity <info | any>, this is a finding.","fixText":"Configure at least one external syslog host is configured to log facility change-log or any, and severity info or any. \n\n[edit system syslog]\nset host <syslog server address> any <info | any> \n\n -OR-\n\n[edit]\nset host <syslog server address> change-log <info | any>","ccis":["CCI-000172"]},{"vulnId":"V-66565","ruleId":"SV-81055r1_rule","severity":"low","ruleTitle":"The Juniper SRX Services Gateway must generate log records when logon events occur.","description":"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.","checkContent":"Verify the device generates a log when login events occur.\n\n[edit]\nshow system syslog\n\nhost <syslog server address> {\n  any <info | any>;\n  source-address <device address>;\n}\n\nIf an external syslog host is not configured to log, or configured for facility any severity <info | any>, this is a finding.","fixText":"Configure at least one external syslog host to log facility any and severity info or any. \n\n[edit system syslog]\nset host <syslog server address> any <info | any>","ccis":["CCI-000172"]},{"vulnId":"V-66567","ruleId":"SV-81057r1_rule","severity":"low","ruleTitle":"The Juniper SRX Services Gateway must generate log records when privileged commands are executed.","description":"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.","checkContent":"Verify the device generates a log when login events occur.\n\n[edit]\nshow system syslog\n\nhost <syslog server address> {\n  any any;\n  source-address <device address>;\n}\n\nIf an external syslog host is not configured to log, or configured for facility any severity any, this is a finding.","fixText":"Configure at least one external syslog host to log facility any and severity info or any. There are multiple ways to accomplish this, the following is an example.\n\n[edit system syslog]\nset host <syslog server address> any any","ccis":["CCI-000172"]},{"vulnId":"V-66569","ruleId":"SV-81059r1_rule","severity":"low","ruleTitle":"The Juniper SRX Services Gateway must generate log records when concurrent logons from different workstations occur.","description":"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.","checkContent":"Verify the device generates a log when login events occur.\n\n[edit]\nshow system syslog\n\nhost <syslog server address> {\n  any any;\n  source-address <device address>;\n}\n\nIf an external syslog host is not configured to log, or configured for facility any severity any, this is a finding.","fixText":"Configure at least one external syslog host to log facility any and severity info or any. There are multiple ways to accomplish this, the following is an example.\n\n[edit system syslog]\nset host <syslog server address> any any","ccis":["CCI-000172"]},{"vulnId":"V-66571","ruleId":"SV-81061r1_rule","severity":"low","ruleTitle":"The Juniper SRX Services Gateway must generate log records containing the full-text recording of privileged commands.","description":"Reconstruction of harmful events or forensic analysis is not possible if log records do not contain enough information. \n\nOrganizations consider limiting the additional audit information to only that information explicitly needed for specific audit requirements. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise. \n\nWhile 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. \n\nEnsure 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).","checkContent":"Verify logging has been enabled and configured.\n\n[edit] \nshow system syslog\n\nIf at least one valid syslog host server and the syslog file names are not configured to capture \"any\" facility and \"any\" event, this is a finding.","fixText":"The following commands configure syslog to record any use of any command, including privileged commands. Configure Syslog and local backup files to capture DoD-defined auditable events. \n\n[edit]\nset system syslog user * any emergency\nset system syslog host <IP-syslog-server> any any\nset system syslog host <IP-syslog-server> source-address <MGT-IP-Address>\nset system syslog host <IP-syslog-server> log-prefix <host-name>\nset system syslog file messages any info\nset system syslog file messages authorization none\nset system syslog file messages interactive-commands none \nset system syslog file messages daemon none \nset system syslog file User-Auth authorization any\n\nset system syslog file interactive-commands interactive-commands any\nset system syslog file processes daemon any\nset system syslog file account-actions change-log any any\nset file account-actions match “system login user”\nset system syslog console any any","ccis":["CCI-000135"]},{"vulnId":"V-66573","ruleId":"SV-81063r1_rule","severity":"low","ruleTitle":"For local logging, the Juniper SRX Services Gateway must generate a message to the system management console when a log processing failure occurs.","description":"It is critical for the appropriate personnel to be aware if a system is at risk of failing to process logs as required. Without this alert, the security personnel may be unaware of an impending failure of the log capability and system operation may be adversely affected. \n\nAlerts provide organizations with urgent messages. Real-time alerts provide these messages at information technology speed (i.e., the time from event detection to alert occurs in seconds or less). Automated alerts can be conveyed in a variety of ways, including, for example, telephonically, via electronic mail, via text message, or via websites.\n\nLog processing failures include software/hardware errors, failures in the log capturing mechanisms, and log storage capacity being reached or exceeded.\n\nWhile this requirement also applies to the event monitoring system (e.g., Syslog, Security Information and Event Management [SIEM], or SNMP servers), the Juniper SRX must also be configured to generate a message to the administrator console.\n\nSyslog and SNMP trap events with a facility of \"daemon\" pertain to errors encountered by system processes.","checkContent":"Verify the system Syslog has been configured to display an alert on the console for the emergency and alert levels of the daemon facility.\n\n[edit] \nshow system syslog\n\nIf the system is not configured to generate a message to the system management console when a log processing failure occurs, this is a finding.","fixText":"The following commands configure syslog to immediately display any emergency level or daemon alert events to the management console. The message will display on any currently logged on administrator's console.\n\n[edit]\nset system syslog user * any emergency\nset system syslog user * daemon alert\nset system syslog user * daemon critical","ccis":["CCI-000139"]},{"vulnId":"V-66595","ruleId":"SV-81085r1_rule","severity":"low","ruleTitle":"The Juniper SRX Services Gateway must have the number of rollbacks set to 5 or more.","description":"Backup of the configuration files allows recovery in case of corruption, misconfiguration, or catastrophic failure. The maximum number of rollbacks for the SRX is 50 while the default is 5 which is recommended as a best practice. Increasing this backup configuration number will result in increased disk usage and increase the number of files to manage. Organizations should not set the value to zero.","checkContent":"To view the current setting for maximum number of rollbacks enter the following command.\n\n[edit]\nshow system max-configuration-rollbacks\n\nIf the number of back up configurations is not set to an organization-defined value which is 5 or more, this is a finding.","fixText":"To configure number of backup configurations to be stored in the configuration partition enter the following command at the configuration hierarchy.\n\n[edit]\nset system max-configuration-rollbacks <organization-defined number>","ccis":["CCI-000366"]},{"vulnId":"V-66597","ruleId":"SV-81087r1_rule","severity":"low","ruleTitle":"The Juniper SRX Services Gateway must specify the order in which authentication servers are used.","description":"Specifying an authentication order implements an authentication, authorization, and accounting methods list to be used, thus allowing the implementation of redundant or backup AAA servers. These commands also ensure that a default method or order will not be used by the device (e.g., local passwords).\n\nThe Juniper SRX must specify the order in which authentication is attempted by including the authentication-order statement in the authentication server configuration. \n\nRemote logon using password results in a CAT 1 finding (CCI-000765) for failure to use two-factor authentication. Thus, if the account of last resort uses only password authentication, this configuration prevents remote access. DoD policy is that redundant AAA servers are required to mitigate the risk of a failure of the primary AAA device.","checkContent":"Verify a RADIUS or TACACS+ server order has been configured.\n\nFrom operational mode enter the command:\nshow system authentication-order\n\nIf the authentication-order for either or both RADIUS or TACACS+ server order has not been configured, this is a finding.\n\nIf the authentication-order includes the password method, this is a finding.","fixText":"Add an external RADIUS or TACACS+ server, and specify the port number and shared secret of the server. Remote logon using password results in a CAT 1 finding (CCI-000765) for failure to use two-factor authentication. Thus, if the account of last resort uses only password authentication, this configuration prevents remote access. DoD policy is that redundant AAA servers are required to mitigate the risk of a failure of the primary AAA device.\n\n[edit]\nset system authentication-order tacplus\n\nor \n\n[edit]\nset system authentication-order radius\n\nFrom operational mode enter the command:\nshow system authentication-order\n\nIf password is set as an option, remove this command from the configuration.\n[edit]\ndelete system authentication-order password","ccis":["CCI-000366"]},{"vulnId":"V-66599","ruleId":"SV-81089r1_rule","severity":"low","ruleTitle":"The Juniper SRX Services Gateway must detect the addition of components and issue a priority 1 alert to the ISSM and SA, at a minimum.","description":"The network device must automatically detect the installation of unauthorized software or hardware onto the device itself. Monitoring may be accomplished on an ongoing basis or by periodic monitoring. Automated mechanisms can be implemented within the network device and/or in another separate information system or device. If the addition of unauthorized components or devices is not automatically detected, then such components or devices could be used for malicious purposes, such as transferring sensitive data to removable media for compromise.\n\nAlerts must be sent immediately to the designated individuals (e.g., via Syslog configuration, SNMP trap, manned console message, or other events monitoring system).","checkContent":"Verify SNMP is configured to capture chassis and device traps. If Syslog or a console method is used, verify that method instead.\n\n[edit]\nshow snmp v3\n \nIf an immediate alert is not sent via SNMPv3 or another method, this is a finding.","fixText":"Update the SNMP configuration with the following device trap settings. This is an example method. Alerts must be sent immediately to the designated individuals (e.g., via Syslog configuration, SNMP trap, manned console message, or other events monitoring system). \n\nset snmp v3 notify-filter device-traps oid jnxChassisTraps include\nset snmp v3 notify-filter device-traps oid jnxChassisOKTraps include\nset snmp v3 notify-filter device-traps oid system include\nset snmp v3 notify-filter device-traps oid .1 include\nset snmp v3 notify-filter device-traps oid","ccis":["CCI-000366"]},{"vulnId":"V-66601","ruleId":"SV-81091r1_rule","severity":"low","ruleTitle":"The Juniper SRX Services Gateway must terminate the console session when the serial cable connected to the console port is unplugged.","description":"If a device management session or connection remains open after management is completed, it may be hijacked by an attacker and used to compromise or damage the network device.","checkContent":"Verify this setting by entering the following commands in configuration mode.\n\n[edit]\nshow system ports console\n\nIf the log-out-on-disconnect is not set for the console port, this is a finding.","fixText":"Configure this setting by entering the following commands in configuration mode.\n\n[edit]\nsystem ports console set log-out-on-disconnect","ccis":["CCI-000879"]},{"vulnId":"V-66603","ruleId":"SV-81093r1_rule","severity":"low","ruleTitle":"The Juniper SRX Services Gateway must implement service redundancy to protect against or limit the effects of common types of Denial of Service (DoS) attacks on the device itself.","description":"Service redundancy, may reduce the susceptibility to some DoS attacks.\n\nOrganizations must consider the need for service redundancy in accordance with DoD policy. If service redundancy is required then this technical control is applicable.\n\nThe Juniper SRX can configure your system to monitor the health of the interfaces belonging to a redundancy group.","checkContent":"If service redundancy is not required by the organization's policy, this is not a finding.\n\nVerify the configuration is working properly: \n\n[edit]\nshow chassis cluster interfaces command.\n\nIf service redundancy is not configured, this is a finding.","fixText":"Interfaces can be monitored by a redundancy group for automatic failover to another node. Assign a weight to the interface to be monitored.\n\nThis configuration is an extremely complex configuration. Consult the vendor documentation.\n\nSet the chassis cluster node ID and cluster ID. \nConfigure the chassis cluster management interface.\nConfigure the chassis cluster fabric.\nConfigure the chassis cluster redundancy group \nSpecify the interface to be monitored by a redundancy group. \n\nSpecify the interface to be monitored by a redundancy group. Example:\n[edit]\nset chassis cluster redundancy-group 1 interface-monitor ge-6/0/2 weight 255","ccis":["CCI-002385"]},{"vulnId":"V-66605","ruleId":"SV-81095r1_rule","severity":"high","ruleTitle":"For nonlocal maintenance sessions, the Juniper SRX Services Gateway must explicitly deny the use of J-Web.","description":"If unsecured functions (lacking FIPS-validated cryptographic mechanisms) are used for management sessions, the contents of those sessions are susceptible to manipulation, potentially allowing alteration and hijacking.\n\nJ-Web (configured using the system services web-management option) does not meet the DoD requirement for management tools. It also does not work with all Juniper SRX hardware. By default, the web interface is disabled; however, it is easily enabled.","checkContent":"Verify web-management is not enabled.\n\n[edit]\nshow system services web-management\n\nIf a stanza exists that configures web-management service options, this is a finding.","fixText":"Remove the web-management service.\n\n[edit]\ndelete system services web-management","ccis":["CCI-000382"]}]}