CCNA Junos OS Security Objects Questions

Global address book entries are defined once and are visible across all security zones on the device, unlike zone-specific books that must be redefined per zone. This satisfies the requirement for entries available device-wide without duplication.

Functional zones are predefined system zones in Junos OS, such as the management and host zones, that handle specific traffic types rather than user-defined security segments. This satisfies the stem's requirement by distinguishing built-in functional zones from security zones, which administrators configure manually to apply policies between network interfaces.

Junos OS applies a default deny posture between zones: no traffic passes from one security zone to another unless a policy explicitly permits it. This satisfies the stem's question about default behaviour, since only intra-zone traffic is permitted by default, not inter-zone.

The show security screen statistics command displays per-zone SCREEN counters, revealing which attack thresholds are being triggered. This lets the administrator identify the offending option and tune its thresholds rather than guessing why legitimate traffic is dropped under load.

This command creates the security zone 'dmz' if it does not exist and assigns interface ge-0/0/2 to it. It is the standard Junos OS syntax for binding an interface to a security zone, directly fulfilling the administrator's requirement in a single step.

Zones group interfaces sharing trust boundaries and policies.

The udp-flood SCREEN option counts incoming UDP packets per second destined for the zone and compares that rate against the configured threshold. This matches the stem: measurement is rate-based on ingress UDP traffic, not session counts or byte volume.

Security policies match traffic by referencing named address book entries, such as address sets and prefixes, rather than inline IP addresses. This satisfies the stem's requirement that policies use address book objects as match criteria, since Junos OS resolves those objects at commit time into the source and destination fields of the policy.

The land screen option detects packets whose source and destination addresses match, indicating a LAND attack. Creating a screen profile with land enabled and applying it to the untrusted zone ensures all entering traffic is inspected, satisfying the stated requirement.

Screen profiles are applied at zone level, so defining ICMP flood thresholds once and referencing the profile under the target security zone enforces protection across every interface bound to that zone, satisfying the all-interfaces-in-one-zone constraint without per-interface duplication.

Local zone address books override global address books when evaluated from that zone context.

Setting the timeout under `[edit applications application <app-name> inactivity-timeout <seconds>]` modifies the custom application's own definition, so the value applies only to that application rather than globally. This satisfies the stem's requirement to change the default session timeout for one specific custom application in Junos OS.

Transit traffic requires interfaces to be bound to security zones and governed by security policies.

Security zones bind to interfaces, and each interface belongs to exactly one routing instance, so a zone cannot span virtual routers. This satisfies the scenario by confirming zones remain confined within a single virtual router on the SRX.

Junos OS stores IPv6 prefixes in address books exactly as it does IPv4 entries, then references them in policies whose from-zone and to-zone statements enforce family inet6. This satisfies the stem's requirement that IPv6 prefixes be usable in security policy matching, not merely configured.

Traffic originating from the SRX itself, including routing protocol updates and syslog messages, is classified into the junos-host zone. This reserved zone handles all self-generated packets, satisfying the stem's requirement for device-originated traffic rather than transit or inter-zone flows.

The show security screen statistics command reports per-zone SCREEN option status and hit counters, confirming which attack protections are active. It queries the flow module's screen table directly, satisfying the requirement to view all zones' screen state operationally.

The 'show security zones' command displays a summary of all configured security zones, including the zone name, type (security, functional, etc.), and the interfaces assigned to each zone. It provides a concise, tabular output that is ideal for quickly verifying zone-to-interface mappings. This command is the standard way to view zone information in Junos OS.

Application Layer Gateway (ALG) inspects control channels for protocols such as FTP, extracting embedded IP addresses and port numbers, then opening corresponding pinholes in the firewall's session table. This satisfies the stem's requirement for translating port numbers during transit across security zones, since FTP negotiates dynamic data connections that static filters cannot anticipate.

Junos resolves address book lookups using the most specific match, so a zone-specific book overrides the global book for traffic originating in that zone. Because both entries share the same host name but define different subnets, the zone-scoped definition supplies the IP used for policy matching.

An address set groups multiple address objects, including IPv4 subnets and ranges, under one named object referenced in security policies. It satisfies the requirement because address books store subnets and ranges as separate objects, and only a set combines them.

Junos address books may be configured at the global level, applying across the device, or scoped within individual security zones. This dual placement gives administrators flexibility to reuse global entries while isolating zone-specific addresses in policy.

`show security alg status` queries the ALG status table directly, listing each configured Application Layer Gateway and whether it is enabled or disabled. This satisfies the stem's requirement to display currently active ALGs and their status, unlike commands that show ALG configuration or session details instead.

Packets carrying both SYN and FIN flags simultaneously are invalid, since SYN initiates a connection while FIN terminates it. The tcp-drop-synfin-set SCREEN option detects this contradictory combination and drops such packets, satisfying the requirement to target that specific malformed flag pairing rather than other scan types.

Host-inbound services bind to the interface where configured, not the whole zone. Enabling SSH on one interface does not extend it to siblings, so the other interfaces reject SSH until the service is added at zone level or on each interface individually.

Junos treats the application as a bidirectional port match: TCP traffic is matched only when the destination port is 8080 and the source port falls within 1024-65535. Both criteria must be satisfied simultaneously, so the source range constrains the client side while the fixed destination port identifies the service.

Ping is one of the host-inbound-traffic system-services values configurable on a Junos security zone, permitting ICMP echo requests to the device itself. It governs traffic destined to the Routing Engine, not transit traffic, which is why it belongs to this specific command hierarchy.

A functional zone is a built-in Junos OS zone type reserved for special system functions, including the management interface used for out-of-band access. Unlike security zones, which host data-plane interfaces and enforce inter-zone policies, functional zones such as junos-host and the management zone handle control-plane traffic, satisfying the out-of-band management constraint.

Defining the application with protocol tcp and destination-port 8080 lets Junos OS match HTTP traffic on the non-standard port, satisfying the stem's requirement. Junos application definitions rely on protocol plus port tuples rather than payload inspection, so specifying TCP port 8080 correctly identifies the traffic without needing an HTTP-specific signature.

Junos address sets accept heterogeneous members: nested address sets and standalone address objects can coexist in one set. This directly satisfies the stem's requirement to combine two address sets with one individual IP address object.

Junos validates address sets against existing address book entries at commit time.

The system-services all keyword enables every host-inbound system service on the zone in one statement, avoiding per-service enumeration. Junos OS expands it to the full service list, satisfying the requirement for an all-inclusive host-inbound keyword.

The ALG reads control-channel payloads, such as FTP PORT or SIP SDP fields, to learn which ports the endpoints negotiate. Junos OS then permits those expected data connections, which a stateless filter alone could not anticipate.

The operational-mode command show security policies queries the active policy configuration held in the device's security policy database, listing each policy's source and destination zones, addresses and actions. It satisfies the stem's requirement to display configured security policies, unlike configuration-mode commands that show raw hierarchy.

For application firewall inspection to occur, the traffic must first be permitted by a security policy that references the custom application matching TCP port 8080. The application firewall rule must also reference the same application or application-set. If either the security policy or the application firewall rule does not reference the custom application, the traffic may be permitted but not inspected. Thus, verifying both references is the correct action.

An application set groups multiple individual applications under one named object, letting a single security policy reference that set instead of listing each application separately, which directly satisfies the requirement for simplified, consolidated policy management.

Security flow traceoptions are configured under the `[edit security flow traceoptions]` hierarchy, which is exactly where Junos OS expects flow-level debugging for a security zone. This satisfies the stem's requirement to trace security flow processing, since traceoptions for flow reside at that stanza rather than under the zone or interface hierarchy.

An ALG parses application-layer signalling, such as SIP or FTP control channels, then dynamically pinholes the secondary data sessions those protocols negotiate on separate ports. This satisfies the stem's multi-port requirement, since static firewall filters cannot predict ephemeral ports, whereas Junos OS ALGs track the control session and open matching data flows automatically.

This configuration creates a global address book named 'global' and adds two addresses: 'subnet1' for the subnet and 'host1' for the host. Global address books are accessible from all security zones, which meets the requirement of being available globally.

In a security policy, the match condition can specify an application or an application set. When an application set is referenced, the policy matches if the traffic matches any application within the set. This is a common practice to simplify policy configuration by grouping related applications. Therefore, this statement is true.

An address book entry with the value 192.168.1.100/32 defines a single host address. The /32 prefix indicates a specific host, which matches the requirement for a host with IP 192.168.1.100. This is a valid and precise way to represent a host in a zone address book.

The SIP Application Layer Gateway inspects signalling to learn the media port allocations, then opens corresponding pinholes for RTP. Without it, Junos permits SIP control traffic but drops the dynamically negotiated audio streams, causing calls to connect with no audio.

Junos address books accept a start and end address pair, letting you define a contiguous block such as 10.1.1.1-10.1.1.50. This range syntax is one of the two supported entry types, satisfying the stem's requirement for valid IP definition methods.

Active FTP has the server initiate the data connection back to the client, so the FTP ALG must inspect the PORT command and open a dynamic pinhole; without it, the inbound data channel is dropped.

Address sets function as named containers of address objects, so Junos OS accepts them in any policy match field where a single address object is valid, including source-address and destination-address. This satisfies the stem's requirement that address sets be usable in security policies wherever individual address objects are accepted.

This configuration defines a custom application with two terms: one for TCP port 8080 and one for UDP port 53. In Junos OS, a custom application can have multiple terms to match different protocols and ports, so this correctly matches both required traffic types.

Junos OS allows a custom application to include multiple protocol and port combinations. You can define an application with both TCP and UDP, and specify source and destination ports or ranges. This flexibility enables matching complex protocols that use different transport mechanisms. The application is then referenced as a single object in security policies, simplifying configuration.

The icmp timestamp SCREEN option inspects ICMP type 13 timestamp requests arriving at the zone and drops them, satisfying the reconnaissance and flooding constraint in the stem. Attackers use these requests to map live hosts and gather clock data, so blocking them at the zone boundary reduces exposure.

`show security flow session` queries the flow module's session table directly, listing every active session with its source, destination, protocol and state. This satisfies the stem's requirement to display sessions currently tracked, since only established flows appear; commands such as `show security policies` display configuration rather than live session state.

TCP SYN flood rate limiting is a core SCREEN feature, enforcing a configurable threshold on half-open connection attempts to protect against resource exhaustion. It satisfies the stem's requirement for features associated with SCREEN option profiles, alongside other attack mitigations such as ICMP flood and UDP flood protection configured within the same profile hierarchy.

LAND attacks send packets with identical source and destination addresses, causing the victim to reply to itself. Junos SCREEN detects this spoofed pattern and drops such packets, satisfying the stem's requirement for a SCREEN-mitigated attack type.

SCREEN options inspect packet headers at layers 3 and 4, matching signatures for SYN floods, IP spoofing and LAND attacks before they reach end hosts. Applied at the zone level, they satisfy the requirement for header-based DoS inspection in Junos OS.

Specifying the IP protocol (tcp or udp) is a configurable match condition within a Junos custom application definition, satisfying the stem's requirement for configurable parameters. Junos uses this value alongside port ranges to identify and classify traffic, enabling the firewall to enforce application-aware security policies accurately.

`show configuration security address-book` displays the committed address-book hierarchy under the security stanza, letting you verify configured entries and their network prefixes. It satisfies the stem's requirement to verify configuration rather than runtime state, which `show security address-book` would instead report.

Host-inbound traffic permissions are configured at zone level, specifying which system services (such as SSH, HTTPS or IKE) may terminate on the device's own interfaces. This satisfies the stem's requirement for a security zone setting, distinct from interface or policy configuration.

`show security flow session` is a valid operational mode command, displaying active session entries from the session table. It satisfies the stem's requirement for security-object commands run from operational mode, not configuration mode. Junos OS places flow session inspection under the `show security flow` hierarchy, confirming its operational-mode validity.

The source-route SCREEN option inspects IP options in packet headers and drops datagrams carrying the LSRR or SSRR source routing flags, satisfying the requirement to block such traffic at the untrusted zone interface before it enters the network.

Security zones are configured under [edit security zones], placing them within the [edit security] hierarchy. This satisfies the stem's requirement, as zones bind interfaces and define the trust boundaries that security policies, SCREEN options and address books reference.

This statement defines a custom application named MY-APP that matches TCP protocol with destination port 8443. Junos OS applications can be defined using protocol and port matching without any payload inspection. The absence of an application-protocol or signature statement means only the TCP header is inspected, and the session naturally terminates when a TCP RST is received from either endpoint.

Custom applications support configuring custom session inactivity timeouts.

This command correctly defines a custom application named my-app with protocol udp, destination-port 5000, and an inactivity-timeout of 300 seconds. The inactivity-timeout parameter specifies how long a session can remain idle before being closed, which is exactly what the engineer needs. This application can then be referenced in a security policy.

The ip spoofing SCREEN option checks whether a packet's source address belongs to the ingress interface's local subnet, dropping such packets as spoofed. It satisfies the stem's requirement by detecting source addresses that should never arrive from that interface.

Enabling snmp under host-inbound-traffic system-services permits SNMP polling destined to the SRX itself on the zone interface, satisfying the monitoring server requirement. Without it, Junos drops the traffic at the zone's host-inbound filter regardless of any policy.

This command assigns the logical unit ge-0/0/1.0 to the security zone TRUST under the [edit security zones] hierarchy. The interface must already be configured with an IP address and not assigned to another zone. This is the standard method to bind an interface to a zone in Junos OS, enabling security policies and screen options to be applied.

SCREEN traceoptions are set under the [edit security screen traceoptions] hierarchy, which controls logging of SCREEN option processing events such as SYN flood or ICMP flood detection, independent of zone-level traceoptions configured elsewhere in the security stanza.

Interfaces are bound to zones, and zone membership establishes the trust boundary that policies reference when permitting or denying traffic between network segments. This logical grouping is what lets Junos apply distinct security treatment per boundary, satisfying the requirement for a definition of trust boundaries.

SIP embeds IP addresses and ports inside its payload, so the ALG inspects and rewrites these to open the required pinholes dynamically. Without it, media sessions fail because NAT and policy cannot see the embedded addressing.

Screens are attached to security zones: after defining a profile, for example 'set security screen ids-option untrust-screen ip spoofing', you apply it with 'set security zones security-zone untrust screen untrust-screen'. Every interface in that zone is then protected for traffic arriving on it. The spoofing check drops packets whose source address routes back through a different zone, similar to a uRPF check.

Predefined applications bundle the port and protocol values for well-known services, so policies reference a single named application instead of hand-entering multiple port ranges. This reduces misconfiguration and keeps policy intent readable across the configuration.

An application set groups multiple applications into one named object referenced by a single security policy term, reducing rule count. It satisfies the requirement to treat a collection of applications as a single unit in policy.

Junos security policies match traffic using address book entries and address sets, which define source and destination prefixes or ranges. These objects are referenced directly in the policy's match criteria to identify the hosts or networks the rule governs.

Junos address sets accept IP address range objects as members, grouping contiguous addresses defined by a start and end value. This satisfies the groupable-component requirement, letting one set reference a whole range instead of enumerating each host individually.

TFTP negotiates its data channel dynamically, so the SRX requires the TFTP ALG to inspect the control exchange and open the corresponding pinhole. Without that ALG, the data transfer is dropped even though the security policy permits the initial session.

The limit-session source-ip SCREEN option caps how many concurrent sessions a single source IP address may establish through the zone, mitigating session-flood and DoS attacks. It satisfies the stem's description by restricting the total session count per source address, distinct from rate-based thresholds.

The icmp all SCREEN option applies a single aggregate threshold across every ICMP packet type combined, rather than per-type policing. It therefore satisfies the stem's requirement by monitoring and limiting the total ICMP rate, catching floods that individually stay under per-type limits.