Any good security plan includes regular monitoring of security devices and the messages they produce. Without this step, administrators wouldn’t know when their environments were under attack or when their firewalls were having problems.

If your network security depends on a Cisco PIX firewall, you should configure an external source to monitor logs the PIX generates. One way to do this is to use a central UNIX or Linux syslog server. A syslog server captures system-logging messages, both informational and error messages, into a common log file. A syslog server also provides a central location for the admin to check messages from the PIX and other devices.

I’ll show you how to use a syslog server to accept your Cisco PIX firewall logs. I’ll be using a Red Hat Linux 7.2 server as the syslog server and a Cisco PIX 501, running version 6.2.1 of the PIX software and version 2.0.1 of the PIX Device Manager (PDM) software. My Linux server is at 192.168.1.200 and my Cisco PIX 501 firewall is at 192.168.1.20.

Setting up syslog
A default installation of Red Hat Linux 7.2 (and almost every Linux and UNIX implementation available) includes the syslog daemon (syslogd). This daemon is started at boot and needs to be configured to receive information from your PIX.

Syslog uses eight levels to determine the priority of the message (as shown in Table A) and can be set up to act on each level differently. An informational message can be sent to a history file while an emergency message is sent to the e-mail address of the network administrator’s pager.

Table A
Level Use
0 Emergency
1 Alert
2 Critical
3 Error
4 Warning
5 Notification
6 Informational
7 Debug
Syslog message levels

Restarting syslogd with the proper parameters
By default, the syslog daemon doesn’t accept messages from the network. To capture messages from your PIX on the syslog server, you must stop and restart syslogd on your Linux server with the -r parameter. To do this, execute the following commands:

  • ·        ps -ef |grep syslog
    Looks for the process ID running the syslog daemon
  • ·        kill -9 process_id
    Stops the syslog daemon
  • ·        /sbin/syslogd -m 0 -r
    Restarts the syslogd service with the –r parameter and turns off timestamp intervals with the -m 0 parameter

When you’ve restarted syslogd with the proper parameters, make sure that your server is listening for syslogd connections by issuing the netstat -an command, which yields an output similar to the one shown in Listing A.

Syslogd uses UDP port 514 by default, but you can configure it to use a more obscure port if you’re concerned about the security of your syslog server. Listing B explains how to change the syslogd port.

Configuring the PIX for syslog
With syslogd running on your Linux server and ready to accept connections from the network, you can then configure your PIX to send messages to the Linux server by logging them to /var/log/messages. This setup can be done in one of two ways: at the command line or via the PDM software included in new releases of the PIX software.

Command line
From the command line (in configuration mode, often called config mode), you need to specify the following options:

  • ·        logging on
    Turns on logging and sends logging information to all configured outputs
  • ·        logging timestamp
    Sends a local timestamp with each message sent to the syslog host
  • ·        logging trap informational
    Sets the type of information that will be sent to the syslog server
  • ·        logging facility 20
    Files messages based on facility
  • ·        logging host inside 192.168.1.200
    Receives syslog messages

For those of you who are not sure how to get to the PIX config mode, Listing C explains how.

For the logging trap informational option, the level set will send messages of that level plus all higher levels. If the trap level is set to error level 3, error (3), critical (2), alert (1), and emergency (0) messages will be sent. By setting the trap to informational (6), all messages with the exception of those related to debugging (7) information will be sent to the syslog server.

Save your changes

If you’re using the command line to set up syslog logging, make sure to save your changes with the write memory command.

Using the PDM
After starting the PDM, click on the System Properties tab. This tab features the same options described in the command line section above, including the host, the syslog facility, the information level, and whether or not to include the timestamp of the message. This screen also allows you to specify how many messages can be queued when the syslog server is too busy to handle them.

To use the PDM, from the System Properties tab, expand the Logging category on the left (see Figure A). On the Logging Setup subcategory, select the check box marked Enable Logging.

Figure A

The second check box allows you to use logging for a standby unit. At the bottom of this window, you have the option to suppress specific messages from the Cisco PIX. This lets you exclude certain messages, such as messages that indicate that a ping failed, like message ID 110001.

Command line equivalent

To configure the PIX to suppress ping messages via command line, the syntax would be no logging message 110001. To configure the PIX to enable logging from the standby unit via command line, execute logging standby.

The PDM logging tab lets you have messages written so that you can use the PDM to view them later instead of needing to use syslog to view them.

Syslog, the next subcategory, (see Figure B) is where the majority of the syslog options are set up.

Figure B
Setting up the syslog options

The final system messages subcategory (see Figure C) is Others, which is listed under Logging.

Figure C
Other syslog options

The first option lets you write messages to the console. The command line equivalent for this option is logging console <level> (where level indicates the required level).If you expect a high volume of messages, I don’t recommend this option.

The second option lets you write messages to all logged in Telnet sessions. Again, I do not recommend this. Sending output directly to the console can make it impossible to use that console window because your work will be interrupted as a message is passed from syslog to the console.

The last option allows you to send syslog messages to an internal buffer that you can later view from the console. It’s best to use this option because it won’t interrupt any command line work while the machine is logging.

Testing the system
Assuming that you’ve configured logging to be fairly generous—logging pretty much everything—it should be easy to test your setup.

From the command line on your PIX, ping a nonexistent device. For example, I will try to ping 2.2.2.2, which will return errors indicating that the device is not responding. Then, from the command line on your Linux server, use the tail /var/log/messages command to view the very end of your /var/log/messages file.

On my Linux system, I get the error message shown in Listing D (taken from var/log/messages) as a result of this command.

One step closer
Using syslog to manage the messages put forth by your PIX brings you closer to central management for your entire infrastructure and will provide an easier means to monitor your equipment. Just remember that syslog uses UDP port 514. If you have an additional firewall between your PIX and your management server or if you are running a firewall on your Linux server, you need to allow this traffic for syslog to work.

For more information

Look for upcoming articles on interpreting Cisco log files. If you need to translate the log files into more understandable form, check out what Cisco has to say about interpreting log files.