1. Define your security zones
Firstly choose what security zones you wish to define, you can choose almost any name you like I have just chosen internal and external for my test, there’s no reason why you couldn’t have 3, 4 or more zones if required. There is a default zone called “local” which is for traffic originated/sent to the router as opposed to passing through it. So as far as I am aware if you don’t play around with the local zone it shouldn’t affect traffic your routing protocol traffic, as it does not pass through it. Define the zones with the following commands;

Router(config)#zone security internal
Router(config-sec-zone)#exit
Router(config)#zone security external
Router(config-sec-zone)#exit

2. Assign interfaces to the relevant zones
Under each interface you wish to link to a zone go under the interface and use the following command where the interface is linked to the zone “internal”.

Router(config-if)#zone-member security internal

3. Define your class maps
Split your traffic up into classes and make sure you use “type inspect” option when defining them, the simple one below uses NBAR to classify http packets. I wont explain class or policy maps in much detail as most other candidates should be familiar with them from MQC.

class-map type inspect match-all http
 match protocol http

4. Tie up the class maps in a policy map
Now to define the action for each of the classes defined in the class maps, make sure you use the “inspect” option if you wish to inspect the traffic to allow return traffic. In the example below I have named the policy zonebasedfw.

policy-map type inspect zonebasedfw
 class type inspect http
  inspect
 class class-default
  drop

5. Tie it all together in a zone pair
Finally create a zone pair with your own name I chose “internal-to-external”, define your source and destination zones and the pre defined policy.

zone-pair security internal-to-external source internal destination external
 service-policy type inspect zonebasedfw

Verification
There are 2 handy verification commands which I am aware of, firstly sh zone security as shown below, this indicates which interfaces are linked to which zone;

Router#sh zone security
zone self
  Description: System defined zone

zone internal
  Member Interfaces:
    FastEthernet0/0
    FastEthernet1/0

zone external
  Member Interfaces:
    FastEthernet0/1

And sh zone-pair security which shows the details from the zone pair, notably which policy has been applied in which direction.

Router#sh zone-pair security
Zone-pair name internal-to-external
    Source-Zone internal  Destination-Zone external
    service-policy zonebasedfw

The process is actually standardised Best Practice in BCP 38 “Network Ingress Filtering” which all service providers should implement if they have Internet facing services for good karma.

There are a number of ways of implementing ingress filtering, one of the technically simplest is to create ACLs of your customers global address ranges and only allow packets sourced from those ranges to leave your network. Configuration wise Unicast Reverse Path Forwarding (uRPF) is in my opinion the simplest way of managing this and it has a couple of extra features.

uRPF checks incoming unicast packets and validates that a return path exists, there is not much point in forwarding a packet if it doesnt know how to return it right?

There are 2 methods of implementation of uRPF strict and loose. Strict mode is where the source of the packet is reachable via the interface that it came from, this is nice for extra security on the edge of your network but not so good if you have multiple edges towards the Internet eg you peer at multiple IXPs where you might expect asymmetric routing. In such cases loose mode is used which checks that a return route exists in the routing table.

Configuration
The configuration is super simple, after CEF has been enabled just go to the interface you wish to check inbound traffic and use the following command, with the “rx” option for strict mode or “any” for loose mode.

Router(config-if)#ip verify unicast source reachable-via ?
  any  Source is reachable via any interface
  rx   Source is reachable via interface on which packet was received

Verification
Obviously you can check the running config to see if its configured but if your a fan of using other show commands its visible under the sh cef interface and sh ip interface as shown below;

Router#sh cef  interface fastEthernet 0/0 | i RPF
  IP unicast RPF check is enabled

Router# sh ip int fa0/0 | i verify
  IP verify source reachable-via RX

Like with anything I thoroughly recommend you test this out before rolling it out to your production systems as on high traffic networks it can cause CPU problems in such cases most people change the amount of sampling. If you are worried about this Cisco has produced a white paper on working out the resource utilisation of Netflow.

Configuration

First of all to configure it choose the interfaces you want to monitor and decide if you want to monitor the ingress, egress or both;

Router(config-if)#ip flow ?
egress Enable outbound NetFlow
ingress Enable inbound NetFlow

There are plenty of extra global options available, below is an example of the configuration to capture the packet length, TTL and the MAC addresses.

ip flow-capture packet-length
ip flow-capture ttl
ip flow-capture mac-addresses

Most implementations of Netflow export the data to a remote server for analysis. There are plenty of Netflow analysis software choices. There are 3 versions supported on Cisco routers at present 1, 5 & 9. Version 1 was designed for classful networks and is almost obsolete, Version 5 is designed for IPv4 Unicast flows, and Version 9 is the newest built and can carry BGP Next Hop information, IPv6, Multicast, and MPLS.

Netflow wont export each packets headers as a single packet but it will collect the packet headers together and report them in a single UDP packet via export. In my example at the bottom of this 715 flows have been exported in 48 UDP packets.

ip flow-export version 9
ip flow-export destination 10.10.10.10 555

Another handy option is configuring logging of the top talkers, this is handy if you have a problem with a remote site where they are complain of problems with this enabled you can see the biggest bandwidth hogs in the period of the cache timeout.

ip flow-top-talkers
        top 100
        sort-by bytes
        cache-timeout 3600000
        match protocol tcp

Verification

Most importantly verification its actually working, show ip flow interface below confirms which interfaces are sampling for netflow

Router#sh ip flow interface
Dot11Radio0
  ip flow ingress
  ip flow egress
BVI1
  ip flow ingress
  ip flow egress

If you configured top talkers then show ip flow top-talkers will show you the bandwidth hogs.

Router#sh ip flow top-talkers

SrcIf         SrcIPaddress    DstIf         DstIPaddress    Pr SrcP DstP Bytes
Di0           74.125.165.145  BV1*          10.10.10.100    06 0050 D89F    92K
BV1           10.10.10.100    Local         10.10.10.1      06 D7DC 0017    19K
BV1           10.10.10.100    Di0           74.125.165.145  06 D89F 0050  7381
BV1           10.10.10.100    Di0           209.85.229.138  06 D89E 0050  1466
Di0           209.85.229.138  BV1*          10.10.10.100    06 0050 D89E  1379
5 of 100 top talkers shown. 5 of 9 flows matched.

Finally if you configured netflow export verify it with the show ip flow export command.

Router#sh ip flow export
Flow export v9 is enabled for main cache
  Export source and destination details :
  VRF ID : Default
    Destination(1)  10.10.10.10 (555)
  Version 9 flow records
  715 flows exported in 48 udp datagrams
  0 flows failed due to lack of export packet
  48 export packets were sent up to process level
  0 export packets were dropped due to no fib
  0 export packets were dropped due to adjacency issues
  0 export packets were dropped due to fragmentation failures
  0 export packets were dropped due to encapsulation fixup failures

The RSA authentication is managed by an RSA application called the RSA Authentication Manager which is currently on version 7.1, this handles replication between servers in a primary to replica’s fashion. Each Authentication Manager can have the RSA “Steel Belted RADIUS” server installed which allows RADIUS clients to authenticate against it. If you are using 2 part authentication you really need to have build in redundancy as if the devices are at a remote site from the RADIUS server they will not be able to perform 2 part authentication in the case of a network or server failure, but we all know that single points of failure are a bad idea?

Authentication Manager Configuration

I wont go to much into how to install and manage the RSA Authentication Manager as there is loads of documentation from RSA on that matter, but there is not much on getting it to authenticate console or vty line users, but luckily its really simple. For each Cisco device that you wish to authenticate users on add it as a RADIUS client in the Authentication Manager, with the model set to “IOS11.1 or later” and then add an associated RSA agent. After this you will need to remember to force replicate the information to the replica RADIUS servers as it does not do this automatically (authentication on the replicas will fail if you don’t do this!)

IOS Configuration

As like most AAA things make sure the aaa new-model is on

aaa new-model

Next we should have sure we have a local user name and password on the system, if the RADIUS servers does not send back a response then we can login using this account. If the response from the RADIUS server comes back as failed from the RADIUS server it will NOT check the local username and password, so this will only be used if the system receive an invalid or no response form the RADIUS server.

username cisco privilege 15 password 0 cisco

Now to enable the RADIUS servers group to be used for the authenticating users on login.

aaa authentication login default group radius line enable local

Now to configure the RADIUS servers, add a separate line for each additional server. It defaults to the standard ports 1645 for authorisation and 1646 for accounting. If there are multiple RADIUS servers it will do a full set of timeouts and retransmits to each one before moving onto the next server.

radius-server host 10.0.0.10 auth-port 1645 acct-port 1646 key password

As I mentioned if anything goes wrong with the RADIUS servers it will fail back to using the locally set username and password, using the default time outs, as waiting for the default timemouts this feels like an eternity so we should change them.

radius-server retransmit 3
radius-server timeout 10

Now give it a test, it even happily support next tokencode mode (see the image), this is where the Authentication Manager can ask you to enter your next token if it thinks your token is starting to drift time abit or it just wants to make sure you actually have the token.

Troubleshooting
#show radius statistics is a good show command to check the response times and make sure everything is singing along well

DistSwitch#show radius statistics
       Maximum inQ length: 1
     Maximum waitQ length: 1
     Maximum doneQ length: 1
     Total responses seen: 53
   Packets with responses: 53
Packets without responses: 17
   Average response delay: 3336 ms
   Maximum response delay: 35048 ms
Number of Radius timeouts: 73
     Duplicate ID detects: 0

  Elapsed time since counters last cleared: 1w2d6h22m

Troubleshooting is pretty simple with #debug radius

User Access Verification

Username: exampleuser
Password:

1w1d: RADIUS: ustruct sharecount=1
1w1d: RADIUS: Initial Transmit tty0 id 45 10.10.0.10:1645, Access-Request, len 66
1w1d:         Attribute 4 6 0A0A34A0
1w1d:         Attribute 5 6 00000000
1w1d:         Attribute 61 6 00000000
1w1d:         Attribute 1 10 62722164
1w1d:         Attribute 2 18 DC6BDD95
DistSwitch>
1w1d: RADIUS: Received from id 45 10.10.20.158:1645, Access-Accept, len 80
1w1d:         Attribute 25 60 53425232
1w1d: RADIUS: saved authorization data for user 80E96540 at 80E95D30
DistSwitch>
DistSwitch>ena
DistSwitch#

If that’s not enough information and your getting alot of timeouts try using Wireshark with a port filter on UDP 1645 will allow you to see the RADIUS rejects, accepts, and challenges.

If the server appears to be rejecting some requests using the real time authentication activity monitor on the RSA Authentication Manager will provide much more detailed information of the reason for the reject or accept.

Right first off we need to enable the aaa new model

DistSwitch(config)#aaa new-model

Then we need to configure dot1x to be used for authentication and as dot1x uses radius define the radius server, pretty standard stuff

DistSwitch(config)#aaa authentication dot1x default group radius
DistSwitch(config)#radius-server host 10.10.10.100 key secretkey

To prevent bad things from happening such as locking yourself out use the following command to only use local login for the lines

DistSwitch(config)#aaa authentication login default line

Now for the interface configuration, to use dot1x the ports must be access ports so lets sort that out

interface FastEthernet0/1
 switchport mode access

This is the most important command and specifies that the port should be either force-authorised where the port is always allowed on the network, force-unauthorised where the port is never allowed on the network, and finally auto where the port is either authorised if dot1x authentication succeeds or unauthorised if it doesnt.

DistSwitch(config-if)#dot1x port-control ?
  auto                PortState will be set to AUTO
  force-authorized    PortState set to Authorized
  force-unauthorized  PortState will be set to UnAuthorized

Still on the interface there are are a couple more useful commands, the next command puts the port into the specified vlan if authentication fails

DistSwitch(config-if)#dot1x auth-fail vlan 666

And this command puts the port in the specified vlan if the connected host does not support dot1x, handy for guests

DistSwitch(config-if)#dot1x guest-vlan 90

And always there is a couple of show commands that we need to do to check that everything is working correctly. To check the queries and responses sent to each radius server just use;

DistSwitch#show aaa servers

RADIUS: id 1, priority 1, host 10.10.10.100, auth-port 1645, acct-port 1646
     State: current UP, duration 1743s, previous duration 0s
     Dead: total time 0s, count 0
     Quarantined: No
     Authen: request 0, timeouts 0
             Response: unexpected 0, server error 0, incorrect 0, time 0ms
             Transaction: success 0, failure 0
     Author: request 0, timeouts 0
             Response: unexpected 0, server error 0, incorrect 0, time 0ms
             Transaction: success 0, failure 0
     Account: request 0, timeouts 0
             Response: unexpected 0, server error 0, incorrect 0, time 0ms
             Transaction: success 0, failure 0
     Elapsed time since counters last cleared: 12m

And to see the dot1x interface specific information the following command provides that information

DistSwitch#show dot1x interface fa0/1
Dot1x Info for FastEthernet0/1
-----------------------------------
PAE                       = AUTHENTICATOR
PortControl               = AUTO
ControlDirection          = Both
HostMode                  = SINGLE_HOST
Violation Mode            = PROTECT
ReAuthentication          = Disabled
QuietPeriod               = 60
ServerTimeout             = 0
SuppTimeout               = 30
ReAuthPeriod              = 3600 (Locally configured)
ReAuthMax                 = 2
MaxReq                    = 2
TxPeriod                  = 30
RateLimitPeriod           = 0
Auth-Fail-Vlan            = 666
Auth-Fail-Max-attempts    = 3
Guest-Vlan                = 90

Simple Network Management Protocol (SNMP) is a set of standards for managing network devices, network devices are monitored by a SNMP manager which connects to an SNMP agent on network devices. Data which the SNMP agent can access is stored in a database called Management Information Base (MIB), MIBs are sometimes called MIB trees and small pieces of information (variables) are stored on MIB leaves.

A community string is a password for accessing the SNMP agent and separate community strings are usually used for systems which require read only or read/write access.

There are 4 version of SNMP;

SNMPv1 – Basic authentication through the use of community strings using SMIv1, the community string is sent in plain text

SNMPv2 – Does not community strings to authenticate. Mandates the use of SMIv2 and allows the use of a new message GetBulk and Inform

SNMPv2c – Uses SNMP version 1 style community strings sent in plain text but operates more similarly to to SNMPv2

SNMPv3 – Similar to SNMPv2 but improvements made for security and access control.

There aren’t that many SNMP message types and its useful to know them all, the SNMP message types are;

Get - Requests a single single variable from a MIB

GetNext - Requests the next MIB leaf in the MIB tree

GetBulk – Requests a sequential list of MIB leaves in a single request, GetBulk is commonly used to extract complex MIB structures

Set - this message changes the value of a MIB variable

Response - Sent in response to a set, get or inform type messages

Trap - This message is sent in an unsolicited fashion and does not require confirmation

Inform - Sent between SNMP managers to inform each other about MIB data

We use storm control to rate limit layer 2 traffic, this helps us prevent a subnet from being flooded with broadcasts, multicasts which would adversely affect the performance of the entire subnet. Storm Control can only be configured on physical interfaces and will not work on subinterfaces, or an LACP/PAGP interface.

Configuration

The first command shown limits the broadcast to 200pps, and if this limit is reached will not forward any more broadcasts until this is reduced to 150pps
(config-if)#storm-control broadcast level pps 200 150

Multicast and unicast traffic can also be limited, the maximum level can also be entered as a percentage instead of pps, in the example below multicasts can use up to 5% of the interface bandwidth, and once that limit is reach no more multicasts will be forwarded until it drops to 4.5% of the total interface bandwidth
(config-if)#storm-control multicast level 5 4.5

In the final example unicast is limited to 80% of the interface bandwidth but a second value is not specified, this causes all unicast to be forwarded up to 80% of the bandwidth and it does not force the traffic to wait until it drops below a second level
(config-if)#storm-control unicast level 80

The default response for storm control is the drop packets which are over the rate limit, and create a syslog message, we can also generate a SNMP trap with the command
(config-if)#storm-control action trap

The show commands for this are also really easy, I will paste the output of this when I am home
(config-if)#show storm-control port [unicast|broadcast|multicast]

There are many other attacks which abuse ARP messages and they commonly result in DOS or man in the middle attacks. Dynamic ARP Inspection (DAI) is a great method of preventing ARP based attacks.

If DAI is deployed on a switch it will examine ARP messages on every untrusted port and discard inappropriate ones, it does not examine ARPs on trusted ports. End stations should be configured as untrusted and connections to other switches & network devices should always be trusted, otherwise possibly valid ARP messages could be discarded.

The following are steps which DAI will decide whether to discard a packet on an untrusted port. Only step 1 is used by default steps 2 to 4 require extra configuration.

1 – If an ARP message states an IP address which has not been assigned via DHCP to that port the ARP is dropped.

2 – The ARP is checked against a staic list of IP/MACs and if it doesnt match the ARP is dropped

3 – An ARP reply should have the source MAC and the MAC in the message the same, if they are different the ARP is dropped. Also the destination MAC and MAC target are compared, if they are different the ARP is dropped

4 – Unusual IP addresses can be also filtered such as the subnet addresses, broadcast addresses and multicast addresses.

Configuration

DAI is enabled per VLAN with the following command;
ip arp inspection vlan vlan-range

All ports default to become trusted ports so to start the inspection of ARPs ports must be configured as untrusted with the interface command
no ip arp inspection trust

Option 2 in the list above where static IP/MAC lists can be checked with the following command
ip arp inspection filter arp-acl-name vlan vlan-range [static]

Steps 3 & 4 in the list above are not checked by default but they can be with the command
ip arp inspection validate {[src-mac] [dst-mac] [ip]}

The maximum rate of ARPs can also be limited to prevent DoS attacks with the command
ip arp inspection limit {rate pps [burst interval seconds] | none}