www.jdmz.net troy.jdmz.net

I wanted to collect more information from various Windows boxes that I manage, but I did not want to pay a lot of money, or manage licenses for another piece of software. I had been using 'syslog' to collect alerts and other messages on a central location for a while, so when I saw the free and open NTsyslog, I was very interested.

I installed it (manually) a couple of times, and it worked well, but it really needed an installer to be of use to me (my Windows installations have few clients and are in unrelated businesses). When I discovered Inno Setup, I knew I could make a nice installer for NTsyslog that would have a Windows client up and reporting in a few clicks. Jason (the person responsible for NTsyslog, thank him very much) put the installer up on the NTsyslog sourceforge page.

Configuring NTsyslog is pretty easy, especially if you have configured syslog on Linux or UNIX hosts before. You can choose to report or not report via syslog for five types of events in each "EventLog". By default there are three EventLogs: Application, Security, and System. You can report for other EventLogs (in the current version), but you will have to edit the registry to do so.

For the event types you decide to report via syslog (of Information, Warning, Error, Audit Success, and Audit Failure) you must choose a syslog facility and priority. What you choose depends on how you wish to log those events in the syslogd server configuration. If you want to log Windows clients and servers separately (like I do), you will want to choose different facilities for those two types of Windows boxes.

         

I have registry files for my current favorite setup for servers and clients, where "192.168.1.1" is the IP address of my Linux log server and "192.168.1.2" is the IP address of my secondary log server, or maybe a Windows box running a syslog server (like Kiwi Syslog). To easily replicate custom setups, I made a batch file to dump the current settings for editing or immediate use.

To configure a typical Linux host to send all of it's syslog messages to the syslog server, add a line like the following to /etc/syslog.conf: where, as in the NTsyslog example above, "192.168.1.1" is the syslog server. If you do not want possibly sensitive log information to go out on your network wire unencrypted, you will have to modify the "*.*" part of the line. The next example sends what you would normally find in /var/log/messages to the syslog server: You may insert multiple lines for different message "selectors" (the "*.*" and "*.info;mail.none;news.none;authpriv.none;cron.none" parts in the examples given), or for sending syslog messages to multiple hosts. Use "man syslog.conf" to find more possibilities for sending log messages from a Linux syslog client, and what the details of the above examples really mean.

I use the settings above with the following in my /etc/syslog.conf file: and I also edit one file and create another on my Red Hat-ish boxes.

One file is /etc/logrotate.d/syslog, and I just include the two new log files on the first line. After modification, the first line looks like this: This is done so that the Windows logs are rotated on the same schedule as the others, requiring the syslog server to restart only one time.

The other file is /etc/sysconfig/syslog. Usually, Linux syslog packages are configured by default not to accept syslog message from other hosts on the network. To fix that I modify the SYSLOGD_OPTIONS variable so that it does accept network syslog messages (-r) and doesn't try to lookup DNS names (-x) for hosts on my (typically) small networks: The other switch and argument are defaults and are explained in the file comments. To put the new settings into effect, the syslog daemon must be restarted [1]:

An iptables firewall may prevent syslog messages from being received by the syslog server, because that is what firewalls like to do. I don't recommend it, but you can shut it off: or you can configure iptables to let syslog messages through to the syslog server. On a Red Hat-ish system like Fedora Core 3, you can add a line to /etc/sysconfig/iptables just before the line with "-j REJECT" in it: and then restart the iptables service: Be aware that this can be a dangerous thing to do, depending on the risk level of the network to which you are connected. You may wish to limit the range of IP addresses that can successfully send syslog messages to this host. Here is an example line that would replace the one above: This example would allow only hosts with IP addresses between 192.168.1.1 and 192.168.1.254 to send syslog messages to the syslog server running on this host. Alternatively, if wanted limit access to a single host, use this line as a replacement: This example would allow only the host with the IP address of 192.168.1.10 to send syslog messages to this syslog server. If you want multiple single hosts, or multiple subnets, to be able to send syslog messages to the syslog server, just use multiple lines to express those rules before the "-j REJECT" line. IPTables has great power and flexibility, and more information concerning it is available from other sources.

I should now be able to see messages in the Windows log files: If you don't see any messages immediately, reboot a machine that is configured to report syslog messages (if it is convenient to do so). Most computers send many interesting syslog messages on bootup.

I have been looking into ways of processing the logs, but I suspect there may be a few I don't know about. One option is logwatch, which comes standard on Fedora Core 3 and on many other Linux distributions. Another is epylog, a log processor implemented in Python. Still another interesting option is Sawmill, and while it isn't free, but it might make your current logs a lot more valuable to you, so may be worth the money (and they have full working versions for evaluation purposes). Lastly, I tried out Splunk recently and found it worth getting to know better, and it comes in free and paid versions.

Though I am mainly interested in email alerts and web reports, I do try to keep an open mind. Please let me know if one log reporting or alerting package or another works great for you.