Otherwise you’ll spend an hour beating your head against the wall trying to figure out why ssh slavehost date works, but send2slaves -t slavehost doesn’t.

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.

Assumptions

1. The ACE has been configured (possibly using the setup wizard) with interface and trunking options.
2. You are deploying the ACE in “routed mode”, e.g. the ACE is the default gateway for the backend servers and the VIPs live on a different network on the “outside” interface.
3. You have three web servers, WEB1, WEB2, and WEB3 all listening on port 80.

Configuration

Unlike a router, the ACE is a “deny by default” device.  You must explicitly permit any traffic entering the ACE from the network.  Thus, we need an access list (ACL) to allow traffic to our HTTP virtual IP (VIP).

access-list VLAN1 extended permit tcp any host 1.1.1.100 eq www

Next, we need to define our backend servers.  The “inservice” keyword is the ACE equivalent of the “no shutdown” command for an interface.  If you forget it, things won’t work.

rserver host WWW1
  ip address 2.2.2.101
  inservice

rserver host WWW2
  ip address 2.2.2.102
  inservice

rserver host WWW3
  ip address 2.2.2.103
  inservice

Now we need to define a health check, so that the ACE can determine if each backend server is functional and should receive traffic.  We’ll use a very basic HTTP service check at this point. We configure the probe to check each server every 10 seconds and accept the default behavior of marking a server as “failed” if it fails 3 checks. Also by default, the ACE will use an HTTP GET request for the root or “/” URL. That’s fine for this example. Finally, we tell the ACE that a server must respond for at least 60 seconds before it is marked as “back up” after a failure.

An important note: the HTTP probe must have an expected status code or range of codes defined. If you omit this statement, your backend servers will never come up!

probe http HTTP_PROBE
  interval 10
  passdetect interval 60
  expect status 200

Now that we have our backend servers defined, as well as a probe to check their status, we can join them together into a server farm. Again, don’t forget to “inservice” each rserver, or it won’t come up.

serverfarm host HTTP_FARM
  probe HTTP_PROBE
  rserver WWW1
    inservice
  rserver WWW2
    inservice
  rserver WWW3
    inservice

We need to tell the ACE about the virtual IP (VIP) on which we want it to listen. This is done with a class-map.

class-map match-all HTTP_VIP
  2 match virtual-address 1.1.1.100 tcp eq www

Next, we need to define our load-balancing policy, to tell the ACE what to do with traffic once it hits the VIP. In this case, we just direct it to the server farm defined above.

policy-map type loadbalance http first-match HTTP_POLICY
  class class-default
    serverfarm HTTP_FARM

The last piece we need is something to tie the policy to the VIP. We do this with a policy-map of type “multi-match”. For convenience, we configure the VIP to respond to ICMP echo request (pings) as long as at least one backend server is up.

policy-map multi-match VIPs
  class HTTP_VIP
    loadbalance vip inservice
    loadbalance policy HTTP_POLICY
    loadbalance vip icmp-reply active

Finally, we need to apply our policy to the “outside” interface of the ACE, bringing up our VIP. We also need to apply the ACL we created above to allow the HTTP requests inbound.

interface vlan 1
  description Public Network
  ip address 1.1.1.1 255.255.255.0
  access-group input VLAN1
  service-policy input VIPs
  no shutdown

That’s the end! You can grab the full configuration here.

In this example, we want to manipulate the routing as follows:

• Traffic between the 192.168.1.0/24 local network and 10.0.1.0/24 remote network should prefer PATH #1
• Traffic between the 192.168.2.0/24 local network and 10.0.2.0/24 remote network should prefer PATH #2

Note: for the purpose of this example we will assume that the specified local and remote networks only talk to each other. We don’t need to consider traffic between 192.168.1.0/24 and other remote networks, for example.

router bgp 65000
  network 192.168.1.0 mask 255.255.255.0
  network 192.168.2.0 mask 255.255.255.0
  !
  neighbor 1.1.1.1 remote-as 65534
  neighbor 1.1.1.1 send-community
  neighbor 1.1.1.1 route-map PATH1-LEARN in
  neighbor 1.1.1.1 route-map PATH1-ADVERTISE out
  !
  neighbor 2.2.2.2 remote-as 65534
  neighbor 2.2.2.2 send-community
  neighbor 2.2.2.2 route-map PATH2-LEARN in
  neighbor 2.2.2.2 route-map PATH2-ADVERTISE out
!

First we need to define our ACLs to specify which traffic prefers which path

ip access-list standard PREFER-PATH1-LOCAL
  permit 192.168.1.0 0.0.0.255
!
ip access-list standard PREFER-PATH1-REMOTE
  permit 10.0.1.0 0.0.0.255
!
ip access-list standard PREFER-PATH2-LOCAL
  permit 192.168.2.0 0.0.0.255
!
ip access-list standard PREFER-PATH2-REMOTE
  permit 10.0.2.0 0.0.0.255
!

As we learn routes, we raise the local preference on routes coming from the preferred path, so they are chosen over the same routes learned on the other path with a default of 100.

The permit 999 ensures all routes are still learned from both peers, even if they’re not being manipulated.

route-map PATH1-LEARN permit 10
  match ip address PREFER-PATH1-REMOTE
  set local-preference 110
!
route-map PATH1-LEARN permit 999
!
route-map PATH2-LEARN permit 10
  match ip address PREFER-PATH2-REMOTE
  set local-preference 110
!
route-map PATH2-LEARN permit 999
!

For incoming traffic, we need to influence the ISP’s routing decisions. There are several ways of doing this, including the MED. In our case, we’ll use the ISP’s pre-defined community values to force them to set a local preference on certain routes.

Again, the permit 999 rules ensure that we’re still sending all our routes to both peers, even if they don’t get tagged.

route-map PATH1-ADVERTISE permit 10
  match ip address PREFER-PATH1-LOCAL
  set community 65534:110
!
route-map PATH1-ADVERTISE permit 999
!
route-map PATH2-ADVERTISE permit 15
  match ip address PREFER-PATH2-LOCAL
  set community 65534:110
!
route-map PATH2-ADVERTISE permit 999
!

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.

Section 1: Layer 2 configuration

- when creating an SVI for a given VLAN, always make sure the VLAN itself exists on all switches in the transit path for that VLAN.

- if the lab specifies restricting “management access”, don’t forget to check if the HTTP server is enabled and add a similar access class to it as to the VTY’s.

- Filtering traffic by ethertype

mac access-list extended F0_15
  deny   any any 0x1234 0x0
  permit any any
!
int fa0/15
  mac access-group F0_15 in
!

- VLAN filtering by MAC address

mac access-list extended VL123
  permit host 0000.1234.4321 host 0000.4321.1234
!
vlan access-map VL123 10
  action forward
  match mac address VL123
vlan access-map VL123 999
  action drop
!
vlan filter VL123 vlan-list 123

No real problems with this section other than interpretation on the VLAN filtering. In a lab, I’d ask the proctor if they meant traffic from this *range* of MAC addresses or just between the two.

Section 2: Pix / ASA Configuration

- When originating a default route and running RIP on both inside & outside, use a route-map with ‘match interface’ to control which side we send the default route to.

- don’t be so quick to assume an answer. Configured HTTP/HTTPS and missed that the question said a “Web/SMTP/DNS” server so left out a bunch of the ACL.

- when configuring AAA through a firewall, don’t forget to set the source int on the remote device if required.

- remember that a transparent firewall will not pass anything inbound by default (except ARP) without an access-list. Just like a routed firewall.

- a transparent firewall must have a management IP address configured or it will not pass any traffic, even if that traffic would otherwise be allowed.

- always check for required single/multiple changes, since it needs a reboot of the device and wastes time.

- basic process for setting up contexts

admin-context FOO
context FOO
  config-url disk0:/FOO.txt
!
context BAR
  config-url disk0:/BAR.txt
  allocate-interface eth0/0
  allocate-interface eth0/1
!

- when configuring local authentication on the ASA, don’t forget to explicitly enable it, for ssh/telnet

hostname ASA1
domain-name ipexpert.com
crypto key generate rsa general-keys
ssh 1.2.3.0 255.255.255.0 inside
username cisco password cisco
aaa authentication ssh console LOCAL

Section 3: IDS Configuration

- I need to spend time learning the IDS command line. I’m fairly solid through IDM but not through the CLI.

- IOS IPS basic config

ip ips name FOO
ip ips notify log
logging host 1.2.3.4
logging on
int se0/1/0
ip ips FOO in
!

Section 7: VPN Configuration

- when configuring L2L VPN’s on the VPN3000 through the GUI, be careful when configuring the interesting traffic. The mask is specified as a *wildcard* mask, e.g. 0.0.0.255, not a subnet mask.