Router Spring Cleaning – No MOP Required
Spring is finally here, and besides being a good time to clean the attic, garage or basement, it is also a good time to clean the configuration on your Cisco IOS devices — removing unneeded ACEs from ACLs, maybe setting some interfaces as passive, removing VLANs from trunks, etc.
And while doing said cleaning, hey, why not also check the device configuration against the Cisco Guide to Harden Cisco IOS Devices, to make sure we’re doing our best to keep those Cisco IOS devices as secure as possible?
When looking over the recommendations on the hardening guide, time and again people are puzzled by this line:
“Issue the no mop enabled command in interface configuration mode in order to disable the Maintenance Operation Protocol (MOP) service.”
And they come back to us with questions like, “what is MOP, why do I have to disable it, and is it even relevant if I’m not running DECnet?” Well, today we hope to clear up some of the confusion that might surround the unMOPping of a Cisco IOS device, so gather round for a story. Sorry, no marshmallows, but I think it will be interesting nonetheless.
Many years ago, in the land of Digital Equipment Corporation (DEC), there was a set of network protocols, collectively called the “DECnet.” One of them was called DRP and its job was routing. Another one was NSP and it could be found at the transport layer. There was also SCP, located at the session layer. And of course, who could forget about NICE and MOP, which spent their days dedicated to network management chores.
MOP (the Maintenance Operation Protocol) offered many features: remote loading of system software, loopback testing, and others (none of which we will talk about today; the one we’re interested in is the “remote console” (RC) functionality). A network operator was able to establish an interactive session from a VAX/VMS host toward a device offering MOP RC capabilities. The MOP RC data was carried directly over L2 frames, with no L3 addressing at all, so any RC session was limited to devices that were either on the same physical network segment or in separate network segments that were bridged together.
Now, Cisco IOS Software has supported both MOP RC and MOP loading of images as far back as Cisco IOS 9.0, which wasn’t even Cisco IOS back then, but “System Software Release 9.0,” and we still support those features in the recently released 15.x trains (talk about a long lasting protocol!). And the MOP RC functionality is enabled by default on ethernet interfaces, so right out the box you can connect to a Cisco IOS device using a MOP RC client and, provided you have a valid set of credentials for said device, establish an interactive remote session.
We hardly need to say that for the 2010 network complexity and threat landscape a remote session protocol that runs only over L2 and provides neither data encryption nor data origin authentication is, well, far from being “state of the art,” nor our first choice to manage a Cisco IOS device.
I’m sure some people reading this are now wondering, “what do I care? I’m not running DECnet.” Well, the thing is, the MOP functionality is decoupled from the DECnet protocol stack, so even if your device isn’t configured for DECnet, you will still be able to establish a MOP RC session to the device, as long as MOP hasn’t been explicitly disabled.
And then some other people will shake their heads. “Where am I going to find a VAX/VMS host to establish a MOP RC session towards my new, shiny 1900, 2900 or 3900 router running IOS 15.1(1)T?” Well, you don’t actually need a VAX/VMS host. Thanks to the DECnet for Linux project, we have a readily available MOP RC client for Linux — the aptly named the moprc utility. And it works just peachy with our MOP RC implementation.
So some key points to note from all of this:
- The MOP protocol (RC and remote load functionality) is still being shipped as part of Cisco IOS 15.x
- MOP RC is enabled by default on ethernet interfaces (and yes, that includes FastEthernet and GigabitEthernet)
- MOP (RC and dump/load) data packets are directly encapsulated on Ethernet L2 frames (Ethertype is 0x6002 for RC)
- MOP packets can’t be routed but can be bridged
- There is a readily available MOP RC client for Linux
- You do have to provide valid credentials for authentication before being allowed interactive access to the device
- A show users WILL show anyone connected to a Cisco IOS device over a MOP RC session
- MOP RC packets are neither encrypted nor authenticated
- Removing transport input mop from the VTY lines will not disable the MOP RC functionality
I hope this post has clarified some of the mystery surrounding our recommendation of disabling MOP. We’re also attaching, for those interested, a pcap file with a MOP RC session between a Linux host running moprc and a Cisco IOS router running release 15.1(1)T.
And that’s about it. As for me, I still have to move these boxes out of the garage before the wife comes back… my own spring cleaning chores.