Access list syslog correlation

ACL syslog correlation is a Cisco IOS feature which provides the ability to identify which access list entry (ACE) was responsible for a permit or deny action appearing in syslog.
Consider the following access list applied to filter externally-sourced traffic destined for the internal network:

Router# show ip access-lists
Extended IP access list EXTERNAL->INTERNAL
 10 permit icmp any any echo-reply
 20 permit udp any eq domain any
 30 permit tcp any any established
 40 permit tcp any host 172.16.0.202 eq www
 50 deny tcp any any eq 22 log
 999 deny ip any any

Lines 10 through 40 allow miscellaneous traffic types in, and line 50 explicitly denies inbound traffic destined to TCP/22 for the purpose of logging. Line 60 defines an explicit "deny any"; this isn't required, but included here for clarity.
When an inbound packet is matched and discard by rule 50, the following syslog message is generated:

%SEC-6-IPACCESSLOGP: list EXTERNAL->INTERNAL denied tcp 10.0.0.2(57289) ->
 10.0.0.1(22), 1 packet  

This log message informs the administrator of the action taken and the ACL which matched the packet, but in some cases we may want more detail readily available. This is where ACL hash correlation comes in handy. We can redefine the ACL rule to include an arbitrary keyword, up to 64 characters in length:

Router(config)# ip access-list ext EXTERNAL->INTERNAL
Router(config-ext-nacl)# 50 deny tcp any any eq 22 log Deny_SSH
Router(config-ext-nacl)# ^Z
Router# show ip access-lists
Extended IP access list EXTERNAL->INTERNAL
 10 permit icmp any any echo-reply
 20 permit udp any eq domain any
 30 permit tcp any any established
 40 permit tcp any host 172.16.0.202 eq www
 50 deny tcp any any eq 22 log (tag = Deny_SSH)
 999 deny ip any any

Now when that rule discards a packet, its log message includes our tag:

%SEC-6-IPACCESSLOGP: list EXTERNAL->INTERNAL denied tcp 10.0.0.2(54843) ->
 10.0.0.1(22), 1 packet  [Deny_SSH]

These tags can be reused by multiple ACEs. Continuing our example, say we also want to deny traffic to SSH servers running on an alternate port, TCP/2222:

Router(config)# ip access-list ext EXTERNAL->INTERNAL
Router(config-ext-nacl)# 60 deny tcp any any eq 2222 log Deny_SSH
Router(config-ext-nacl)# ^Z
Router# show ip access-lists
Extended IP access list EXTERNAL->INTERNAL
 10 permit icmp any any echo-reply
 20 permit udp any eq domain any
 30 permit tcp any any established
 40 permit tcp any host 172.16.0.202 eq www
 50 deny tcp any any eq 22 log (1 match) (tag = Deny_SSH)
 60 deny tcp any any eq 2222 log (tag = Deny_SSH)
 999 deny ip any any

ACL logging tags are great for readily identifying ACE matches, particularly when you expect certain matches to occur, but manually defining a tag for each ACE isn't always practical. This is especially true when you want to maintain syslog correlation among hundreds or thousands of individual ACL rules. In such cases, automatically generated hashes would be the preferred option. Automatic hashing is enabled globally, and applied to any ACE with the log keyword with no argument following it.
Here we enable hash generation and add a few more ACEs to our ACL:

Router(config)# ip access-list logging hash-generation
Router(config)# ip access-list extended EXTERNAL->INTERNAL
Router(config-ext-nacl)# 70 deny tcp any any eq 1000 log
Router(config-ext-nacl)# 80 deny tcp any any eq 2000 log
Router(config-ext-nacl)# 90 deny tcp any any eq 3000 log
Router(config-ext-nacl)# ^Z
Router# show ip access-lists
Extended IP access list EXTERNAL->INTERNAL
 10 permit icmp any any echo-reply
 20 permit udp any eq domain any
 30 permit tcp any any established
 40 permit tcp any host 172.16.0.202 eq www
 50 deny tcp any any eq 22 log (1 match) (tag = Deny_SSH)
 60 deny tcp any any eq 2222 log (tag = Deny_SSH)
 70 deny tcp any any eq 1000 log (hash = 0x594F8697)
 80 deny tcp any any eq 2000 log (hash = 0xE471528C)
 90 deny tcp any any eq 3000 log (hash = 0x34CC0DD6)
 999 deny ip any any

As expected, a trigger by any of the ACEs with a hash appended works just as it does with tags:

%SEC-6-IPACCESSLOGP: list EXTERNAL->INTERNAL denied tcp 10.0.0.2(21196) ->
 10.0.0.1(1000), 1 packet  [0x594F8697]

While not immediately useful, a hash can be used to filter an ACL configuration and quickly identify the ACE responsible for an action:

Router# show ip access-lists EXTERNAL->INTERNAL | include 594F8697
 70 deny tcp any any eq 1000 log (1 match) (hash = 0x594F8697)

IOS Resilient Configuration

Cisco IOS Resilient feature enables critical router files, namely the IOS image and configuration, to persist despite destructive events such as deletion of the startup configuration or a format of the Flash filesystem. The feature does not require any external services; all persistent files are stored locally on the router.

Enabling Resilient Configuration

First, a quick review of how Cisco ISR (x800 series) routers work. The binary IOS image used to boot the router is stored on the Flash filesystem, which is a type of memory very similar to that found inside a USB thumbdrive. The startup configuration file is stored on a separate filesystem, NVRAM. The contents of both filesystems can be viewed with the dir command.

Router# dir flash:
Directory of flash:/

    1  -rw-    23587052   Jan 9 2010 17:16:58 +00:00  c181x-advipservicesk9-mz.124-24.T.bin
    2  -rw-         600  Sep 26 2010 07:28:12 +00:00  vlan.dat

128237568 bytes total (104644608 bytes free)
Router# dir nvram:
Directory of nvram:/

  189  -rw-        1396                      startup-config
  190  ----          24                      private-config
  191  -rw-        1396                      underlying-config
    1  -rw-           0                      ifIndex-table
    2  -rw-         593                      IOS-Self-Sig#3401.cer
    3  ----          32                      persistent-data
    4  -rw-        2945                      cwmp_inventory
   21  -rw-         581                      IOS-Self-Sig#1.cer

196600 bytes total (130616 bytes free)

The resilient image and configuration features are enabled with one command each.

Router(config)# secure boot-image
Router(config)#
%IOS_RESILIENCE-5-IMAGE_RESIL_ACTIVE: Successfully secured running image
Router(config)# secure boot-config
Router(config)#
%IOS_RESILIENCE-5-CONFIG_RESIL_ACTIVE: Successfully secured config archive [flash:.runcfg-20101017-020040.ar]

The combination of the secured IOS image and configuration file is referred to as the bootset. We can verify the secure configuration with the command show secure bootset.

Router# show secure bootset
IOS resilience router id FHK110913UQ

IOS image resilience version 12.4 activated at 02:00:30 UTC Sun Oct 17 2010
Secure archive flash:c181x-advipservicesk9-mz.124-24.T.bin type is image (elf) []
  file size is 23587052 bytes, run size is 23752654 bytes
  Runnable image, entry point 0x80012000, run from ram

IOS configuration resilience version 12.4 activated at 02:00:41 UTC Sun Oct 17 2010
Secure archive flash:.runcfg-20101017-020040.ar type is config
configuration archive size 1544 bytes

At this point, we notice that our IOS image file on Flash is now hidden.

Router# dir flash:
Directory of flash:/

2  -rw-         600  Sep 26 2010 07:28:12 +00:00  vlan.dat

128237568 bytes total (104636416 bytes free)

Restoring an Archived Configuration

Now suppose that the router's startup configuration file is erased (accidentally or otherwise) and the router is reloaded. Naturally, it boots with a default configuration. The resilient configuration feature will even appear to be disabled.

Router# erase startup-config
Erasing the nvram filesystem will remove all configuration files! Continue? [confirm]
[OK]
Erase of nvram: complete
Router# show startup-config
startup-config is not present
Router# reload

System configuration has been modified. Save? [yes/no]: n
Proceed with reload? [confirm]
...
Router> enable
Router# show secure bootset
%IOS image and configuration resilience is not active

To restore our original configuration, we simply have to extract it from the secure archive and save it to Flash. Next, we can replace the current running configuration with the archived config using the configure replace command.

Router(config)# secure boot-config restore flash:archived-config
ios resilience:configuration successfully restored as flash:archived-config
Router(config)# ^C
Router# configure replace flash:archived-config
This will apply all necessary additions and deletions
to replace the current running configuration with the
contents of the specified configuration file, which is
assumed to be a complete configuration, not a partial
configuration. Enter Y if you are sure you want to proceed. ? [no]: y
Total number of passes: 1
Rollback Done

Router#

Don't forget to save the running configuration once the restoration is complete (copy run start).
Be aware that the resilient configuration file is not automatically updated along with the startup configuration. To update it, you must first delete the existing resilient configuration and issue the secure boot-config command again.

Router(config)# no secure boot-config
%IOS_RESILIENCE-5-CONFIG_RESIL_INACTIVE: Disabled secure config archival [removed
 flash:.runcfg-20101017-020040.ar]
Router(config)# secure boot-config
%IOS_RESILIENCE-5-CONFIG_RESIL_ACTIVE: Successfully secured config archive
 [flash:.runcfg-20101017-024745.ar]

Finally, note that the secure bootset features can only be disabled from the console line.

Router(config)# no secure boot-config
%You must be logged on the console to apply this command

In fact, attempting to disable either part of the secure bootset generates a handy syslog message to alert administrators:

%IOS_RESILIENCE-5-NON_CONSOLE_ACCESS: Non console configuration request denied for command "no secure boot-config "

What About the IOS Image?

It turns out that the secure boot image feature works pretty well too. Here we can see that it persists even when the Flash filesystem appears to have been formatted.

Router# format flash:
Format operation may take a while. Continue? [confirm]
Format operation will destroy all data in "flash:".  Continue? [confirm]
Writing Monlib sectors...
Monlib write complete

Format: All system sectors written. OK...

Format: Total sectors in formatted partition: 250848
Format: Total bytes in formatted partition: 128434176
Format: Operation completed successfully.

Format of flash: complete
Router# dir
Directory of flash:/

No files in directory

128237568 bytes total (104640512 bytes free)
Router# reload
Proceed with reload? [confirm]

*Oct 17 02:37:37.127: %SYS-5-RELOAD: Reload requested  by console. Reload Reason
: Reload Command.
System Bootstrap, Version 12.3(8r)YH8, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 2006 by cisco Systems, Inc.
C1800 platform with 131072 Kbytes of main memory with parity disabled

Upgrade ROMMON initialized
program load complete, entry point: 0x80012000, size: 0xc0c0

Initializing ATA monitor library.......
program load complete, entry point: 0x80012000, size: 0xc0c0

Initializing ATA monitor library.......

program load complete, entry point: 0x80012000, size: 0x167e724
Self decompressing the image : #################################################
################################################################################
################################################################ [OK]

Restricted Rights Legend

Use, duplication, or disclosure by the Government is
subject to restrictions as set forth in subparagraph
(c) of the Commercial Computer Software - Restricted
Rights clause at FAR sec. 52.227-19 and subparagraph
(c) (1) (ii) of the Rights in Technical Data and Computer
Software clause at DFARS sec. 252.227-7013.

cisco Systems, Inc.
           170 West Tasman Drive
           San Jose, California 95134-1706

Cisco IOS Software, C181X Software (C181X-ADVIPSERVICESK9-M), Version 12.4(24)T,
 RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2009 by Cisco Systems, Inc.
Compiled Thu 26-Feb-09 03:22 by prod_rel_team
...
Router> enable
Password:
Router# dir
Directory of flash:/

No files in directory

128237568 bytes total (104640512 bytes free)
Router# show version
Cisco IOS Software, C181X Software (C181X-ADVIPSERVICESK9-M), Version 12.4(24)T,
 RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2009 by Cisco Systems, Inc.
Compiled Thu 26-Feb-09 03:22 by prod_rel_team
...

Cisco Switch Port Security

Port security is a layer two traffic control feature on Cisco Catalyst switches. It enables an administrator configure individual switch ports to allow only a specified number of source MAC addresses ingressing the port. Its primary use is to deter the addition by users of "dumb" switches to illegally extend the reach of the network (e.g. so that two or three users can share a single access port). The addition of unmanaged devices complicates troubleshooting by administrators and is best avoided.

Enabling Port Security

Port security can be enabled with default parameters by issuing a single command on an interface:

Switch(config)# interface f0/13
Switch(config-if)# switchport port-security

Although only a single interface is used for illustration in this article, port security, if configured, is typically configured on all user-facing interfaces.
We can view the default port security configuration with show port-security:

Switch# show port-security interface f0/13
Port Security              : Enabled
Port Status                : Secure-down
Violation Mode             : Shutdown
Aging Time                 : 0 mins
Aging Type                 : Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses      : 1
Total MAC Addresses        : 0
Configured MAC Addresses   : 0
Sticky MAC Addresses       : 0
Last Source Address:Vlan   : 0000.0000.0000:0
Security Violation Count   : 0

As you can see, there are a number of attributes which can be adjusted. We'll cover these in a moment. When a host connects to the switch port, the port learns the host's MAC address as the first frame is received:

Switch# show port-security interface f0/13
Port Security              : Enabled
Port Status                : Secure-up
Violation Mode             : Shutdown
Aging Time                 : 0 mins
Aging Type                 : Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses      : 1
Total MAC Addresses        : 1
Configured MAC Addresses   : 0
Sticky MAC Addresses       : 0
Last Source Address:Vlan   : 001b.d41b.a4d8:10
Security Violation Count   : 0

Now, we disconnect the host from the port, connect a small switch or hub, and reconnect the original host plus a second, unauthorized host so that they both attempt to share the access port. Observe what happens as soon as the second host attempts to send traffic:

%PM-4-ERR_DISABLE: psecure-violation error detected on Fa0/13, putting Fa0/13 in err-disable state
%PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 0021.55c8.f13c on port FastEthernet0/13.
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/13, changed state to down
%LINK-3-UPDOWN: Interface FastEthernet0/13, changed state to down

Inspecting the status of port security on the port again, we can see that the new MAC address triggered a violation:

Switch# show port-security interface f0/13
Port Security              : Enabled
Port Status                : Secure-shutdown
Violation Mode             : Shutdown
Aging Time                 : 0 mins
Aging Type                 : Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses      : 1
Total MAC Addresses        : 0
Configured MAC Addresses   : 0
Sticky MAC Addresses       : 0
Last Source Address:Vlan   : 0021.55c8.f13c:10
Security Violation Count   : 1
Switch# show interfaces f0/13
FastEthernet0/13 is down, line protocol is down (err-disabled) 
  Hardware is Fast Ethernet, address is 0013.c412.0f0d (bia 0013.c412.0f0d)
  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
...

By default, a port security violation forces the interface into the error-disabled state. An administrator must re-enable the port manually by issuing the shutdown interface command followed by no shutdown. This must be done after the offending host has been removed, or the violation will be triggered again as soon as the second host sends another frame.

Tweaking Port Security

Violation Mode

Port security can be configured to take one of three actions upon detecting a violation:
shutdown (default) ; The interface is placed into the error-disabled state, blocking all traffic. protect ; Frames from MAC addresses other than the allowed addresses are dropped; traffic from allowed addresses is permitted to pass normally. restrict ; Like protect mode, but generates a syslog message and increases the violation counter.
By changing the violation mode to restrict, we are still alerted when a violation occurs, but legitimate traffic remains unaffected:

Switch(config-if)# switchport port-security violation restrict
Switch(config-if)# ^Z
Switch#
%PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 0021.55c8.f13c on port FastEthernet0/13.
Switch# show port-security interface f0/13
Port Security              : Enabled
Port Status                : Secure-up
Violation Mode             : Restrict
Aging Time                 : 0 mins
Aging Type                 : Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses      : 1
Total MAC Addresses        : 1
Configured MAC Addresses   : 0
Sticky MAC Addresses       : 0
Last Source Address:Vlan   : 0021.55c8.f13c:10
Security Violation Count   : 3

Unfortunately, violating traffic will continue to trigger log notifications, and the violation counter will continue to increase, until the violating host is dealt with.

Maximum MAC Addresses

By default, port security limits the ingress MAC address count to one. This can be modified, for example, to accommodate both a host and an IP phone connected in series on a switch port:

Switch(config-if)# switchport port-security maximum 2

One also has the option to set a maximum MAC count for the access and voice VLANs independently (assuming a voice VLAN has been configured on the interface):

Switch(config-if)# switchport port-security maximum 1 vlan access
Switch(config-if)# switchport port-security maximum 1 vlan voice

MAC Address Learning

An administrator has the option of statically configuring allowed MAC addresses per interface. MAC addresses can optionally be configured per VLAN (access or voice).

Switch(config-if)# switchport port-security mac-address 001b.d41b.a4d8 ?
  vlan  set VLAN ID of the VLAN on which this address can be learned
  
Switch(config-if)# switchport port-security mac-address 001b.d41b.a4d8 vlan access

The configured MAC address(es) are recorded in the running configuration:

Switch# show running-config interface f0/13
Building configuration...

Current configuration : 259 bytes
!
interface FastEthernet0/13
 switchport access vlan 10
 switchport mode access
 switchport voice vlan 20
 switchport port-security
 switchport port-security violation restrict
 switchport port-security mac-address 001b.d41b.a4d8
 spanning-tree portfast
end

Obviously, this is not a scalable practice. A much more convenient alternative is to enable "sticky" MAC address learning; MAC addresses will be dynamically learned until the maximum limit for the interface is reached.

Switch(config-if)# no switchport port-security mac-address 001b.d41b.a4d8
Switch(config-if)# switchport port-security mac-address sticky
Switch(config-if)# ^Z
Switch# show port-security interface f0/13
Port Security              : Enabled
Port Status                : Secure-up
Violation Mode             : Restrict
Aging Time                 : 0 mins
Aging Type                 : Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses      : 1
Total MAC Addresses        : 1
Configured MAC Addresses   : 0
Sticky MAC Addresses       : 1
Last Source Address:Vlan   : 001b.d41b.a4d8:10
Security Violation Count   : 0

After a MAC address has been learned, it is recorded to the configuration similarly to as if it were entered manually:

Switch# show running-config interface f0/13
Building configuration...

Current configuration : 311 bytes
!
interface FastEthernet0/13
 switchport access vlan 10
 switchport mode access
 switchport voice vlan 20
 switchport port-security
 switchport port-security violation restrict
 switchport port-security mac-address sticky
 switchport port-security mac-address sticky 001b.d41b.a4d8
 spanning-tree portfast
end

MAC Address Aging

By default, secure MAC addresses are learned (in effect) permanently. Aging can be configured so that the addresses expire after a certain amount of time has passed. This allows a new host to take the place of one which has been removed. Aging can be configured to take effect at regular intervals, or only during periods of inactivity. The following example configures expiration of MAC addresses after five minutes of inactivity:

Switch(config-if)# switchport port-security aging time 5
Switch(config-if)# switchport port-security aging type inactivity
Switch(config-if)# ^Z
Switch# show port-security interface f0/13
Port Security              : Enabled
Port Status                : Secure-up
Violation Mode             : Restrict
Aging Time                 : 5 mins
Aging Type                 : Inactivity
SecureStatic Address Aging : Disabled
Maximum MAC Addresses      : 1
Total MAC Addresses        : 1
Configured MAC Addresses   : 0
Sticky MAC Addresses       : 0
Last Source Address:Vlan   : 001b.d41b.a4d8:10
Security Violation Count   : 0

After five minutes of inactivity, we can see that the address has been purged:

Switch# show port-security interface f0/13
Port Security              : Enabled
Port Status                : Secure-up
Violation Mode             : Restrict
Aging Time                 : 5 mins
Aging Type                 : Inactivity
SecureStatic Address Aging : Disabled
Maximum MAC Addresses      : 1
Total MAC Addresses        : 0
Configured MAC Addresses   : 0
Sticky MAC Addresses       : 0
Last Source Address:Vlan   : 001b.d41b.a4d8:10
Security Violation Count   : 0

At this point, the old address will be re-learned the next time a frame is sent from that host, or a new host can take its place.

Auto-recovery

To avoid having to manually intervene every time a port-security violation forces an interface into the error-disabled state, one can enable auto-recovery for port security violations. A recovery interval is configured in seconds.

Switch(config)# errdisable recovery cause psecure-violation
Switch(config)# errdisable recovery interval 600

Ten minutes after a port was error-disabled, we can see that the port is automatically transitioned back into operation:

%PM-4-ERR_RECOVER: Attempting to recover from psecure-violation err-disable state on Fa0/13
%LINK-3-UPDOWN: Interface FastEthernet0/13, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/13, changed state to up

This is a great way to automatically clear port security violations after the user has been given an opportunity to remove the offending host(s). Note that is the cause is not cleared, the violation will trigger again after the port comes back up, re-initating the auto-recovery cycle.

Note

Although a deterrent, port security is not a reliable security feature, as MAC addresses are trivially spoofed, and multiple hosts can still easily be hidden behind a small router. IEEE 802.1X is a much more robust access edge security solution.

IOS Control Plane Protection for DoS Mitigation

IOS control plane protection is an extension of control plane policing (CoPP) introduced in 12.4(4)T which allows an administrator to apply a quality of service (QoS) policy to a router's control plane. The control plane handles all traffic which must be processed by the router in software.
A policy can be applied to the control plane generally, as with legacy CoPP, or it can be applied to one of the three control plane "subinterfaces:"

• Host - Traffic destined for the router itself (management, routing protocols, etc.)
• Transit - Software-switched transit traffic
• CEF exception - Traffic which triggers a CEF exception (ARP, non-IP packets, etc.)

To illustrate the benefits of configuring control plane protection, we can observe what happens when an unprotected router is targeted by a primitive denial of service (DoS) attack. We can initiate a primitive DoS against a router at 10.0.0.1 by initiating a UDP flood:

Attacker$ udp-flood.pl 10.0.0.1 1234 64 0

UDP packets are flooded at or near line rate with the intention of overwhleming the recipient. Since these packets are destined for the router itself, each gets punted from hardware to software prcoessing, consuming expensive CPU and memory resources. With no countermeasures in place, the router's processing power is quickly consumed:

Router# show processes cpu sorted
CPU utilization for five seconds: 100%/28%; one minute: 76%; five minutes: 25%
 PID Runtime(ms)     Invoked      uSecs   5Sec   1Min   5Min TTY Process
  29       85468         295     289722 71.30% 52.46% 16.90%   0 Net Background
   4        2136         118      18101  0.42%  0.35%  0.28%   0 Check heaps
   2          24          50        480  0.08%  0.02%  0.00%   0 Load Meter
  56          12        4131          2  0.08%  0.01%  0.00%   0 Dot11 driver
  80         848         185       4583  0.08%  0.20%  0.07%   0 IP Input
   1           4          11        363  0.00%  0.00%  0.00%   0 Chunk Manager
...

To mitigate this, we can apply control plane protection. A CoPP policy is configured via the modular QoS CLI (MQC) as with any regular QoS policy, and applied akin to a normal interface service policy. To keep things simple, we'll create a policy which just polices inbound UDP traffic to 16 Kbps:

class-map match-all UDP
 match access-group name UDP
!
policy-map CoPP
 class UDP
  police 16000 conform-action transmit exceed-action drop violate-action drop
!
ip access-list extended UDP
 permit udp any any

Finally we apply the service policy to the control plane. In this example, it is applied to the aggregate rather than to a subinterface:

R1(config)# control-plane ?
  cef-exception  Cef-exception traffic control-plane configuration
  host           Host traffic control-plane configuration
  transit        Transit traffic control-plane configuration
  

R1(config)# control-plane
R1(config-cp-host)# service-policy input CoPP
R1(config-cp-host)#
%CP-5-FEATURE: Control-plane Policing feature enabled on Control plane aggregate path

We can relaunch our UDP flood and compare the CPU utilization to what we saw without CoPP:

Router#show processes cpu sorted
CPU utilization for five seconds: 100%/97%; one minute: 53%; five minutes: 32%
 PID Runtime(ms)     Invoked      uSecs   5Sec   1Min   5Min TTY Process
  55       13492        2055       6565  0.32%  0.08%  0.02%   0 COLLECT STAT COU
   1           4          12        333  0.00%  0.00%  0.00%   0 Chunk Manager  
   2         968          83      11662  0.00%  0.00%  0.00%   0 Load Meter     
   4        3932         206      19087  0.00%  0.60%  0.49%   0 Check heaps    
   5           0           1          0  0.00%  0.00%  0.00%   0 Pool Manager   
   6           0           2          0  0.00%  0.00%  0.00%   0 Timers    
...     

That's probably not what you expected: CPU utilization actually appears to have gone up! What happened? Before moving any further, let's verify that our CoPP policy is indeed performing as expected:

Router# show policy-map control-plane
 Control Plane

Service-policy input: CoPP

Class-map: UDP (match-all)
      6918133 packets, 733322098 bytes
      5 minute offered rate 16552000 bps, drop rate 16551000 bps
      Match: access-group name UDP
      police:
          cir 16000 bps, bc 1500 bytes, be 1500 bytes
        conformed 1575 packets, 166950 bytes; actions:
          transmit
        exceeded 14 packets, 1484 bytes; actions:
          drop
        violated 6921762 packets, 733706772 bytes; actions:
          drop
        conformed 18000 bps, exceed 0 bps, violate 74591000 bps

Class-map: class-default (match-any)
      2 packets, 120 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any

Yep, our CoPP policy is policing at merely 16 Kbps inbound, and discarding all other malicious traffic. What gives?
The five-second CPU statistics listed at the beginning of the show processes cpu outputs is composed of two numbers: total utilization and utilization resulting from hardware interrupt requests. In our first report, interrupt utilization accounted for only around 30% of the total CPU utilization, whereas it now accounts for nearly all of it. Conversely, the first report showed the "Net Background" process (responsible for buffer allocation on newer IOS versions) consuming over 70% CPU utilization while the same process's utilization on the second output is negligible (it's not even listed in the top few).
What we've witnessed here is a shift from process-heavy computation to interrupt-heavy computation. Unfortunately, depending on the platform, this can be just as bad. Testing this on an 1811W I noticed that the terminal felt just as sluggish under 100% load with or without CoPP. Fortunately, once the load has been pushed back to the interrupt level, you can adjust the process scheduler allocation to give software processes a little more breathing room.
Scheduler allocation is defined as a proprotion of interrupt run time to process run time; for most platforms, 4000 µsec of interrupt time is allowed for merely 200 µsec of process time (according to the documentation). Older platforms might be limited to the scheduler interval command. Sensible scheduler allocation is a hairy topic in itself, but the permitted ranges offer some idea of the intended ratio:

Router(config)# scheduler allocate ?
  <3000-60000>  Microseconds handling network interrupts
  

Router(config)# scheduler allocate 8000 ?
  <1000-8000>  Microseconds running processes

Router(config)# scheduler allocate 8000 1000

An allocation of 8000/1000 worked well to put the spring back into the console of my 1800 series while it was being beaten to death with UDP. I have not experimented with the impact of this allocation on actual throughput. Your mileage may vary.

Securing IOS local authentication logins

By default, the local authentication provided by IOS is fairly simple. However, there are a number of enhancements which can be enabled to greatly improve its resiliency against dictionary and brute-force login attacks.
A derivation of the login command can be used to enforce a temporary block, or "quiet period," against login attempts after a specified number of failed attempts have been made within a given time frame. For example, a router can be configured to disable inbound terminal connections for five minutes (300 seconds) after encountering five failed login attempts within 60 seconds:

Router(config)# login block-for 300 attempts 5 within 60

Issuing this command creates an access list named sl_def_acl as we'll see shortly. We can observe what happens when five failed login attempts are made within 60 seconds:

Host# telnet 10.0.0.1
Trying 10.0.0.1 ... Open
User Access Verification
Username: attempt1
Password:
% Authentication failed

Username: attempt2
Password:
% Authentication failed
Username: attempt3
Password:
% Authentication failed

[Connection to 10.0.0.1 closed by foreign host]
Host# telnet 10.0.0.1
Trying 10.0.0.1 ... Open
User Access Verification
Username: attempt4
Password:
% Authentication failed

Username: attempt5
Password:
% Authentication failed
[Connection to 10.0.0.1 closed by foreign host]
 

Host# telnet 10.0.0.1
Trying 10.0.0.1 ... 
% Connection refused by remote host

Notice that we never received a sixth authentication prompt. On the router, we see that this log message was generated as soon as the fifth login attempt failed:

%SEC_LOGIN-1-QUIET_MODE_ON: Still timeleft for watching failures is 33 secs, [user: ]
 [Source: 10.0.0.2] [localport: 23] [Reason: Login Authentication Failed] [ACL: sl_def_acl]
 at 15:39:25 UTC Sun Jan 02 2011

The router automatically activated the ACL sl_def_acl to deny all inbound terminal and HTTP connections for the duration of the quiet period. This ACL does not appear in the running configuration, but is visible using  show ip access-lists:

Router# show ip access-lists
Extended IP access list sl_def_acl
 10 deny tcp any any eq telnet log
 20 deny tcp any any eq www log
 30 deny tcp any any eq 22 log
 40 permit tcp any any eq 22 log

Our last connection attempt above triggers a match and subsequent deny on the ACL as you would expect:

%SEC-6-IPACCESSLOGP: list sl_def_acl denied tcp 10.0.0.2(16167) -> 0.0.0.0(23), 1 packet

After the quiet period has expired, a log message appears letting us know that the router is ready to accept connections again (this message appears exactly 300 seconds after the QUIET_MODE_ON alert):

%SEC_LOGIN-5-QUIET_MODE_OFF: Quiet Mode is OFF, because block period timed out at 15:44:25
 UTC Sun Jul 26 2009

Of course, disabling all connection attempts during the quiet period likely does more harm than good, as legitimate administrators are affected as well. Alternatively, a custom quiet period ACL can be supplied to exempt certain source addresses.

Router(config)# login quiet-mode access-class TRUSTED_HOSTS

It's worth mentioning that, if you've properly secured remote terminal access to begin with, this command should be unnecessary.
Other login options include:

• delay - Configure a delay between 1 and 10 seconds to wait between login attempts.
• on-failure - Log individual login failures.
• on-success - Log individual successful logins.

HTTP Session Cloning & Cookie Stealing Tool - sessionthief

sessionthief performs HTTP session cloning by cookie stealing. It can issue basic nmap and nbtscan commands to see which IPs are on the subnet, or just listen for IPs broadcasting packets. It can quickly perform ARP poison routing to get packets given the IP of the client if not on an open network or hub, and should also work with interfaces in monitor mode. It integrates automatically with Firefox, dynamically creating a temporary profile for each attack performed. In this way, in contrast to tools like the middler, it doesn’t require any additional configuration, and makes it easy to simultaneously own multiple logins to the same site.


For example, if multiple clients on the open or WEP-encrypted wireless network you are on are on Facebook (or yahoo mail or just about any site you log into), you can:

A.Start the program
B.Select your interface
C.Hit watch
D.Select a request from each of them to facebook, and click the session button.

The program will start a new instance of firefox for each session hacked, and let you control the login of all of them at once. It compiles and runs on linux and windows depending on the pcap and wxwidgets libraries.

You can download sessionthief from below location:
Download
More Informations

Cisco Router Black hole filtering

Black hole filtering is a technique usually used by service providers for traffic filtering without applying access-lists.

The technique is very useful in mitigation of many types of DOS attacks. The idea behind Black hole filtering is very simple; just define the traffic you want to discard and configure a static route pointing to the Null0 interface.

The following rules summarize the technique:

• Define the suspected traffic by destination.
• Configure static route pointing this destination to null0.

Black hole filtering is based on the destination address of the packet.
Packets directed to the Null interface are just discarded.
Static routes to the Null0 interface use the same rules of normal static routes (redistribution, AD, etc..).

Example:

!-- packets destined to 195.226.123.200 disarded

ip route 195.226.123.200 255.255.255.255 null0

!-- Disable ICMP unreachable packets

int null0

no ip unreachables

Hack Simplifies Attacks On Cisco Routers

A security researcher has discovered a method of hacking Cisco routers with only basic knowledge about the targeted device.

Although researchers have found various vulnerabilities in Cisco routers, exploits mostly have been focused on hacks of specific IOS router configurations, which require targeted and skilled attacks. But Felix "FX" Lindner, a researcher with Recurity Labs, demonstrated last week at the 25th Chaos Communication Congress in Berlin a technique that lets an attacker execute code remotely on Cisco routers, regardless of their configuration.

"The bottom line is that before, all IOS exploits had to know the exact IOS image running on the target to get code execution. This is approximately a 1 to 100,000 chance, [and] a professional attacker doesn't risk his 0-day exploit when the odds are stacked against him like that," Linder says. "I [demonstrated] that at least on one group of Cisco routers, there is a way to execute code without knowing the IOS image version [they are] running."

Lindner says his exploit method is independent of a router vulnerability, and applies only to stack-buffer overflow bugs. He was able to execute memory writes and to disable CPU caches on Cisco routers running on the PowerPC CPU. Lindner hasn't yet tested his technique on larger, more expensive Cisco routers, but plans to do so eventually.

Security researcher Dan Kaminsky says FX's hack disproves conventional wisdom in enterprises that routers are at low risk of attack, and that patching them is riskier than an attack due to the potential network outages that patching can incur.

The research also broke the barrier of one exploit, one router: "Three-and-a-half years ago it was international news that one guy got one exploit working on one Cisco router," he says. "Today, it's now clear that it's possible, given a flaw in IOS, to reliably exploit many versions of many routers.

"Something we thought was difficult, for no good reason, is now shown to be so very simple after all," Kaminsky says.
Lindner says his research shows that detection of Cisco IOS attacks should be focused on the payload of an exploit, such as a backdoor program, rather than on the exploit itself.
To protect against a widespread router attack, Cisco should encourage users to run more standard versions of IOS, as well as make IOS more modular to simplify patching for its customers with customized versions, Kaminsky says.

The bottom line is that enterprises need to change their tune when it comes to their IOS patching policy. When a remote-code execution bug is discovered in one of their routers, they should treat it like any other system vulnerability, Kaminsky says. "They should treat it as equivalent to a vulnerability against sensitive servers or domain controllers, and act accordingly," he says. And that may require working closely with Cisco on just how to do that, he adds.

Ref:- Presentation

Using the capture command in a Cisco Systems PIX firewall.

This is an excellent article you might find useful covering the use of the capture command in Cisco PIX firewalls.

A vital tool to use when troubleshooting computer networking problems and monitoring computer networks is a packet sniffer. That being said, one of the best methods to use when troubleshooting connection problems or monitoring suspicious network activity in a Cisco Systems PIX firewall is by using the capture command. Many times Cisco TAC will request captures from a PIX in PCAP format for open problem tickets associated with unusual problems or activity associated with the PIX and the network.

Cisco kit can be a bit daunting for a newcomer, but very well featured, it’s important to learn what your PIX can do!

The capture command was first introduced to the PIX OS in version 6.2 and has the ability to capture all data that passes through the PIX device. You can use access-lists to specify the type of traffic that you wish to capture, along with the source and destination addresses and ports. Multiple capture statements can be used to attach the capture command to multiple interfaces. You can even copy the raw header and hexadecimal data in PCAP format to a tftp server and open it with TCPDUMP or Ethereal.

NOTE: You must be in privileged mode to invoke the capture command.
Full article here.

Domain Information Gathering Tool

The first stage of penetration testing is usually passive information gathering and enumeration (active information gathering). This is where tools like dnsenum come in, the purpose of DNSenum is to gather as much information as possible about a domain.

The program currently performs the following operations:

1. Get the host’s addresse (A record).
2. Get the namservers (threaded).
3. Get the MX record (threaded).
4. Perform axfr queries on nameservers (threaded).
5. Get extra names and subdomains via google scraping (google query = “allinurl: -www site:domain”).
6. Brute force subdomains from file, can also perform recursion on subdomain that have NS records (all threaded).
7. Calculate C class domain network ranges and perform whois queries on them (threaded).
8. Perform reverse lookups on netranges ( C class or/and whois netranges) (threaded).
9. Write to domain_ips.txt file ip-blocks.

The output file domain_ips.txt will contain non-contiguous IP blocks:

127.0.0.1/32
127.0.0.8/31

You can download DNSenum v1.2 here:

dnsenum1.2.tar.gz

Or you can read more here.

Firewall Auditing & Ruleset Analyzer Tool

FWAuto (Firewall Rulebase Automation) is a Perl script and should work on any system with Perl installed. Provide the running config of a PIX firewall to fwauto. It will analyze and give you a list of weak rules in your rule base and store the result in multiple output files.

Maybe there have been times when you have pentested a firewall. As part of a grey box engagement you were assigned the task of auditing that HUGE firewall rulebase and were stuck on how to proceed, just because of the sheer volume of information. This tool in Perl is created to help in auditing a rulebase and helping you to narrow down on the weak rules. Current support is just for Cisco PIX though the framework was designed to scale across multiple firewalls and no major changes need to be made.

Updates

• Outputs now available in reasonably neat HTML format
• No more complex command line arguments, everything’s in a config file
• More ports added in vulnerable ports section
• Options available to obtain detailed/non detailed output

You can download fwauto v.1.1 here:

fwauto_v1.1.zip

Or read more here.

What firewalls do and don’t do

Over the last few years, security threats to companies have grown and altered dramatically and so have the defences. Traditional firewalls, installed over three years ago, are often not best suited for current threats and don’t protect against a number of newer threats.

What firewalls do

A firewall is a system designed to prevent unauthorised access to or from a private computer network. Firewalls are frequently used to prevent unauthorised Internet users from accessing private networks connected to the Internet (often described as intranets). All messages entering or leaving the intranet pass through the firewall, which examines each message and blocks those that do not meet the specified security criteria.

You need a firewall to protect your confidential information from those not authorised to access it and to protect against malicious users and accidents that originate outside your network. One of the most important elements of a firewall is its access control features, which distinguish between good and bad traffic.

There are various types of firewall. In ascending order, they are:

* Packet layer
This analyses network traffic at the transport protocol layer.

* Circuit level
This validates that packets are either connection or data packets.

* Application layer
This ensures valid data at the application level before connecting.

* Proxy server
This intercepts all messages entering or leaving the network.

In the real world, threats have evolved over the years and firewalls have evolved to deal with them. While it is still possible to buy packet only firewalls, they are not adequate for business use. Protection against combination threats is best provided by firewalls which combine all of the above elements.

Specific functions performed by firewalls include:
* Gateway defence
* Carrying out defined security policies
* Segregating activity between your trusted network, the Internet and your DMZ ( a protected zone midway between your network and the Internet, where you would perhaps have your web or email server).
* Hiding and protecting your internal network addresses (NAT)
* Reporting on threats and activity.

What firewalls don’t do

Even with a firewall, there are still many areas of risk for your network. The most obvious is malware. Malware is a combination of the words ‘malicious’ and ‘software’ and includes viruses, trojan horses, worms, spyware/adware, phishing and pharming. Malware is most commonly acquired through clicking on email attachments and email links.

Viruses, trojans and worms can cause a range of symptoms from the annoying and/or embarrassing to the much more serious which can affect the functioning of your business. Spyware/adware gathers information about you. It can record keystrokes and, as such, can potentially be very dangerous, revealing everything you do on your computer,

Another well-known threat, not covered by your firewall, is SPAM. Dealing with SPAM can seriously affect your productivity and, as SPAM often contains viruses and phishing emails, it is also a direct security threat.

Phishing is about fake emails trying to extract sensitive information, such as your bank passwords or credit card details and a variation of this is pharming, where the criminal sets up a fake web site which looks like one you normally use, typically a banking site. Once you enter your details, the criminal is able to plunder your account.

Many people are also unaware that you can actually acquire malware by simply browsing web sites. This is a rapidly growing threat and some of the malware is used to create Botnets (see below). Some security applications (e.g. those from Finjan) have a facility which protects you against web sites containing malware, by checking the sites before you click on them.

Another danger to your network is from a DDoS (distributed denial of service) attack. This is a malicious attempt to prevent an organisation being able to use its Internet based systems by flooding them with emails until the servers are overwhelmed. These attacks are often carried out by BotNet networks of compromised PCs, which are also used in SPAM campaigns. Specific DDoS software can guard against this threat.

Other dangers to your network include unauthorised access, and the way to deal with this is to have proper authentication procedures in place, for both local and remote access. In many cases, passwords are not enough and the use of strong authentication with tokens provides much better security.

Further potential problems are from data theft or leakage, for example when a laptop is stolen. The answer here is to encrypt all sensitive data. Low cost solutions are available from companies such as Utimaco. Finally all wireless use is risky and requires a specific wireless firewall, and wireless VPN for remote access.

A firewall is no longer enough to protect a company network. Other security solutions to combat the threats outlined above are also necessary, as well as proper staff training.

One of the best ways to protect against the main threats not covered by a firewall is to use a UTM (unified threat management) device. UTM devices are multi-purpose security solutions which have a minimum of a firewall, VPN, anti-virus and intrusion detection/prevention. Some UTMs (sometimes known as super UTMs) also incorporate capabilities such as web filtering (blocking problematic web sites), SPAM blocking and spyware protection.

UTMs are usually lower cost than buying and installing several security components separately. They are also typically greener, as one solution uses much less power than multiple solutions. When buying a UTM or a super UTM, it is important to ensure that your reseller sizes it correctly i.e. ensures that it has the performance capability to deal with current throughput and future business expansion.

Wipe data with Cipher security tool

When you delete data files, the information is not really removed from the hard disk. Instead, the space that was occupied by the deleted data is deallocated and is available for use when new data is written to the disk. Until the space is overwritten, it is possible to recover delete data with raw disk editors and various data recovery software.

The built-in Cipher command-line utility has a special option to clean deleted data on a hard disk. To overwrite delete data, use the Cipher utility with the /w switch. Use the following steps:

Click the Start button and type cmd and press ENTER.

Type cipher /w:DRIVER:\DIRECTORY and press enter. Specify the drive and the folder that contains the deleted data that you want to overwrite.

The Cipher utility permanently removes the data. The process can take a long time if you are overwriting a large space. The Cipher utility is available for Windows XP - Vista. Windows 2000 users must install the Windows 2000 Security Rollup Package 1.

Layer 2 Attacks

The OSI stack was conceived so that different layers are able to function independently (with only the knowledge of their mutual interfaces). This allows for flexibility in that developments for a given layer of the protocol stack do not impact other layers so long as the standard interface between the layers is maintained.

Unfortunately this also means that if one layer is hacked, communication may be compromised without the other layers being aware of the problem (as shown in Below Figure).

OSI Stack Structure

In this architecture, security is only as strong as its weakest link.

The Data Link layer is as vulnerable as any other layer and can be subjected to a variety of attacks which the switch must be configured to protect against.

What Are the Possible Attacks in a VLAN-Based Network?
The majority of attacks at L2 exploit the inability of a device to track the attacker who can therefore perform undetected malicious actions on the forwarding path to alter it and then exploit the change.
These are the most talked-about L2 attacks and incidentally also the ones that @stake documented in its findings [1]:
•MAC Flooding Attack
•802.1Q and ISL Tagging Attack
•Double-Encapsulated 802.1Q/Nested VLAN Attack
•ARP Attacks
•Private VLAN Attack
•Multicast Brute Force Attack
•Spanning-Tree Attack
•Random Frame Stress Attack
A description of each of these threats follows.

MAC Flooding Attack
This is not properly a network "attack" but more a limitation of the way all switches and bridges work. They possess a finite hardware learning table to store the source addresses of all received packets: when this table becomes full, the traffic that is directed to addresses that cannot be learned anymore will be permanently flooded. Packet flooding however is constrained within the VLAN of origin, therefore no VLAN hopping is permitted.

This corner case behavior can be exploited by a malicious user that wants to turn the switch he or she is connected to into a dumb pseudo-hub and sniff all the flooded traffic. Several programs are available to perform this task: for example macof, part of the dsniff suite [4]. This weakness can then be exploited to perform an actual attack, like the ARP poisoning attack (see ARP Attacks for more details on the subject).

On non intelligent switches this problem arises because a sender's L2 identity is not checked, therefore the sender is allowed to impersonate an unlimited number of devices simply by counterfeiting packets.

Cisco's switches support a variety of features whose only goal is to identify and control the identities of connected devices. The security principle on which they are based is very simple: authentication and accountability are critical for all untrusted devices.

In particular, Port Security, 802.1x, and Dynamic VLANs are three features that can be used to constrain the connectivity of a device based on its user's login ID and based on the device's own MAC layer identification.

With Port Security, for instance, preventing any MAC flooding attack becomes as simple as limiting the number of MAC addresses that can be used by a single port: the identification of the traffic of a device is thereby directly tied to its port of origin.

802.1Q and ISL Tagging Attack
Tagging attacks are malicious schemes that allow a user on a VLAN to get unauthorized access to another VLAN. For example, if a switch port were configured as DTP auto and were to receive a fake DTP packet, it might become a trunk port and it might start accepting traffic destined for any VLAN. Therefore, a malicious user could start communicating with other VLANs through that compromised port.

Sometimes, even when simply receiving regular packets, a switch port may behave like a full-fledged trunk port (for example, accept packets for VLANs different from the native), even if it is not supposed to. This is commonly referred to as "VLAN leaking"

While the first attack can be prevented very easily by setting DTP to off on all non trusted ports (again the principle of trust at work...), the second attack can usually be addressed by following simple configuration guidelines (such as the one suggested in the next section) or with software upgrades. Fortunately, Cisco Catalyst 2950, Catalyst 3550, Catalyst 4000, and Catalyst 6000 series switches don't need any such upgrade, since their software and hardware have been designed to always enforce proper traffic classification and isolation on all their ports .

Double-Encapsulated 802.1Q/Nested VLAN Attack
While internal to a switch, VLAN numbers and identification are carried in a special extended format that allows the forwarding path to maintain VLAN isolation from end to end without any loss of information. Instead, outside of a switch, the tagging rules are dictated by standards such as ISL or 802.1Q.

ISL is a Cisco proprietary technology and is in a sense a compact form of the extended packet header used inside the device: since every packet always gets a tag, there is no risk of identity loss and therefore of security weaknesses.

On the other hand, the IEEE committee that defined 802.1Q decided that because of backward compatibility it was desirable to support the so-called native VLAN, that is to say, a VLAN that is not associated explicitly to any tag on an 802.1Q link. This VLAN is implicitly used for all the untagged traffic received on an 802.1Q capable port.

This capability is desirable because it allows 802.1Q capable ports to talk to old 802.3 ports directly by sending and receiving untagged traffic. However, in all other cases, it may be very detrimental because packets associated with the native VLAN lose their tags, for example, their identity enforcement, as well as their Class of Service (802.1p bits) when transmitted over an 802.1Q link.

For these sole reasons—loss of means of identification and loss of classification—the use of the native VLAN should be avoided. There is a more subtle reason, though.

When double-encapsulated 802.1Q packets are injected into the network from a device whose VLAN happens to be the native VLAN of a trunk, the VLAN identification of those packets cannot be preserved from end to end since the 802.1Q trunk would always modify the packets by stripping their outer tag. After the external tag is removed, the internal tag permanently becomes the packet's only VLAN identifier. Therefore, by double-encapsulating packets with two different tags, traffic can be made to hop across VLANs.

This scenario is to be considered a misconfiguration, since the 802.1Q standard does not necessarily force the users to use the native VLAN in these cases. As a matter of fact, the proper configuration that should always be used is to clear the native VLAN from all 802.1Q trunks (alternatively, setting them to 802.1q-all-tagged mode achieves the exact same result). In cases where the native VLAN cannot be cleared, then always pick an unused VLAN as native VLAN of all the trunks; don't use this VLAN for any other purpose. Protocols like STP, DTP, and UDLD should be the only rightful users of the native VLAN and their traffic should be completely isolated from any data packet.

ARP Attacks
The ARP protocol is quite an old technology. The ARP RFC is from a time when everyone in a network was supposed to be "friendly" and therefore there was no security built into the ARP function. As a consequence, anyone can claim to be the owner of any IP address they like. To be more precise, anyone can claim that his or her MAC address is associated to any IP address within a specific subnet. This is possible because ARP requests or replies carry the information about the L2 identity (MAC address) and the L3 identity (IP address) of a device and there is no verification mechanism of the correctness of these identities.

Again, this is another case where lack of a precise and reliable means of identification of a device leads to a serious security vulnerability. Also, this is a perfect example of why by compromising a lower level in the OSI stack it's possible to directly affect an upper level without the upper layer being aware of the problem. (ARP is a unique specimen of protocol living and breathing in the L2 world but logically residing at the boundary between the Data Link and the Network layer in the OSI stack.)

The ARP attacks that @stake performed were targeted to fool a switch into forwarding packets to a device in a different VLAN by sending ARP packets containing appropriately forged identities. However, in all Cisco devices VLANs are orthogonal to and therefore independent from MAC addresses: so by changing a device's identity in an ARP packet, it's not possible to affect the way it communicates with other devices across VLANs. As a matter of fact, as the report states, any VLAN hopping attempt was thwarted.

On the other hand, within the same VLAN, the so-called ARP poisoning or ARP spoofing attacks are a very effective way to fool end stations or routers into learning counterfeited device identities: this can allow a malicious user to pose as intermediary and perform a Man-In-the-Middle (MiM) attack.

The MiM attack is performed by impersonating another device (for example, the default gateway) in the ARP packets sent to the attacked device: these packets are not verified by the receiver and therefore they "poison" its ARP table with forged information.

This type of attack can be prevented either by blocking the direct communication at L2 between the attacker and the attacked device or by embedding more intelligence into the network so that it can check the forwarded ARP packets for identity correctness. The former countermeasure can be achieved with Cisco Catalyst Private VLANs or Private VLAN Edge features. The latter can be achieved by using a new feature called ARP Inspection, available first in CatOS 7.5 on the Cisco Catalyst 6500 Supervisor Engine II and a little later also in the Cisco IOS Software for the Cisco Catalyst switches.

Private VLAN Attack
"Private VLAN attack" is actually a misnomer because it corresponds not to a vulnerability but rather to the expected behavior of the feature. Private VLANs is a L2 feature and therefore it is supposed to isolate traffic only at L2. On the other hand, a router is a Layer 3 (L3) device and when it's attached to a Private VLAN promiscuous port it is supposed to forward L3 traffic received on that port to whatever destination it is meant to, even if it's in the same subnet as the source (@stake refers to this behavior as Layer 2 Proxy).

Therefore, it is absolutely normal for two hosts in an Isolated VLAN to fail to communicate with each other through direct L2 communication and instead to succeed to talk to each other by using the router as a packet relay.

As with regular routed traffic, packets relayed through L2 Proxy can be filtered, if desired, through the configuration of an appropriate ACL on the forwarding device.

Here is a simple example of output Cisco IOS ACL to block the relayed traffic:
deny subnet/mask subnet/mask
permit any subnet/mask
deny any any

Multicast Brute Force Attack
This attack tries to exploit switches' potential vulnerabilities (read: bugs) against a storm of L2 multicast frames. @stake's test was designed to ascertain what happens when a L2 switch receives lots of L2 multicast frames in rapid succession. The correct behavior should be to constrain the traffic to its VLAN of origin, the failure behavior would be to leak frames to other VLANs.

In @stake's results, this type of attack proved ineffective against Cisco Catalyst switches because they correctly contained all the frames within their appropriate broadcast domain (no surprise here: after all, in all Catalyst switches broadcasts are just special cases of multicasts).

Spanning-Tree Attack
Another attack that tries to leverage a possible switch weakness (for example, bug) is the STP attack. All of the Cisco Catalyst switches tested by @stake support this protocol. By default, STP is turned on and every port on the switch both speaks and listens for STP messages. @stake tried to see if Cisco PVST (Per VLAN Spanning Tree) would fail open across1 multiple VLANs under specific conditions. The attack consisted in sniffing for STP frames on the wire to get the ID of the port STP was transmitting on. Next, the attacker would begin sending out STP Configuration/Topology Change Acknowledgement BPDUs announcing that he was the new root bridge with a much lower priority.

During this procedure broadcast traffic was injected by the testers to discover any possible VLAN leaks, but none were found. This is an indication of the robustness of STP's implementations on Cisco switches.

Random Frame Stress Attack
This last test can have many incarnations but in general it consists in a brute force attack that randomly varies several fields of a packet while keeping only the source and destination addresses constant. After repetitive testing by @stake's engineers, no packets were found to have successfully hopped VLANs.

Private VLANs can be used in this context to better isolate hosts at L2 and shield them from unwanted malicious traffic from untrustworthy devices. Communities of mutually-trusting hosts can be created so as to partition a L2 network into subdomains where only friendly devices are allowed to communicate with each other.

Router-Based Firewall Solution

The Cisco IOS Firewall feature set provides network security with integrated, inline security solutions. The IOS Firewall feature set is a suite of security services provisioning a single point of protection at the network perimeter. In addition, the IOS Firewall feature is widely available on a range of IOS software-based devices, thereby offering sophisticated security and policy enforcement for network connections.

The Cisco IOS Firewall feature is a stateful-inspection firewall engine with application-level intelligence. This provides dynamic control to permit or deny traffic flow, thereby providing enhanced security. In the simplest form, the principal function of a firewall is to monitor and filter traffic.

Cisco routers can be configured with the IOS Firewall feature in one of the following deployment scenarios:

• A firewall router facing the Internet.
• A firewall router to protect the internal network from the external network. An external network can be any network outside the organization (for example, a customer or a partner network).
• A firewall router between groups of networks in the internal network.
• A firewall router that provides secure connections to or from remote or branch offices.

Cisco IOS Software provides an extensive set of security features to design customized firewall solutions to fit an organization's security policy. A Cisco networking device running Cisco IOS Software can be configured to function as a firewall by using several solutions available in the IOS Firewall feature set.

The Cisco IOS Firewall consists of several major subsystems:

Cisco IOS Firewall stateful packet inspection (SPI): SPI provides true firewall capabilities to protect networks against unauthorized traffic and to control legitimate business-critical data.

Context-Based Access Control (CBAC): CBAC (now known as Classic Firewall) is a stateful-inspection firewall engine that provides dynamic traffic filtering functionality.

Intrusion Prevention System (IOS IPS) (formerly known as IOS IDS): Cisco IOS IPS offers integrated IPS functionality as part of the Cisco IOS Software. From IOS Version 12.3T, Cisco IOS IPS replaces the previous IOS IDS functionality by implementing a large part of classic sensor functionality as part of the IOS-based device. IOS IPS is an inline intrusion detection sensor that scans packets and sessions flowing through the router to identify any of the Cisco IOS IPS signatures that protect the network from internal and external threats.

Authentication proxy: The authentication proxy feature (also known as Proxy Authentication) allows security policy enforcement on a per-user basis. Earlier, user access and policy enforcement was associated with a user's IP address or a single global policy applied to an entire user group. With the authentication proxy feature, users can now be authenticated and authorized on a per-user policy with access control customized to an individual level.

Port-to-Application Mapping (PAM): PAM allows you to customize TCP or User Datagram Protocol (UDP) port numbers for network services or applications to nonstandard ports (for example, HTTP service using TCP port 8080 instead of the default port 80). CBAC inspection leverages this information to examine nonstandard application-layer protocols.

Network Address Translation (NAT): NAT hides internal IP addresses from networks that are external to the firewall. NAT was designed to provide IP address conservation and for internal IP networks that use the unregistered private address space per RFC 1918. NAT translates these private IP addresses into legal registered addresses as packets traverse through the NAT device. This provides a basic low-level security by effectively hiding the internal network from the outside world.

Zone-Based Policy Firewall (ZFW): ZFW is a new enhanced security tool available in the Cisco IOS Software-based firewall feature set. ZFW offers a completely revamped configuration syntax that offers network protection that uses intuitive policies and increased granularity to control unauthorized network access.

Several other security solutions are available on Cisco IOS. These include Lock-and-Key, Reflexive access list, TCP Intercept, IPsec, and AAA support.

Layer2 Security Checklist

A security checklist is an important document containing a summary of various guidelines and instructions for secure implementations. Layer2 security checklists can be viewed as templates for device lockdown and security implementation guidelines. You can use the following checklist as a quick summary and working guide to the cisco device security configuration.

• Manage the switches in a secure manner. For example, use SSH, authentication mechanism, access list, and set privilege levels.
• Restrict management access to the switch so that untrusted networks are not able to exploit management interfaces and protocols such as SNMP.
• Always use a dedicated VLAN ID for all trunk ports. Be skeptical; avoid using VLAN 1 for anything.
• Disable DTP on all non-trunking access ports.
• Deploy the Port Security feature to prevent unauthorized access from switching ports.
• Use the Private VLAN feature where applicable to segregate network traffic at Layer 2.
• Use MD5 authentication where applicable.
• Disable CDP where possible.
• Prevent denial-of-service attacks and other exploitation by disabling unused services and protocols.
• Shut down or disable all unused ports on the switch, and put them in a VLAN that is not used for normal operations.
• Use port security mechanisms to provide protection against a MAC flooding attack.
• Use port-level security features such as DHCP Snooping, IP Source Guard, and ARP security where applicable.
• Enable Spanning Tree Protocol features (for example, BPDU Guard, Loopguard, and Root Guard).
• Use Switch IOS ACLs and Wire-speed ACLs to filter undesirable traffic (IP and non-IP).

Control Plane Policing (CoPP) Feature

The Cisco Catalyst series switches offer a strong set of integrated security features, including the following:
hardware- and software-based CPU rate limiters (for DoS protection), user-based rate limiting, hardware-based MAC learning, uRPF check in hardware, TCP intercept hardware acceleration, and most important, the Control Plane Policing (CoPP) feature. CoPP is also supported on all Cisco Integrated Services Routers (ISRs). One of the main advantages is that most of these integrated security features are based on hardware and can be enabled concurrently with no performance penalty.

The traffic managed by a device can be divided into three functional components or planes:

• Data plane
• Management plane
• Control plane

The vast majority of traffic flows through the device via the data plane; however, the route processor handles certain traffic, such as routing protocol updates, remote-access services, and network management traffic such as SNMP. This type of traffic is referred to as the control and management plane.

The route processor is critical to network operation. Therefore any service disruption or security compromise to the route processor, and hence the control and management planes, can result in network outages that impact regular operations. For example, a DoS attack targeting the route processor typically involves high bursty traffic resulting in excessive CPU
utilization on the route processor. Such attacks can be devastating to network stability and availability. The bulk of traffic managed by the route processor is handled by way of the control and management planes.

The CoPP feature is used to protect the aforementioned control and management planes; to ensure stability, reachability, and availability and to block unnecessary or DoS traffic. CoPP uses a dedicated control plane configuration through the modular QoS CLI (MQC) to provide filtering and rate limiting capabilities for the control plane packets.

As mentioned earlier, the CoPP feature is available on all major Cisco router series including ISR.


Perform the following steps to configure and apply the CoPP feature:

Step 1. Define a packet classification criterion. There are a number of ways to categorize the type of traffic—for example, by using an access list or protocol or IP precedence values.

Code View:
Hostname(config)# class-map {traffic_class_name}
Hostname(config-cmap)# match {access-list protocol ip prec ip dscp vlan}

Step 2. Define a service policy. Note that flow policing is the only valid option available (as of this writing) in the policy map for CoPP.

Code View:
Hostname(config-pmap)# policy-map {service_policy_name}
Hostname(config-pmap)# class {traffic_class_name}
Hostname(config-pmap-c)# police conform-action exceed-action

Step 3. Enter control plane configuration mode using the control-plane global command. In this CP submode, the service policies are attached to the control plane.

Hostname(config)# control-plane

Step 4. Apply QoS policy configured to the control plane.
Hostname(config-cp)# service-policy {input output} {service_policy_name}

Dynamic ARP Inspection (DAI)

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 ARPbased 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.

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


Below Figure shows an example of an attacker attempting to spoof and hijack traffic for an important address (a default gateway in this example) by broadcasting to all hosts spoofing the MAC address of the router (using a gratuitous ARP). This will poison ARP cache entries (create an invalid ARP entry) on Host A and Host B, resulting in data being redirected to the wrong destination. Because of the poisoned entries, when Host A sends data destined for the router, it is incorrectly sent to the attacker instead. Dynamic ARP inspection locks down the IPMAC
mapping for hosts so that the attacking ARP is denied and logged.

The dynamic ARP Inspection (DAI) feature safeguards the network from many of the commonly known man-inthe-middle (MITM) type attacks. Dynamic ARP Inspection ensures that only valid ARP requests and responses are forwarded.

Below Figure illustrates the DAI feature in action and shows how the intruder is blocked on the untrusted port when it is trying to poison ARP entries.

DAI in a DHCP Environment

As mentioned earlier, DAI relies on the entries in the DHCP snooping binding database to verify IP-to-MAC address bindings. Configure each secure interface as trusted using the ip arp inspection trust interface configuration command. The trusted interfaces bypass the ARP inspection validation checks, and all other packets are subject to inspection when they arrive on untrusted interfaces.

Enable DAI on a per-VLAN basis by using the ip arp inspection vlan [vlan-range] command from the global configuration command.

Below example shows how to configure an interface as trusted and how to enable DAI for VLANs 5 through 10.

Example:- DAI in a DHCP Environment Configuration Example

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

In non-DHCP environments, because there is no DHCP snooping binding database, the DAI can validate ARP packets against a user-defined ARP ACL to map hosts with a statically configured IP address to their MAC address.

Use the arp access-list [acl-name] command from the global configuration mode on the switch to define an ARP ACL and apply the ARP ACL to the specified VLANs on the switch.

Below Example shows how to configure an ARP ACL to permit ARP packets from host IP address 10.1.1.11 with MAC address 0011.0011.0011 and how to apply this ACL to VLAN 5 with the interface configured as untrusted.

Example: DAI in a Non-DHCP Environment Configuration Example


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

Use the show ip arp inspection vlan [vlan# or range] command to verify the configuration.

Rate Limiting Incoming ARP Packets

Because the switch CPU performs the DAI, there is a potential for an ARP flooding denial-of-service (DoS) attack resulting in performance degradation. To prevent this, ARP packets can be rate limited using the ip arp inspection limit command from the interface configuration mode to limit the rate of incoming ARP requests and responses. By default, 15 pps (packets per second) is allowed on untrusted interfaces; however, there is no limit on trusted interfaces. The burst interval is 1 second.

When the rate of incoming ARP packets exceeds the configured thresholds, the port is placed in the errordisabled state. The port will remain in this state until the user intervenes or the errdisable recovery cause arp-inspection interval [seconds] command is enabled, so that ports can automatically recover from this state after a specified timeout period.

Use the show ip arp inspection interfaces to display the trust state, the rate limit (pps stands for packets per second), and the burst interval configured for the interfaces.

Use the show ip arp inspection vlan [vlan# or range] command to display the DAI configuration and the operation state of the VLANs configured on the switch.

ARP Validation Checks

Specific additional checks can be performed on incoming ARP packets to validate the destination MAC address, the sender IP address in ARP requests, the target IP address in ARP responses, or the source MAC address. Use the ip arp inspection validate {[src-mac] [dst-mac] [ip]} command from the global configuration mode to enable these additional ARP validation checks.

Use the show ip arp inspection statistics command to display packet statistics on DAI-configured VLANs.

Dynamic Host Configuration Protocol (DHCP) Snooping

The DHCP Snooping feature provides network protection from rogue DHCP servers. It creates a logical firewall between untrusted hosts and DHCP servers. The switch builds and maintains a DHCP snooping table (also called DHCP binding database), shown in below Figure. In addition, the switch uses this table to identify and filter untrusted messages from the network. The switch maintains a DHCP binding database that keeps track of DHCP addresses that are assigned to ports, as well as filtering DHCP messages from untrusted ports. For incoming
packets received on untrusted ports, packets are dropped if the source MAC address does not match MAC in the binding table entry.



Below Figure illustrates the DHCP Snooping feature in action, showing how the intruder is blocked on the untrusted port when it tries to intervene by injecting a bogus DHCP response packet to a legitimate conversation between the DHCP client and server.




The DHCP Snooping feature can be configured for switches and VLANs. When enabled on a switch, the interface acts as a Layer 2 bridge, intercepting and safeguarding DHCP messages going to a Layer 2 VLAN. When enabled on a VLAN, the switch acts as a Layer 2 bridge within a VLAN domain.

For DHCP Snooping to function correctly, all DHCP servers connected to the switch must be configured as trusted interfaces. A trusted interface can be configured by using the ip dhcp snooping trust interface configuration command. All other DHCP clients connected to the switch and other ports receiving traffic from outside the network or firewall should be configured as untrusted by using the no ip dhcp snooping trust interface configuration command.

To configure the DHCP Snooping feature, first enable DHCP Snooping on a particular VLAN by using the ip dhcp snooping vlan [vlan-id] command in global configuration mode. (Repeat this command for multiple VLANs.)

Next, enable DHCP Snooping globally by using the ip dhcp snooping command from the global configuration mode. Both options must be set to enable DHCP snooping.

In Example below, the DHCP server is connected to the FastEthernet0/1 interface and is configured as a trusted port with a rate limit of 100 packets per second. The rate limit command ensures that a DHCP flood will not overwhelm the DHCP server. DHCP Snooping is enabled on VLAN 5 and globally activated.

Example: DHCP Snooping Configuration
Switch(config)# interface Fastethernet0/1
Switch(config-if)# ip dhcp snooping trust
Switch(config-if)# ip dhcp snooping limit rate 100
Switch(config-if)# exit
Switch(config)# ip dhcp snooping vlan 5
Switch(config)# ip dhcp snooping
Switch(config)# ip dhcp snooping information option

Use the show ip dhcp snooping command to display DHCP snooping settings. Use the show ip dhcp snooping binding command to display binding entries corresponding to untrusted ports.

Device Security Checklist

A security checklist is an important document containing a summary of various guidelines and instructions for secure implementations. Device security checklists can be viewed as templates for device lockdown and security implementation guidelines. You can use the following checklist as a quick summary and working guide to the cisco device security configuration.

• Device security policy written, approved, distributed, and reviewed on regular basis.
• Facilities (room, building, area) housing the devices secured—physical security.
• Password policies to ensure that good passwords are created that cannot be easily
  guessed or hacked.
• Password encryption used so that passwords are not visible when device configuration is
  viewed.
• Access methods such as Console, VTY, AUX using ACLs, and authentication mechanisms
  secured.
• Access methods such as SSH with AAA authentication chosen wisely.
• Unneeded services and protocols to be disabled.
• Unused interfaces shut down or disabled.
• Configuration hardened for network services and protocols in use (for example, HTTP
  and SNMP).
• Port and protocol needs of the network and use access lists to limit traffic flow
  identified.
• Access list for anti-spoofing and infrastructure protection and for blocking reserved and
  private addresses considered.
• Routing protocols established that use authentication mechanisms for integrity.
  Appropriate logging enabled with proper time information.
• Device's time of day set accurately, maintained with NTP.