If you're worried about whether or not your system is being attacked, running regular inspections with Log Parser can help you get a handle on what types of attacks are being made and where they're coming from.
Using Log Parser to do this sort of work, as opposed to a general purpose string-search tool (like the UNIX grep command) has several advantages:
- The program uses standard SQL querying. If you're already familiar with SQL, you can use your existing knowledge of the language to get the best from the program.
- You can perform structured queries directly in the logs, so you can narrow the results down by time, date or IP cluster without having to perform additional filtering.
- Queries can be saved as scripts, reused indefinitely, or invoked from batch files or VB shell scripts.
One important caveat about Log Parser is that it requires the logs to be used in a consistent format, including column headers, and that you properly specify which format is to be used. Log Parser supports most of the common types (IIS, W3C, NCSA, etc.), but the column definitions for each type of server log format differ widely. This will affect how you construct your query, since you need to know which columns to parse.
If you're using the standard W3C format for your logs, for instance, a query to look for attacks that attempt to execute arbitrary code through CMD.EXE might look something like this:
select * from C:\WINDOWS\system32\LogFiles\W3SVC752518\*.log where cs-uri-query like '%cmd.exe%'
Note, of course, that the exact path to the log files would vary from system to system. The cs-uri-query column name (which contains the data passed for a GET or POST query) will change depending on the type of logging being used. The program's own documentation details what column types are valid for each variety of log.
Most attack signatures are visible as ordinary GET requests, making them relatively easy to find when you're using a tool like Log Parser. Several common signatures to look for are:
CMD.EXE ROOT.EXE AAAAAAAA / XXXXXXXX (used in many common buffer overflow exploits)
Another useful feature for doing queries of logs with Log Parser is the iCheckpoint function, which lets you do incremental processing. This allows Log Parser to "bookmark" a given log file, so that the next time Log Parser is run on that file, it will pick up where it left off instead of reparsing everything from the beginning. To use iCheckpoint with a particular script, pass this parameter in the command line used to invoke Log Parser:
The checkpoint file is used to preserve the state of every file parsed with Log Parser, so you can use the same checkpoint file for all the logs in a given system. If you run Log Parser on a weekly or even daily basis, this feature's a great timesaver.
About the author: Serdar Yegulalp is the editor of the Windows 2000 Power Users Newsletter. Check it out for the latest advice and musings on the world of Windows network administrators -- and please share your thoughts as well!
More information from SearchWindowsSecurity.com
This was first published in July 2005