cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
136
Views
3
Helpful
2
Replies

Ipv6 DHCP Guard and RA Guard Policy

cooperrocks78
Level 1
Level 1

Hello.  My company that I work for currently does not use IPv6 in our organization.  We currently only use IPv4.  During our annual penetration test last month, the pentesters were able to reply to IPv6 DHCPv6 requests to successfully hijack DNS for workstations within the local domain.  They recommended to enable DHCPv6 Guard on switch.  

Would this configuration work ?  Would I need to set up a IPv6 server policy even thought we do not use Ipv6?  

This is the config in a test lab on the access swithes.  Vlan 20 and 21 are DHCP user Vlan's.  

DHCP Guard

1.ipv6 dhcp guard policy RCH-DHCP-CLIENT

2. device-role client

3. vlan config 20

4. ipv6 dhcp guard attach-policy DHCP-CLIENT

5. vlan config 21

6. ipv6 dhcp guard attach-policy DHCP-CLIENT


RA Guard

  1. ipv6 nd raguard policy DHCP-HOST

  2. device role host

  3. vlan config 20

  4. ipv6 nd raguard attach-policy DHCP-HOST

  5. vlan config 21

  6. ipv6 nd raguard attach-policy DHCP-HOST

2 Accepted Solutions

Accepted Solutions

M02@rt37
VIP
VIP

Hello @cooperrocks78 

Your proposed configuration for enabling DHCPv6 Guard and RA Guard on the access switches is appropriate and should work effectively to mitigate the issue identified during your penetration test...

The configuration helps prevent unauthorized or rogue DHCPv6 servers and malicious RA messages within your network, even though your organization does not actively use IPv6.

The DHCPv6 Guard feature ensures that only trusted DHCPv6 servers can respond to DHCPv6 requests, blocking rogue devices from hijacking DNS or other network services. Your configuration includes the creation of a DHCPv6 Guard policy (RCH-DHCP-CLIENT) with the role set to client. By attaching this policy to VLANs 20 and 21, you effectively block any unauthorized DHCPv6 server responses in these VLANs.

Also, since your organization does not use IPv6, you do not need to configure a server policy or define trusted DHCPv6 servers. The current setup protects your network by enforcing the client-only policy and ensures no rogue devices can respond to DHCPv6 requests. This approach is sufficient to address the penetration testers' findings without introducing unnecessary complexity.

As concerned RA Guard, it prevents unauthorized or malicious RA messages, which can be used to perform man-in-the-middle attacks or redirect traffic to rogue gateways. The DHCP-GOST policy in your configuration specifies the host device role and blocks RAs in VLANs 20 and 21 by attaching the RA Guard policy, seems to be good. This ensures that endpoints within these VLANs cannot be influenced by rogue RAs or incorrect IPv6 routing information...

 

Best regards
.ı|ı.ı|ı. If This Helps, Please Rate .ı|ı.ı|ı.

View solution in original post

vishalbhandari
Spotlight
Spotlight

@cooperrocks78 

Yes, your configuration would help mitigate the issue by preventing rogue IPv6 DHCP servers from assigning malicious settings to clients. Enabling DHCPv6 Guard ensures that only trusted devices can respond to DHCPv6 requests, blocking unauthorized DHCP servers. Similarly, enabling RA Guard prevents malicious devices from sending rogue Router Advertisement (RA) messages that can disrupt IPv6 operations.

Even though your organization doesn't currently use IPv6, it's good practice to implement these safeguards because IPv6 is enabled by default on many devices, and attackers can exploit it in dual-stack environments. You don't need to set up an IPv6 server policy if you're not actively using IPv6, as the guard features work by blocking untrusted traffic rather than requiring a functioning IPv6 server. Ensure proper testing to validate the configuration in your environment.

View solution in original post

2 Replies 2

M02@rt37
VIP
VIP

Hello @cooperrocks78 

Your proposed configuration for enabling DHCPv6 Guard and RA Guard on the access switches is appropriate and should work effectively to mitigate the issue identified during your penetration test...

The configuration helps prevent unauthorized or rogue DHCPv6 servers and malicious RA messages within your network, even though your organization does not actively use IPv6.

The DHCPv6 Guard feature ensures that only trusted DHCPv6 servers can respond to DHCPv6 requests, blocking rogue devices from hijacking DNS or other network services. Your configuration includes the creation of a DHCPv6 Guard policy (RCH-DHCP-CLIENT) with the role set to client. By attaching this policy to VLANs 20 and 21, you effectively block any unauthorized DHCPv6 server responses in these VLANs.

Also, since your organization does not use IPv6, you do not need to configure a server policy or define trusted DHCPv6 servers. The current setup protects your network by enforcing the client-only policy and ensures no rogue devices can respond to DHCPv6 requests. This approach is sufficient to address the penetration testers' findings without introducing unnecessary complexity.

As concerned RA Guard, it prevents unauthorized or malicious RA messages, which can be used to perform man-in-the-middle attacks or redirect traffic to rogue gateways. The DHCP-GOST policy in your configuration specifies the host device role and blocks RAs in VLANs 20 and 21 by attaching the RA Guard policy, seems to be good. This ensures that endpoints within these VLANs cannot be influenced by rogue RAs or incorrect IPv6 routing information...

 

Best regards
.ı|ı.ı|ı. If This Helps, Please Rate .ı|ı.ı|ı.

vishalbhandari
Spotlight
Spotlight

@cooperrocks78 

Yes, your configuration would help mitigate the issue by preventing rogue IPv6 DHCP servers from assigning malicious settings to clients. Enabling DHCPv6 Guard ensures that only trusted devices can respond to DHCPv6 requests, blocking unauthorized DHCP servers. Similarly, enabling RA Guard prevents malicious devices from sending rogue Router Advertisement (RA) messages that can disrupt IPv6 operations.

Even though your organization doesn't currently use IPv6, it's good practice to implement these safeguards because IPv6 is enabled by default on many devices, and attackers can exploit it in dual-stack environments. You don't need to set up an IPv6 server policy if you're not actively using IPv6, as the guard features work by blocking untrusted traffic rather than requiring a functioning IPv6 server. Ensure proper testing to validate the configuration in your environment.

Review Cisco Networking for a $25 gift card