|Windows port of Logcheck|
- PGP Keys
- Vossen's Law
- Firewall Rules
- Home Net Security
- Snort Books
- Sec Tools
- Honeypot Stats
- Firewall Stats
- IP Calcs
- SME Server
- Backup (DI-30)
- Win Tools
- Win. Shell Scripting
- POSIX Redirection
Welcome to the Windows port of Logcheck (now called LogSentry), the famous UNIX log processing tool. Psionic was bought by Cisco who has moved the cool Abacus tools, including LogSentry, to http://sourceforge.net/projects/sentrytools/
As you probably know if you are bothering to read this, LogSentry helps spot problems and security violations in your logfiles automatically and will send the results to you in e-mail. However, it can only work with what it's given. I personally find the Windows Event Logs to be verbose, yet un-informative. So when you get e-mailed messages with three or 4 lines on arcane gibberish, remember that it's the same information as you would see in the Event Log, except it's in a slightly different format, and you are actually SEEING it! (Of course, you would have reviewed the Event Logs anyway, right?) :-)
The beginning of each log entry contains the name of the Event Log, the date, and the time, like: "DIR,7/20/2001 11:52:12". this is followed by the event details. The three letter codes for the Event Logs are:
It will help to look for those codes to isolate one event from the next, since your mailer will probably wrap the lines.
Also, the MS API for the Event Logs will return the application log if the Event Log being asked for does not exist. Once it returns the handle, there isn't any way that DumpEvt can tell which log is being read. For example, if you dump RPL on an NT box, or DNS on W2k Pro it dumps the APP log instead. This causes duplicate entries in the capture file. The only work-around right now is to edit wrapper.cmd and REM out the Event Logs that do not exist on that machine.
While the actual logcheck.sh script could have been ported to the CMD.EXE shell, I thought it was much more efficient and effective to make as few changes to that as possible, and instead create a "wrapper" program to translate "Windows" into "UNIX."
I gave the wrapper the highly imaginative and interesting name of "wrapper.cmd." Note that it only runs under Windows NT and 2000 (and probably XP though I have not tested that). In short, logcheck is pointless without logs, which means the Event Logs. Since the Win9x series doesn't have those...
See the "Tools-Readme.txt" for details about what tools are needed.
I struggled with the default directory location for a while. I *hate* programs that put themselves in the %SYSTEMROOT% (e.g. c:\winnt) directory. However, I wanted to be a little obscure, so I thought c:\etc was a little too obvious. And I wanted to be reliable, so "c:\Program Files" or "c:\Documents and Settings" were both too long, and had annoying spaces. C:\Progra~1 and c:\Docume~1 are not 100% reliable. So %SYSTEMROOT%\etc it is... Of course, you can change that if you want.
Note the word "secured" above. YOU need to set proper permissions on those directories so that the account under which logcheck runs as the proper access, but "Everyone" else does not. See the INSTALL-Windows.txt file for more details.
At the heart of logcheck are two basic things, grep and mail. If they fail, so will logcheck. While in the UNIX world you can assume the ability to send mail from the command line, in the Windows world you can't. So make sure Blat is working. Again, see the INSTALL-Windows.txt file for more details.
This software is released under the GPLv2. See the included LICENSE file.
First, to Marcus J. Ranum and Fred Avolio for writing the deceptively simple yet brilliant original frequentcheck.sh for TIS Gauntlet.
Second, to Craig Rowland for applying the idea to system logs.
Third, to all the people who wrote or ported the tools I needed to get logcheck to run under Windows, notably K. M. Syring, the guys at Somarsoft, and Tim Charron.
Fourth, to G.P. and I.P. who sent me logs to test to help me tune the keyword files, and answered various other questions.
I should also mention the guys at Bastille Linux, whos style I've copied here a bit in the Setup program "interview."
Finally, a few notes about other tools or resources that may be of interest, if you've managed to read this far.
I've found the following book to be essential in other Windows scripting projects, and it proved helpful in this project as well. For anyone who thinks you couldn't possibly find enough material in the old DOS batch file language to write a book about it -- that's what I thought when I saw it. Check it out! While not nearly as powerful, flexible or easy to use (though some would argue that last) as UNIX shells, Windows's CMD.EXE is actually a lot more powerful than you think. Forget about Command.com though...
Windows NT Shell Scripting, by Tim Hill
Other Methods of accessing the NT Event logs (not free):
Other Tools of interest (free):
Last Modified: $Date: 2009-02-27 15:16:07 -0500 (Fri, 27 Feb 2009) $