iamjeffvader's studymotron and rantatorium

Control plane filtering on the 7750 is managed with CPM filters, any time you want to secure you device or protocols you need to use these guys. They are basically access control to the processors and used wisely they are incredibly powerful. Use them foolishly and they may cost you your job. Configure them incorrectly and you can isolate your node or bring down your entire network! There is an urban legend that someone made a change to CPM filters from SAM and pushed them out to all nodes and unfortunately all remote access was lost, mega truck roll time!

****************** Caveat and warning time ******************
I am writing this post from memory, with some output I was able to find. I don’t have
any lab equipment to test this on so nothing below can be considered tested and/or safe
to deploy. You can do some serious damage with control plane filters. Do not deploy
without doing your own testing and/or vendor support. I’m not taking responsibility for
your actions. I can’t over emphasize testing every single change no matter how small.
**********************************************************************

OK so now the formalities are done with what can CPM filters do? I guess the first thing is they are not supported on the SR1 (or the 7210, they have other methods) so you need a bigger router. Like I said above they allow us to permit or deny addresses and protocols access to the CPM. You can configure MAC, IPv4, IPv6 filters but we will focus on IPv4 for today.

The first, and probably most crucial, is the default action applied to the filters. If you have no filters configured and you set the default action to deny then get in your car and head to site. Let’s set the default to accept which you should always do when you are making the filter list for the first time.

configure system security cpm-filter default-action accept

For reference the keyword to set the deny all else is ‘drop’ instead of ‘accept’

Now we have allowed all access to the routers control plane. Anything else we specify will either be allowed or dropped. Anything we don’t match at this point will be allowed as well, highly insecure. It’s up to you to determine your security policy and ensure it is based on best practice.

For the remainder of this post we will look at OSPF ensuring it is secure (we still need authentication of course). We will create filters for OSPF but also create a log mechanism to ensure any denied traffic is signalled to the operations guys. We will permit what we want, explicitly denying what we don’t and ignore the default action until the end.

Let’s configure the prefixes we want to match against and allow, assuming the neighbours are on 10.10.10.0/24

configure system security cpm-filter ip-filter
entry 10 create
description "allow ospf"
action accept
match protocol ospf-igp
src-ip 10.10.10.0/24
exit
exit

Lets deny all other OSPF

entry 20 create
description "drop all other ospf"
action drop
log 123
match protocol ospf-igp
exit
exit

If any OSPF traffic not sourced from 10.10.10.0/24 hits the CPM it will be dropped and because we have the default action set to accept all traffic will be successful beyond this.

In order to verify if packets are being processed or not issue this command and you will see something similar to the following:

show system security cpm-filter ip-filter
===============================================================================
CPM IP Filter (applied)
===============================================================================
Id   Dropped              Forwarded            Description
-------------------------------------------------------------------------------
10  0                    648                   "allow ospf"
20  11                    0                    "drop all other ospf"

What this tells us is 648 packets have been accepted sourced from 10.10.10.0/24. These will allow us to form adjacencies. The makey-uppy 11 dropped packets are assumed to be from any other address that we don't trust. You can see more detailed output on a per entry basis by specifying entry $number$ in the show command.

Now you will notice the log 123 statement in the deny entry. This will allow us to have a record of denied OSPF packets by sending entries to syslog.
First lets configure a syslog specific log

configure log
syslog 2
description "send naughty ospf to syslog server"
address 172.16.1.1
exit all

Here we are saying log 2 is used for syslog and the IP of the syslog server is 172.16.1.1. We now need to reference the syslog credentials in the filter log.

configure filter
log 123 create
description "log for untrusted ospf"
destination syslog 2
wrap-around
no shutdown

What we have done now is send logs for entry 20, based on its mapping to log 123, to the server listed in syslog 2. It's extra work to do all this but it's this type of modularity that I like about SROS.

So what have we achieved? We can now form adjacencies with our neighbours without being open to any attack from other routers outside of our controlled prefix. Of course we must secure our entire control plane as best we can. You should look to permit your IGP, LDP, RSVP, BGP, VRRP if you use it, multichassis protocols such as MC-LAG, BFD along with management protocols such as TACACS, SSH, NTP etc. This list is by no means exhaustive, you need to analyze your network traffic to see what you have hitting your CPMs. Once you have identified all relevant traffic, test your filters then set your default action to drop using

configure system security cpm-filter default-action drop

CPM filters are a must but they need to be respected or they will create more work for you down the road.