I'm experiencing a problem with my Cisco router 1900 Series, the router sometimes stop routing packets, and when i log into it and show the running-config i see no ip routing executing ip routing command does not solve the problem i have to reboot the router to make it work again. I thought this was an attack, but the problem persist even after changing all passwords and the time interval between each occurrence is very random! somtimes 15min somtimes couple hours or days.
I saw a discussion on cisco support forum which surprisingly started 6 days ago, (my problem is also recent, about 2 weeks)
Till now they didn't worked it out, I wanted to have your opinions and ideas, can a router in some circumstances or for some reasons disable his routing ? Have you ever experienced such a problem ? how did you solve it ?
Thanks!
This is the answer from Cisco support forum, In case the link get broken. Apparently it has something to do with SNMP configuration, it should be more secure.
Fortify the Simple Network Management Protocol
This section highlights several methods that can be used in order to secure the deployment of SNMP within IOS devices. It is critical that SNMP be properly secured in order to protect the confidentiality, integrity, and availability of both the network data and the network devices through which this data transits. SNMP provides you with a wealth of information on the health of network devices. This information should be protected from malicious users that want to leverage this data in order to perform attacks against the network.
Community strings are passwords that are applied to an IOS device to restrict access, both read-only and read-write access, to the SNMP data on the device. These community strings, as with all passwords, should be carefully chosen to ensure they are not trivial. Community strings should be changed at regular intervals and in accordance with network security policies. For example, the strings should be changed when a network administrator changes roles or leaves the company.
These configuration lines configure a read-only community string of READONLY and a read-write community string of READWRITE:
Refer to IOS SNMP Command Reference for more information about this feature.
In addition to the community string, an ACL should be applied that further restricts SNMP access to a select group of source IP addresses. This configuration restricts SNMP read-only access to end host devices that reside in the 192.168.100.0/24 address space and restricts SNMP read-write access to only the end host device at 192.168.100.1.
Refer to snmp-server community in the Cisco IOS Network Management Command Reference for more information about this feature.
Infrastructure ACLs (iACLs) can be deployed in order to ensure that only end hosts with trusted IP addresses can send SNMP traffic to an IOS device. An iACL should contain a policy that denies unauthorized SNMP packets on UDP port 161.
See the Limiting Access to the Network with Infrastructure ACLs section of this document for more information on the use of iACLs.
SNMP Views are a security feature that can permit or deny access to certain SNMP MIBs. Once a view is created and applied to a community string with the snmp-server community community-string view global configuration commands, if you access MIB data, you are restricted to the permissions that are defined by the view. When appropriate, you are advised to use views to limit users of SNMP to the data that they require.
This configuration example restricts SNMP access with the community string LIMITED to the MIB data that is located in the system group:
SNMP Version 3 (SNMPv3) is defined by RFC3410, RFC3411, RFC3412, RFC3413, RFC3414, and RFC3415 and is an interoperable standards-based protocol for network management. SNMPv3 provides secure access to devices because it authenticates and optionally encrypts packets over the network. Where supported, SNMPv3 can be used in order to add another layer of security when you deploy SNMP. SNMPv3 consists of three primary configuration options:
no auth - This mode does not require any authentication nor any encryption of SNMP packets auth - This mode requires authentication of the SNMP packet without encryption priv - This mode requires both authentication and encryption (privacy) of each SNMP packet An authoritative engine ID must exist in order to use the SNMPv3 security mechanisms - authentication or authentication and encryption - to handle SNMP packets; by default, the engine ID is generated locally. The engine ID can be displayed with the show snmp engineID command as shown in this example:
The next step is to configure an SNMPv3 group. This command configures a Cisco IOS device for SNMPv3 with an SNMP server group AUTHGROUP and enables only authentication for this group with the auth keyword:
Note that snmp-server user configuration commands are not displayed in the configuration output of the device as required by RFC 3414; therefore, the user password is not viewable from the configuration. In order to view the configured users, enter the show snmp user command as shown in this example:
Refer to Configuring SNMP Support for more information about this feature.
The Management Plane Protection (MPP) feature in Cisco IOS software can be used in order to help secure SNMP because it restricts the interfaces through which SNMP traffic can terminate on the device. The MPP feature allows an administrator to designate one or more interfaces as management interfaces. Management traffic is permitted to enter a device only through these management interfaces. After MPP is enabled, no interfaces except designated management interfaces accept network management traffic that is destined to the device.
Note that the MPP is a subset of the CPPr feature and requires a version of IOS that supports CPPr. Refer to Understanding Control Plane Protection for more information on CPPr.
In this example, MPP is used in order to restrict SNMP and SSH access to only the FastEthernet 0/0 interface:
Refer to Management Plane Protection Feature Guide for more information.
However I found that this could also be related to a vulnerability, here is the link where they are talking about that, and how to fix it: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20010227-ios-snmp-ilmi
The Cisco Support Forum thread has the answer now. It's your SNMP config with easy to guess community string and RW access.
http://www.cisco.com/c/en/us/support/docs/ip/access-lists/13608-21.html#anc50