Configuring Cisco IOS

General Information

Routers come with different memory sets:

Commands

ALCs

Note: (CHECK) You cannot remove just one line from an existing ACL instruction, as this removes the entire section from IOS. You must type the entire section to add or remove one instruction.

Note: Watch out for the order of instructions in ACLs, as they are processed from top to bottom, ie."deny ip any any" followed by "allow tcp any any" means that a user will not be able to connect using a TCP-based application since the first line is interpreted first.

access-list 110 permit tcp 172.16.120.0 0.0.0.255 any eq smtp
access-list 110 permit tcp 172.16.120.0 0.0.0.255 any eq pop3
access-list 110 permit tcp 172.16.120.0 0.0.0.255 any eq 110
access-list 110 permit udp any any eq 137
access-list 110 permit udp any any eq 138
access-list 110 permit udp any any eq 139
access-list 110 permit icmp any any
access-list 110 deny ip any any!

Logging

IOS debugging messages use the same "facilities" for identification. They are, however, formatted differently than error messages, beginning with a timestamp followed only by the "facility" and the debug message output. IOS error and debug messages follow the Unix syslog severity format (0 emerg to 7 debug). Messages appear in the IOS reporting output action depending on the severity level defined.

The IOS provides four output actions for viewing system event and error data. Console logging is activated by default. In its default configuration, all (severity level 7, debugging) message data is sent to the router's console port (line con0). This approach is similar to Unix, where error and event data is sent to /dev/console or /dev/tty0. To disable console logging, use the configuration mode command <no logging console>. Sending logging data only to the console port may seem odd, since most interaction is done using vty sessions, but the console port can be connected to a terminal server, which buffers the message data or a serial line printer (just like Unix) that can print out event messages. While esoteric, these two methods of data collection were quite acceptable for many years and they are secure from a networking perspective since the data is sent via serial to a locally attached display device (just remember to lock the door).

To view system messages over a vty session (line vty 0 - 4), monitor logging must be configured. To view logging data, the enable exec command <terminal monitor}> is run to activate logging output to the vty. To enable monitor logging, use the configuration command <logging monitor [severity]>. The monitor logging option is the most practical method for viewing logging events in real time. It is highly recommended that you establish two vty sessions, one for displaying event reporting data, and the other for command execution. Often, when troubleshooting or running a debugging sequence, a large amount of logging data is generated. This obscures the vty with logging output, making command entry quite difficult at times. Once terminal monitoring is enables on a vty, it cannot be disabled (unless the logging monitor service is disabled using the configuration command <no logging monitor>).

Local storage of logging messages on the router is also available via buffer logging. Since most routers do not have a hard disk, messages are saved in a DRAM buffer. While buffer logging does not directly affect the router's performance, it does consume memory. However, if your router is short on memory, you may see performance issues with processes that need memory if your logging buffer allocation is too large. To verify your router's memory configuration, use the enable exec command <show version> which will provide a variety of operational facts about your router, including the amount of DRAM allocated for packet buffers and the amount allocated for operational processes (i.e., routing tables, CEF tables, etc.) To see if you are having memory allocation issues, use the enable exec command <show memory failures alloc >. A reasonable buffer allocation is 64k; the "history" logfile is a rotating one, which overwrites the last log entry when the size limit has been reached. To configure buffered logging use the following configuration commands:

Godzilla-ABR(config)#logging buffered notice
Godzilla-ABR(config)#logging buffered 64000
Godzilla-ABR(config)#logging history size 250

The above configuration sets the buffer size at 64k and sets the history count at 250 messages. To view the buffered logging data, use the exec command <show logging>. This command performs two functions; it reports on the configuration of the router's various reporting display actions, and outputs the logging buffer history (if buffer logging is configured).

To send system messages to a remote syslog host, ;TRAP logging needs to be configured as a reporting output action. Remote reporting has two big advantages over local reporting.

Configuring TRAP logging is a four step process:

  1. Define a syslog host using the configuration command <logging {hostname or IP address}>.</i>
  2. Define the logging severity of the messages to be sent using the configuration command <logging trap {severity}>.
  3. Define the IP address that will be associated as the origin address of the logging messages. This is set using the configuration command <logging source-interface {interface type m/s/p}>.
    The final step defines the syslog "facility" that the messages are sent to on the remote syslog server. Use the configuration command <logging facility {syslog facility}>. Here is a trap reporting configuration example that uses the Loopback interface as the report origin address:

    Godzilla-ABR(config)#logging 64.128.20.12
    Godzilla-ABR(config)#logging trap informational
    Godzilla-ABR(config)#logging source-interface Loopback 0
    Godzilla-ABR(config)#logging facility local2
 

Conclusion
That covers the basics of Unix syslog and IOS logging and IOS logging configuration. In part two, we will move on to implementation and look at a practical IOS logging approach. We'll include using your routers to collect intrusion and security exploit scans from the Internet, as well as implementing syslogd on Red Hat Linux and some scripts to generate reports on the data the router collects. So stay tuned...

Resources