ACL. For example; blocking all UDP traffic at the top of the list negates the blocking of SNMP packets that are lower in the list. Ensure that statements at the top of the ACL do not negate any statements found lower in the list.

Directional filtering: Cisco ACLs have a directional filter that determines whether they examine inbound packets (toward the interface) or outbound packets (away from the interface). Always double-check the direction of data that your ACL is filtering.

Adding statements: New statements that you add to an existing ACL are always appended to the bottom of the ACL. Because of the inherent top-down statement evaluation order of ACLs, these new entries may render the ACL unusable. In these cases, you must create a new ACL (with the correct statement ordering). Delete the old ACL and assign the new ACL to the router interface.

Special packets: Router-generated packets, such as routing table updates, are not subject to outbound ACL statements on the source router. If filtering these types of packets is part of your security policy, then the packets must be acted upon by inbound ACLs on adjacent routers or through other router filter mechanisms using ACLs.

Extended ACL placement: Extended ACLs that are placed on routers too far from the source that the ACL is filtering can adversely impact packets that are flowing to other routers and interfaces. Always consider placing extended ACLs on routers as close as possible to the source that the ACL is filtering.

Standard ACL placement: Because standard ACLs filter packets based on the source address of the packet, placing these ACLs too close to the source can adversely impact packets that are going to other destinations. Always place standard ACLs as close to the destination as possible.

Content 5.8 Securing Management and Reporting Features 5.8.1 Secure Management and Reporting Planning Considerations Configuring logging for your Cisco routers is a straightforward operation when your network contains only a few Cisco routers. However, logging and reading information from hundreds of devices can be a challenging proposition. Too much information can be as bad as too little information and can raise these important questions, summarized in Figure :

Which logs are most important?
How do you separate important messages from mere notifications?
How do you ensure that no one tampers with the logs while the logs are in transit?
How do you ensure that time stamps match each other when multiple devices report the same alarm?
What information do you need if the log data is required for a criminal investigation?
How do you deal with the volume of messages that a large network generates?

Securing administrative access and device configurations is also a straightforward operation for smaller Cisco router networks. However, managing administrative access and device configurations for a large number of devices can raise these questions:

How do you securely manage many devices in many locations?
How can you track and troubleshoot changes on devices when attacks or network failures occur?

Each of these issues is specific to your needs. To identify the priorities of reporting and monitoring, you need input from management and from the network and security teams. The implemented security policy should also play a large role in answering these questions. From a reporting standpoint, most networking devices can send syslog data when you are troubleshooting network problems or security threats. You can send this data to your syslog analysis host from any device whose logs you wish to view. You can view this data in real time, on demand, or in scheduled reports. Depending on the device that is involved, you can choose various logging levels to ensure that the device sends the correct amount of data to the logging device. You must also flag device log data within the analysis software to permit granular viewing and reporting. For example, during an attack, the log data that Layer 2 switches provide might not be as interesting as the data that the intrusion detection system (IDS) provides. To ensure that log messages are time-synchronized, you must synchronize the clocks on hosts and network devices. For devices that support Network Time Protocol (NTP), NTP provides a way to ensure that time is accurate on all devices. When you are dealing with an attack, seconds matter, because it is important to identify the order in which a specified attack occurred. Configuration change management is another issue that is related to secure management. When a network is under attack, it is important to know the state of critical network devices and when the last known modifications occurred. Creating a plan for change management should be a part of your comprehensive security policy, but, at a minimum, you should record changes using authentication systems on the devices and archive configurations via FTP or TFTP.

Content 5.8 Securing Management and Reporting Features 5.8.2 Secure Management and Reporting Architecture Figure shows a management module with two network segments that are separated by a Cisco IOS router that acts as a firewall and a virtual private network (VPN) termination device. The segment outside the firewall connects to all the devices that require management. The segment inside the firewall contains the management hosts themselves and the Cisco IOS routers that act as terminal servers. Information flow between management hosts and the managed devices can take two paths:

In-band: Information flows across the enterprise production network or the Internet (or both).
Out of Band (OOB): Information flows within a network on which no production traffic resides.

The connection to the production network is only provided for selective Internet access, limited in-band management traffic, and IPsec-protected management traffic from predetermined hosts. In-band management occurs only when a management application itself does not function out-of-band, or when the Cisco device being managed does not physically have enough interfaces to support the normal management connection. This latter case employs IPsec tunnels. The Cisco IOS firewall is configured to allow syslog information into the management segment, as well as Telnet, SSH, and SNMP, if these services are first initiated by the inside network. Both management subnets operate under an address space that is completely separate from the rest of the production network. This practice ensures that the management network is not advertised by any routing protocols and enables the production network devices to block any traffic from the management subnets that appear on the production network links. Any in-band management or Internet access occurs through a Network Address Translation (NAT) process on the Cisco IOS router that translates the non-routable management IP addresses to previously determined production IP address ranges. The management module provides configuration management for nearly all devices in the network using two primary technologies:

Cisco IOS routers acting as terminal servers: The routers provide a reverse Telnet function to the console ports on the Cisco devices throughout the enterprise.
Dedicated management network segment: More extensive management features such as software changes, content updates, log and alarm aggregation, and SNMP management are provided through the dedicated management network segment.

Because the management network has administrative access to nearly every area of the network, this network can be a very attractive target to hackers. The management module was built with several technologies designed to mitigate those risks. The primary threat is a hacker attempting to gain access to the management network itself. Only effective deployment of security features