Juniper JN0-335 Security - Specialist (JNCIS-SEC) Exam Practice Test

• Referring to the SRX Series flow module diagram shown in the exhibit, application security is processed at the Services ALGs stage. Application Layer Gateways (ALGs) are software components that enable the SRX Series device to provide application-level security for specific protocols and applications1.
• ALGs inspect the application layer payload of packets and perform various actions, such as modifying the payload, opening pinholes, creating sessions, applying security policies, and enforcing application-specific behavior12.
• ALGs are required for protocols and applications that embed IP address information or port numbers in the application layer data, that open secondary connections, or that are dynamically assigned ports1. Some examples of protocols and applications that require ALGs are FTP, SIP, H.323, RTSP, PPTP, and DNS2.
• ALGs are configured as part of the security policy and are applied to the traffic that matches the policy criteria. ALGs can also be enabled or disabled globally or per zone12.

References:

• 1: Application Layer Gateways Overview
• 2: Application Layer Gateways Feature Guide for Security Devices

AppTrack is a logging and reporting tool that provides statistics for analyzing bandwidth usage of your network. When enabled, AppTrack collects byte, packet, and duration statistics for application flows in the specified zone. AppTrack sends log messages through syslog, providing application activity update messages. AppTrack can be used to share information for application visibility with devices such as Security Threat Response Manager (STRM)12 References:

• 1: Application Tracking | Junos OS | Juniper Networks
• 2: application-tracking | Junos OS | Juniper Networks

 The policy rematch feature enables the device to reevaluate an active session when its associated security policy is modified. The session remains open if it still matches the policy that allowed the session initially. The session is closed if its associated policy is renamed, deactivated, or deleted1

When a policy change includes changing the policy’s action from permit to deny, all existing sessions are dropped. This is because the policy rematch feature does not allow a session to continue if it violates the new policy action1

When a policy change includes changing the policy’s source or destination address match condition, all existing sessions are reevaluated. This is because the policy rematch feature tries to find a suitable policy that can still permit the session based on the new address criteria. If no such policy exists, the session is dropped12

References: 1: policy-rematch | Junos OS | Juniper Networks 2: What is session rematch and how to use it to avoid traffic disruption during a policy update via NSM - Juniper Networks

A reth LAG is a redundant Ethernet interface that includes one or more physical interfaces from each node of a chassis cluster. A reth LAG provides increased bandwidth and link availability for the cluster. To configure a reth LAG, you need to follow these steps:

• Configure the physical interfaces on each node as aggregated Ethernet interfaces with the same speed and duplex settings. This is required to ensure that the links can form a LAG andpass traffic correctly. You can use different cable types (such as copper or fiber-optic) for the links, but the speed must be the same.
• Configure the reth interface with the redundant-ether-options statement and specify the aggregated Ethernet interfaces as child links. You should have at least two interfaces (one from each node) in the reth LAG, but you can add more for redundancy and load balancing. You can also specify the minimum-links statement to set the minimum number of child links that must be up for the reth interface to be up. The default value is one, but you can change it to a higher value if needed.
• Configure the reth interface with the appropriate IP address, security zone, and other settings as needed. You can also enable LACP on the reth interface to dynamically negotiate the LAG parameters with the peer devices.

References:

• [Aggregated Ethernet Interfaces in a Chassis Cluster] 1
• [Chassis Cluster Redundant Ethernet Interfaces] 2
• [LACP / LAG on Chassis Cluster - Interface Monitoring?] 3
• [URGENT (LAG - RETH Interconnect)] 4

 This is because the error message indicates that the client device does not trust the certificate authority that issued the certificate for the external server. Therefore, you need to import the root CA certificate from the SRX Series device to the client device and add it to the trusted certificate store. This will allow the client device to verify the identity of the SRX Series device and accept the certificates it generates for the external servers3.

The other options are not correct because:

• A. Load a known good, but expired. CA certificate onto the SRX Series device. This will not solve the problem because the client device will still reject the certificates from the SRX Series device if they are signed by an expired CA certificate. The expiration date of the CA certificate is one of the factors that the client device checks when validating the certificate2.
• B. Install a new SRX Series device to act as the client proxy. This will not solve the problem because the new SRX Series device will still need to have a root CA certificate configured and imported to the client devices. The problem is not with the SRX Series device itself, but with the trust relationship between the SRX Series device and the client devices2.
• C. Reboot the SRX Series device. This will not solve the problem because rebooting the SRX Series device will not change the configuration or the certificates on the SRX Series device or the client devices. The problem is not caused by a temporary glitch or a malfunction, but by a mismatch between the certificates on the SRX Series device and the client devices2.

I hope this helps you understand the problem and the solution better. If you want to learn more about SSL client protection proxy, you can check out the following references:

• SSL Proxy Overview
• Configuring SSL Forward Proxy
• Configuring a Root CA Certificate
• SSL Proxy - Client Protection

Static attack object groups are predefined groups of attack objects that are included in Juniper’s IPS signature database. These groups do not change automatically when Juniper updates the database. You must manually add matching attack objects to a custom group34 References:

• Attack Objects and Object Groups for IDP Policies | Junos OS
• Attack Objects and Object Groups for IDP Policies on NFX Devices
• Exam Name: Security, Specialist (JNCIS-SEC) Version: DEMO - Lead2Pass
• Juniper - ExamsBoost

The cSRX is a containerized version of the SRX Series device that runs on Linux platforms. The cSRX has the following benefits for deploying in a virtual environment:

• The cSRX supports Layer 2 and Layer 3 deployments, which means it can operate as a transparent or a routed firewall. The cSRX can also support multiple routing instances and virtual routers2
• The cSRX supports firewall, NAT, IPS, and UTM services, which means it can provide comprehensive security features for protecting the virtual network. The cSRX can also support application identification, user firewall, and VPN services2

The cSRX default configuration does not contain three default zones: trust, untrust, and management. The cSRX default configuration contains only one zone: junos-host. The cSRX does not have low memory requirements. The cSRX requires at least 2 GB of memory and 2 CPU cores to run2 References:

• 1: Juniper Security Specialist (JNCIS-SEC) (JN0-334) | Study Guide 3
• 2: Junos OS Security Configuration Guide | cSRX Overview 4

The Junos IPS feature is a security service that is integrated on SRX Series devices, which are high-performance network security platforms that offer firewall, VPN, IPS, application security, and unified threat management capabilities. The Junos IPS feature uses various methods to detect and prevent intrusions, such as signature-based detection, protocol anomaly detection, behavioral anomaly detection, and custom signatures. Signature-based detection compares network traffic against predefined patterns of known attacks and blocks traffic when a match is found. Protocol anomaly detection monitors network traffic for deviations from the expected or normal behavior of common protocols, such as HTTP, FTP, SMTP, and DNS, and blocks traffic when an anomaly is detected. Behavioral anomaly detection monitors network traffic forchanges in the baseline behavior of hosts, networks, or applications, and blocks traffic when a significant deviation is detected. Custom signatures allow administrators to create their own patterns of attacks based on specific criteria, such as IP addresses, ports, protocols, or payload content, and block traffic when a match is found. The Junos IPS feature does not use sandboxing to detect unknown attacks, as this is a function of the Juniper ATP Cloud service, which is a cloud-based service that provides advanced malware detection and prevention for the network. The Junos IPS feature is not a standalone platform, but rather a service that runs on SRX Series devices, which can be deployed as physical or virtual appliances. References:

• [Juniper Security, Professional (JNCIP-SEC) Reference Materials] 1
• [Juniper Security, Specialist (JNCIS-SEC) Reference Materials] 2
• [Junos OS Security Configuration Guide] 3
• [Junos OS Security Feature Guide] 4
• [Junos OS Security Feature Support Reference] 5

SRX chassis clustering is a high availability feature that allows two SRX Series devices to operate as a single logical device. The two devices are connected by a control link and a fabric link, which are used to synchronize the configuration, state, and traffic between the nodes. The control plane is responsible for managing the cluster configuration, monitoring the health and status of the nodes, and performing failover operations. The data plane is responsible for processing and forwarding the traffic through the cluster. SRX chassis clustering supports two modes for the data plane: active/passive and active/active. In active/passive mode, only one node is active for each redundancy group, which is a logical grouping of interfaces and services. The active node handles all the traffic for the redundancy group, while the passive node acts as a backup. In active/active mode, both nodes are active for different redundancy groups, and they can share the traffic load for the cluster. SRX chassis clustering supports only one mode for the control plane: active/passive. In this mode, only one node is the primary node, which is the master of the cluster configuration and the source of truth for the cluster state. The primary node also initiates the failover process in case of a node or interface failure. The other node is the secondary node, which is the slave of the cluster configuration and the backup of the cluster state. The secondary node takes over the primary role if the primary node fails or is manually disabled. References: Chassis Cluster Overview, SRX Series Chassis Cluster Configuration Overview, Chassis Cluster Overview

= SSL proxy server protection is a type of reverse proxy that enables the SRX Series device to act as an intermediary between external clients and internal servers that use SSL encryption. SSL proxy server protection provides benefits such as load balancing, caching, compression, encryption, authentication, and application firewalling. To enable SSL proxy server protection, you do not need to configure the servers to use the SSL proxy function on the SRX Series device. The SRX Series device will terminate the SSL connection from the client and initiate a new SSL connection to the server, without requiring any changes on the server side. However, you must load the server certificates on the SRX Series device, so that the SRX Series device can present the server certificate to the client and establish a secure connection. You must also import the root CA on the servers, so that the servers can trust the SRX Series device as a valid intermediary and accept the connection from the SRX Series device. References: SSL Proxy, Configuring SSL Proxy, JNCIP-SEC Certification

Juniper ATP Cloud is a cloud-based threat detection service that protects all hosts in your network against evolving security threats. It uses a combination of tools to identify and block malware, such as cache lookup, static analysis, and dynamic analysis12

Cache lookup is the first step in the malware detection process. It checks the file hash against a database of known malicious and benign files. If the file is found in the cache, the analysis is completed and the file is either allowed or blocked based on the cache result12

Static analysis is the second step in the malware detection process. It examines the file attributes, such as file size, file type, file name, and embedded URLs, to determine if the file is suspicious or not. If the file is deemed suspicious, it is sent to the next step for further analysis. If the file is deemed benign, it is allowed to pass through12

Dynamic analysis is the third and final step in the malware detection process. It executes the file in a sandbox environment and observes its behavior, such as network connections, registry changes, file operations, and process injections. If the file exhibits malicious behavior, it is blocked and reported. If the file does not exhibit malicious behavior, it is allowed to pass through12

Therefore, dynamic analysis is not always performed to determine if a file contains malware, as it depends on the results of the cache lookup and static analysis. Similarly, if the cache lookup determines that a file contains malware, static analysis is not performed to verify the results, as the file is already blocked based on the cache lookup12

References:

• Juniper Advanced Threat Prevention Cloud (ATP Cloud) Documentation
• Juniper Advanced Threat Prevention Cloud | Juniper Networks

 To track BitTorrent traffic on your network, you need to use the Security Intelligence feature, which allows you to apply actions to traffic based on predefined or custom feeds. The High_Risk_Workstations and BitTorrent_Servers are examples of custom feeds that you can create and populate with IP addresses of devices that match certain criteria. To automatically add the workstations and servers to the respective feeds, you need to use the administration-feed option under the application-services security-intelligence hierarchy. This option specifies the feed name and the action to be taken for the traffic that matches the feed. For example, to add the workstations to the High_Risk_Workstations feed and drop the traffic, you would use:

set security policies from-zone untrust policy FindThreat then permit application-services security-intelligence administration-feed High_Risk_Workstations drop

To add the servers to the BitTorrent_Servers feed and log the traffic, you would use:

set security policies from-zone untrust policy FindThreat then permit application-services security-intelligence administration-feed BitTorrent_Servers log

Option B and Option C show the correct commands for these scenarios. Option A and Option D are incorrect because they use the wrong syntax for the administration-feed option. They also use the wrong feed names, as the feeds are case-sensitive and must match the ones defined under the security-intelligence hierarchy. References: Juniper Security, Specialist (JNCIS-SEC) Reference Materials and Juniper Security, Professional (JNCIP-SEC) Reference Materials

Juniper ATP Cloud is a cloud-based service that provides advanced threat prevention for SRX Series devices. Juniper ATP Cloud can inspect files for malware by sending them to the cloud or performing a hash lookup. To reduce delays in the inspection of files, Juniper ATP Cloud performs the following two functions12:

• Juniper ATP Cloud allows the creation of allowlists. Allowlists are lists of trusted files or domains that are not sent to the cloud for inspection. This reduces the network traffic and the processing time for the files that are known to be safe. You can create allowlists from the Juniper ATP Cloud Web UI or the SRX Series device CLI.
• Juniper ATP Cloud performs a cache lookup on files. Cache lookup is a feature that checks if a file has been previously scanned by Juniper ATP Cloud and returns the cached verdict. This avoids sending the same file to the cloud again and saves bandwidth and time. Cache lookup is enabled by default and can be configured from the SRX Series device CLI. References:
• Juniper ATP Cloud User Guide
• Juniper ATP Cloud Deployment Guide for SRX Series Devices

After JSA receives external events and flows, the data goes through the following steps in the event and flow pipeline 1:

• Event and flow collection: JSA accepts event logs and flow records from various sources by using different protocols and methods. The data is parsed and normalized into a JSA-usable format.
• Event and flow processing: JSA applies rules, custom properties, and anomaly detection to the data. The data is also coalesced, filtered, and forwarded as needed. The data is stored in an asset database and an Ariel database for further analysis and reporting.
• Event and flow correlation: JSA analyzes the data for patterns that indicate malicious activity or policy violations. JSA generates offenses, alerts, and notifications based on the correlation rules and building blocks.
• Event and flow response: JSA responds to the offenses and alerts by taking active measures such as blocking IP addresses, quarantining hosts, or updating reference data. JSA also provides investigation and remediation tools for analysts to handle the incidents. References:
• 1: JSA Events and Flows | Junos OS | Juniper Networks

 The configuration shown in the exhibit is a pre-ID default policy, which is a security policy that applies to traffic that cannot be identified by the SRX Series device before the user authentication process is complete. The pre-ID default policy has the following characteristics1:

• It is applied to all traffic that matches the from-zone and to-zone parameters, regardless of the source and destination addresses or applications.
• It can only have the permit action, and it cannot be deleted or renamed.
• It can have optional parameters such as log, session-timeout, and session-class.

The session-timeout parameter specifies the maximum time that a session can remain idle before it is closed by the SRX Series device. The session-timeout parameter can have different values for different types of traffic, such as TCP, UDP, or others. The others parameter applies to traffic that is not TCP or UDP, such as ICMP or GRE. The value of the others parameter is in seconds, not milliseconds. Therefore, the others 300 parameter means unidentified traffic flows will be dropped in 300 seconds, not milliseconds2. This statement is correct, so option B is a valid answer.

The log parameter enables the SRX Series device to generate a log message for each session that matches the pre-ID default policy. The log parameter can have two values: session-init and session-close. The session-init value logs the session when it is created, and the session-close value logs the session when it is closed. The session-init value is useful for identifying the source and destination of the unidentified traffic, while the session-close value is useful for measuring the duration and volume of the traffic3. The configuration shown in the exhibit has the session-init value, which means every session that enters the SRX Series device will generate an event. This statement is correct, so option C is a valid answer.

The session-class parameter is used to assign a priority to the sessions that match the pre-ID default policy. The session-class parameter can have four values: high, medium-high, medium-low, and low. The session-class parameter is useful for managing the resources allocated to the sessions and for applying quality of service (QoS) policies. The session-class parameter is not only used when troubleshooting, but also when optimizing the performance and security of the SRX Series device4. This statement is incorrect, so option A is not a valid answer.

Replacing the session-init parameter with session-lose will not log unidentified flows, but rather log the sessions that are closed due to session timeout or other reasons. This will not help in identifying the source and destination of the unidentified traffic, but rather provide information about the duration and volume of the traffic. This statement is incorrect, so option D is not a valid answer.

References:

• Pre-ID Default Policy Overview
• Configuring Session Timeout Values for Security Policies
• Configuring Logging for Security Policies
• Configuring Session Class for Security Policies

AppTrack: Tracks and reports applications passing through

the device.

• Intrusion Detection and Prevention (IDP): Applies

appropriate attack objects to applications running on

nonstandard ports. Application identification improves IDP

performance by narrowing the scope of attack signatures

for applications without decoders.

• AppFW: Implements an application firewall using

application-based rules.

• AppQoS: Provides quality-of-service (QoS) prioritization

based on application awareness

The AppSecure AppTrack service module is a logging and reporting tool used to share information about application visibility. Once AppID identifies an application, AppTrack notonly monitors and records its usage, it also sends regular application activity update messages. Since these messages are sent by syslog, they can be read by any compatible third-party device, including Juniper Networks JSA Series Secure Analytics Appliances and Contrail Service Orchestration.

Encrypted Traffic Insights is a feature of Juniper ATP Cloud and SRX Series firewalls that can detect malicious threats that are hidden in encrypted traffic without intercepting and decrypting the traffic. It permits organizations greater visibility and policy control over encrypted traffic, without requiring resource-intensive SSL Decryption1.

Encrypted Traffic Insights assesses the threat of the traffic by using two methods:

• It validates the certificates used by the external servers that the internal hosts are trying to connect to. It compares the certificate signatures with a blocklist of known malicious certificates and also checks the certificate validity, issuer, and subject. If the certificate is invalid or matches a malicious signature, the connection is blocked or alerted2.
• It reviews the timing and frequency of the connections to the external servers. It uses behavior analysis and machine learning to identify patterns and anomalies that indicate malicious activity, such as command and control (C&C) communications, botnet traffic, or data exfiltration. It also uses threat intelligence feeds to enrich the analysis and provide additional context2.

Encrypted Traffic Insights does not decrypt the file or the data in a sandbox or to validate the hash, as these methods would require breaking the encryption of the traffic, which would violate data privacy laws and introduce latency and performance issues21. References:

• 3: SRX5400, SRX5600, SRX5800 Firewalls Datasheet - Juniper Networks
• 2: Encrypted Traffic Insights Overview and Benefits | ATP Cloud | Juniper …
• 1: Juniper Networks Expands Connected Security Portfolio with Encrypted …

Based on the information from the exhibit, node0 is the primary node for both redundancy group 0 (RG0) and redundancy group 1 (RG1). RG0 is responsible for the control plane, which includes the Routing Engine and the management interface. RG1 is responsible for the data plane, which includes the interfaces and services. Therefore, node0 is the active node for the data plane, and node1 is the active node for the control plane34 References:

• Chassis Cluster Redundancy Groups | Junos OS | Juniper Networks
• Troubleshooting a Redundancy Group that Does Not Fail Over in an SRX Chassis Cluster | Junos OS | Juniper Networks
• Understanding Chassis Cluster Redundancy Group 0: Routing Engines | Junos OS | Juniper Networks
• Understanding Chassis Cluster Redundancy Groups 1 Through 128 | Junos OS | Juniper Networks

AppFW and APPID are two application security features that can be used to block malicious applications regardless of the port number being used. AppFW provides policy-based enforcement and control on traffic based on application signatures. By using AppFW, you can block any application traffic not sanctioned by the enterprise. APPID identifies applications based on their behavior and characteristics, regardless of port, protocol, or encryption method. By using APPID, you can classify applications and apply appropriate security policies to them123 References:

• AppSecure: Application Visibility and Control Solution Brief
• Application Firewall | Junos OS | Juniper Networks
• Security Policy Applications and Application Sets | Junos OS | Juniper Networks

 Logging for a security policy can be configured to generate log entries at session initialization, at session close, or both. Logging at session initialization records the initial packet that matches the policy and triggers the session creation. Logging at session close records the summary statistics of the session, such as bytes and packets transmitted and received, and the reason for session termination. Logging at session initialization and close provides the most complete information about the traffic that matches the policy. Logging at fixed intervals, such as every 10 minutes or every 60 seconds, is not supported by Junos OS security policies. References:

• Security, Professional (JNCIP-SEC) Exam Objectives, Firewall Filters section
• Junos OS Security Configuration Guide, Understanding Security Policy Logging section
• Advanced Juniper Security (AJSEC) Course, Chapter 4: Advanced Logging and Reporting

 To implement IPS on your SRX Series device, you need to download and install the IPS signature database. The IPS signature database contains the attack signatures and predefined attack groups that are used to detect and prevent intrusions. You can download the IPS signature database from the Juniper Networks website or from a local server. You can install the IPS signature database manually or automatically. You do not need to enroll the SRX Series device with Juniper ATP Cloud or reboot the SRX Series device to implement IPS34 References:

• Configuring the IPS Policy on SRX Series Devices Using NSM
• Installing SRX 1400 with IPS activation ??? | SRX - Juniper Networks
• Download an IPS Signature | J-Web for SRX Series 21.2 - Juniper Networks
• IPS Configuration (CLI) | Junos OS | Juniper Networks

A vSRX is a virtualized security platform that runs on various hypervisors and cloud environments. It provides firewall and NAT services, as well as other security features, such as IPS, VPN, UTM, and AppSecure. A single vSRX can fulfill the minimum requirements for providing firewall and NAT services in a private cloud, as it can be deployed as a gateway or an edge device, and can scale up or down as needed. A vSRX can also interoperate with other Juniper and third-party products, such as Contrail Networking, Junos Space Security Director, and Sky ATP. A single vSRX is more cost-effective and simpler to manage than having separate vSRX instances for firewall and NAT services. A cSRX is a containerized version of vSRX that runs on Linux-based platforms. It provides similar security features as vSRX, but with a smaller footprint and faster deployment. However, a cSRX is not yet supported on all cloud environments, and it may have some limitations compared to vSRX, such as lower throughput and fewer interfaces. Therefore, a single cSRX may not be able to fulfill the minimum requirements for providing firewall and NAT services in a private cloud, depending on the specific cloud platform and the performance and scalability needs. A cSRX for firewall services and a separate cSRX for NAT services would also introduce more complexity and overhead than a single vSRX. References: vSRX Overview, cSRX Overview, JNCIP-SEC Certification

The Juniper Networks solution that will accomplish the task of alerting if the wrong password is used more than three times on a single device within five minutes is Juniper Secure Analytics (JSA). JSA is a security intelligence platform that collects, analyzes, and correlates network data from various sources, such as firewalls, routers, switches, servers, and applications. JSA can detect and respond to threats, anomalies, and vulnerabilities in real time using rules, offenses, reports, and dashboards. JSA can also integrate with JIMS (Juniper Identity Management Service) to obtain user identity information from Active Directory domains or syslog sources. JSA can use this information to create custom rules that trigger offenses or alerts based on user behavior or activity, such as failed login attempts or password changes.

References := Juniper Secure Analytics Troubleshooting Guide, Juniper Identity Management Service User Guide

• JSA Rules
• Custom Rules
• Creating a Custom Rule
• JSA Rules - TechLibrary

Juniper ATP Cloud is a cloud-based threat detection service that protects all hosts in your network against evolving security threats. It assigns a threat level to each attacker IP address from 1 to 10, with 10 being the highest severity. Once the target threshold ismet, Juniper ATP Cloud continues looking for threats for a configurable duration from 0 to 10 minutes. This allows Juniper ATP Cloud to collect more information about the attacker and the attack vector, and to update the threat intelligence accordingly. The other options are incorrect. Option A is not configurable, and option D is not consistent with the documentation. References:

• Juniper Advanced Threat Prevention Cloud | Juniper Networks
• Juniper’s Attacker IP feed bolsters threat protection with SecIntel

 SSL proxy is a transparent proxy that performs SSL encryption and decryption between the client and the server. It allows inspection of encrypted traffic by terminating the SSL connection from either end and applying security policies to the clear text. SSL proxy can leverage pre-match or post-match results to determine whether to apply SSL proxy to a session. Pre-match results are based on the initial packet of the session, while post-match results are based on the application identification after the session is established. In the exhibit, the session shows that the application services identification is “ssl-proxy”, which means that SSL proxy is applied based on the pre-match results. The cache lookup status for application services is “on”, which means that the SRX Series device uses the application system cache to store the pre-match results for faster processing. Therefore, the correct answer is D. SSL proxy leverages pre-match result. References: = SSL Proxy, Configuring SSL Proxy, and Application System Cache