Automatically filtering bogons with BGP and Team Cymru Bogon Route Server Project

What do you do if someone knocks at your door, you see him through the peephole, and you notice he has a black cowl, a crowbar and a big bag? I’m quite sure: you do not open that door! Why? Because, sometimes, the gown does make the friar! And, actually, he’s really not a friar!

Same thing should happen in a network! If you know a packet is a bad packet, why should you let it go through?

In this (stupid) example bad packets are those coming from or going toward bogon IP addresses, that is, addresses picked up from unallocated or private (so, not routable) address spaces. As you know, there are many subnets used only for private addressing (RFC 1918), other are reserved (RFC 3330), and few subnets are still not allocated by IANA… so, if your router is sending or receiving a packet to/from one of these addresses, there is something you should be concerned about (of course, some restrictions may apply!)

How to identify bogons

In order to identify and catch bogon packets we need to know which subnets have to be marked as bogon.

One way to achieve this goal is to deploy static ACLs or route filters on every router we want to secure… a quite boring job on its own! But, what happens when IANA allocate one of the previously unallocated (so, bogon) subnets? Well, we have to change those ACLs on every router! This is a very boring job! Someone at RIPE knows that well!

Do you really want this?

Fortunately, we can use a great utility by Team Cymru: Bogon Route Server Project.

What is Bogon Route Server Project?

For the sake of our sanity, Team Cymru deployed some route servers running BGP which announce bogon prefixes over eBGP peering sessions. Once we have a BGP-aware box, we can get those prefixes and do what we want of them.

Here, I’ll show how to automatically handle bogon prefixes using a Linux box running Quagga, a routing software suite providing implementation of BGP.

What can we do with bogon prefixes?

From our central Quagga box we can distribute those prefixes to our routers, or to customers CPEs, and here we can filter traffic on the basis of source or destination addresses.

For example, we can avoid to route packets with a bogon destination address, simply by adding a route toward bogon prefixes with a null-pointing next-hop; it’s a kind of blackhole filtering:

ip route 192.0.2.1 255.255.255.255 Null0
ip route 1.0.0.0 255.0.0.0 192.0.2.1

With Cymru Bogon Route Server Project we can do this job in a fully automatic and central way.

Of course, we can also drop incoming packets presenting bogon source IP addresses; we can accomplish this using uRPF in a kind of source-based black hole filtering:

interface Serial1/0
 ip verify unicast source reachable-via any

Anyway, you, and only you know what’s better for your network!

Now, I would like to show you how to setup a Linux box running Quagga, with a peer session with Cymru routers, and how to use it to distribute bogon prefixes to our routers.

Peering with Cymru Bogon Route Server

At first, we have to ask Team Cymru to setup a BGP session with our Quagga box: to do so we have to contact them on the basis of what we can find on their website. We have to tell them our AS number, our peering IP addresses and optional MD5 passwords and GPG/PGP public key.

You don’t need to have a public AS number, you can also peer with them using a private AS number.

Quagga: bgpd configuration

Once we have installed Quagga and received Cymru details, we just have to edit the bgpd.conf file and add a few lines.

Quagga bgpd.conf:

router bgp YOUR_AS_NUMBER
 bgp router-id YOUR_ROUTER_ID
 neighbor cymru-bogon peer-group
 neighbor cymru-bogon remote-as 65333
 neighbor cymru-bogon ebgp-multihop
 neighbor cymru-bogon prefix-list cymru-out out
 neighbor cymru-bogon route-map CYMRUBOGONS in
 neighbor cymru-bogon maximum-prefix 100

 neighbor CYMRU_PEER_1_IP peer-group cymru-bogon
 neighbor CYMRU_PEER_2_IP peer-group cymru-bogon
!
ip community-list 10 permit 65333:888
!
route-map CYMRUBOGONS permit 10
  match community 10
  set ip next-hop 192.0.2.1
!
ip prefix-list cymru-out seq 5 deny 0.0.0.0/0 le 32

Prefix-list prevents any update to leave our box toward Cymru routers; route-map allows marked prefixes and set their next-hop to 192.0.2.1, null-pointing route.

Automagically our Quagga box gets bogon prefixes:

QuaggaBox#show ip bgp
BGP table version is 0, local router ID is YOUR_ROUTER_ID
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*  1.0.0.0          192.0.2.1                0             0 65333 i
*>                  192.0.2.1                0             0 65333 i
*  5.0.0.0          192.0.2.1                0             0 65333 i
*>                  192.0.2.1                0             0 65333 i
[cut]
*  192.168.0.0/16   192.0.2.1                0             0 65333 i
*>                  192.0.2.1                0             0 65333 i
*  198.18.0.0/15    192.0.2.1                0             0 65333 i
*>                  192.0.2.1                0             0 65333 i
*  223.0.0.0/8      192.0.2.1                0             0 65333 i
*>                  192.0.2.1                0             0 65333 i

Total number of prefixes 32

Now, setup our Quagga box to bring up peering with your routers; just add few config lines to bgpd.conf:

router bgp YOUR_AS_NUMBER
 neighbor Clients peer-group
 neighbor Clients prefix-list DoNotAcceptAnything in
 neighbor Clients route-map CYMRUBOGONS out
 neighbor Clients ebgp-multihop
 neighbor Clients send-community

 neighbor YOUR_ROUTER1_IP remote-as YOUR_AS_NUMBER
 neighbor YOUR_ROUTER1_IP peer-group Clients

 neighbor YOUR_ROUTER2_IP remote-as YOUR_AS_NUMBER
 neighbor YOUR_ROUTER2_IP peer-group Clients
!
ip prefix-list DoNotAcceptAnything seq 5 deny 0.0.0.0/0 le 32

Routers configuration

We can deploy iBGP or eBGP configuration on our routers and automatically get bogon prefixes.

This is a sample configuration:

ip route 192.0.2.1 255.255.255.255 Null0
!
ip bgp-community new-format
!
router bgp YOUR_AS_NUMBER
 no synchronization
 bgp log-neighbor-changes
 neighbor YOUR_QUAGGA_BOX_IP remote-as YOUR_AS_NUMBER
 neighbor YOUR_QUAGGA_BOX_IP update-source Loopback0
 neighbor YOUR_QUAGGA_BOX_IP prefix-list DoNotAnnounceAnything out
 neighbor YOUR_QUAGGA_BOX_IP route-map CymruBogons in
 no auto-summary
!
ip community-list standard CymruBogons permit 65333:888
!
ip prefix-list DoNotAnnounceAnything seq 5 deny 0.0.0.0/0 le 32
!
route-map CymruBogons permit 10
 match community CymruBogons
 set ip next-hop 192.0.2.1

Tests

And now, let’s verify our job…

Router#show ip bgp
BGP table version is 163, local router ID is X.Y.Z.W
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*>i1.0.0.0          192.0.2.1                0    100      0 65333 i
*>i5.0.0.0          192.0.2.1                0    100      0 65333 i
[cut]
*>i192.168.0.0/16   192.0.2.1                0    100      0 65333 i
*>i198.18.0.0/15    192.0.2.1                0    100      0 65333 i
*>i223.0.0.0/8      192.0.2.1                0    100      0 65333 i

BGP gets bogon prefixes from our Quagga box; let’s take a look at our routing table, with focus on 192.168.0.0:

Router#show ip route | i 192.168
O IA 192.168.4.0/24 [110/196] via 192.168.254.3, 5d05h, Tunnel1
O IA 192.168.5.0/24 [110/196] via 192.168.254.1, 5d05h, Tunnel0
[cut]
O IA 192.168.1.0/24 [110/196] via 192.168.254.1, 5d05h, Tunnel0
B    192.168.0.0/16 [200/0] via 192.0.2.1, 1d01h

Here we have some private prefixes from OSPF, used for branch offices, and they have the right paths; in the last line, the whole 192.168.0.0/16 goes toward the null-pointing route.
Remember: more specific route wins; until we have our private prefixes from OSPF no packets will be filtered out.

Router#sh ip cef 192.168.222.1
192.168.0.0/16, version 411, epoch 0
0 packets, 0 bytes
  via 192.0.2.1, 0 dependencies, recursive
    next hop 192.0.2.1, Null0 via 192.0.2.1/32
    valid null (drop) adjacency

Well done: it’s simple and it works fine! Anyway, remember to take precautions: do no send bogon prefixes to your BGP peers (no-export plus safeguard communities) and keep in mind every network is different from others!

References

Team Cymru: Bogon Route Server Project

Quagga: Quagga Software Routing Suite

Andree Toonk: Bong Traffic Analysis in 2006

Rob Thomas (on Team Cymru website): 60 Days of Basic Naughtiness, a study conducted in 2001.

Cisco IOS configuration management using SCP and pscp

SCP is a powerful tool introduced in IOS 12.2(2)T which allows us to securely transfer files to and from our routers. With this feature we can transfer files, images and configurations in an encrypted way, and we can also authenticate accesses on the routers.

It’s easy to deploy, easy to use and Cisco recommends to use it in the Guide to Harden Cisco IOS Devices too: why do not use it?!

It relays on SSH and AAA, so both features have to be enabled on the device:

Router(config)#hostname R1
R1(config)#crypto key generate rsa general-keys modulus 512
The name for the keys will be: R1.mydomain

% The key modulus size is 512 bits
% Generating 512 bit RSA keys, keys will be non-exportable...[OK]
R1(config)#
R1(config)#aaa new-model
R1(config)#aaa authentication login default local
R1(config)#aaa authorization exec default local

In order to use scp to manage configuration we must have an user account with enough privileges to access it:

R1(config)#
R1(config)#username admin privilege 15 secret 0 topsecret

Finally, we can turn the scp server on:

R1(config)#ip scp server enable

On the client side we can use an utility such as pscp, from the PuTTY suite, to interact with our SCP server – the router!

C:\>pscp.exe
PuTTY Secure Copy client
Release 0.59
Usage: pscp [options] [user@]host:source target
       pscp [options] source [/source] [user@]host:target
       pscp [options] -ls [user@]host:filespec
[cut]

For example, we can download the startup-config and put it on a directory:

C:\>pscp.exe admin@192.168.0.42:nvram:startup-config C:\MyConfigs\R1.cfg
admin@192.168.0.42's password:
R1.cfg                    | 0 kB |   0.6 kB/s | ETA: 00:00:00 | 100%

C:\>

Using an integrated AAA system, such as a Radius based AAA with IAS and Active Directory as backend, we can also omit the username part and use our own domain password!

Dear TFTP & Co., it’s time for retirement!

References

Cisco.com: Cisco Guide to Harden Cisco IOS Devices

Cisco.com: Cisco Secure Copy (SCP) Feature Guide – 12.2T

PuTTY: PuTTY: A Free Telnet/SSH Client

Different policies in Cisco RADIUS AAA

These days I had to implement centralized terminal authentication on a few Cisco routers using aaa new-model and RADIUS.

The solution in its own was pretty simple: it was based on the usual Microsoft IAS (Internet Authentication Service) which was integrated in an Active Directory domain.

The interesting aspect is that those routers were under different administrative controls, so some users had to be granted access on a part of them and denied on other. Let’s say Group1 had to be enabled on routers RA, RB and RC, while Group2 on routers RD, RE and RF.

Solution adopted

In order to achieve this goal we may use a lot of solutions, but most of them are quite unscalable, because we have to map each router to the specific policy.

To obtain a good degree of scalability we may use the radius-server attribute 32 include-in-access-req command. This command tells IOS to append the NAS-Identifier attribute in the RADIUS authentication request message, and let us to set a format for its value:

RA(config)#radius-server attribute 32 include-in-access-req format ?
  LINE  A string where %i = IP address and %h = hostname, %d = domain name

For example, we can prepend the router’s hostname with a “tag” to distinguish the owner group:

Group1 routers:

RA(config)#radius-server attribute 32 include-in-access-req format Group1-%h
RB(config)#radius-server attribute 32 include-in-access-req format Group1-%h
RC(config)#radius-server attribute 32 include-in-access-req format Group1-%h

Group2 routers:

RD(config)#radius-server attribute 32 include-in-access-req format Group2-%h
RE(config)#radius-server attribute 32 include-in-access-req format Group2-%h
RF(config)#radius-server attribute 32 include-in-access-req format Group2-%h

Finally we can create two policies in IAS to handle the incoming authentication requests, by filtering them on the basis of NAS-Identifier attribute.
On the NAS-Identifier filter, we can use a star (“*”) to match any character which follows the router’s “tag”. Once we matched the router’s tag, we bind it to the right Active Directory group. Please take a look at the picture for details.

References

Cisco.com: Cisco IOS Security Command Reference, Release 12.3 T

Cisco.com: Command Lookup Tool

PacketLife.net Blog: Seven free ways to improve your network’s security

Kpjungle’s Weblog: Authentication by Radius on a Cisco device

GNS3 Labs: Source-based Remote Triggered Black Hole (RTBH) Filtering with Unicast Reverse Path Forwarding (uRPF)

This post is part of a series about “ISP Security Tools and Techniques“; in this series I talk about some (I think) useful practices:

1. Remote Triggered Black Holing

2. BGP Customer triggered black holing

3. BGP triggered rate limiting and less-than-best-effort (LBE) with QPPB

4. Source-based RTBH with Unicast Reverse Path Forwarding (uRPF)

Stay tuned!

Today I drew inspiration from a brand new RFC to add a post to this little series: RFC-5635, Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF).

Especially, I would like to focus on section 4 of this RFC, Source Address RTBH Filtering.

To fully understand this post I would suggest to read my previous post Remote Triggered Black Holing.

What is source-based RTBH? and what are the differences with destination-based RTBH?

Until now, in my previous posts, I always talked about destination-based RTBH. But a source-based RTBH filtering exists too.

This mitigation technique allows an ISP to stop malicious traffic (let’s think to DDOS) on the basis of the source address it comes from. Indeed, destination-based RTBH can just be used to stop traffic on the basis of the attacked hosts addresses, or in the best case, on the couple attacked-hosts/incoming-upstream-provider (you can use different BGP communities to black-hole a prefix only on specific edge routers).

As mentioned in the RFC, if a DDOS software is instructed to attack an host name rather than an IP address, even if you change the IP address resolved by that host name, the attack won’t stop. In this scenario you just have to disrupt the whole service by filtering out the attacked prefix. Source-based RTBH can help you!

How does it work?

Source-based RTBH uses Unicast Reverse Path Forwarding (uRPF) as background mechanism to work.
As RFC says…

uRPF performs a route lookup of the source address of the packet and checks to see if the ingress interface of the packet is a valid egress interface for the packet source address (strict mode) or if any route to the source address of the packet exists (loose mode). If the check fails, the packet is typically dropped.

So, in order to stop incoming traffic from hosts A, B and C toward host Z through router R we just need to add discard routes for A, B and C on router R. And, as seen for destination-based RTBH, we can do it using BGP and communities.

Is that all?

Well, no! Some policy enforcements are due!

As first, in the same way we did for destination-based RTBH, we must use the no-export community to be sure our black-holed prefix doesn’t leave our AS.

Our policy must accept prefixes outside our network (while destination-based RTBH only accepts prefixes within our network) and, as a rule of thumb, we should not accept source-based RTBH prefixes from our customers, but we should just use this tool from management workstations under our control.

Configuration

The starting configuration is the one we left on the post BGP triggered rate limiting and less-than-best-effort (LBE) with QPPB.

In our scenario source-based RTBH is triggered from the Core router, using tagged static routes redistribution in BGP; nothing different from destination-based RTBH. So, let’s define the tags and communities:

300:300 - tag 300 - global source-based black-hole
300:301 - tag 301 - ISP1 source-based black-hole
300:302 - tag 302 - ISP2 source-based black-hole

On the Core router, here used as RTBH trigger, we have to enable BGP redistribution of static routes tagged with the news tags; indeed, we will trigger RTBH by adding tagged static routes:

route-map RTBH permit 50
 match tag 300
 set local-preference 200
 set origin igp
 set community 300:300 no-export
route-map RTBH permit 60
 match tag 301
 set local-preference 200
 set origin igp
 set community 300:301 no-export
route-map RTBH permit 70
 match tag 302
 set local-preference 200
 set origin igp
 set community 300:302 no-export

On edge routers facing upstream providers we have to implement our new communities in the route-map:

Edge1:

ip community-list 5 permit 19661100     ! 300:300
ip community-list 5 permit 19661101     ! 300:301
ip community-list 6 permit 19661102     ! 300:302
!
ip as-path access-list 2 permit ^$
!
ip access-list extended InternalNetworks
 permit ip 192.168.0.0 0.0.255.255 255.255.0.0 0.0.255.255
 deny   ip any any
!
route-map FROM_RR deny 30
 match community 6
!
route-map FROM_RR deny 35
 match ip address InternalNetworks
 match community 5
!
route-map FROM_RR permit 40
 match as-path 2
 match community 5
 set community no-export no-advertise
 set ip next-hop 192.0.2.1

Here, 300:300 and 300:301 communities (community-list 5) are welcome, while 300:302 community is not accepted – it’s only for ISP2 facing router. Moreover, we just accept prefixes external to our network (192.168.0.0/16).

Similar config is on Edge2:

ip community-list 5 permit 19661100     ! 300:300
ip community-list 5 permit 19661102     ! 300:302
ip community-list 6 permit 19661101     ! 300:301
!
ip as-path access-list 2 permit ^$
!
ip access-list extended InternalNetworks
 permit ip 192.168.0.0 0.0.255.255 255.255.0.0 0.0.255.255
 deny   ip any any
!
route-map FROM_RR deny 30
 match community 6
!
route-map FROM_RR deny 35
 match ip address InternalNetworks
 match community 5
!
route-map FROM_RR permit 40
 match as-path 2
 match community 5
 set community no-export no-advertise
 set ip next-hop 192.0.2.1

Finally, we have to enable uRPF on ISP-facing interfaces; we use the loose mode here:

Edge1:

interface Serial1/0
 ip address 172.16.1.1 255.255.255.252
 ip verify unicast source reachable-via any

Edge2:

interface Serial1/0
 ip address 172.16.2.1 255.255.255.252
 ip verify unicast source reachable-via any

Tests

To test the solution we have to add another loopback interface to ISPs routers, in order to have two different source IP addresses for each ISP:

ISP1:

interface Loopback1
 ip address 10.0.1.2 255.255.255.255
!
router bgp 100
 network 10.0.1.2 mask 255.255.255.255

ISP2:

interface Loopback1
 ip address 10.0.2.2 255.255.255.255
!
router bgp 200
 network 10.0.2.2 mask 255.255.255.255

Now, suppose we have an attack from ISP1 Loopback1 toward Cust10 (so, from 10.0.1.2 to 192.168.10.1).

We can stop the attack using destination-based RTBH, but traffic from Loopback0 will be disrupted too:

Core(config)#ip route 192.168.10.1 255.255.255.255 null0 tag 101

ISP1#ping 192.168.10.1 so lo1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.1.2
.....
Success rate is 0 percent (0/5)

ISP1#ping 192.168.10.1 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.1.1
.....
Success rate is 0 percent (0/5)

As you can see, both source addresses can’t reach our host.

So, let’s try our new solution; as first remove the previous RTBH filter:

Core(config)#no ip route 192.168.10.1 255.255.255.255 null0 tag 101

then trigger the source-based filtering for the attacking IP address:

Core(config)#ip route 10.0.1.2 255.255.255.255 null0 tag 301

Edge1 receives the new BGP announcement and it adds the discard interface route:

Edge1#sh ip route bgp | i 10.0.1.2
B       10.0.1.2 [200/0] via 192.0.2.1, 00:01:03

Edge1#sh ip cef 10.0.1.2
10.0.1.2/32, version 32, epoch 0
0 packets, 0 bytes
  via 192.0.2.1, 0 dependencies, recursive
    next hop 192.0.2.1, Null0 via 192.0.2.1/32
    valid null adjacency

As we can see, packets from ISP1 Loopback1 are dropped at Edge1, while packets from Loopback0 pass:

ISP1#ping 192.168.10.1 so lo1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.1.2
.....
Success rate is 0 percent (0/5)

ISP1#ping 192.168.10.1 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 476/608/724 ms

Download

You can download the updated GNS3 file and configs here. The ZIP file contains multiple config subdirectories, one for each step covered on previous posts, and the new “6. Source-based RTBH filtering”.

References

IETF: RFC-5635, Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)

Cisco CEF monitoring with SNMP and CISCO-CEF-MIB

Here I am, back from summer vacation, ready to update my little blog again!
I would like to talk about another Cisco SNMP MIB…

Starting from release 12.4(20)T IOS offers a powerful tool to manage and monitor enterprise class products performances: SNMP CEF MIB.
CISCO-CEF-MIB is available for large scale Service Provider releases too, such as 12.2(33)SB, but 12.4(20)T is the first release to make it available on low and mid-range products.

The CEF-MIB is quite big and covers a lot of topics about CEF configuration, monitoring and managing; in this topic I will talk about a little, specific branch of this MIB, about stats collection, and how to use it for routers performances monitoring.

MIB structure

As you can see from the Cisco SNMP Object Navigator there are many tables describing CEF: FIB, prefixes, Adjacencies and stats.

In this post I focus on the switching stats table: cefSwitchingStatsTable.

Switching stats table

This table offers statistics related to packets dropping and punting. The CLI command show ip cef switching statistics gives the same view about these stats.

As you know, while packets dropping is not a resource intensive process, packets punting may lead to a huge CPU load, because punted packets need to be switched with a less fast switching method, such as process switching.

cefSwitchingStatsTable
----------------------

# snmpwalk -v 2c -c public -m ALL 192.168.0.8 .1.3.6.1.4.1.9.9.492.1.8.2

CISCO-CEF-MIB::cefSwitchingPath.9.1.1 = STRING: RP RIB
CISCO-CEF-MIB::cefSwitchingPath.9.1.2 = STRING: RP LES
CISCO-CEF-MIB::cefSwitchingPath.9.1.3 = STRING: RP PAS
CISCO-CEF-MIB::cefSwitchingPath.9.2.1 = STRING: RP LES
CISCO-CEF-MIB::cefSwitchingDrop.9.1.1 = Counter32: 0 packets
CISCO-CEF-MIB::cefSwitchingDrop.9.1.2 = Counter32: 0 packets
CISCO-CEF-MIB::cefSwitchingDrop.9.1.3 = Counter32: 3265 packets
CISCO-CEF-MIB::cefSwitchingDrop.9.2.1 = Counter32: 0 packets
CISCO-CEF-MIB::cefSwitchingPunt.9.1.1 = Counter32: 0 packets
CISCO-CEF-MIB::cefSwitchingPunt.9.1.2 = Counter32: 3505 packets
CISCO-CEF-MIB::cefSwitchingPunt.9.1.3 = Counter32: 3506 packets
CISCO-CEF-MIB::cefSwitchingPunt.9.2.1 = Counter32: 0 packets
CISCO-CEF-MIB::cefSwitchingPunt2Host.9.1.1 = Counter32: 0 packets
CISCO-CEF-MIB::cefSwitchingPunt2Host.9.1.2 = Counter32: 0 packets
CISCO-CEF-MIB::cefSwitchingPunt2Host.9.1.3 = Counter32: 8 packets
CISCO-CEF-MIB::cefSwitchingPunt2Host.9.2.1 = Counter32: 0 packets

The table presents an index composed by three elements: entPhysicalIndex, cefFIBIpVersion and cefSwitchingIndex.

The first, entPhysicalIndex, is the value of the entPhysicalTable’s index (.iso.org.dod.internet.mgmt.mib-2.entityMIB.entityMIBObjects.entityPhysical.entPhysicalTable); it describes the CEF-enabled hardware module the stats refer to.

[...].entPhysicalTable.entPhysicalEntry.entPhysicalDescr.9 = Cisco 7200VXR Network Processing Engine NPE-400
[...].entPhysicalTable.entPhysicalEntry.entPhysicalClass.9 = module
[...].entPhysicalTable.entPhysicalEntry.entPhysicalName.9 = NPE400 0

The second element, cefFIBIpVersion, of type CefIpVersion (see CISCO-CEF-TC MIB), describes the IP protocol: IPv4 (1) or IPv6 (2).

The third, cefSwitchingIndex, is the local identifier: indeed, you may have more switching paths for each module/IP-version.
Switching paths are platform dependent and may be RIB (process switching with CEF assistance), LES (low-end switching CEF), PAS (CEF turbo switch path)… you can find a more comprehensive list on the Cisco Command Lookup Tool, looking for show ip cef switching statistics command.

Why to use CEF monitoring?

To monitor punted packets value, for example by using a SNMP-enabled NMS, may be useful to get an overview about routers and network performances and health, and to lower response time and MTTR in case of degradation. A fast increase on punted packets may be a sign of DOS attacks against routers, or if you have a total packets over punted packets disproportion maybe you have to revise your network design, offloading some work to other routers.

References

Cisco.com: Cisco Express Forwarding SNMP CEF-MIB Support

Cisco.com: Cisco Express Forwarding (CEF)

Cisco.com: CISCO-CEF-MIB