Router Configuration, Phase Two
The routers need to have their system logging capabilities modified to allow for logging to the syslog database above. Add these lines to your configuration:
Enter configuration commands, one per line. End with CNTL/Z.
RouterA(config)#logging rate-limit 5
RouterA(config)#logging trap debugging
RouterA(config)#logging source-interface FastEthernet0/0
The most important line of this configuration code is the logging rate-limit
command. This command limits the number of syslog events that can be sent to your syslog server per second. This is ESPECIALLY important when dealing with virus traffic because of the high number of syslog events that it's possible to receive. I have mine set very low, which means that there's no guarantee that every system log event is going to hit the syslog server. However, I'm am assured that it's not going to saturate my network.
Secondly, the source-interface is important. By default, IOS will pick whichever interface it desires from which to send the syslogs. It will be a bit easier to find these devices if you use the most commonly known IP address, such as the Ethernet interface. The router used in these scripts is a Cisco 2621 router, so it has a FastEthernet 0/0 port, but your router may have a different port.
Once the configuration has been modified, save the configuration. This will do two things. First, it's going to save your changes, secondly, it should send an event to the syslog server, so you can check to see if the data is working properly.
Now run select msg from syslog to see if that syslog event that you just created is getting logged properly. The output should show all of the current syslog messages.
After you verify that one router is working properly, repeat the above steps on all of the routers that you would like to have logged to your centralized syslog.
The Fun Part
There are other front ends for system logs that are stored in SQL servers. However, I chose to write my own for a variety of reasons. Mainly, my processing needs are fairly simple, and I have some customized colorization needs to make it easier to parse through the data. I wrote a customized front end as a simple Perl CGI that runs under the Apache Web server.
First off, you need to verify that your CGI environment is configured properly. Apache comes with a simple CGI called test-cgi in the cgi-bin that Apache installs. Rename it to make it parse properly and make it executable:
mv test-cgi test.cgi
chmod 755 test.cgi
Next, make sure your httpd.conf will process .cgi files by adding:
AddHandler cgi-script .cgi
AddHandler cgi-script .pl
Now, access your Web server in a browser. The url should be http://server-name/cgi-bin/test.cgi
. There should be a response like this:
CGI/1.0 test script report:
argc is 0. argv is .
SERVER_SOFTWARE = Apache/1.3.26 (Unix) mod_perl/1.27 PHP/4.2.3 mod_ssl/2.8.10 OpenSSL/0.9.6a
SERVER_NAME = server-name
GATEWAY_INTERFACE = CGI/1.1
SERVER_PROTOCOL = HTTP/1.1
SERVER_PORT = 80
That means that you're ready to start with your CGI!
You'll need to get the attached syslog.cgi script, and modify it a bit to suit your environment. First, you'll need to edit the list of your IP addresses for your routers (look for the first FIXME section). If you're not entirely certain which IP addresses the devices are using to send data to the syslog server, run the select distinct(ip) from syslog; on the syslog database. This will show all of the unique IP addresses. Make sure that each of these IP addresses are in this list.
Secondly, you'll need to configure your Postgres logging information to the correct username and password for doing queries on the database (Look for the second FIXME section).
Finally, you'll need to copy it to your Web server's cgi-bin directory and set permissions on it. Type chmod 755 search.cgi on the cgi. I usually run the CGI from the command line to make sure I didn't type-o anything the first time. If you run the CGI and all that's shown is