The Management Plane Protection (MPP) feature in Cisco IOS software provides the capability to restrict the interfaces on which network management packets are allowed to enter a device. The MPP feature allows a network operator to designate one or more router interfaces as management interfaces. Device management traffic is permitted to enter a device only through these management interfaces. After MPP is enabled, no interfaces except designated management interfaces will accept network management traffic destined to the device.

http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/htsecmpp.html

This feature was added in 12.4(6)T but only seems to be documented under Feature Guides, not in the main IOS command reference or configuration guides.  Gee, thanks Cisco!

A configuration example (based on the practice lab task above):

control-plane host
  management-interface GigabitEthernet0/1 allow ssh snmp
end

When this configuration is applied to the router (assuming SSH has been previously configured), remote SSH and SNMP connections to the router will only be accepted when entering through Gi0/1.  This is based on the interface, not on the IP address.  SSH and SNMP connections to Gi0/1′s IP address entering through other interfaces will fail.  In addition, other management traffic (telnet, etc.) entering through Gi0/1 will also fail.  The complete list of what IOS considers management traffic is:

• SSH v1 and v2
• telnet
• HTTP / HTTPS
• FTP
• SNMP (all version)
• TFTP
• BEEP (Blocks Extensible Exchange Protocol)

Note that other traffic destined for the router (such as routing protocols and ARP) are not affected, nor is traffic routed through the management interface.  This is different from the management-interface functionality on an ASA, where the designated port can only be used for management traffic.

In summary, it is quite annoying that Cisco doesn’t seem to have actually documented this feature properly, since it has the potential to be a very useful tool in the network administrator’s toolbox.  Depending on the network design, enabling MPP makes it less likely that a management protocol becomes accessible on an interface connected to a hostile network, while simplifying interface ACLs needed to properly secure the device.

regex domlist1 "facebook.com"
regex domlist2 "myspace.com"
!
class-map type regex match-any DomainBlockList
  match regex domlist1
  match regex domlist2
!
class-map type inspect http match-all BlockDomainsClass
  match request header host regex class DomainBlockList
!
policy-map type inspect http http_inspection_policy
  class BlockDomainsClass
  reset log
!
policy-map global_policy
  class inspection_default
  inspect http http_inspection_policy
!
service-policy global_policy global
wr mem

tcp-map BGP_FIX
  tcp-options range 19 19 allow
!
access-list BGP permit tcp any any eq 179
!
class BGP
  match access-list BGP
  !! could also use match protocol tcp eq bgp
!
policy-map global_policy
  class BGP
    set connection advanced-options BGP_FIX
    set connection random-sequence-number disable
!

aaa-server ACS_SERVER protocol tacacs+
aaa-server ACS_SERVER (inside) host 1.2.3.4
    key myACSkey
!
access-list outbound_auth permit tcp any any eq 23
access-list outbound_auth permit tcp any any eq 80
!
aaa authentication match outbound_auth inside ACS_SERVER

There are additional options to configure HTTP vs. HTTPS and redirection vs. basic HTTP authentication.  The documentation is a bit confusing, so I will be labbing this up shortly.

The 8.0 release of the ASA software solves this problem by introducing an enhanced Service object group that allows a mix of multiple protocols within the same group.  Unfortunately, the 8.0 and 8.2 ASA configuration guides don’t appear to cover this new type of service group or show an example.

object-group network DMZ_NET
  network-object 1.2.3.0 255.255.255.0
!
object-group service DMZ_SERVICES
  service-object tcp eq 80
  service-object udp eq 53
  service-object tcp eq 53
  service-object icmp
!
access-list DMZ extended permit object-group DMZ_SERVICES any object-group DMZ_NET

I’ll be using a mix of both IPexpert and InternetworkExpert materials for my preparation.  Both vendors’ new technology-focused lab releases look terrific.  Hopefully, by the time I work through them they’ll have some updated 8-hour full mock labs available.

For the most part, I’ll be relying on Dynamips for lab work, since now that the VPN 3000 is no longer in the lab everything except for the switches can be simulated.  I’ll have to rent some rack time to review the switch-based security stuff from R&S, but for the most part I’m not worried there.

Local Networks

In most sane networks, you should never see inbound traffic from your own address space. Thus, if you have 12.3.45.0/24 as your public address space, your inbound ACL should block traffic appearing to be sourced from this network.

RFC 1918

10.0.0.0 /8
172.16.0.0 /12
192.168.0.0 /16

An easy way to remember the CIDR value for these (found on GroupStudy): each is 4 greater than the last.

Local-only Networks

0.0.0.0 /8
127.0.0.0 /8 – note: not just 127.0.0.1!
169.254.0.0 /16

These are (respectively) the “this network” range, the localhost address space, and the Microsoft AutoNet network (also called APIPA, for Automated Private IP Addressing).

Reserved Networks

192.0.2.0 /24 – TEST-NET, e.g. example.com
198.18.0.0 /15 – Benchmark networks
240.0.0.0 /4 – Class E

Multicast

224.0.0.0 /4

The multicast address space will never appear as a source address in legitimate traffic. A multicast IP is always a destination.

Unassigned Address Space

Many experts recommend filtering all unallocated address space (networks that have not been assigned to users or ISPs by the various numbering authorities, such as ARIN or APNIC). This requires diligence on the part of network administrators to track new address allocations and keep ACLs up-to-date, to avoid blackholing legitimate traffic from newly-assigned networks. For more information, see the Bogon Reference at Cymru.

interface FastEthernet0/0
  description TO_ISP
  ip nat outside
!
interface FastEthernet0/1
  description TO_LAN
  ip nat inside
!
ip access-list standard NAT_SOURCE
  permit 10.1.1.0 0.0.0.255
!
ip nat inside source list NAT_SOURCE interface FastEthernet0/0 overload