Thursday, 23 May 2013

Cisco IOS Switch Security - Part III

  • Port Security
You can use port security with dynamically learned and static MAC addresses to restrict a port's ingress traffic by limiting the MAC addresses that are allowed to send traffic into the port. When you assign secure MAC addresses to a secure port, the port does not forward ingress traffic that has source addresses outside the group of defined addresses. If you limit the number of secure MAC addresses to one and assign a single secure MAC address, the device attached to that port has the full bandwidth of the port.

A security violation occurs in either of these situations:
  • When the maximum number of secure MAC addresses is reached on a secure port and the source MAC address of the ingress traffic is different from any of the identified secure MAC addresses, port security applies the configured violation mode.
  • If traffic with a secure MAC address that is configured or learned on one secure port attempts to access another secure port in the same VLAN, applies the configured violation mode.
Port security includes the secure addresses in the address table in one of these ways:
  • You can statically configure all secure MAC addresses by using the switchport port-security mac-address mac_address interface configuration command.
  • You can allow the port to dynamically configure secure MAC addresses with the MAC addresses of connected devices.
  • You can statically configure a number of addresses and allow the rest to be dynamically configured.
If the port has a link-down condition, all dynamically learned addresses are removed.

  • Sticky MAC Addresses
Port security with sticky MAC addresses provides many of the same benefits as port security with static MAC addresses, but sticky MAC addresses can be learned dynamically. Port security with sticky MAC addresses retains dynamically learned MAC addresses during a link-down condition.

If you enter a write memory or copy running-config startup-config command, then port security with sticky MAC addresses saves dynamically learned MAC addresses in the startup-config file and the port does not have to learn addresses from ingress traffic after bootup or a restart.

Configuration:
  • Enables port security on the port.
Router(config-if)# switchport port-security 
  • (Optional) Sets the violation mode and the action to be taken when a security violation is detected.
Router(config-if)# switchport port-security violation {protect | restrict | shutdown}
  • Sets the maximum number of secure MAC addresses for the port (default is 1)
Router(config-if)# switchport port-security maximum number_of_addresses vlan {vlan_ID | vlan_range}
  • Enables port security with sticky MAC addresses on a port.
Router(config-if)# switchport port-security mac-address sticky
  • Configures a static MAC address as secure on the port.
Router(config-if)# switchport port-security mac-address [sticky] mac_address [vlan vlan_ID]
Note Per-VLAN configuration is supported only on trunks.
  • Configures the secure MAC address aging type on the port (default is absolute).
Router(config-if)# switchport port-security aging type {absolute | inactivity}
  • Configures the secure MAC address aging time on the port. The aging_time range is 1 to 1440 minutes (default is 0).
Router(config-if)# switchport port-security aging time aging_time
Verification:
 Router# show port-security
Secure Port      MaxSecureAddr  CurrentAddr  SecurityViolation  Security
Action
                    (Count)        (Count)      (Count)
----------------------------------------------------------------------------
     Fa5/1           11            11            0            Shutdown
     Fa5/5           15            5             0            Restrict
     Fa5/11          5             4             0            Protect
----------------------------------------------------------------------------
Total Addresses in System: 21
Max Addresses limit in System: 128

Router# show port-security interface fastethernet 5/1
Port Security: Enabled
Port status: SecureUp
Violation mode: Shutdown
Maximum MAC Addresses: 11
Total MAC Addresses: 11
Configured MAC Addresses: 3
Aging time: 20 mins
Aging type: Inactivity
SecureStatic address aging: Enabled
Security Violation count: 0

Router# show port-security address
          Secure Mac Address Table
-------------------------------------------------------------------
Vlan    Mac Address       Type                Ports   Remaining Age
                                                         (mins)
----    -----------       ----                -----   -------------
   1    0001.0001.0001    SecureDynamic       Fa5/1      15 (I)
   1    0001.0001.0002    SecureDynamic       Fa5/1      15 (I)
   1    0001.0001.1111    SecureConfigured    Fa5/1      16 (I)
   1    0001.0001.1112    SecureConfigured    Fa5/1      -
   1    0001.0001.1113    SecureConfigured    Fa5/1      -
   1    0005.0005.0001    SecureConfigured    Fa5/5      23
   1    0005.0005.0002    SecureConfigured    Fa5/5      23
   1    0005.0005.0003    SecureConfigured    Fa5/5      23
   1    0011.0011.0001    SecureConfigured    Fa5/11     25 (I)
   1    0011.0011.0002    SecureConfigured    Fa5/11     25 (I)
-------------------------------------------------------------------
Total Addresses in System: 10
Max Addresses limit in System: 128
  • STP BPDU Guard
STP configures meshed topology into a loop-free, tree-like topology. When the link on a bridge port goes up, STP calculation occurs on that port. The result of the calculation is the transition of the port into forwarding or blocking state. The result depends on the position of the port in the network and the STP parameters. This calculation and transition period usually takes about 30 to 50 seconds. At that time, no user data pass via the port. Some user applications can time out during the period.

In order to allow immediate transition of the port into forwarding state, enable the STP PortFast feature. PortFast immediately transitions the port into STP forwarding mode upon linkup. 
This could be desired for ports where are connected end user devices, servers or access-points.
Using BPDU Guard, when an unexpected BPDU is detected (an end-user plug in a switch in one PortFast interface) the port will shutdown and enter a err-disable state.

Configuration:
CatSwitch-IOS(config)# spanning-tree portfast bpduguard 
When STP BPDU guard disables the port, the port remains in the disabled state unless the port is enabled manually. You can configure a port to re-enable itself automatically from the errdisable state. Issue these commands, which set the errdisable-timeout interval and enable the timeout feature:
CatSwitch-IOS(config)# errdisable recovery cause bpduguard
CatSwitch-IOS(config)# errdisable recovery interval 400
Note: The default timeout interval is 300 seconds and, by default, the timeout feature is disabled.

Best Practices: enable BPDU Guard only on access ports (access ports lead to end user devices) so that any end user devices on these ports that have BPDU Guard enabled are not able to influence the Spanning-tree topology.
  • STP BPDU Filter
BPDUfilter on the other hand filters BPDUs in both directions, which effectively disables STP on the port. Bpdu filter will prevent inbound and outbound bpdu.Enabling BPDU filtering on an interface is the same as disabling spanning tree on it and can result in spanning-tree loops.
If a bpdu is received on a PortFast interface(configured with BPDU Filter) then PortFast state will be removed.
 BPDU Filter can be use on the demarcation point between two layer 2 networks owned by to separated ISPs.

Configuration:
BPDU filtering can be enabled on a per-interface basis or globally.  The commands are:
  • globally - applies to all ports configured as "portfast"
spanning-tree portfast bpdu filter default
  • per-interface
spanning-tree portfast bpdufilter enable 
  • STP Root Guard
The forwarding topology of the switched network is calculated using STP. The calculation is based on the root bridge position, among other parameters. Any switch can be the root bridge in a network. But a more optimal forwarding topology places the root bridge at a specific predetermined location. With the standard STP, any bridge in the network with a lower bridge ID takes the role of the root bridge. The administrator cannot enforce the position of the root bridge.

The root guard ensures that the port on which root guard is enabled is the designated port. Normally, root bridge ports are all designated ports, unless two or more ports of the root bridge are connected together. If the bridge receives superior STP Bridge Protocol Data Units (BPDUs) on a root guard-enabled port, root guard moves this port to a root-inconsistent STP state. This root-inconsistent state is effectively equal to a listening state. No traffic is forwarded across this port. In this way, the root guard enforces the position of the root bridge.
You must enable root guard on all ports where the root bridge should not appear. In a way, you can configure a perimeter around the part of the network where the STP root is able to be located

Configuration:
Cat-IOS#(config)# interface fastethernet 3/1
Cat-IOS#(config-if)# spanning-tree guard root

Wednesday, 15 May 2013

Cisco IOS Switch Security - Part II

  • Traffic Storm Control
A traffic storm occurs when packets flood the LAN, creating excessive traffic and degrading network performance. The traffic storm control feature prevents LAN ports from being disrupted by a broadcast, multicast, or unicast traffic storm on physical interfaces.  

Traffic storm control (also called traffic suppression) monitors incoming traffic levels over a 1-second traffic storm control interval, and during the interval it compares the traffic level with the traffic storm control level that you configure. The traffic storm control level is a percentage of the total available bandwidth of the port. Each port has a single traffic storm control level that is used for all types of traffic (broadcast, multicast, and unicast).

Traffic storm control monitors the level of each traffic type for which you enable traffic storm control in 1-second traffic storm control intervals. 

 When the ingress traffic for which traffic storm control is enabled reaches the traffic storm control level that is configured on the port, traffic storm control drops the traffic until the traffic storm control interval ends.

Optional actions:
  • Shutdown—When a traffic storm occurs, traffic storm control puts the port into the error-disabled state. To reenable ports, use the error-disable detection and recovery feature or the shutdown and no shutdown commands.
  • Trap—When a traffic storm occurs, traffic storm control generates an SNMP trap.

 Example:
 SW(config-if)# storm-control broadcast level level[.level]
 SW(config-if)# storm-control multicast level level[.level] 
 SW(config-if)# storm-control unicast level level[.level]
Specify the level as a percentage of the total interface bandwidth:

The level can be from 0 to 100.

The optional fraction of a level can be from 0 to 99.

100 percent means no traffic storm control.

0.0 percent suppresses all traffic. 

Verification:
SW# show interfaces gig4/10 counters storm-control
Port      UcastSupp %     McastSupp %     BcastSupp %  TotalSuppDiscards
Gi4/10      00.70           00.70           00.70              0

  • DHCP Snooping
DHCP snooping is a security feature that acts like a firewall between untrusted hosts and trusted DHCP servers. The DHCP snooping feature performs the following activities:

Validates DHCP messages received from untrusted sources and filters out invalid messages.

Rate-limits DHCP traffic from trusted and untrusted sources.

Builds and maintains the DHCP snooping binding database, which contains information about untrusted hosts with leased IP addresses.

Utilizes the DHCP snooping binding database to validate subsequent requests from untrusted hosts. 

  The DHCP snooping feature determines whether traffic sources are trusted or untrusted. An untrusted source may initiate traffic attacks or other hostile actions. To prevent such attacks, the DHCP snooping feature filters messages and rate-limits traffic from untrusted sources. 
  
Trusted and Untrusted Sources
 In an enterprise network, devices under your administrative control are trusted sources. These devices include the switches, routers, and servers in your network. Any device beyond the firewall or outside your network is an untrusted source. Host ports and unknown DHCP servers are generally treated as untrusted sources. 

 In the switch, you indicate that a source is trusted by configuring the trust state of its connecting interface.

 The default trust state of all interfaces is untrusted. You must configure DHCP server interfaces as trusted. You can also configure other interfaces as trusted if they connect to devices (such as switches or routers) inside your network. You usually do not configure host port interfaces as trusted. 

DHCP Snooping Binding Database 
 The DHCP snooping feature dynamically builds and maintains the database using information extracted from intercepted DHCP messages. The database contains an entry for each untrusted host with a leased IP address if the host is associated with a VLAN that has DHCP snooping enabled. The database does not contain entries for hosts connected through trusted interfaces. 

 Each entry in the DHCP snooping binding database includes the MAC address of the host, the leased IP address, the lease time, the binding type, and the VLAN number and interface information associated with the host. 
  
Packet Validation
The switch validates DHCP packets received on the untrusted interfaces of VLANs with DHCP snooping enabled. The switch forwards the DHCP packet unless any of the following conditions occur (in which case the packet is dropped):
  • The switch receives a packet (such as a DHCPOFFER, DHCPACK, DHCPNAK, or DHCPLEASEQUERY packet) from a DHCP server outside the network or firewall.
  • The switch receives a packet on an untrusted interface, and the source MAC address and the DHCP client hardware address do not match. This check is performed only if the DHCP snooping MAC address verification option is turned on.
  • The switch receives a DHCPRELEASE or DHCPDECLINE message from an untrusted host with an entry in the DHCP snooping binding table, and the interface information in the binding table does not match the interface on which the message was received.
  • The switch receives a DHCP packet that includes a relay agent IP address that is not 0.0.0.0. 
 DHCP Snooping Database Agent

 To retain the bindings across reloads, you must use the DHCP snooping database agent. Without this agent, the bindings established by DHCP snooping are lost upon reload, and connectivity is lost as well.

The database agent stores the bindings in a file at a configured location. Upon reload, the switch reads the file to build the database for the bindings. The switch keeps the file current by writing to the file as the database changes. 

DHCP Snooping Host Tracking 
  The DHCP snooping host tracking feature implements a cache to learn VLAN and MAC addresses to port the mapping of clients from snooped DHCP request packets and uses this information to forward snooped DHCP reply packets. 
 This feature improves DHCP snooping packet processing performance for DHCP reply packets by not needing to lookup the hardware VLAN and MAC address table in order to determine the port on which to send the DHCP reply packets. This feature is useful in deployments where it is not possible to use the DHCP snooping information option along with DHCP (for example, when the server does not support DHCP information option). If DHCP is configured it takes hugher precedence than the DHCP snooping host tracking feature in determining the port on which to forward reply packets.

DHCP Snooping Option-82 Data Insertion 
 The DHCP Information option (Option 82) is commonly used in metro or large enterprise deployments to provide additional information on “physical attachment” of the client. Option 82 is supposed to be used in distributed DHCP server/relay environment, where relays 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. The choice of the pool is made based on the “giaddr” field or the incoming interface, if the “giaddr” is missing or zero . Option 82 serves as refinement to the request, allowing the DHCP server to select a “sub-range” in the pool. (Notice that by default Cisco IOS devices reject packets with zero “giaddr” and by default Cisco Catalyst switches use “giaddr” of zero when configured for DHCP snooping!)

Spurious DHCP server
 A DHCP server that is on your network without your knowledge on an untrusted port is called a spurious DHCP server. A spurious DHCP server is any piece of equipment that is loaded with DHCP server enabled. Some examples are desktop systems and laptop systems that are loaded with DHCP server enabled, or wireless access points honoring DHCP requests on the wired side of your network. If spurious DHCP servers remain undetected, you will have difficulties troubleshooting a network outage.

Example: 
  • Configuring the DHCP Trust State on Layer 2 LAN Interfaces
SW(config)# interface FastEthernet 0/0
SW(config-if)# ip dhcp snooping trust

SW# show ip dhcp snooping | begin pps

Interface                    Trusted     Rate limit (pps)

------------------------     -------     ----------------

FastEthernet0/0             yes         unlimited
  • Enabling DHCP Snooping Globally
SW(config)# ip dhcp snooping

SW# show ip dhcp snooping | include Switch
Switch DHCP snooping is enabled
  • Enabling DHCP Snooping on VLANs
SW(config)# ip dhcp snooping vlan 10-12,15

SW# show ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
10-12,15
DHCP snooping is operational on following VLANs:
none
  • Enabling DHCP Option-82 Data Insertion
Router(config)# no ip dhcp snooping information op
  • Enabling DHCP Snooping Host Tracking
SW(config)# no ip dhcp snooping information option
SW(config)# ip dhcp snooping track host
  •   Enable Database Agent
The following example shows how to configure the DHCP snooping database agent to store the bindings at a given location and to view the configuration and operating state:

SW(config)# ip dhcp snooping database tftp://10.1.1.1/directory/file

To manually read the entries from a TFTP file, perform this task:

SW# renew ip dhcp snoop data tftp://10.1.1.1/directory/file 
Loading directory/file from 10.1.1.1 (via GigabitEthernet1/1): !
[OK - 457 bytes]
Database downloaded successfully.
Router#
00:01:29: %DHCP_SNOOPING-6-AGENT_OPERATION_SUCCEEDED: DHCP snooping database Read
succeeded.
  • Configuring Spurious DHCP Server Detection
SW# configure terminal 
SW(config)# ip dhcp snooping detect spurious vlan 20-25
SW(config)# ip dhcp snooping detect spurious interval 50
SW# do show ip dhcp snooping detect spurious
Spurious DHCP server detection is enabled.
Detection VLAN list : 20-25
Detection interval : 50 minutes
  • Enabling DHCP Snooping MAC Address Verification

 With DHCP snooping MAC address verification enabled, DHCP snooping verifies that the source MAC address and the client hardware address match in DHCP packets that are received on untrusted ports.

SW(config)# ip dhcp snooping verify mac-address
SW#show ip dhcp snooping | include hwaddr
Verification of hwaddr field is enabled
  • Configuring DHCP Snooping Rate Limiting on Layer 2 LAN Interfaces
SW(config)# interface FastEthernet 0/0
SW(config-if)# ip dhcp snooping limit rate 100
SW(config-if)# do show ip dhcp snooping | begin pps
Interface                    Trusted     Rate limit (pps)

------------------------     -------     ----------------

FastEthernet0/0             no          100

  • IP Source Guard
IP Source Guard is a security feature that restricts IP traffic on untrusted Layer 2 ports by filtering traffic based on the DHCP snooping binding database or manually configured IP source bindings. This feature helps prevent IP spoofing attacks when a host tries to spoof and use the IP address of another host. Any IP traffic coming into the interface with a source IP address other than that assigned (via DHCP or static configuration) will be filtered out on the untrusted Layer 2 ports.
The IP Source Guard feature is enabled in combination with the DHCP snooping feature on untrusted Layer 2 interfaces. It builds and maintains an IP source binding table that is learned by DHCP snooping or manually configured (static IP source bindings). An entry in the IP source binding table contains the IP address and the associated MAC and VLAN numbers. The IP Source Guard is supported on Layer 2 ports only, including access and trunk ports.


Example:
Switch(config)#interface GigabitEthernet1/0/1
Switch(config-if)#ip verify source port-security
 Switch(config)# ip source binding 0011.0011.0011 vlan 5 10.1.1.11 interface GigabitEthernet1/0/2

  • Dynamic ARP Inspection
Address Resolution Protocol (ARP) provides IP-to-MAC (32-bit IP address into a 48-bit Ethernet address) resolution. ARP operates at Layer 2 (the data-link layer) of the OSI model. ARP provides the translation mapping the IP address to the MAC address of the destination host using a lookup table (also known as the ARP cache).
Several types of attacks can be launched against a host or devices connected to Layer 2 networks by "poisoning" the ARP caches. A malicious user could intercept traffic intended for other hosts on the LAN segment and poison the ARP caches of connected systems by broadcasting forged ARP responses. Several known ARP-based attacks can have a devastating impact on data privacy, confidentiality, and sensitive information. To block such attacks, the Layer 2 switch must have a mechanism to validate and ensure that only valid ARP requests and responses are forwarded.
Dynamic ARP inspection is a security feature that validates ARP packets in a network. Dynamic ARP inspection determines the validity of packets by performing an IP-to-MAC address binding inspection stored in a trusted database, (the DHCP snooping binding database) before forwarding the packet to the appropriate destination. Dynamic ARP inspection will drop all ARP packets with invalid IP-to-MAC address bindings that fail the inspection. The DHCP snooping binding database is built when the DHCP snooping feature is enabled on the VLANs and on the switch.

 Dynamic ARP inspection inspects inbound packets only; it does not check outbound packets.

Example:
  • DAI in a DHCP Environment
Switch(config)# interface GigabitEthernet1/0/1
Switch(config-if)# ip arp inspection trust
Switch(config)# ip arp inspection vlan 5-10
  •  DAI in a Non-DHCP Environment
Switch(config)# arp access-list arpacl
Switch(config-arp-acl)# permit ip host 10.1.1.11 mac host 0011.0011.0011
Switch(config-arp-acl)# exit
Switch(config)# ip arp inspection filter arpacl vlan 5
Switch(config)# interface GigabitEthernet1/0/2
Switch(config-if)# no ip arp inspection trust

    Friday, 10 May 2013

    Cisco IOS Switch Security - Part I - PACL and VACL

    Port ACLs (PACLs) and VLAN ACLs (VACLs)

    Access control lists (ACLs) provide the ability to filter ingress and egress traffic based on conditions specified in the ACL.
    • Cisco IOS ACLs are applied to Layer 3 interfaces. They filter traffic routed between VLANs.
    • VACLs control access to the VLAN of all packets (bridged and routed). Packets can either enter the VLAN through a Layer 2 port or through a Layer 3 port after being routed. You can also use VACLs to filter traffic between devices in the same VLAN.
    • Port ACLs perform access control on all traffic entering the specified Layer 2 port.
    PACLs and VACLs can provide access control based on the Layer 3 addresses (for IP protocols) or Layer 2 MAC addresses (for non-IP protocols).
    You can apply only one IP access list and one MAC access list to a Layer 2 interface

    • Port ACL
     The port ACL (PACL) feature provides the ability to perform access control on specific Layer 2 ports.
    A Layer 2 port is a physical LAN or trunk port that belongs to a VLAN. Port ACLs are applied only on the ingress traffic. The port ACL feature is supported only in hardware (port ACLs are not applied to any packets routed in software).
    When you create a port ACL, an entry is created in the ACL TCAM. You can use the show tcam counts command to see how much TCAM space is available.
    The PACL feature does not affect Layer 2 control packets received on the port.
    You can use the access-group mode command to change the way that
    PACLs interact with other ACLs.
    PACLs use the following modes:
    • Prefer port mode — If a PACL is configured on a Layer 2 interface, the PACL takes effect and overwrites the effect of other ACL
    • Merge mode —In this mode, the PACL, VACL, and Cisco IOS ACLs are merged in the ingress direction.
    • VLAN ACL
    VLAN ACLs (VACLs) can provide access control for all packets that are bridged within a VLAN or that are routed into or out of a VLAN or a WAN interface
    for VACL capture. Unlike Cisco IOS ACLs that are applied on routed packets only, VACLs apply to all packets and can be applied to any VLAN or WAN
    interface. VACLs are processed in the ACL TCAM hard ware. VACLs ignore any Cisco IOS ACL fields that are not supported in hardware. You can configure VACLs for IP and MAC-layer traffic. VACLs applied to WAN interfaces support only IP traffic for VACL capture.
    If a VACL is configured for a packet type, and a packet of that type does not match the VACL, the default action is to deny the packet

    Consider the following guidelines when configuring PACLs:

    • There can be at most one IP access list and one MAC access list applied to the same Layer 2 interface per direction.
    • PACLs are not applied to IPv6, MPLS, or ARP messages.
    • An IP access list filters only IPv4 packets. ForIP access lists, you can define a standard, extended,or named access-list.
    • A MAC access list filters ingress packets that are of an unsupported type (not IP, IPv6, ARP, or MPLS packets) based on the fields of the Ethernet datagram. You can define only named MAC access lists.
    • The number of ACLs and ACEs that can be configured as part of a PACL are bounded by the hardware resources on the switch.Those hardware resources are shared by various ACL features (such as VACLs) that are configured on the system. If there are insufficient hardware resources to program a PACL in hardware, the PACL is not applied.
    • PACL does not support the access-list log and reflect/evaluate keywords. These keywords are ignored if you add them to the access list for a PACL.
    • The access group mode can change the way PACLs interact with other ACLs. To maintain consistent behavior across Cisco platforms, use the default access group mode (merge mode)
    Example:

    Switch(config)#ip access-list extended simple-ip-acl
    Switch(config-ext-nacl)#permit tcp any any
    Switch(config-ext-nacl)#end

    Switch(config)#mac access-list extended simple-mac-acl
    Switch(config-ext-macl)#permit host 000.000.011 any
    Switch(config-ext-macl)#end

    Switch(config)# interface
    Switch(config-if)#ip access-group simple-ip-acl in[out]
    Switch(config-if)#mac access-group simple-mac-acl in[out]
    This example shows how to configure an interface to use prefer port mode:

    Switch(config)#interface gigabitEthernet 0/1
    Switch(config-if)#access-group mode prefer port

    This example shows how to configure an interface to use merge mode:

    Switch(config)#interface gigabitEthernet 0/1
    Switch(config-if)#access-group mode merge
    Consider the following guidelines when configuring VACLs:

    • VACLs use standard and extended Cisco IOS IP and MAC layer-named ACLs and VLAN access maps.
    • VLAN access maps can be applied to VLANs or to WAN interfaces for VACL capture. VACLs attached to WAN interfaces support only standard and extended Cisco IOS IP ACLs.
    • Each VLAN access map can consist of one or more map sequences; each sequence has a match clause and an action clause. The match clause specifies IP or MAC ACLs for traffic filtering and the action clause specifies the action to be taken when a match occurs. When a flow matches a permit ACL entry, the associated action is taken and the flow is not checked against the remaining sequences. When a flow matches a deny ACL entry,it will be checked against the next ACL in the same sequence or the next sequence. If a flow does not match any ACL entry and at least one ACL is configured for that packet type, the packet is denied.
    • To apply access control to both bridged and routed traffic, you can use VACLs alone or a combination of VACLs and ACLs. You can define ACLs on the VLAN interfaces to apply access control to both the ingress and egress routed traffic. You can define a VACL to apply access control to the bridged traffic.
    • The following caveats apply to ACLs when used with VACLs:
      • Packets that require logging on the outbound ACLs are not logged if they are denied by a VACL.
      • VACLs are applied on packets before NAT translation. If the translated flow is not subject to access control, the flow might be subject to access control after the translation because of theVACL configuration.
    • The action clause in a VACL can be forward, drop, capture, or redirect. Traffic can also be logged. VACLs applied to WAN interfaces do not support the redirect or log actions. 
    • VACLs cannot be applied to IGMP, MLD, or PIM traffic.
    Example:
    vlan access-map map-name [sequence-number]
    match {ip|ipv6} address ip-access-list
    match mac address mac-access-list
    action {drop|forward|redirect}

    vlan filter vlan-acl-map-name vlan-list [vlan range]

    Sunday, 5 May 2013

    Role-Based Access Control

    The Role-Based CLI Access feature allows the network administrator to define "views" which are a set of operational commands and configuration capabilities that provide selective or partial access to Cisco IOS EXEC and configuration (config) mode commands. Views restrict user access to Cisco IOS command-line interface (CLI) and configuration information.

    Root View
    When a system is in "root view," it has all of the access privileges as a user who has level 15 privileges. If the administrator wishes to configure any view to the system (such as a CLI view, a superview, or a lawful intercept view), the system must be in root view.
    The difference between a user who has level 15 privileges and a root view user is that a root view user can configure a new view and add or remove commands from the view. Also, when you are in a CLI view, you have access only to the commands that have been added to that view by the root view user.

    Superviews
    A superview consists of one or more CLI views, which allow users to define what commands are accepted and what configuration information is visible. Superviews allow a network administrator to easily assign all users within configured CLI views to a superview instead of having to assign multiple CLI views to a group of users.

    Superviews contain these characteristics:
    •A CLI view can be shared among multiple superviews.
    •Commands cannot be configured for a superview; that is, you must add commands to the CLI view and add that CLI view to the superview.
    •Users who are logged into a superview can access all of the commands that are configured for any of the CLI views that are part of the superview.
    •Each superview has a password that is used to switch between superviews or from a CLI view to a superview.
    •If a superview is deleted, all CLI views associated with that superview will not be deleted too.

    Authentication via a New AAA Attribute

    View authentication is performed by an external authentication, authorization, and accounting (AAA) server via the new attribute "cli-view-name."
    AAA authentication associates only one view name to a particular user; that is, only one view name can be configured for a user in an authentication server.
    • Configuring a CLI View (required)
      • aaa new model must be enabled
    aaa new-model 
      • Enables root view
    enable view
      • Creates a view and enters view configuration mode
    parser view view-name
      • Configure the password for the view
    secret 5 encrypted-password
      • Adds exec or config commands to a view
    commands parser-mode {include | include-exclusive | exclude} [all] [interface interface-name | command]
        • include—Adds a command or an interface to the view and allows the same command or interface to be added to an additional view.
        • include-exclusive—Adds a command or an interface to the view and excludes the same command or interface from being added to all other views.
        • exclude—Excludes a command or an interface from the view; that is, customers cannot access a command or an interface.
        • all—A "wildcard" that allows every command in a specified configuration mode that begins with the same keyword or every subinterface for a specified interface to be part of the view.
        • interface interface-name—Interface that is added to the view.
        • command—Command that is added to the view.
    • Configuring a Superview (optional)
      • Enables root view. 
    enable view
      • Creates a superview and enters view configuration mode.
     parser view superview-name superview
      •  Associates a CLI view or superview with a password.
    secret 5 encrypted-password
      • Adds a normal CLI view to a superview
    view view-name

    Example:
     parser view CLI_VIEW_1
     secret 5 $1$3R6N$Z3dleEBoQkgtfrladEprt.
     commands interface include all ip
     commands configure include interface
     commands exec include configure terminal
     commands exec include configure
     commands exec include show interfaces
     commands exec include show running-config
     commands exec include show
     commands configure include interface FastEthernet1/0

    parser view CLI_VIEW_2
     secret 5 $1$B1y2$KmkRM.QupXXPcCfoyNc9q/
     commands configure include interface
     commands exec include configure terminal
     commands exec include configure
     commands configure include interface FastEthernet1/1

    parser view SUPERVIEW superview
     secret 5 $1$njZX$7xJL6nSgKfLtWNAfAOw8W.
     view CLI_VIEW_1
     view CLI_VIEW_2
    • Monitoring Views and View Users (optional)
    R1#show parser view
    Current view is 'root'
    R1#show parser view all
    Views/SuperViews Present in System:
     CLI_VIEW_1
     CLI_VIEW_2
     SUPERVIEW *
    -------(*) represent superview-------

     R1#show parser dump ?  

    R1#enable view SUPERUSER
    Password:
    R1#show parser view
    Current view is 'SUPERVIEW'
    R1#?
    Exec commands:
      configure  Enter configuration mode
      enable     Turn on privileged commands
      exit       Exit from the EXEC
      show       Show running system information
    R1#show ?
      bootflash:      display information about bootflash: file system
      disk0:          display information about disk0: file system
      disk1:          display information about disk1: file system
      flash:          display information about flash: file system
      interfaces      Interface status and configuration
      parser          Show parser commands
      running-config  Current operating configuration
      slot0:          display information about slot0: file system
      slot1:          display information about slot1: file system
    R1#conf t
    Enter configuration commands, one per line.  End with CNTL/Z.
    R1(config)#?
    Configure commands:
      do         To run exec commands in config mode
      exit       Exit from configure mode
      interface  Select an interface to configure

    RMON Event and Alarm Notification

    RMON is a standard monitoring specification that enables various network monitors and console systems to exchange network-monitoring data.

    The RMON specification defines a set of statistics and functions that can be exchanged between RMON-compliant console managers and network probes. RMON provides network administrators with comprehensive network-fault diagnosis, planning, and performance-tuning information.

    The RMON feature identifies activity on individual nodes and allows you to monitor all nodes and their interaction on a LAN segment. Used in conjunction with the SNMP agent in a router, RMON allows you to view both traffic that flows through the router and segment traffic that is not necessarily destined for the router. Combining RMON alarms and events (classes of messages that indicate traffic violations and various unusual occurrences over a network) with existing MIBs allows you to choose where proactive monitoring will occur.

    RMON delivers information in RMON groups of monitoring elements, each providing specific sets of data to meet common network-monitoring requirements. Each group is optional so that you do not need to support all the groups within the Management Information Base (MIB). Some RMON groups require support of other RMON groups to function properly.

    RMON Groups
    • Statistics - Contains statistics measured by the probe for each monitored interface on this device.
    • History - Records periodic statistical samples from a network and stores them for later retrieval.
    • Alarm - Periodically takes statistical samples from variables in the probe and compares them with previously configured thresholds. If the monitored variable crosses a threshold, an event is generated. Requires the implementation of the event group. 
    • Host - Contains statistics associated with each host discovered on the network. 
    • HostTopN - Prepares tables that describe the hosts that top a list ordered by one of their base statistics over an interval specified by the management station. Thus, these statistics are rate-based.
    • Matrix - Stores statistics for conversations between sets of two addresses. As the device detects a new conversation, it creates a new entry in its table.
    • Filters - Enables packets to be matched by a filter equation. These matched packets form a data stream that might be captured or that might generate events.
    • Packet - Capture Enables packets to be captured after they flow through a channel.
    • Events - Controls the generation and notification of events from this device.
    Thresholds allow you to minimize the number of notifications sent on the network. The RMON MIB defines two traps, the risingAlarm trap which is the rising-threshold value and fallingAlarm trap which is the falling-threshold value. Alarms are triggered when a problem exceeds a set rising-threshold value. No alarm notifications are sent until the agent recovers, as defined by the falling-threshold value. This means that notifications are not sent each time a minor failure or recovery occurs.

    Configuring RMON Event and Alarm Notifications
    rmon event eventIndex [log] [trap community] [description string] [owner string]

    • eventIndex— Event number (1–65535)
    • log—(Optional) Generate an RMON log when the event fires.
    • trap community —(Optional) Generate an SNMP trap when the event fires, for the specified SNMP community string.
    • description string —(Optional) Specify a WORD or a description of the event.
    • owner string  —(Optional) Specify an owner for the event.

    rmon alarm alarmIndex alarmVariable alarmInterval {delta | absolute} rising-threshold alarmRisingThreshold [event-number] falling-threshold alarmFallingThreshold [event-number] [owner string]
    •  alarmIndex—Alarm number (1–65535)
    • alarmVariable—MIB object to monitor (WORD)
    • alarmInterval—Sample interval (1–4294967295
    • absolute—Test each sample directly.
    • delta—Test delta between samples.
    • alarmRisingThreshold—Rising threshold value (-2147483648–2147483647)
    • event-number —(optional) Event to fire when the rising threshold is crossed (1–65535)
    • alarmFallingThreshold—Falling threshold value (-2147483648–2147483647)
    • event-number —(optional) Event to fire when the falling threshold is crossed (1–65535)
    • owner string —(Optional) Specify an owner for the alarm (WORD).
    An absolute sampling threshold is used for variables that increase or decrease over time, and have an upper or lower limit for when a log should be generated (ex: CPU utilization, memory utilization).
    A delta sampling threshold is used for variables that either constantly increase (most common) or constantly decrease (ex: interface errors, input packets).

    Scenario:
    rmon event 1 log description "Traffic exced 500 ppm" owner TEST_RMON
    rmon event 2 log description "Traffic less than 200 ppm" owner TEST_RMON
    rmon alarm 1 ifInUcastPkts.2 60 delta rising-threshold 500 1 falling-threshold 200 2 owner TEST_RMON
    To find out the ifIndex for interface that you want to monitor use next command
    R1#show snmp mib ifmib ifindex f1/0
    Interface = FastEthernet1/0, Ifindex = 2
    Verification: 
    R1#show rmon alarms
    Alarm 1 is active, owned by TEST_RMON
     Monitors ifInUcastPkts.2 every 60 second(s)
     Taking delta samples, last value was 667
     Rising threshold is 500, assigned to event 1
     Falling threshold is 200, assigned to event 2
     On startup enable rising or falling alarm
     *May  5 14:05:09.355: %RMON-5-RISINGTRAP: Rising trap is generated because the value of ifInUcastPkts.2 exceeded the rising-threshold value 500

    *May  5 14:06:09.359: %RMON-5-FALLINGTRAP: Falling trap is generated because the value of ifInUcastPkts.2 has fallen below the falling-threshold value 200
     R1#show rmon alarms              
    Alarm 1 is active, owned by TEST_RMON
     Monitors ifInUcastPkts.2 every 60 second(s)
     Taking delta samples, last value was 6
     Rising threshold is 500, assigned to event 1
     Falling threshold is 200, assigned to event 2
     On startup enable rising or falling alarm










    Saturday, 4 May 2013

    SNMPv3

    SNMPv3 extends the previous versions of SNMP by introducing a new security model that replaces the old community-based authentication system. SMNPv3 also provides for communication privacy by means of encryption. The new concepts for SNMPv3 are the user, group, and security level.


    To configure an SNMP v3 server, specify an SNMP group that maps SNMP users to SNMP views. Then, specify the IP address or port number for the remote SNMP agent of the device where the user resides.


    A group defines what access rights a set of users have. The access policy is defined by associating a read, write, or notify view with the group.

    The group also defines the security model (SNMP version) and the security level (authentication and/or encryption) for its users

    The security models are defined as SNMPv1, SNMPv2, SNMPv3, while the security levels are defined as noAuthNoPriv, AuthNoPriv, and AuthPriv. 

    SNMPv3 can implement any of the three above security levels. SNMPv1 and SNMPv2 only support noAuthNoPriv.

    In the case that SNMPv3 uses noAuthNoPriv, the username serves as a replacement for the community string.

    Configuration:

    • Define snmp group 

    snmp-server group [group-name {v1 | v2c | v3 [auth | noauth | priv]}] [read read-view] [write write-view] [notify notify-view] [access access-list] 

    • Define remote IP address (for NMS) - Optional

      snmp-server engineID {local engine-id | remote ip-address [udp-port udp-port-number] [vrf vrf-name] engine-id-string} 

    • Define SNMP user 
    snmp-server user user-name group-name [remote ip-address [udp-port port]] {v1 | v2c | v3 [encrypted] [auth {md5 | sha} auth-password]} [access access-list] 
    Configuration:

    • NoAuthNoPriv

     snmp-server user TEST_NOAUTH_NOPRIV NoAuthNoPriv v3
    snmp-server group NoAuthNoPriv v3 noauth 
      • verification

    R1#show snmp user
    ser name: TEST_NOAUTH_NOPRIV
    Engine ID: 800000090300CA002A260000
    storage-type: nonvolatile active
    Authentication Protocol: None
    Privacy Protocol: None
    Group-name: NoAuthNoPriv

    R1#show snmp group
    groupname: NoAuthNoPriv                     security model:v3 noauth
    readview : v1default                        writeview:      
    notifyview:      
    row status: active
    • AuthNoPriv
    snmp-server group AuthNoPriv v3 auth
    snmp-server user TEST_AUTH_NOPRIV AuthNoPriv v3 auth md5 CISCO_SNMP

      • verification 

    R1#show snmp user
    User name: TEST_AUTH_NOPRIV
    Engine ID: 800000090300CA002A260000
    storage-type: nonvolatile  active
    Authentication Protocol: MD5
    Privacy Protocol: None
    Group-name: AuthNoPriv

    R1#show snmp group
     groupname: AuthNoPriv                       security model:v3 auth
    readview : v1default                        writeview:      
    notifyview:      
    row status: active
    • AuthPriv
    snmp-server group AuthPriv v3 priv
    snmp-server user TEST_AUTH_PRIV AuthPriv v3 auth md5 CISCO_SNMP priv des CISCO_SNMPv3

      • verification 

    R1#show snmp user
    User name: TEST_AUTH_PRIV
    Engine ID: 800000090300CA002A260000
    storage-type: nonvolatile active
    Authentication Protocol: MD5
    Privacy Protocol: DES
    Group-name: AuthPriv

    R1#show snmp group
    groupname: AuthPriv                         security model:v3 priv
    readview : v1default                        writeview:      
    notifyview:      
    row status: active



    SNMPv2c


    Simple Network Management Protocol (SNMP), an application layer protocol, facilitates the exchange of management information among network devices, such as nodes and routers. It comprises part of the TCP/IP suite. System administrators can remotely manage network performance, find and solve network problems, and plan for network growth by using SNMP.

    Instead of defining a large set of commands, SNMP places all operations in a get-request, get-next-request, get-bulk-request, and set-request format. For example, an SNMP manager can get a value from an SNMP agent or store a value in that SNMP agent. The SNMP manager can comprise part of a network management system (NMS), and the SNMP agent can reside on a networking device such as a router.

    SNMP comprises of three parts—SNMP manager, SNMP agent, and MIBs. You can compile the Cisco MIB with your network management software.

    A network that uses SNMP requires three key components—managed devices, agents, and network management software (NMS).

    The NMS uses the Cisco MIB variables to set device variables and to poll devices on the internetwork for specific information. The results of a poll can get graphed and analyzed to help you troubleshoot internetwork problems, increase network performance, verify the configuration of devices, and monitor traffic loads.
    The SNMP agent gathers data from the MIB, which is the repository for information about device parameters and network data. The SNMP agent also can send traps (notifications) of certain events, to the SNMP manager.

    SNMP Basic Commands

    Managed devices get monitored and controlled by using four basic SNMP commands: read, write, trap, and traversal operations.

    •NMS uses the read command to monitor managed devices. The NMS examines different variables that are maintained by managed devices.

    •NMS uses the write command to control managed devices. The NMS changes the values of variables stored within managed devices.

    •Managed devices use the trap command to asynchronously report events to the NMS. When certain types of events occur, a managed device sends a trap to the NMS.

    •NMS uses traversal operations to determine which variables a managed device supports and to sequentially gather information in variable tables, such as a routing table.


    SNMP Versioning

    • SNMPv1 was the first version of SNMP which is defined in RFCs 1155 and 1157
    • SNMPv2c is a sub-version of SNMPv2.  It is defined in RFC 1901, RFC 1905, RFC 1906, RFC2578. One advantage over previous versions is the Inform command. Unlike Traps, which are simply received by a manager, Informs are positively acknowledged with a response message. If a manager does not reply to an Inform, the SNMP agent will resend the Inform.
    • SNMPv3 provides the following security features:
      • Authentication—Verifying that the request comes from a genuine source.
      • Privacy—Encrypting data.
      • Authorization—Verifying that the user allows the requested operation.
      • Access control—Verifying that the user has access to the objects that are requested.
    SNMPv3 prevents packets from being exposed on the network. Instead of using community strings like SNMP v1 and v2, SNMP v3 uses SNMP users.

    SNMP Community Strings and Users
    Although SNMP community strings provide no security, the strings authenticate access to MIB objects and function as embedded passwords. You configure SNMP community strings for SNMP v1 and v2c only.

    SNMP v3 does not use community strings. It uses SNMP users that serve the same purpose as community strings but provide security because encryption or authentication is configured.

    No default community string or user exists.

    SNMPv2c Configuration:
    • Enable SNMP aggent on the managed device
    snmp-server community string [view view-name] [ro | rw] [number]

      •  Community string acts like a password and permits access to the SNMP protocol.
      • [view-name] (Optional) Name of a previously defined view. The view defines the objects available to the community.
      • The read-write (rw) string allows the management station to make changes to the managed device, as opposed to the read-only (ro) string.
      • [number] (Optional) Integer from 1 to 99 that specifies an access list of IP addresses that are allowed to use the community string to gain access to the SNMP agent
    • Set interfaces index persist
    snmp-server ifindex persist
      • SNMP interface index (IfIndex) values are not being the same between reloads by default. You can change that using the above command.
    • Set system location string
    snmp-server location text  
      • text is a string that describes the system location information.
    • Set system contact 
    snmp-server contact text
      • text string that describes the system contact information.
    • Allow the NMS to reload the managed device
    snmp-server system-shutdown
      • Specifies the FTP server list with acceptable addresses to download/upload the router’s configuration when instructed via SNMP
      snmp-server tftp-server-list [number]

        • [number] Integer from 1 to 99 that specifies an access list 
      • Create or update a view entry
      snmp-server view view-name oid-tree {included | excluded}

        • view-name - Label for the view record that you are updating or creating. The name is used to reference the record.
        • oid-tree Object identifier of the ASN.1 subtree to be included or excluded from the view. To identify the subtree, specify a text string consisting of numbers, such as 1.3.6.2.4, or a word, such as system. Replace a single subidentifier with the asterisk (*) wildcard to specify a subtree family; for example 1.3.*.4.
      • SNMP traps and informs
      SNMP traps are part of SNMPv1 and SNMPv2 specifications. The traps which are to be sent can be configured either globally or on a per-host basis.

      snmp-server enable traps
       Additionally SNMPv2 allows sending notifications as informs, which differ from traps in that
      they require acknowledgement from the NMS. Informs are kept in router local queue until they are acknowledged or timeout has expired. Informs make SNMP reliable even though the transport protocol is still UDP.
      snmp-server host host-addr [traps | informs] community-string [udp-port port] [notification-type]
        • traps - (Optional) Sends SNMP traps to this host. This is the default.
        • informs - (Optional) Sends SNMP informs to this host.
        • community-string -  community string sent with the notification operation
        • udp-port - (Optional) UDP port of the host to use. The default is 162
        • notification-type - (Optional) type of notification to be sent to the host. If no type is specified, all notifications are sent. Example of notification-type : bgp, hdrp, syslog, snmp, etc.

      • show commands
      R1#show snmp
      Chassis: 4294967295
      Contact: John Doe
      Location: test lab
      0 SNMP packets input
          0 Bad SNMP version errors
          0 Unknown community name
          0 Illegal operation for community name supplied
          0 Encoding errors
          0 Number of requested variables
          0 Number of altered variables
          0 Get-request PDUs
          0 Get-next PDUs
          0 Set-request PDUs
          0 Input queue packet drops (Maximum queue size 1000)
      0 SNMP packets output
          0 Too big errors (Maximum packet size 1500)
          0 No such name errors
          0 Bad values errors
          0 General errors
          0 Response PDUs
          0 Trap PDUs
      SNMP logging: enabled
          Logging to 10.1.1.2.162, 0/10, 0 sent, 0 dropped.
      SNMP Manager-role output packets
          0 Get-request PDUs
          0 Get-next PDUs
          0 Get-bulk PDUs
          0 Set-request PDUs
          0 Inform-request PDUs
          0 Timeouts
          0 Drops
      SNMP Manager-role input packets
          0 Inform request PDUs
          0 Trap PDUs
          0 Response PDUs
          0 Responses with errors
      SNMP informs: enabled
          Informs in flight 0/25 (current/max)
          Logging to 10.1.1.2.162
              0 sent, 0 in-flight, 0 retries, 0 failed, 0 dropped

      R1#show snmp community
      Community name: ILMI
      Community Index: cisco0
      Community SecurityName: ILMI
      storage-type: read-only active

      Community name: TEST-RO
      Community Index: cisco1
      Community SecurityName: TEST-RO
      storage-type: nonvolatile active access-list: 10

      Community name: TEST-RW
      Community Index: cisco4
      Community SecurityName: TEST-RW
      storage-type: nonvolatile active

      R1#show snmp host    
      Notification host: 10.1.1.2 udp-port: 162 type: inform
      user: TEST-RW security model: v2c
      Notification host: 10.1.1.2 udp-port: 162 type: trap
      user: TEST-RO security model: v1
      • snmpwalk command