Semester 3 v5 -Chapter 8
Cisco Networking Academy
CCNP
Minimizing Service Loss
and Data Theft in a
Campus Network
Switch security concerns
• Network security coverage often focuses on
edge-routing devices and filtering of packets
• Campus access devices and L2 communication
are left largely unconsidered
• But if an attack is launched at L2 on an internal
campus device, the rest of the network can be
quickly compromised
Rogue Devices
• Rogue devices can be
– Access Points
– Wireless routers
– Access switches
– Hubs
• Devices typically connected at access level
switches
• To mitigate STP manipulation
• root guard
• BPDU guard
Switch attack categories
• L2 malicious attacks are typically launched by a
device connected to the campus network
– A physical rogue device
– An external intrusion that takes control of and
launches attacks from a trusted device
• Types of L2 attacks
– MAC layer attacks
– VLAN attacks
– Spoof attacks
– Attacks on switch devices
MAC flooding attack
•
CAM table overflow that causes flooding of regular data
frames out of all switch ports
•
Purposes
– Collecting a broad sample of traffic
– DoS attack
•
Suggested mitigation:
– Limit the number of allowed MAC addresses in a port using
Port Security
Port security
•
•
•
•
•
Available on the 6500, 3550 and 2950
Administrator configures MAC addresses to provide security
It restricts a switch port to a specific set and/or number of
MAC addresses
Maximum number of secure MAC on a port
A MAC address can be allowed:
– Static assignment of the MAC address
• switchport port-security mac-address mac_address
– Dynamic learning of the MAC address (sticky learning)
– Manually configure a number of MAC and the rest dynamically
configured
Configuring Port security
1.
Enable port security
2.
3.
4.
Set MAC address limit default = 1
Specify allowable MAC addresses
Define violation actions
–
–
–
When the maximum number of secure MAC addresses has been
added and a station whose MAC address is not in the table
attempts to access
A station whose MAC address is configured as secure on
another secure port attempts to access the interface
3 violation modes
•
•
•
Protect packets with unknown source addresses are dropped until
secure MAC are manually removed
Restrict trap notification to the SNMP management station
Shutdown interface shut down and send an SNMP trap
notification
Sticky MAC addresses
•
•
Limits switch port access to a single, specific MAC
address without the network administrator having
gather and manually associate the MAC address of
every legitimate device with a particular switch port
The switch port converts dynamically learned MAC
addresses to sticky MAC addresses
It subsequently adds them to the running configuration
as if they were static entries for a single MAC address
to be allowed by Port Security
Configuration:
•
It can not be used on ports that use voice VLANs
•
•
– switchport port-security mac-address sticky
AAA
• usernames and passwords can be configured
directly on the network device
– This configuration does not scale well
• Recommend security handled at centralized location
• Different security features (AAA):
– Authentication
• Verifies a user identity
– Authorization
• Specifies the permitted tasks for the user
– Accounting
• Provides billing, auditing and monitoring
• AAA can use protocols such as RADIUS, TACACS+
or 802.1x to administer its security functions
AAA process
•
AAA enables dynamic configuration of the type of
authentication and authorization
– On a per-line (per-user) basis
– On a per-service basis
•
Method lists must be created
– Sequential list that defines the authentication methods used to
authenticate a user
– Enable designation of one or more security protocols to be used
for authentication
•
Order is established by which servers will be contacted
for authentication and authorization
•
Users attempt login and must be authenticated by server
•
Users must be authorized to user requested resources if
Authorization is configured
•
Users activity is recorded if Accounting is configured
Configuring AAA Authentication
• AAA authentication
– Access to the console: aaa authentication login
– Access to VTYs through Telnet and SSH
– Access to privileged EXEC mode
•
Default method:
– applied to all interfaces if no other method list is defined
•
Named list method:
– must be applied to a specific interface before any of the defined
authentication methods will be performed
Configuring AAA Authentication
• Responses:
– FAIL
• User has not met the criteria contained in the
authentication database to be successfully
authenticated
• Authentication ends with a FAIL response
– ERROR
• The security server has not responded to an
authentication query
• When ERROR detected, AAA select the next
authentication method defined in the authentication
method list
Configuring AAA Authentication
•
Authentication for logins on TTYs, VTYs, and the console:
RTA(config)#aaa authentication login
default tacacs+ none
default method
1st method
If 1st errors, then grant access
802.1x
• Client-server-based access control and authentication
protocol
• Restricts unauthorized clients from connecting to a
LAN through publicly accessible ports
• The authentication server authenticates each client
connected to a switch port before making available
any services offered by the switch or the LAN
• Before authentication, 802.1x only allows EAPOL
traffic through the port
– EAPOL(Extensible Authentication Protocol over LAN)
Roles in 802.1x
•
Client
– device that requests access to the LAN and switch services and
responds to requests from the switch
– It must be running 802.1X-compliant client software (Ex: XP)
•
Authentication server
– validates the identity of the client
– notifies the switch whether or not the client is authorized to
access the LAN and switch services
– RADIUS + EAP (Extensible Authentication Protocol) only
•
Switch
– controls the physical access to the network based on the
authentication status of the client
– proxy between the client and the authentication server
– includes the RADIUS client + 802.1x
– encapsulates and decapsulates the EAP frames
802.1x message exchange
•
The switch or the client can start authentication
•
If 802.1X not enabled on the switch EAPOL frames dropped
•
If the client does not receive an EAP-request/identity frame
after a defined number of attempts to start authentication client sends frames as if the port is in the authorized state
•
Ex: OTP (One-Time-Password) authentication method +
RADIUS server
802.1x authorized ports
•
Unauthorized state State where port starts
– the port disallows all traffic except for 802.1X protocol packets
•
Authorized state
– When a client is successfully authenticated
– Allows all traffic for the client to flow normally
•
If a client that does not support 802.1X is connected to an
unauthorized 802.1X port
– The client is not granted access to the network
•
If an 802.1X-enabled client connects to a port that is not
running the 802.1X protocol
– the client sends frames as if the port is in the authorized state
• Dot1x port-control
– Force-authorized
– Force unauthorized
– Auto
802.1x authorized ports
• Dot1x port-control
– Force-authorized (default)
• 802.1X is disabled and the port transitions to the authorized state
without any authentication exchange required
– Force unauthorized
• the port remains in the unauthorized state
• The switch cannot provide authentication services
– Auto
• enables 802.1X authentication
• The port begins in unauthorized state
• allows only EAPOL frames through the port
• If the client is successfully authenticated, the port state changes to
authorized
• When a client logs off
– it sends an EAPOL-logoff message
– the switch port transitions to the unauthorized state
Configuring 802.1x
1. Enable AAA
switch(config)#aaa new-model
2. Create a 802.1x authentication method list
switch(config)# aaa authentication dot1x
{default} method1 [method2…]
3. Globally enable 802.1x port-based
authentication
switch(config)#dot1x system-auth-control
4. Enable 802.1x on the interface
switch(config)# interface interface_id
switch(config-if)# dot1x port-control auto
VLAN hopping
• Network attack where
– Attacking system sends packets to, or collects them from,
a VLAN that should not be accessible to that system
– Attacking system spoofs itself as a legitimate trunk
negotiating device
– Trunk link is negotiated dinamically
– Attacking device gains access to data on all VLANs
carried by the negotiated trunk
• Implementations
• Switch spoofing
• Double tagging
VLAN hopping – Switch spoofing
• Attacker gains access to a switch port and
sends DTP negotiation frames toward a switch
with DTP running and autonegotiation turned
on
• Attacker and switch negotiate trunking over
the port
• Switch allows all VLANs to traverse de trunk
link
• Attacker sends data to, or collects it from, all
VLANs carried on that trunk
VLAN hopping – Double tagging
• An attacker generates frames with two 802.1Q
headers in order to get the switch to forward
frames onto a VLAN that would be inaccessible
to the attacker through legitimate means
– Attacker sends a frame with two 802.1Q headers
– Switch1 strips the outer tag and forwards the frame
to all ports within same native VLAN
– Switch2 interprets the frame according to information
in the inner tag
– Switch2 forwards the
frame out all ports
associated with the
second VLAN,
including trunk ports
How to mitigate VLAN hopping
• Measures to defend the network from VLAN
hopping
– Configure all unused ports as access ports
• switch(config)#interface-range type mod/port
switch(config-if)#switchport mode access
– Place all unused ports in the shutdown state and
associate with a VLAN designed only for unused
ports, carrying no user data traffic
• switch(config-if)#switchport access vlan vlan-id
– When establishing a trunk link, configure
• the Native VLAN to be different from any data VLANs
• trunking as on, rather than negotiated
• the specific VLAN range to be carried on the trunk
ACLs
• ACLs filter traffic
• 3 applications of ACLs:
– Router ACLs (RACLs)
• IP standard and IP extended ACLs
• filter routed traffic between VLANs
• Applied to L3 interfaces for specific directions
(inbound/outbound)
– Port ACLs (PACLs)
• filter traffic entering a L2 switch port, trunk or Etherchannel
– VLAN ACLs or VLAN maps
• filter bridged and routed packets
• apply to all traffic on the VLAN based on Ethertype and MAC
address
• Follow route-map conventions, where map sequences are
checked in order
• VACLs are not defined by direction
VLAN ACLs and VLAN Maps
• Can filter all traffic traversing a switch
• VLAN maps
– not defined by direction
– match clauses to select traffic
and perform operations on it
– Each clause contains one or more ACLs
– only way to control filtering within a VLAN
– If there is a match clause for a packet in the VLAN map,
and that packet does not match any of the entries within
the map default VLAN map action = drop the packet
– If there is no match clause for that packet
• default forward the packet
• A VLAN map cannot be applied to a VLAN on a
switch that has ACLs applied to L2 interfaces (port
ACLs)
VLAN ACLs and VLAN Maps
• Example of VACLs configuration:
– It does not allow any host using a source IP address
from 10.1.0.0 to 10.1.255.255 to send frames across
this switch
Private VLAN (PVLAN)
•
Traditional solution
– One VLAN per costumer, with each VLAN having its own IP
subnet
– Challenges
•
•
•
•
•
High number of interfaces on SP devices
Spanning tree becomes more complicated
Network address space must be divided into many subnets
Multiple ACL applications required to maintain security
Private VLANs
– L2 isolation between ports within the same VLAN
– It eliminates the need for a separate VLAN and IP subnet
per costumer
– Types of ports
• Isolated: Communicate only with promiscuous ports
• Promiscuous: Communicate with all other ports
• Community: Communicate with other members of community
and all promiscuous ports
Private VLAN (PVLAN)
•
Different PVLANs:
– Primary VLAN: Carries traffic from promiscuous ports to
isolated, community, and other promiscuous ports in the
same primary VLAN
– Secondary VLANs
• Isolated VLAN: Carries traffic from isolated ports to a
promiscuous ports
• Community VLAN: Carries traffic between community ports
and promiscuous ports
Configuring PVLANs
1.
Set VTP mode to transparent
2.
Create secondary VLANs (isolated and community)
3.
Create the primary VLAN
–
4.
switch(config-vlan)#private-vlan [primary |
isolated | community]
Associate the secondary VLAN to the primary VLAN
–
switch(config-vlan)#private-vlan association
{secondary_vlan_list | add sv1 | remove sv1}
5.
Configure an interface to an isolated or community
port
6.
Associate the isolated port or community port to the
primary-secondary VLAN pair
7.
Configure an interface as a promiscuous port
8.
Map the promiscuous port to the primary-secondary
VLAN pair
DHCP Spoofing Attack
• An attacker hosts a rogue DHCP server off of a
switch port
• Client broadcasts a request for DHCP
configuration information
• The rogue DHCP server responds before the
legitimate DHCP server, assigning attackerdefined IP configuration information
• Host packets are redirected
to the attacker address as it
emulates a default gateway
for the erroneous DHCP
address provided to the
clients
DHCP Snooping
•
Catalyst feature that determines which switch ports can
respond to DHCP requests
– Trusted ports can source all DCHP messages
– Untrusted ports can only source requests
•
If a rogue DCHP on an untrusted port attempts to send
DHCP response packets, the port is shut down
•
DHCP Option 82: switch information, such as the port ID of
the DHCP request, is inserted into the DHCP request packet
ARP Spoofing Attack
•
•
By spoofing an ARP reply from a legitimate device, an
attacking device appears to be the destination host sought
by the senders
The ARP reply from the attacker causes the sender to store
the attacking system MAC address in the ARP cache. All
packets destined for those IP address will be forwarded
through the attacker system
–
–
–
–
The attacker sends ARP binding its MAC address with the IP destination address
Host A updates ARP cache with attacker’s MAC address bound to C’s IP address
The attacker sends ARP binding its MAC address with the IP sender address
Destination updates ARP cache with attacker’s MAC address bound to sender’s IP
address
Dynamic ARP inspection
•
•
Prevents ARP spoofing or ‘poisoning’
Intercepts and validates all ARP requests and responses
– Forwards ARP packets received on a trusted interface without any checks
– Intercepts all ARP packets on untrusted ports
– Verifies that each intercepted packet has a valid IP-to-MAC address
binding before forwarding packets that can update the local ARP cache
– Drops and/or logs ARP packets with invalid IP-to-MAC address bindings
•
Configure all Access switch ports as untrusted and all switch ports
connected to other switches as trusted
Protecting Spanning Tree
•
•
Protect against switches being added on PortFast ports
– BPDU Guard shuts ports down when BPDUs are
received
– BPDU filter specifies action to be taken when
BPDUs are received
BPDU Root Guard protects against a switch outside the
designated network attempting to become the root
bridge
Configuring BPDU Guard
• BPDU Guard protects the network from loops that
might form if BPDUS are received on a PortFast
enabled switch port
• When a BPDU is received, the port is put in errordisabled state
• Global configuration
Switch(config)#spanning-tree portfast bpduguard default
• Interface configuration
Switch(config-if)#spanning-tree bpduguard enable
Configuring BPDU Filtering
– Global configuration
• It affects all PortFast ports on a switch without BPDU filtering
configured on the individual port
• If BPDUs are seen, the port looses its PortFast Status, BPDU
filtering is disabled and STP sends and receives BPDUs on the port
as any other STP port on the switch
• Upon startup, the port transmits ten BPDUs. If this port receives
any BPDUs during that time, PortFast and PortFast BPDU filtering
are disabled
Switch(config)#spanning-tree portfast bpdufilter default
– Interface configuration
• Ignores all BPDUs received
• Sends no BPDUs
Switch(config-if)#spanning-tree bpdufilter enable
Configuring Root Guard
– Root Guard limits the switch ports out of which the root
bridge may be negotiated
– If a root guard-enabled port receives BPDUs that are
superior to those being sent by the current root bridge,
• that port will be moved to a root-inconsistent state (listening state)
• no data traffic will be forwarded across this port
– When the root guard-enable port receives inferior BPDUs,
the port will be unblocked again
Switch(config-if)#spanning-tree guard root
Unidirectional link detection
• Unidirectional link
– Traffic is transmitted between neighbors in one direction only
– Can cause ST topology loops
• UDLD
– L2 protocol that works with the L1 mechanisms to determine the
physical status of a link
– Protocol that allows devices to detect an unidirectional link
– Both ends of the link must support UDLD
• A switch configured with UDLD
periodically transmits UDLD packets
– If packets are not echoed back within a
specific time, the link is flagged as
unidirectional and the interface is shut
down (aggressive) or the port changes to an
undetermined state (normal)
Loop guard
• Provides protection when BPDUs are being sent, but not
received on a link that is considered operational
• When an unidirectional link is detected, the interface will
move into the STP loop-inconsistent blocking state
• Once a BPDU is received, the port will transition to the
appropriate state
Before loop guard
With loop guard
– C is not receiving BPDUs from B – C is not receiving BPDUs from B
– Port on C transitions to forwarding – Port on C transitions to loopstate in 50 sec LOOP
inconsistent state
Comparison between Loop Guard and UDLD
• On an Etherchannel bundle
– UDLD will disable individual failed links
– Loop Guard will put the entire channel in loop-inconsistent state
• Enabling both UDLD and Loop Guard provides the
highest level of protection
Configuring UDLD and Loop Guard
• Configuring UDLD
– Enable UDLD on an interface
• S(config-if)#udld port
– Enable UDLD globally
• S(config)#udld enable
– Verify and reset UDLD
• S#udld reset
• S#show udld interface
• Configuring Loop Guard
– Enable Loop Guard on an interface
• S(config)#spantree guard loop mod/port
• S(config)#spantree guard none mod/port
• Enabling root guard will disable root guard, if root guard is
currently enabled on the ports
– Enable Loop Guard globally
• S(config)#spantree global-default loopguard enable
• S#show spantree guard mod/port | vlan
CDP security issues
•
CDP is transmitted in clear text and unauthenticated
•
An attacker can use a packet analyzer to intercept
CDP traffic
•
An attacker can analyze information in CDP packets to
gain knowledge of network address and device
information
•
An attacker can formulate attacks based on known
vulnerabilities of network platforms
Telnet and SSH
• Telnet
– Telnet packets are transmitted in clear-text
– A user with an account on the system could gain elevated
privileges
– A remote attacker could crash the Telnet service, preventing
legitimate use of that service
– A remote attacker could find an enabled guest account
present anywhere within the trusted domains of the server
• SSH (Secure Shell)
– The entire login session is encrypted
– Replacement for rlogin, rsh, rcp, and rdist as well as Telnet
and FTP
– protects a network from attacks such as IP spoofing, IP
source routing, and DNS spoofing
Using vty ACLs
• Restricting VTY connections
– The access-class ACL-number applies the ACL to the interface
– The ACL can be a standard or an extended ACL
• Restricting web interface connections
– To bind a standard ACL to the http server process:
• ip http access-class ACL-number
• ACL-number: 1 - 99
Best practices
• Consider or establish organizational security
policies
– Proces for auditing existing networks
– General security framework
– Behaviors toward electronic data that are disallowed
– Which tools and procedures are needed
– Responsibilities of users and administrators
– Process for handling network security incidents
– Enterprise-wide, all site security implementation and
enforcement plan
• Secure switch devices
• Secure switch protocols
• Mitigate compromises launched through a switch
Best practices: Secure switch access
• Set system passwords enable
secret
• Secure physical access to the console
• Secure access via Telnet
• Use SSH when possible
• Configure system warning banners
• Disable unused services no
service finger/config…
• Disable the integrated HTTP daemon if not in use
• Configure basic logging
Restricting VTY connections
• Remote management sessions can be enhanced
using optional messages:
– Message of the day
• Display a banner to users as they enter a network device
– Router(config)# banner motd ^C message ^C
– Vacant message
• displayed when the user session is disconnected.
Router(config)#vacant-message ^C message ^C
– Refuse message
• displayed when the authentication fails at login
Router(config)#refuse-message ^C message ^C
• Applied to console, aux and vty lines
• Not displayed for users connecting over SSH
Best practices: Secure switch protocols
• CDP
– If CDP is not required, disable CDP globally on the device
– If CDP is required, disable CDP on a per-interface basis on
ports connected to untrusted networks
• Secure the Spanning Tree protocol
– Identify the intended root bridge in the design and assign
an adequate bridge priority
– Activate BPDU guard feature if available
Best practices: Mitigating Compromises
Launched through a switch
• Proactively configure unused ports
– Shutdown on unused ports
– All unused ports in a specific unused VLAN
– Configure unused ports as access ports
• Considerations for trunk links
– Disable automatic negotiation of trunking, and manually enable it on links
that will require it
– Ensure that trunks use a native VLAN dedicated only to trunk links
• Minimize physical port access
• Establish standard access port configuration for
both unused and used ports
• switchport host
– Macro that disables Etherchannel, disables trunking, and enables STP
Portfast
Semester3v5 - Chapter 8
Cisco Networking Academy
Minimizing Service Loss
and Data Theft in a
Campus Network
The End