Tuesday, August 10, 2004

Enterprise Monitoring, Windows Systems

SourceForge.net: Project Info - Enterprise Monitoring, Windows Systems

We had a problem to solve. How to effectively review Windows remote client Event Logs to make sure that our firewall and security policies were working. I learned the importance of reviewing security logs after I first used Windows 2000 TCP/IP filtering to limit access to our remote clients. This worked for most computers but failed whenever a DSL company added a internal modem. Basically the TCP/IP filtering only worked when all traffic used the LAN interface. I didn't like finding out about the security problems after someone was infected by a worm.

I looked into two different tools for polling Windows event logs. One method was using a syslog Windows client to send a UDP message whenever a event log message was generated. I was able to find GPL free license for the Windows client but not for the Windows server piece. However, I could always use a Linux machine for the server.

The biggest advantage of this method was it's use in the Unix/Linux world. I felt comfortable using old tried and true system enterprise logging and I really liked the idea that I could integrate some Linux technology into Windows. The biggest problem was that the security log messages would be pushed to the server whenever there was an issue. Now our remote clients connect to work through a VPN connection and are not always able to connect to the syslogd server. Apparently the messages would be serialized to easily show when information was missing from the server but I expected that the remote client would see that situation 40% of the time. I thought about sending the UDP messages over the Internet through our firewall, but realized that the messages would be unencrypted and able to be sniffed from anyone.

So in order to use syslog with Windows logging I would have to encrypt the UDP connection to a internet exposed server and look into the possibility of caching the syslog messages which was highly not recommended for problems with bandwidth when everybody started their morning shift.

The other option is working quite well for us. I ended up using Event Collector/Monitor from sourceforge because of the GPL license and the fact that it pulled the information from the remote clients. The Event Monitor project using the Windows admin$ share to copy the system log to a centralized server and then uses Perl to parse the contents into a SQL database (MS-SQL or MySQL). It uses a php front end to input the computer names and create search reports. It also has a filter system that is used to email an administrator when certain criteria are met. Currently, I have every warning, error, and security failure emailing my Exchange account which throws the alert into its own folder.

This software worked so well that I have included all of our in-house computers and servers. It was really useful for me to get an email for every error, although I'm starting to get too many emails and will probably create better filters. Now that I understand what errors I'm getting I think the more specific filter will work better than if I didn't get all errors sent to me.

Through this program, I have found out that there are more issues than I remembered with the client computers. I would see errors here and there when manually auditing the event log but I never was able to see patterns over all the computers. I realized because of this software that a software package is continuing to ask for more security privileges than I gave it. It didn't stop the program in any noticable way but now I have something to fix pro-actively.

I installed the Event Collector (Event Collector is the name of the Windows application that polls the clients) on my workstation. I used IIS, MySQL, and cygwin's perl package. The actual event collecting can use quite a bit of the processor but usually only when adding a new client that needs the entire log parsed.

No comments:

Post a Comment