V2R5 changes
Juniper EX Series Switches Layer 2 Switch STIG V2R5 (2026-07-01) replaced V2R4 (2026-01-05): 3 checks updated. It has 24 checks, against 24 in V2R4.
V2R5 checklistV2R4 checklist Compare V2R4 and V2R5 in STIG Compare
- 0 added
- 0 removed
- 3 updated
Updated fields: Check text 3Fix text 3Title 3Discussion 3
Updated in V2R5 (3)
V-253959CAT IIThe Juniper EX switch must be configured to enable DHCP snooping for all user VLANs with active access interfaces to validate DHCP messages from untrusted sources.Title, Check text, Fix text, Discussion
Title
The Juniper EX switch must be configured to enable DHCP snooping for all user VLANs with active access interfaces to validate DHCP messages from untrusted sources.
Check text
Review the switch configuration and verify that DHCP snooping is enabled on all user-facing or untrusted VLANs with active access interfaces.
DHCP snooping is enabled if dhcp-security is configured for any VLAN, and is automatically enabled whenwhenever any other VLAN port security feature is configured (e.g., IP Source Guard or Dynamic ARP Inspection).
Devices likesuch as printers, servers, and VoIP phones are under administrative control and connected to controlled access interfaces (802.1x, Static MAC Bypass, or MAC RADIUS), making them trusted sources in nonnonuser-user-facing VLANs. Trunked interfaces are trusted sources.
Verify DHCP snooping on user-facing or untrusted VLANs is configured with active access interfaces.
[edit vlans]
<untrusted VLAN name> {
vlan-id <VLAN ID>;
forwarding-options {
dhcp-security;
}
}
This check is not applicable to switches configured with user-facing or untrusted VLANs merely for inclusion in trunks (e.g., core or distribution switch without access interfaces assigned to user-facing or untrusted VLANs).
If the switch does not have DHCP snooping enabled for all user-facing or untrusted VLANs with active access interfaces to validate DHCP messages from untrusted sources, this is a finding.
Fix text
Configure the switch towith have DHCP snooping for all user-facing or untrusted VLANs with active access interfaces to validate DHCP messages from untrusted sources.
1. ThisEnter requirementconfiguration ismode.
2. applicableConfigure touser-facing or untrusted VLANs with active access interfaces assigned,with butDHCP notsnooping.
3. toCommit switches that only trunk the VLANsconfiguration.
user@host> betweenconfigure
Entering switches.configuration mode
user@host# set vlans <untrusted VLAN name> vlan-id <untrusted VLAN ID>
user@host# set vlans <untrusted VLAN name> forwarding-options dhcp-security
user@host# commit
commit complete
Discussion
In an enterprise network, devices under administrative control are trusted sources. These devices include the switches, routers, and servers in the network. Host (i.e., access) interfaces and unknown DHCP servers are considered untrusted sources. An unknown DHCP server on the network on an untrusted interface is called a spurious DHCP server, any device (PC, Wireless Access Point) that is loaded with DHCP server enabled. The DHCP snooping feature determines whether traffic sources are trusted or untrusted. The potential exists for a spurious DHCP server to respond to DHCPDISCOVER messages before the real server has time to respond. DHCP snooping allows switches on the network to trust the interface a DHCP server is connected to and not trust the other interfaces.
The DHCP snooping feature validates DHCP messages received from untrusted sources, and filters out invalid messages, asand well as rate-limits DHCP traffic from trusted and untrusted sources. The DHCP snooping feature builds and maintains a binding database, which contains information about untrusted hosts with leased IP addresses, and it utilizesuses the database to validate subsequent requests from untrusted hosts. Other security features, such as IP Source Guard and Dynamic Address Resolution Protocol (ARP) Inspection (DAI), also use information stored in the DHCP snooping binding database. ThereforeHence, it is imperative that the DHCP snooping feature mustis be enabled on all user-facing or untrusted VLANs.
This requirement is applicable to VLANs with active access interfaces assigned, but not to switches that only trunk the VLANs between switches.
V-253960CAT IIThe Juniper EX switch must be configured to enable IP Source Guard on all user-facing or untrusted access VLANs with active access interfaces.Title, Check text, Fix text, Discussion
Title
The Juniper EX switch must be configured to enable IP Source Guard on all user-facing or untrusted access VLANs with active access interfaces.
Check text
Review the switch configuration to verify that IP Source Guard is enabled on all user-facing or untrusted VLANs with active access interfaces. Configuring IP Source Guard automatically enables DHCP snooping.
Devices likesuch as printers, servers, and VoIP phones are under enterprise control and connected to controlled access interfaces (802.1x, Static MAC Bypass, or MAC RADIUS), making them trusted sources in nonnonuser-user-facing VLANs.
Verify IP Source Guard on user-facing or untrusted VLANs with active access interfaces.
[edit
user@host> show configuration vlans]
<untrusted VLAN name> {
vlan-id <VLAN ID>;
forwarding-options {
dhcp-security {
ip-source-guard;
}
}
}
Note: IP Source Guard depends uponon DHCP snooping or static MAC address bindings.
This check is not applicable to switches configured with user-facing or untrusted VLANs merely for inclusion in trunks (e.g., core or distribution switch without access interfaces assigned to user-facing or untrusted VLANs).
If the switch does not have IP Source Guard enabled on all user-facing or untrusted VLANs with active access interfaces, this is a finding.
Fix text
Configure the switch to have IP Source Guard enabled on all user-facing or untrusted VLANs with active access interfaces.
1. ThisEnter requirementconfiguration ismode.
2. applicableConfigure touser-facing or untrusted VLANs with active access interfaces assignedwith butIP notsource toguard.
3. switchesCommit that only trunk the VLANsconfiguration.
user@host> betweenconfigure
Entering switches.configuration mode
user@host# set vlans <untrusted VLAN name> vlan-id <VLANltuntrusted VLAN ID>
user@host# set vlans <untrusted VLAN name> forwarding-options dhcp-security ip-source-guard
user@host# commit
commit complete
Discussion
IP Source Guard provides source IP address filtering on an untrusted layer 2 interface to prevent a malicious host from impersonating a legitimate host by assuming the legitimate host's IP address. The feature uses dynamic DHCP snooping and static IP source binding to match IP addresses to hosts on untrusted layer 2 access interfaces. Initially, all IP traffic on the protected access interface is blocked except for DHCP packets. After a client receives an IP address from the DHCP server, or after static IP source binding is configured by the administrator, all traffic with that IP source address is permitted from that client. Traffic from other hosts is denied. This filtering limits a host's ability to attack the network by claiming a neighbor host's IP address.
This requirement is applicable to VLANs with active access interfaces assigned but not to switches that only trunk the VLANs between switches.
V-253961CAT IIThe Juniper EX switch must be configured to enable Dynamic Address Resolution Protocol (ARP) Inspection (DAI) on all user VLANs with active access interfaces.Title, Check text, Fix text, Discussion
Title
The Juniper EX switch must be configured to enable Dynamic Address Resolution Protocol (ARP) Inspection (DAI) on all user VLANs with active access interfaces.
Check text
Review the switch configuration to verify that Dynamic ARP DAI feature is enabled on all user VLANs with active access interfaces. Configuring DAI automatically enables DHCP snooping.
Devices likesuch as printers, servers, and VoIP phones are under enterprise control and connected to controlled access interfaces (802.1x, Static MAC Bypass, or MAC RADIUS), making them trusted sources in nonnonuser-user-facing VLANs.
Verify DAI on user-facing or untrusted VLANs with active access interfaces.
[edit
user@host> show configuration vlans]
<untrusted VLAN name> {
vlan-id <VLAN ID>;
forwarding-options {
dhcp-security {
arp-inspection;
}
}
}
Note: DAI depends uponon DHCP snooping or static MAC address bindings.
This check is not applicable to switches configured with user-facing or untrusted VLANs merely for inclusion in trunks (e.g., core or distribution switch without access interfaces assigned to user-facing or untrusted VLANs).
If DAI is not enabled on all user VLANs with active access interfaces, this is a finding.
Fix text
Configure the switch to have ARP DAI enabled on all user VLANs with active access interfaces.
1. ThisEnter requirementconfiguration ismode.
2. applicableConfigure touser-facing or untrusted VLANs with active access interfaces assignedwith butDAI.
3. notCommit to switches that only trunk the VLANsconfiguration.
user@host> betweenconfigure
Entering switches.configuration mode
user@host# set vlans <untrusted VLAN name> vlan-id <VLANltuntrusted VLAN ID>
user@host# set vlans <untrusted VLAN name> forwarding-options dhcp-security arp-inspection
user@host# commit
commit complete
Discussion
DAI intercepts ARP requests and verifies that each of these packets has a valid IP-to-MAC address binding before updating the local ARP cache and before forwarding the packet to the appropriate destination. Invalid ARP packets are dropped and logged. DAI determines the validity of an ARP packet based on valid IP-to-MAC address bindings stored in the DHCP snooping binding database. If the ARP packet is received on a trusted interface (e.g., access interface with a valid binding or a trunked interface), the switch forwards the packet without any checks. On untrusted interfaces, the switch forwards the packet only if it is valid.
This requirement is applicable to VLANs with active access interfaces assigned but not to switches that only trunk the VLANs between switches.
How these changes are found
Checks are matched across the two releases by V-number. A check counts as updated when DISA gave it a new rule revision (the r number in its SV-…_rule id) and its title, severity, check text, fix text, discussion, CCIs or other fields changed — the same comparison STIG Compare makes. Added checks are new V-numbers; removed checks are V-numbers V2R5 no longer has.
Comparing other releases, or this one against an older release? Pick any two in STIG Compare.