Here's the scenario: You notice that there's a new virus or worm variant out there. The Windows System Administrators in your organization have pushed out the new virus definitions, however, you start noticing a huge amount of latency on the wide area network. Your strategy is to apply selective access lists on the ethernet interfaces of the branch office and central office routers, so you can see the hosts on those networks that are originating the traffic by querying the database on the syslog server. This gives your helpdesk people the capability to determine these hosts without any additional manpower from the network administrators.
Another strategy is to simply monitor for these new virus or worm variants, or anything else an for which an access list can be created. Even the best virus protection out there gives some window for the spread of new viruses. By crafting a special access list, you can easily 'monitor' the outgoing ports that your hosts are looking for. This, too, can be sent to your syslog server, and can be monitored for new infections.
Setting this up doesn't solve all the network problems out there, and it isn't foolproof. It's simply a very valuable tool for doing network firefighting to keep your network up and functioning through virus and worm attacks.
This article presumes you have a working, Unix-like host on your networklike a Linux or FreeBSD host. These instructions for installing each package are fairly generic, since various Unix variants have their own package management systems. Simply install the package via your package manager, and then do any post configuration that may be required.
First, you must have a working NTP server on your network, or your routers must have external NTP servers. An NTP server helps correlate events on your network across all your networking devices. An example of an NTP server is the ntp server at ntp.org. There are others out there. Take your pick.
Next, you need a working RDBMS to log to. Really, this should work with any RDBMS that you are familiar with, if it has a Unix-based client. The examples in this article uses PostgreSQL, which can be downloaded here. The current version as of this writing is 7.4.2.
You'll also need to have a Web-server that allows for the running of CGI scripts. Apache 1.3 or 2.0 should work just fine. It's not imperative that the Web server be installed on the same host as the RDBMS, since Perl should be able to access the database over the network. If the hosts are separate, you need to intall a client on the unix host.
Because you'll be writing CGI's in Perl to access the information in the database, your perl installation needs to have the DBI and CGI modules. Specifically, you need the DBI::Pg module to in order to perform reports on the syslog database. While I recommend installing these modules via packages (so that they automatically upgrad with your OS), you can also manually install them on your system. As root, run these commands on the system you expect to host the CGI scripts:
perl -MCPAN -e 'install DBI'
perl -MCPAN -e 'install DBD::Pg'
perl -MCPAN -e 'install CGI'
Finally, you'll need to install syslog-ng (click here
) to actually perform the logging of the data. Get version 1.6.x, since anything newer is still heavily under development. Current version as of this writing is 1.6.2 If you are compiling syslog-ng, you'll also need to get libol from http://www.balabit.hu/downloads/syslog-ng/libol/0.3/. Also, if compiling, you'll need a syslog-ng.confthere are ones in the contrib directory of syslog-ng. Copy the one that best suits your system to /usr/local/etc/syslog-ng/syslog-ng.conf
. You will probably have to make /usr/local/etc/syslog-ng