Inband management guidelines

- Apply only to devices needing to be managed or monitored

- Use IPsec when possible

- Use SSH or SSL

- Decide whether the management channel needs to be open at all times

- Keep clocks on hosts and network devices synchronized

- Record changes and archive configurations

The figure outlines guidelines for OOB and in-band management of the architecture.

As a general rule, OOB management is appropriate for large enterprise networks. In smaller networks, in-band management is recommended as a means of achieving a more cost-effective security deployment. In such architectures, management traffic flows in-band in all cases and is made as secure as possible using tunneling protocols and secure variants to insecure management protocols; for example, SSH is used whenever possible instead of Telnet.

To ensure that log messages are synchronized with one another, clocks on hosts and network devices must be synchronized. For devices that support it, NTP provides a way to ensure that accurate time is kept on all devices.

NTP is used to synchronize the clocks of various devices across a network. Synchronization of the clocks within a network is critical for digital certificates and for correct interpretation of events within syslog data. A secure method of providing clocking for the network is for network administrators to implement their own master clocks. The private network should then be synchronized to Coordinated Universal Time (UTC) via satellite or radio. However, clock sources are available that synchronize via the Internet for network administrators who do not wish to implement their own master clocks because of cost or other reasons.

An attacker could attempt a denial of service (DoS) attack on a network by sending bogus NTP data across the Internet in an attempt to change the clocks on network devices in such a manner that digital certificates are considered invalid. Further, an attacker could attempt to confuse a network administrator during an attack by disrupting the clocks on network devices. This scenario would make it difficult for the network administrator to determine the order of syslog events on multiple devices.

2-134 Securing Cisco Network Devices (SND) v2.0 © 2006 Cisco Systems, Inc.

NTP version 3 (NTPv3) and above supports a cryptographic authentication mechanism between peers. The use of the authentication mechanism, and the use of access control lists (ACLs) that specify which network devices are allowed to synchronize with other network devices, is recommended to help mitigate such an attack.

The network administrator should weigh the cost benefits of pulling the clock time from the Internet against the possible risk of doing so and allowing unsecured packets through the firewall. Many NTP servers on the Internet do not require any authentication of peers. Therefore, the network administrator must trust that the clock itself is reliable, valid, and secure. NTP uses UDP port 123.

© 2006 Cisco Systems, Inc. Securing the Perimeter 2-135

Continue reading here: SNMP Security Is Not My Problem

Was this article helpful?

0 0