IOS Security

Control Plane Policing and Protection

-Policing and Protection are very similar, except that Protection offers more granular control Control Plane Policing (CoPP) -used to protect CPU from a DoS attack by limiting traffic that is punted to the process switching process, that generally is processed by CPU -e.g flood router's CPU with routing protocol hellos -configured as a QoS policing policy -not all matches supported in class-map -applied under control-plane -"control-plane" -"serivce-policy input" -uses class-maps, policy-map, and serivce-policy to match specific types of traffic such as Telnet or SSH from sending too much traffic to the routers CPU -protect against DoS caused from ICMP, Telnet, SSH, etc. -limitations are that in most cases, user is not able to use NBAR features -control plane protection allows for more matching and granular control in terms of classifying different types of protocols i.e. Control Plane Protection allows for use of NBAR when using QoS to secure the CPU from DoS attacks -CoPP requires MQC to configure the policing policies -Packets that are considered to be destined for the CPU are: - Routing protocol control packets - Packets destined for the local IP address of the router - Packets from management protocols (such as Simple Network Management Protocol [SNMP], Telnet, and secure shell [SSH]) Control Plane Protection -similar to CoPP, but allows for more granular restrictions on traffic that is process by the CPU control plane -unlike CoPP which classifies all traffic as belonging to the aggregate control-plane interface, protection breaks down traffic into 3 subinterfaces. FYI an aggregate control-plane interface means that CoPP treats and applies QoS policies to one single individual logical interface when it sees traffic to the control-plane CPU -Control-Plane Host Subinterface; traffic that is destined to the local routers interfaces. e.g. routing protocol messages, SSH, Telnet, etc. -Control-Plane Transit Subinterface; traffic that is going through the local router, not to the router. Traffic such as non-terminating tunnels -Control-Plane CEF-Exception Subinterface; traffic that is on a layer 2 management such as ARP and any non-IP host traffic -"The aggregate Control-plane Policing policy will be applied on all control-plane traffic types. However, Control Plane Protection allows for additional and/or separate Control-plane Policing policies to be configured and applied on the different types of control-plane subinterfaces (host, transit, CEF-exception)." -"The addition of the Control Plane Logging feature enables logging of the packets that are dropped or permitted by Control-Plane Policing, port-filtering, queue-threshold, and Protection features." Configuration ! ip access-list extended PERMIT_ICMP permit icmp any any ! class-map CLASS match access-group name ICMP ! policy-map POLICY class CLASS police 8000 ! control-plane service-policy input POLICY ! -allow ICMP packets to go through to the control-plane of the router, but only at a pace of 8000kbs interval, police the rate with default setting ! Show Commands -"show policy-map control-plane" -"show policy-map" -"show class-map"

Data Plane Security

Access-Lists -Standard Access-lists match on Source IP Address -Extended Access-lists match on... -IP protocol number -source address/destination address -protocol options -TCP/UDP ports (eq, neq, It, gt, range) -ICMP Type Code -TCP state (established keyword) -Packet markings (DSCP/IPP) -Non-initial fragments (fragments keyword) Access List Logging -good for troubleshooting, but not to be left running for a long time as it can be CUP intensive! -Log message can be generated on ACL match -log vs log-input; log-input does is on regular IOS platform it also tells you who is the layer 2 address -Generated as syslog level "informational" -causes packets to be process switched -ACL Logging rate-limiting -"ip access-list logging interval" -"ip access-list log-update threshold" -"logging rate-limit" -ACL Syslog Correlation Tags -"log [cookie]" -"ip access-list logging hash-generation" -logging is a good way to find the source and destination of traffic, especially for routing protocols Commands -"ip access-list log-update threshold [number of hits]" tells the router to only generate ACL logs after there is a number of hits that meet the threshold -"ip access-list logging interval [milliseconds]" tells the router to only generate logs during a configured timed interval -"ip icmp rate-limit unreachable [once per milliseconds]" When ICMP messages are unreachable, the router will send out an "administratively prohibited unreachable" message to the source that sent the package. This command tells the router how many ICMP "administratively prohibited unreachable" messages should be sent out in one millisecond when this occurs. FYI can cause issue for router that has to generate all the messages and send it out IPv4 ACL Applications -Traffic Filtering -"ip access-group" applied on interface config -outbound access-list doesn't affect locally generated traffic i.e. "ip access-group TEST_ACL out" will only apply to transit traffic originating outside the scope of the local router's IP addresses. If the traffic, for example, routing protocol OSPF sends a Hello out the interface there will be no issues as the Hello was generated locally by the router -Traffic Classification -"match access-group" under class-map for QoS -Route Filtering -"distribute-list" or "route-map" but it is recommended to only use prefix-list for these filtering processes -VTY line/username access-control -"access-class in/out" ! access-list 1 permit 150.1.6.6 access-list 2 permit 150.1.7.7 ! line con 0 access-class 2 out line vty 0 4 access-class 1 in access-class 2 out ! -"line vty 0 4" has "access-class" applied in and out on the line. When applied "access-class 1 in" this means only routers with IP address 150.1.6.6 is allowed access to the line vty 0-4. On the access-class out direction, "access-class 1 out", it only applies to when Host B has already established a Telnet with Host A, and during that vty session Host B wants to establish another session outbound it will be able to do another Telnet with 150.1.7.7 -"line con 0" has the "access-class 2 out" command applied, which means that the local router can only telnet outbound to IP address 150.1.7.7 IPv6 ACL Applications -Traffic Filtering -"ipv6 traffic-filter" -VTY line/username access-control -"ipv6 access-class" -ICMPv6 NS needs to NOT be filtered, because NS now takes care of the layer 2 to layer 3 mapping -IPv6 ACL must explicitly permit Neighbor Solicitation traffic in the ACL, this is because of the implicit deny any any at the end of an ACL. If it is not explicitly permitted, then it means that if NS is not completed there will be issues ! ipv6 access-list IPv6_ACL permit tcp any any eq telnet permit icmp any any nd-na permit icmp any any nd-ns permit icmp any any router-advertisement permit icmp any any router-solicitation ! -on IPv4, we have to use two different ACLs to filter layer 2 and layer 3 i.e. MAC ACL and IP ACL -on IPv6 you can use one ACL Time Based ACLs -Used to activate ACL entry based on clock -Defined as time-range [name] -Absolute -at one specific time period -Periodic -at one or more recurring time periods -Potential Applications -time based traffic filter -time based QoS -only when the time-range is active, then the ACL could be used Catalyst PACL -Port ACLs -"Port ACLs are ACLs that are applied to Layer 2 interfaces on a switch." -IMPORTANT! basically applying regular IP ACLs or MAC ACLs on layer 2 switches! To apply IP ACLs to layer 2 interface, use "ip access-group [ACL name] in" and to apply MAC ACLs to layer 2 interfaces use "mac access-group [MAC ACL name] in" -applies to layer 2 switches -apply ingress only -filter transit traffic -traffic ingress on the VLAN/port -could be IP or MAC based -MAC ACLs only affect non-IP traffic -" MAC ACLs are ACLs that filter traffic using information in the Layer 2 header of each packet." -3 Ways to apply ACL on Cat Switches; Port level for layer 2 and 3, and VLAN level for both layer 2 and layer 3 Configuration for MAC ACL ! mac access-list extended simple-mac-acl permit host 000.000.011 any ! int f1/1 mac access-group simple-mac-acl in ! -this config will only "permit host 000.000.011" to any destination, the rest Catalyst RACL -Router ACL -same as PACL but only apply to L3 traffic -apply to L3 ports or SVIs -Ingress or Egress unlike PACL -Can only filter using IPv4 standard/extended ACLs Catalyst VACL -VLAN ACL or VLAN map -Apply to an VLAN/SVI -effective for all ports in this VLAN -access and trunk ports -may inspect both IP and non IP traffic -matching based on IP or MAC ACL -configuring an IP/MAC entry activates implicit deny VACL Considerations -Good to affect all future ports in the VLAN -applied globally -Don't use implicit deny -you may block STP or ARP! -Be careful when filtering L2 traffic -STP and ARP could be easily blocked! -Account for the fact that ALL transit traffic is affected -be careful when filtering transit VLANs Configuration Example ! ip access-list DROP_TELNET permit tcp any any eq 23 ! vlan access-map DROP_IT 10 match ip address DROP_TELNET action drop vlan access-map DROP_IT 20 action forward ! vlan filter DROP_IT vlan-list 10-16 ! -first, an access-list is needed to determine what kinds of traffic gets forwarded and what gets dropped -second, the ACL is called upon by the "vlan access-map [ACL name]" command -inside the access-map config mode, the "match ip address DROP_TELNET" tells the VACL to use the access-list named "DROP_TELNET" and to drop traffic permitted by this ACL "action drop" -it is important for statement 20 to exist in the VACL because if not all traffic gets denied due to the implicit deny all at the end of the VACL! -lastly, the VACL must be used with the "vlan filter [access-map name] vlan-list 10-16" command, essentially saying that this VACL will be applied to vlans 10-16 only! -this creates a safe way to create a vlan access-map i.e. explicitly deny what you need to and permit any at the end. Doing it this way will prevent accidentally blockage of layer 2 protocols! URPF -" Unicast RPF deflects such attacks by forwarding only packets that have source addresses that are valid and consistent with the IP routing table." -"Unicast RPF checks to see if any packet received at a router interface arrives on the best return path (return route) to the source of the packet." -"With Unicast RPF, all equal-cost "best" return paths are considered valid." -"When you configure an access control list (ACL) and a packet fails the Unicast RPF check, the Unicast RPF checks the ACL to see if the packet should be dropped (by using a deny statement in the ACL) or forwarded (by using a permit statement in the ACL)." -Unicast Reverse Path Forwarding (URPF) -used to simplify bogon/martian filters. I.e. bogon/maritan IP addresses are sources that should never have that IP address such as 224.0.0.0/4 or 127.0.0.0/8. Also, martian is any address that is sourced from an IP address that is the same as an internal IP address on your interface -ingress traffic has source checked against CEF table -by default, packets without a correct reverse route are dropped -if however, configured with an access-list, when a URPF check is performed and fails, the ACL will determine if the traffic will be dropped or can continue to be forwarded -Can be both strict and loose -strict means reverse route back to sender must be via ingress interface i.e. route back to the source must used the same interface as the packet came in on. If i learned route 10.10.10.0/24 from interface FastEtherne1/0 and a packet has sender ip address 10.10.10.1, then the packet must arrive on interface Fa1/0 otherwise it will be dropped -loose means reverse route can be via any interface -Can be used to implement RTBHF -Remotely Triggered Black Hole Filtering -URPF Commands applied at the interface level -"ip verify unicast source reachable-via rx" for strict URPF -"ip verify unicast source reachable-via any" for loose URPF Strict Mode Config ! access-list 100 permit ip host 150.1.6.6 any ! int f1/1.146 ip verify source reachable-via rx 100 ! -by default, when in Strict URPF and a packet fails the validation check, then it will be dropped. However, if you use an access-list along with the "ip verify unicast source...", the ACL would determine which failed validation packets can still continue to forwarded and which must be dropped via the access or deny statement, where the access statement says even though you fail the URPF check you can still pass traffic, but the deny statement says the same as the default where it means you will get your traffic dropped if your IP address fails the URPF check -this essentially means that if there is an URPF failure at interface f1/1.146, then all the traffic that is sourced from 150.1.6.6 is allowed and drop all else. URPF: Strict vs Loose -in strict mode, if a packet failed the unicast RPF check, by default (without any permit statements and ACLs) the traffic would be dropped. -IMPORTANT! this essentially means that traffic must be symmetrical in order to pass the RPF check -ISPs and customers with multi-home BGP traffic can have asymmetrical routing, thus unicast RPF in strict mode would not suffice -in loose mode, there is no requirement that a packet's source IP address must enter and go out of the same interface (as is the case with strict mode). The check that loose mode has is that the packet's source IP address must be in the FIB of the local router in order for it to be forwarded. -similar to strict mode however, an ACL could be utilized to control what IP addresses are allowed to be forwarded or dropped (by permit/deny statement) if URPF check fails. By default failed URPF means that traffic will be dropped. NBAR and Flexible Packet Matching -Network Based Application Recognition (NBAR) and Flexible Packet Matching (FPM) -used to classify traffic in the data plane based on upper layer protocol information -e.g. HTTP GET payload -Once match occurs, traffic can be selectively dropped -Unconditional Packet Discard -Policer with conform and transmit drop actions in MQC policy -NBAR called from QoS policy and filter based on specific type of application traffic! -"NBAR is a classification engine that recognizes and classifies a wide variety of protocols and applications, including web-based and other difficult-to-classify applications and protocols that use dynamic TCP/UDP port assignments. "

DHCP Snooping, Dynamic ARP Inspection, & IP Source Guard

DHCP Snooping http://packetpushers.net/five-things-to-know-about-dhcp-snooping/ -Prevents DHCP Server spoofing and exhaustion attack i.e. protects DHCP Servers by only "trusting" the ports that they are connected into, by default all interfaces are in the untrusted state -"DHCP snooping will drop DHCP messages from a DHCP server that is not trusted", i.e. DHCP server messages will be dropped on an untrusted DHCP snooping port. Therefore it is important to configure "ip dhcp snooping trust" on the ports that have DHCP servers connected on the other end, like uplink ports. -IMPORTANT! DHCP Snooping only accepts incoming DHCP responses to DHCP Discovery messages on trusted interfaces. Snooping has two states, trusted and untrusted. DHCP server messages are only allowed to be passed on through Trusted ports, but these messages can't go through untrusted ports. -Trusted ports are usually ports that are connected to DHCP Servers, inside network switches, routers, and firewalls and all uplinks that are between them e.g. trunks, port-channels, etc. DHCP Server <=> SW1 <=> SW2 <=> SW3 <=> DHCP Client, so the uplinks between the switches from the client and towards the server must have "ip dhcp snooping trust" otherwise DHCP messages will be dropped -Untrusted ports are the ports that are connected to anything outside your network AND your host ports i.e. DHCP clients -i.e. Trust means to leave the interface alone and treat it as if DHCP snooping was not enabled in the first place. Untrusted means, I will use DHCP Snooping to check if DHCP messages are is running on the port and if the port is not configured with " ip dhcp snooping trust" then i will drop the DHCP message responses to DHCP client Discovery -IMPORTANT! Trusted ports are allowed to RECEIVE DHCP server messages e.g. DHCH ACK and OFFER on the interface. Untrusted ports will drop any received DHCP server messages. But Untrusted ports can always send out any DHCP messages once the messages are already inside the switch -exhaustion attack: when the attacker sends out DHCP request over and over and tries to leases out all the IP addresses from legitimate DHCP servers. Then, when the legitimate DHCP server runs out of IP addresses to give, the attacker will have it's DHCP server start taking in DHCP Requests from potential victims and hand out DHCP addresses from its pool -Enforces DHCP server role on ports -only trusted ports may respond to DHCP Discovers that came from clients -with snooping, Switch maintains IP, MAC, and port binding -could be used for security enforcement -Four main commands -"ip dhcp snooping" global -"ip dhcp snooping VLAN x" global -"ip dhcp snooping trust (interface)" interface -"no ip dhcp snooping information option" global -IMPORTANT! remember to disable DHCP Information Option 82, otherwise the DHCP servers will not respond to the switch that relayed the Option 82 with a 0.0.0.0 address on the gateway IP address (giaddr) -there are two supplemental features that assist DHCP Snooping with layer 2 security, and the two both utilize the already built DHCP Snooping binding database information -Dynamic ARP Inspection - for whichever VLAN that has DAI enabled (by default when global command "ip arp inspection vlan x" is configured, all interfaces that have the vlan are considered untrusted), check with the DHCP Snooping database in terms of MAC addresses to see if the incoming MAC address matches the IP that is recorded in the snoop table -IP Source Guard - does the same thing as DAI, but this checks if the IP address came in from the same interface as the one recorded in the DHCP Snoop table -DAI and IP Source Guard does not need the DHCP Snooping database, but it makes it easier to reference it for validation checks DHCP Snooping Caveats -IMPORTANT! Don't forget to trust port to the DHCP server -IMPORTANT! By default, when IP DHCP Snooping is enabled, all interfaces are untrusted! -in multi-switch scenarios trust trunks as well -i.e. on the DHCP server port where the server would send DHCP Offer messages into the switch and then onto the clients, the switch has to enable "ip dhcp snooping trust" on those interfaces connected to servers! i.e. TRUST the ports that has the DHCP Server! and also from switches that are downstream, configure the uplinks on those switches to be trusted, so as to not drop legitimate server messages that are flowing downstream. -Keep in mind that DHCP snooping on switches inserts information option, BUT... -adds empty "giaddr" (gateway IP address) field, IOS DHCP server rejects such packets -Information Option insertion could be disabled on relay switch -"no ip dhcp snooping information option" (dont set the gateway IP address!) in the global config, use this method easiest to use! -Alternative is configure server to trust empty giaddr DHCP Option 82 -"If DHCP option 82 is enabled on a VLAN or bridge domain, then when a network device—a DHCP client—that is connected to the VLAN or bridge domain on an untrusted interface sends a DHCP request, the switching device inserts information about the client's network location into the packet header of that request. The switching device then sends the request to the DHCP server. The DHCP server reads the option 82 information in the packet header and uses it to implement the IP address or another parameter for the client. " -Used to provide additional information on the "physical attachment" of the DHCP clients, so DHCP servers can use this information to specify parameters -" Option 82 is supposed to be used in distributed DHCP server/relay environment, where relays (e.g. switches) insert additional information to identify the client's point of attachment." -"DHCP relay is supposed to insert the "giaddr" field in the relayed DHCP packets, so that DHCP server may identify the pool to be used for the request." -IMPORTANT! " by default Cisco IOS devices reject packets with zero "giaddr" and by default Cisco Catalyst switches that act as DHCP Relay use "giaddr" of zero when configured for DHCP snooping!" -IMPORTANT! "Option 82 provides information about the network location of a DHCP client, and the DHCP server uses this information to implement IP addresses or other parameters for the client" -Resource https://www.juniper.net/documentation/en_US/junos/topics/concept/port-security-dhcp-option-82.html Configuration -"ip dhcp snooping" this command MUST be enabled first, everything else relies on this command and everything else won't work unless you enable snooping with this command -"ip dhcp snooping vlan [number]" configured in the global config mode, this is needed to enable the feature! IMPORTANT! By default, all links are UNTRUSTED when DHCP Snooping is enabled -"ip dhcp snooping trust" configured on interface mode, needed to tell the switch that this port has DHCP clients on it so allow DHCP Discovery messages to pass through when snooping is enabled Dynamic ARP Inspection (DAI) -Prevents ARP address spoofing by using the recorded entries in the DHCP Snooping database -"Dynamic ARP inspection is a security feature that validates ARP packets in a network" -layer 2 MAC address to IP inspection checks on ARP replies; an add-on feature to supplement the security functions of DHCP Snooping -"If the ARP packet is received on a trusted interface, the switch forwards the packet without any checks. On untrusted interfaces, the switch forwards the packet only if it is valid." -IMPORTANT! on untrusted interfaces, the IP-to-ARP mapping must correlate with the DHCP Snooping binding database! -by default, DAI puts all interfaces that have the VLAN configured in the untrusted state! -"In a typical network configuration, you configure all switch ports connected to host ports as untrusted and configure all switch ports connected to switches as trusted" -Prevents ARP poisoning attack i.e. attacker sends Gratuitous ARP to do a man-in-middle attack. This works because the attacker sends out it's own MAC address and saying that it is the gateway via using the gateway IP address and associating it with its own MAC -Inspects ARP Requests/Responses -"ip arp inspection VLAN X" -"ip arp inspection trust" port level command -IMPORTANT! use this command on the port that is connected to the DHCP server because the IP address of the DHCP server will not have been mapped into the DHCP snooping binding database (because it is the server and therefore does not request an IP address for itself, so then its IP address will not be in the database) -Enforces IP-to-MAC bindings based on DHCP snooping database Problems with Static IP Addresses Dynamic ARP Inspection -if a host statically configures an IP address, then the snooping database will not have its binding to validate against, and therefore the host can have its traffic blocked by DAI and IP Source Guard -If DHCP is not used, static ARP mappings could be configured -takes precedence over dynamic entries i.e. when "ip arp inspection filter [arp ACL] vlan x" is configured, that means that DAI will now use the ACL to permit/deny ARP requests, it will no longer rely on the DHCP Snooping Database to check for MAC-to-IP mappings!! -configured using ARP inspection ACL -"arp access-list x" -"permit ip host <ip> mac host <MAC>" -Applied to a VLAN -"ip arp inspection filter <NAME> VLAN y" IP Source Guard -Static IP to MAC mapping on a VLAN -"ip source binding" global command Configuration -"ip arp inspection vlan [number]" applies globally, will use Dynamic ARP Inspection on the selected VLAN and VLAN interfaces -"ip arp inspection trust" applied on the interface, usually the trusted ports for DHCP Snooping also has ARP Inspection as trusted as well! This configuration is usually applied on the interface connected to the DHCP server and also any trunk interfaces where there are many MACs being learned Configuration Example: DAI ! arp access-list DAI_ACL permit ip host 123.0.0.2 mac host 0019.3039.4341 ! ip arp inspection vlan 3,123 ip arp inspection filter DAI_ACL vlan 123 static ! ip dhcp snooping vlan 77, 123 ! !G1/0/2 is connected to switch ! interface GigabitEthernet1/0/2 no ip arp inspection trust ! -by default DAI uses DHCP snooping database to use the IP-to-MAC bindings cached in the binding table to validate ARP requests on untrusted ports, however, we could statically filter and map DAI as well -"ip arp inspection filter DAI_ACL vlan 123 static" uses an ARP ACL in order to filter packets. It is saying that use ARP ACL "DAI_ACL" to permit or deny packets, based on what the ACL permits, and apply the filter to only VLAN 123. By default, there is an implicit deny at the end of ACLs, meaning all other source/destination will be denied depending on the ACL. This ACL will only apply on untrusted interfaces. -additionally, the "static" keyword at the end of the statement says that DO NOT use cache IP-to-MAC entries in the DHCP Snooping database AFTER checking with the ACL. Meaning after the match, the implicit deny takes over and denies all other traffic according to ACL "DAI_ACL". Without the use of the word "static" at the end of the configuration would mean to check with the DHCP binding database for additional IP-to-MAC entries to permit AFTER checking with the DAI_ACL IP Source Guard -Prevents IP address spoofing by checking where the the source IP address (which was obtained by DHCP) of the packet that came in and checking to see if it's the same interface as the entry on the DHCP snooping database i.e. This IP address 10.0.0.1 is associated to FastEthernet0/1 on the DHCP Snoop dabase, if I see a packet coming from 10.0.0.1 and it entered on FastEthernet0/2 then this is a violation of the IP Source Guard protocol! -matches IP addresses to hosts on untrusted ports and correlates it to DHCP Snooping database to ensure that the IP-to-Interface mapping is correct -enforces IP-to-Interface mappings based on the DHCP Snooping binding database! -usually configured downstream towards the access layer -applied based on the DHCP Snooping database information as well -Uses DHCP Snooping database to filter IPs on the port dynamically -"ip verify source" configured on interface level on a layer 2 interface on untrusted ports! -IMPORTANT! not to be confused with "ip verify unicast source" which is used for Unicast RPF checks and is configured on a Router/Layer3 interface! -MAC address filtering could be enforced as all i.e. MAC to Interface mapping and again by utilizing the information in the DHCP snooping binding database -requires port-security enabled on interface -additional parameter "ip verify source port-security" -Configuring: Static IP to MAC mapping on a VLAN, for cases where static IP addresses are configured without the use of DHCP -"ip source binding..." global config Configuration -"ip verify source" interface level Configuration Example ! interface G1/0/40 ip verify source tracking ip device tracking maximum 2 ! ip device tracking ! ip source binding 1111.2222.3333 vlan 123 123.0.0.100 interface Gi1/0/40 ! -usually when configured with "ip verify source" on an interface, it means to check the IP address to interface mapping on the DHCP snooping binding table before permitting traffic on ports that have the config -the addition of the "tracking" keyword indicates that we also permit the addition of IP source static mappings, in addition to the DHCP binding table caches -device tracking is the static database (instead of dynamic database DHCP snooping) that is used by static source-guard binding to check and verify address mappings -"ip device tracking maximum..." to determine how many devices can be tracked on the interface -"ip source binding 1111.2222.3333 vlan 123 123.0.0.100 interface Gi1/0/40" is used to statically define the IP, MAC, and source interface that must be tied! This is what is used when you enable "ip verify source tracking" command on the interface. IMPORTANT! When configuring source guard, the switch either uses the cache DHCP snooping binding table or the static source binding to check. BUT, when if configuring "ip verify source tracking" and static mapping "ip source binding..." the local switch will use the static binding to verify before using DHCP Snooping Database i.e. permit/deny traffic based on the static mapping. It depends on when the commands are configured....order of operation matters! IMPORTANT! -Trusted ports for DHCP Snooping and DAI are on the Northbound links i.e. links facing the DHCP server, switches, routers, etc. -Untrusted ports and IP Source Guard ports face the southbound towards the hosts. This is so that Snooping can record the IP-to-MAC bindings on the host ports, so DAI can check IP-to-MAC bindings on these ports, and for IPSG to check IP to interface bindings on the host ports Configuration: Source Guard with Port-Security ! interface FastEthernet1/1 switchport access vlan 5 ip verify source port-secuirity switchport port-security ! ip dhcp snooping vlan 5 ! ! -IP Source Guard could be combined with Port-Security to verify the IP address from DHCP Snooping/Static binding mappings AND the MAC address obtained from port-security on the interface. This essentially means that both the IP address and MAC address must belong to this interface! e.g. both IP and MAC must pass verification test by IP Source Guard and Port-Security to be permitted! IMPORTANT! To configure both IP Source Guard and Port-Security checks, "ip verify source port-security", then you must not only enable the command "ip verify source port-security" BUT also the Port-Security "switchport port-security" command must be configured as well!

IOS Device Access Security

IOS AAA -Old-Model -Local Authentication -Local Authorization based on line/username settings -New-Model -Supports AAA lists that define sequence of methods -List can be bound to access technologies -e.g. login or PPP -Default lists vs. explicitly assigned lists -very easy to log yourself out if not configured correctly, especially with AAA config that uses RADIUS server! TACACS+ and RADIUS -Terminal Access Controller Access-Control System (TACACS) -Primarily for device authentication management e.g. switches and routers -e.g. IOS Admins for Telnet and SSH to store passwords and username -Supports per-command authorization and accounting i.e. User A can use "show" commands only -Remote Authentication Dial In User Service (RADIUS) -Primarily for end user authentication management -e.g. remote access VPN users -Does not support per-command authorization and accounting; only supports ACL role-based -normally used for end users i.e. wireless authentication, WPA-2, EAP, etc. -Regardless which method used, local database fallback should be configured! Local Authentication -Default authentication method -Passwords are in clear-text by default -local login configure "username anthony password cisco" this will be considered Type 0 passwords with clear password in the running-config -"service password-encryption" can be used to globally change the default Type 0 clear-text password to a Type 7 encrypted password (Type 7 is reversible) -"username xxxx secret" will use a one-way MD5 hash to encrypt the password e.g. "username anthony1 secret cisco" can translate to "username anthony1 secret 5 $1$iM.0$zl32HwjyO.yc375zjaHie0" which is a one-way MD5 hash -same thing with "enable password/secret" command, which with the "password" and "service password-encryption" keywords the clear-text will change to Type 7 encrypted password. But with the "secret" keyword the clear-text will change to a one-way MD5 hash -IMPORTANT! once local authentication is configured, then we have to specify on the individual lines to use local username/password i.e. go to "line vty" -for Telnet and SSH Line Vty "no login" -"no login" configured on the line means that there is not authentication requirement to login to the line Line Vty "transport input" -by default both Telnet and SSH traffic is allowed to establish a remote console connection to routers. But if you use the command "transport input ssh" on the "line vty" then it means that only SSH connections are allowed! Line Parameters -Line VTY -this is where the parameters for Telnet and SSH are configured -"line vty 0 9" where this tells how many consecutive Telnet and SSH connections can be active at one time. "...0 9" means that there can be 10 active connections, with 0 being the first and 9 being the last. By default, the router or switch allows 5 lines i.e. "line vty 0 4" -Line aux -parameters for direct auxiliary connection -Line con -parameters for direct console connection Local Command Authorization -Privilege levels used to control access to exec commands -Default privilege levels -0 - no access -1 - user mode access i.e. if I only enabled "line vty..." without configuring any parameters, then when someone Telnet or SSH into the router I could only enter the "R1>" mode with privilege level 1 commands. Any other level between 2-14 can skip authenticating and straight into "enable" mode. i.e. if your username has only assigned privilege level 1, then you will enter R> automatically after you authenticate -15 - privilege (enable) mode access i.e. if I configured "enable password/secret" on the local router and someone Telnet or SSH, their privilege level would first default to their account but then if they enter enable config mode "R1#" it would default to privilege level 15 i.e. you will be in privilege level 15 after you enter "enable". Under level 15 would not be allowed to use "config terminal" mode -User defined privilege levels -Levels 2 - 14 available assignment -Level 15 means can run from level 0 - 15 commands, level 10 means can run command levels 0 - 10 -Moving command privilege down -allow privilege 1 to... -run extended ping -show running config -only see what you can configure -Moving command privilege up -revoke privilege 1 from -running show commands -using the enable command -Modified with privilege command -exec | configure | interface | router | etc. Assigning privilege level -can be assigned globally on all Telnet and SSH sessions in "line vty" mode -can be assigned individually based on username as well -username privilege level assignment overrides global assignment -IMPORTANT! if no custom commands are allocated to the different levels, then by default all levels from 1-14 are the same i.e. level 14 can only run commands same to level 1 -Use "aaa new-model" lists to assign each privilege levels different types of commands -"aaa new-model" this command is needed to enable Authentication, Authorization, and Accounting on the local machine -the aaa lists are separate instances for authentication, authorization, and accouting Different Privilege Modes Router> "User EXEC" Router# "Privilege EXEC" Router(config)# "Global Configuration" Configure Authentication List ! aaa new-model aaa authentication login LOCAL_DATABASE group tacacs+ group radius local aaa authentication enable default none ! Or use the "aaa authentication enable default enable" ! line vty 0 4 privilege level 15 login authentication LOCAL_DATABASE ! -the first line enables aaa new-model -the second line says, use aaa model for the method of the "authentication" process when users "login" to the local router. When they are one of the first 5 sessions ("line vty 0 4") to login to the router, they will need to first need to check with the tacacs* group, if the local router can't connect to the tacacs+ server, then use the radius server, if the local router can't reach the radius server, then use your locally configured usernames and passwords. The "LOCAL_DATABASE" is the authentication list that is defined, and the configuration is saying that if any "line..." is specifically configured to use this manually defined authentication list "LOCAL_DATABASE", then use the following methods to check for authentication. If the authentication list isn't defined and we use "aaa authentication login default...", the "default" keyword means that any "line" that does not specifically call forth an authentication list, then use the "default" list i.e. if my "line" doesn't say to use any list, then I will use whatever the default list the "aaa new-model" says to use -the third line is saying use the "aaa authentication" as the method for to determine access to the "enable" config mode i.e. "aaa authentitcation enable..." means set the authentication list for "enable" config mode. Use this as the "default" authentication list (i.e. all methods that do not specifically call forth a list) to allow/deny access. "aaa authentication enable default none", the "none" on the command is saying do not use any authentication checks for users trying to enter "enable" config mode! i.e. I don't need a password to enter enable config mode! -the alternative option for "enable" mode is to use configured "enable password/secret..." to authenticate -the "login authentication LOCAL_DATABASE" under the "line vty 0 4" config mode is telling the router that for the first 5 telnet/SSH sessions, use the authentication list "LOCAL_DATABASE" to check and allow access Configuring Default Privilege level and Local Login line vty 0 4 privilege level 15 login local -"login local" means that for SSH and Telnet access to this local router, use the locally configured username and password to authenticate i.e. use "username...password/secret" to check against. Then once authenticated, user will have to "enable" and enter in password to get "privilege level 15" access -IMPORTANT! the command "login local" under the "line vty 0 4" config mode implies that the "no aaa new-model" command is present. This means that the command "login local" is only present and can only be present when "aaa new-model" is not present! If "aaa new-model" is enabled, it means that Commands ! aaa authentication login LOCAL_DATABASE group tacacs+ group radius local aaa authentication enable default group tacacs+ enable aaa authorization config-commands aaa authorization exec EXEC_AUTHOR group tacacs+ aaa authorization commands 0 TACACS_AUTHOR group tacacs+ aaa authorization commands 1 TACACS_AUTHOR group tacacs+ aaa authorization commands 15 TACACS_AUTHOR group tacacs+ ! line vty 5 9 privilege level 14 authorization commands 1 TACACS_AUTHOR login authentication LOCAL_DATABASE ! -"aaa authentication enable default group tacacs+ enable" use an authentication list to check when users try to access the "enable" config mode. Use the default group that applies to all methods and use the TACACS+ server first. If TACACS+ server isn't reachable, then use the locally configured "enable password/secret" on the router -"aaa authorization commands 1 TACACS_AUTHOR group tacacs+" is saying users that have privilege level 1 assigned to them can issue only certain commands on the CLI. Those selected certain commands are defined by the authorization list "TACACS_AUTHOR" that resides on the TACACS+ server -"aaa authorization config-commands" by default, after a user is assigned a certain privilege and is able to access either "enable" or "config t" mode, and the user successfully authenticates, the user can then issue whatever command they want to in those config modes. However, with "aaa authorization config-commands" the local router is saying that once those user authenticate and enter those global config modes, the local router will check with TACACS+ i.e. you can be at privilege level 15, but every time you run a command I will check with the TACACS+ to see if you are authorized to run those commands -"aaa authorization exec EXEC_AUTHOR group tacacs+" for users who want to run certain commands once they are in the privilege EXEC mode, check withe the TACACS server first to see what commands the user can enter when they are in privilege EXEC mode. If TACACS server can't be reached, user won't be able to issue any commands! Because the list doesn't have an alternative method to authorize users! Should have use command "aaa authorization exec EXEC_AUTHOR group tacacs+ none" basically saying if the TACACS server is not available, then don't use any authorization methods and authorize all -IMPORTANT! "aaa authorization exec [list]..." is used to control permissions at the User EXEC level ( Router> ). "aaa authorization commands [level] [list]..." is used to control permissions at the Privilege EXEC level ( Router# ) Defining Authorization on Local Router (Optional) -authorization for what privilege level can issue what commands can be manually defined on the local router with the global config "privilege..." ! privilege interface level 5 ip address privilege interface level 5 ip privilege configure level 5 interface privilege exec level 5 configure terminal privilege exec level 5 configure privilege exec level 0 show running-config privilege exec level 5 show ! enable secret level 5 CCIE ! -"privilege exec level 5 configure terminal" this is saying that users with privilege level 5 can issue the "configure terminal" command when they are in the privilege exec mode i.e. "R1#" usually you would need to be at privilege level 15 to issue this command, but by manually defining the privilege and command on the local router, the default behavior is bypassed -"privilege interface level 5 ip address" this is saying that users with privilege level 5 can issue the command "ip address..." on interface configuration mode, users with privilege level 5 can issue the "ip address" command on interface level -"privilege exec level 0 show running-config" . When the user is at level 0 and in privilege EXEC mode, they are allowed to issue the "show run" command. This is usually a privilege level 15 command, but users with privilege level 0 can now run this command -"enable secret level 5 CCIE" this command is configured by the admin so that when users access the router and are at the user EXEC (Router>), they enter in the "enable level 5" command and are challenged to put in the password to have access at level 5. This is an alternative from giving out privilege levels via "username xxx level xxx" command. Role-Based Access Control (RBAC) -Replacement for privilege-levels on remote servers -more flexible in terms of command allocation -but not as granular compared to TACACS in terms of restrictions on what commands a user can or cannot do -Role is a group of commands -Known as "parser view" in IOS -Roles could be -Manually switched to (enable view) -Assigned to users -Roles should be configured from root view (enable view) -RBAC requires "aaa new-model" enabled in the router!, even if done locally -IMPORTANT! if you allow the user to enter privilege EXEC mode by configuring an "enable password/secret" option, then by default the user will enter with a privilege of 15, bypassing the view. To enter the view, usually user must enter "enable view (view name)" and then enter the "secret" configured. ! username brian view VIEW1 password 7 104D000A0618 parser view VIEW1 secret 5 $1$6Z8M$jkwD3VRpL/gQx.IvU8/z81 commands router include all network commands configure include all router commands exec include configure terminal commands exec include configure commands exec include all show ! !Telnet to the RBAC router ! R1#telnet 150.1.10.10 username: password: R1> R1(config)> R1(config-router)> ! -Create the RBAC with the "parser view [name]" command -create a "secret" -"commands exec include configure terminal" means that when user is in user EXEC mode, allow them to use the command "configure terminal" to enter global configuration mode -" commands router include all network" means to allow the users to issue all the "network" commands under router config mode -"username brian view VIEW1 password 7 104D000A0618" this command is needed to identify the username "brian" and password will be given authorization permissions based on the RBAC group "VIEW1" Configuration Change Notification and Logging -Local command accounting -Tracks users and commands issued through CLI and HTTP -Configured as "archive" and "log config" Cisco IOS Login Enhancements -Used to protect against brute force high attacks -After x number of failed attacks, delay login box -Configured as "login block-for" -"login block-for 30 attempts 2 within 10" is saying to lock-out users that fail 2 attempts with incorrect username/password within a period of 10 seconds. The lock-out period is for 30 seconds. IOS Resilient Config -used to prevent config or IOS image from being deleted -hides the config and IOS image on flash/nvram -configured as "secure boot-config" and "secure boot-image" Different Modes R1> This is the user EXEC mode R1# This is the privileged EXEC mode R#(config) This is the global configuration mode Verification -"debug aaa authentication" -"show parser view" All Configs ! aaa new-model aaa authentication login default local aaa authentication login LOCAL_AUTHEN group tacacs+ group radius aaa authorization exec default group tacacs+ none ! username anthony privilege 5 password 0 cisco ! line vty 0 login authentication LOCAL_AUTHEN line vty 1 ! username bui privilege 5 view RBAC password 0 cisco ! parser view RBAC parser view RBAC secret 5 $1$CU20$7Dmq1x7UAhucBW8Jze0xI. commands configure include all router commands exec include configure terminal commands exec include configure commands exec include show ! -this means that the username "bui" has privilege 5 and is using RBAC named "RBAC". In parser view "RBAC" the user can issue the "show" and "configure terminal" command under user EXEC mode. Under the global "configure" mode, the user can issue "all router" commands Parser View Example aaa new-model aaa authentication login default group RAT group tacacs+ local none aaa authentication login CCIE group tacacs+ local aaa authentication enable default none aaa authorization config-commands aaa authorization exec default local aaa session-id common username a privilege 10 password 7 104C49 username aaa privilege 10 password 7 0509040D username test password 7 131112010E18 username parser view VIEW_ONE password 7 071F205E5D0C0B username parser2 privilege 10 view VIEW_TWO password 7 1315160018091678 username parser3 privilege 14 view VIEW_THREE password 7 03145A19150A331F username parser4 view SUPERVIEW password 7 00141214175E1952 parser view VIEW_ONE secret 5 $1$uQnd$pxJKkvEsDW1JiD1A2Zg/J. commands exec include show running-config commands exec include show parser view VIEW_TWO commands configure exclude router commands exec exclude configure terminal commands exec include show ip interface brief commands exec include show ip interface commands exec include show ip commands exec include show privilege commands exec include show parser view VIEW_THREE secret 5 $1$.8T/$qhNO8KXra3Kg8XzICxYKy1 commands configure include router commands exec include configure terminal commands exec include configure commands exec include show ip interface brief commands exec include show ip interface commands exec include show ip commands exec include show running-config commands exec include show privilege commands exec include show parser view VIEW_ONE_SUPER superview secret 5 $1$wBq9$Fp4A6xxs5h3mEdeIk.0Bf/ view VIEW_ONE parser view SUPERVIEW superview secret 5 $1$4LKM$V6o6Kap0p93btCg/0DUGj. view VIEW_ONE view VIEW_TWO

Catalyst Port Based Traffic Control

Port Security -used to limit access to a port based on MAC address -limit the number of devices to connect to a switchport i.e. maybe 2 maximum devices per port e.g. PC and Phone -Violation Modes for Port Security; determines if there are too many MAC addresses or the wrong addresses shown -Shutdown (default) -send port to err-disable -Protect -violator MACs cannot send traffic in; accepted MACs still can -Restrict -violator MACs cannot send traffic in; accepted MACs still can & -switch generates SNMP / Syslog messages -Port security is disabled by default; must show to ensure it is on -Applies to access and trunk ports by default, but not dynamic ports i.e. if you do not explicitly define a port as either access or trunk, then you can't configure port-security! -ensure port mode is statically defined -Secure MAC addresses -can only belong to one port i.e. MAC can only belong to one port -static -learned (dynaminc) -Sticky; learn it dynamically and automatically put it in the port as a statically learned, and show it on the running-config i.e. learn dynamically and stick to interface and running config! -Trunk ports -support per-VLAN limits (default unlimited) -Port limit is aggregate across all VLANs -remember that you can change device MACs -Keep in mind port-security and HSRP interaction -HSRP/VRRP/GLBP and virtual MACs -two solutions -Standby use-bia -Allowing the virtual MAC -avoid using "protected" mode on trunks -disables MAC learning once limit is reached for any VLAN -Consider additional MACs with IP Phones Protected Ports -smaller subset of private VLANs e.g. lightweight version of PVLAN -Protected ports cannot exchange L2 frames -used to prevevnt devices on the same VLAN from communicating at layer 2 -"switchport protected" -limited to one switch (stack or not) i.e. protected ports can't communicate to other protected ports within the same "switch" i.e. locally significant, applies to same switch and same VLAN only -Example: prevent compromised WWW server from launching DoS at servers on the same VLAN -unknown unicast and multicast packets are allowed at layer 2 -could be disabled explicitly -"A protected port does not forward any layer 2 traffic (unicast, multicast, or broadcast) to any other port on the same switch that is also a protected port." -i.e. configured "protected ports" cannot send layer 2 traffic to each other -however, they can still send layer 3 traffic to each other via layer 3 device such as MLS or routers "switchport protected" is configured on the interface level command to enable layer 2 protect mode Port Blocking -"To prevent unknown MAC unicast or multicast traffic from being forwarded from one port to another, you can block a port (protected or nonprotected) from flooding unknown unicast or multicast packets to other ports." -"switchport block unicast/multicast" is configured on the interface to block out unknown MAC addresses from being flooded out of the interface -unknown MAC addresses is considered MAC addresses with unknown destinations, by default once a switch receives a packet with an unknown unicast/multicast MAC address, it will flood it out all ports except the port on which it received the initial packet. By configuring port blocking on a port, it will prevent the configured port from this default behavior i.e. packets with unknown destination MAC addresses will not get flooded out and into all other ports! Static MAC/CAM Entries -Switch learns MAC addresses dynamically -learning can be disabled, e.g. on P2P VLANs -Static MAC entry can be configured -Points to be a fixed port -Static CAM entries can be used for "null-routing" -"mac address-table static aaaa.bbbb.cccc vlan 20 drop" this is essentially the same as a layer 3 static route to a null interface e.g. ip route 1.2.3.4 255.255.255.255 null0. This command states that any packets destined to MAC address aaaa.bbbb.cccc will get dropped Storm-Control -essentially a Policer -Limit the amount of unicast / broadcast / multicast L2 traffic accepted in a port -ingress rate-limiting only on the interface -"storm-control {broadcast | multicast | unicast} level {level [level-low] | pps pps [pps-low]} -level is a % of interface speed, not bandwidth -10/100/1000 issue -where the upper threshold of storm-control the type of traffic defined will start dropping, and the lower threshold is where the traffic will begin to forward as normal -"storm-control" violations can be shutdown or configured to only send traps Configuration -Enable port security on access or trunk port -"switchport port-security" -by default only 1 MAC address is allowed per port, even for trunks -port-security can only be enabled on access or trunk ports ! interface GigabitEthernet1/0/38 switchport mode access switchport port-security switchport port-security maximum 5 switchport port-security aging time 5 switchport port-security violation restrict switchport port-security aging type inactivity switchport port-security aging static ! -IMPORTANT! "switchport port-security" this must be configured for ALL other port-security features to work! This command enables the port-security process, without it nothing port-security related will work -" switchport port-security maximum 5" there can only be a maximum of 5 dynamically learned addresses allowed on this port -" switchport port-security aging time 5" there is a 5 minute aging timer configured for this port i.e. after 5 minutes the MAC address is either deleted from the port security due to total timer countdown or periods of inactivity -" switchport port-security violation restrict" when there is a violation on port-security, the violating and unknown MAC addresses will not be allowed to pass traffic AND there will be SNMP/Syslog messages generated, but the permitted MAC address traffic will be allowed -" switchport port-security aging type inactivity" this sets the aging timer to inactivity i.e. if there is a period of inactivity on this port for the port-security defined MAC address, then the secured MAC addresses are deleted. This is in contrast to "absolute" timing where after the configured time the secured MAC is deleted, where the timer is counted down regardless of inactive/active status - "switchport port-security aging static" by default, the aging timers only apply to dynamically learned addresses, to enable aging for statically configured addresses, use this config -IMPORTANT! by default, if no "switchport port-security" violation modes are configured it is defaulted to shutdown if a violation occurs. The only way to bring it out of shutdown is to either manually shut/no shut on the port or to configure "errdisble recovery" features Verification Commands -"show port-security interface ..." to show port-security features configured and and they are enabled on the interface. Also to show the status of the port-security e.g. disabled/enabled -"show port-security addresses" to show allowed and configured secured MAC addresses on the interface

Private VLANs

Private VLANs -Similar to Port Protection feature, but with more features -IMPORTANT! Must run in VTP Transparent mode if using version 1 and 2. Only version 3 supports runNing PVLAN in all modes -Allows for layer 2 isolation between ports within the same VLAN -Expansion of protected port feature -Allows isolation across multiple switches -Allows for additional granular control within the same VLAN -Requires "sub-VLAN" within the "main" VLAN -Private VLANs use "sub-VLANs" within the primary VLAN for the layer 2 isolation -Main VLAN is known as "Primary" VLAN -Sub-VLAN is known as "Secondary" VLAN -There are two types of Secondary VLANs -Community -Isolated Private VLANs Port Types -Two Type of Ports -Promiscuous Ports -connects to router or layer 3 device -Host Ports -connects to end hosts -either isolated or community ports Private VLANs VLAN Types -Primary VLAN -Carries traffic from Promiscuous ports to Host ports -Isolated VLAN -Carries traffic from Host ports to Promiscuous port -Community VLAN -Carries traffic between same Community host ports and to the Promiscuous port Private VLANs and VTPv3 -VTPv1 and VTPv2 cannot advertise extended VLANs -Private VLANs are Extended VLANs -implies that Private VLAN config must be manually synced i.e. version 1 and 2 does not advertise Private VLAN -VTPv3 Fixes this -Private and Extended VLANs can be advertised Configuration !!Host Configuration ! vlan 2001 private-vlan isolated ! vlan 2002 private-vlan community ! vlan 100 private-vlan primary private-vlan association 2001-2002 ! interface GigabitEthernet1/0/23 switchport private-vlan host-association 100 2001 switchport mode private-vlan host ! interface GigabitEthernet1/0/24 switchport private-vlan host-association 100 2002 switchport mode private-vlan host ! !!Layer 2 Port to Router on Switch ! interface GigabitEthernet1/0/25 switchport private-vlan mapping 2001 2002 switchport mode private-vlan promiscuous ! !!Layer 3 Port as SVI ! interface vlan 100 ip address 192.168.0.11 255.255.255.0 private-vlan mapping 2001-2002 !

IPv6 First Hop Security

What is First Hop Security (FHS)? -First Hop -Network segment between end hosts and their default gateway -i.e. the Access Layer -Security -Prevent against internal threats at the access layer -e.g. Man-in-the-Middle (MIM) attack Why is IPv6 FHS Needed? -Both IPv4 and IPv6 suffer from insecure control plane protocols in the access layer -For IPv4... -ARP - attacker uses poison ARP to send out fake MAC for gateway IP address i.e. gratuitous ARP -DHCP - attacker responds to DHCP Discovery messages and gives out IP addresses for malicious purposes e.g. use their IP address as the gateway to sniff victim traffic -For IPv6... -ICMPv6 Neighbor Discovery (ND) -Duplicate Address Detection (DAD) -Stateless Address AutoConfiguration (SLAAC) -DHCPv6 How ICMPv6 ND Works -ICMPv6 ND/NDP replaces IPv4 ARP -IPv4 ARP uses 2 messages: Request and Reply -Request - trying to resolve the IP to MAC -Reply - here is the mapping -ICMPv6 ND uses 4 messages: -NS - Neighbor Solicitation -ask for information about neighbor, do you have this IP address? used for DAD -NA - Neighbor Advertisement -Advertise yourself to other neighbors -RS - Router Solicitation -Ask for information about local routers -RA - Router Advertisement -Advertise yourself as an active router ICMPv6 ND Workflow for New Hosts -When an end host wants to join the IPv6 LAN... -Choose a link-local address by automatically creating one -FE:80::/10 + EUI-64 -Check if link-local address is unique -Send NS for link-local solicited node multicast -FF02:0:0:0:0:1:FF00::/104 + 24 low-order bits of link-local address, used for Duplicate Address Detection (DAD) -If no reply address, then address is unique! -Announce yourself as a live host -Send NA to all hosts multicast FF02::1 when you find that your address is unique -Discover the routers -Send RS to all routers multicast FF02::2 -Routers replies with RA -Contains the router's IPv6 address and MAC, along with prefix information for SLAAC -Host chooses a global prefix for SLAAC -RA Prefix + EUI-64 -perform DAD again for the global prefix Potential Attacks in the First Hop Segment -Spoof the router -Send gratuitous RA to announce yourself as the router -Result is MIM or a basic DoS attack -Spoof the DHCPv6 server -respond with bogus offer -result is basic DoS attack or MiM if combined with RA spoofing -Poison the router's ND cache -send gratuitous NA message with other people's addresses -result is MiM or a basic DoS attack -Overload the router's ND cache -send packets to entire /64 range -result is router's CPU is DoSed trying to send lots of NS messages IPv6 RA Guard -Host dynamically discover the default gateway based on NDP RA messages (ICMPv6) -interfaces connected to downstream (host) ports should not be sending out RAs or receiving RAs, if they are then something is not right! -Only upstream or links connected to routers should be sending out RAs or receiving RAs -RA Guard prevents router spoofing on the segment -RA also prevents prefix spoofing on the segment -Policy can be applied at VLAN or port level -Link to router should be configured as "trusted" port -failed validated RA packets on untrusted ports will be dropped -Device Roles -Host: interfaces in this device-role can't receive or transmit RAs -Router: Interfaces in this device-role could receive, process, and transmit RAs Configuration ! ipv6 nd raguard policy TRUST trusted-port device-role router ipv6 nd raguard policy UNTRUST device-role host ! interface GigabitEthernet1/0/23 description Host Connected Access Port ipv6 nd raguard attach-policy UNTRUST vlan 230 ! interface GigabitEthernet1/0/24 descrition Router or Upstream Port ipv6 nd raguard attach-policy TRUST vlan 230 ! -RA Guard works by first creating a policy that defines what the trusted port, untrusted port, accepted ipv6 accepted prefixes for SLAAC, etc. -RA policy could be applied globally or on an interface level -under the policy, you must define the "device-role" and the trust state, with the default being "host" and "untrusted" -any interface ports with a "ipv6 nd raguard attach-policy...vlan..." that has "trusted-port" configured will not have it's RA packets dropped, as oppose to untrusted ports which will have its packet inspected and dropped if it's a RA/RS -default state is untrusted DHCPv6 Guard -DHCPv6 does not assign default-router as in IPv4 -Default router is learned through SLAAC from RA messages -Similar in scope with IPv4 DHCP Snooping -Prevents DHCPv6 server spoofing -Policy can be applied at VLAN or port level IPv6 Snooping -IPv6-to-MAC resolution achieved through NDP NS/NA messages (ICMPv6) i.e IPv6 ND Inspection -similar in scope with IPv4 DAI -same with Dynamic ARP Inspection -Inspects DHCPv6 and NDP messages -performs neighbor binding table through IPv6 neighbor tracking via records from the RA address bindings table -Prevents host spoofing on the segment -optionally enables basic RA Guard and DHCPv6 Guard -optionally can inspect data packets to perform neighbor binding i.e. this neighbor has this IPv6 address on the IPv6 neighbor table -manual bindings are possible for strict control and for non-DHCP statically defined IP addresses used by routers, APs, etc. -policy can be applied at the VLAN or port level IPv6 Source-Guard -Similar in scope to IPv4 Source Guard -relies on IPv6 Snooping to create the IPv6 neighbor binding table, maps IPv6 to interfaces bases on IPv6 Snooping binding table -creates automatic IPv6 PACL to filter sources based on neighbor binding table IPv6 Secure Neighbor Discovery (SeND) -An extension to NDP to secure and authenticate these messages -requires PKI infrastructure and routers enrolled (certificates issued) -hosts do not need to be enrolled but need to trust the PKI chain -RA and RS messages are authenticated between hosts and routers -routers are authorized to send RA messages for specific prefixes based on IPv6 Extension certificate field -IMPORTANT! Most likely will not be in CCIE R&S!! Verification -"show ipv6 neighbor bindings" -"show ipv6 nd raguard policy..." -"show ipv6 snooping..."