The CONVLOG utility lets you convert other log formats to the NCSA format. In addition, the utility can resolve individual IP addresses to Fully Qualified Domain Names (FQDNs) during the conversion process. Here's a typical CONVLOG command:
CONVLOG ie ex00312.log -d
This command converts a W3C-formatted log to the NCSA format and resolves any IP addresses. The syntax of the CONVLOG command is too lengthy to print here, but you can easily see it from the command line of your IIS server by entering the command CONVLOG from the DOS command shell in Win2K. (Note that if you convert W3C logs to the NCSA format, you'll lose any process accounting information.)
ODBC Logging
ODBC logging is best described as logging directly to a Microsoft SQL Server or ODBC-ready database. Microsoft Access can also speak ODBC, so you could also log directly to that platform. ODBC logging isn't a popular option because it requires additional overhead and network connections to a remote database server.
The benefit of this logging format is that you have all your Web server logs centralized in one place. You might also have other logging going to the same database. When you need to print reports, you'll have an easier time pulling the logs from an offline database rather than sacrificing your Web server's resources. Another benefit is that you can use SQL-type queries against your logs, which makes ad hoc queries a snap.
Making the Log File Information Useful
If you're staring at piles of log files and you're not quite sure what to do with them, you're probably not alone. Some of the Web servers I'm responsible for log more than 100MB per day in the W3C format. That number might not be impressive depending on the Web site traffic and the number of graphics and application calls in your content. Nevertheless, it's a lot of information to chew through.
Web server administrators evaluate logs in two ways—performance and problems. Showing performance is easy with commercial packages such as WebTrends' Log Analyzer and Mach5 Enterprises' FastStats Analyzer. However, even if you have a commercial package that automates everything, you still need to check your logs for potential problems the logging package can't catch. Malicious users wanting to test your resolve toward Web server security are commonplace in this business. These users check whether your patches and security settings are up-to-date. For example, you might see something like this in your Web logs:
POST /msadc/msadcs.dll
Unless you're using an application that uses the Remote Data Factory object, this line doesn't appear in your logs. Malicious users also attempt to exploit other applications and content on your system to see whether you've overlooked security precautions during your installation process. So, how do you keep an eye out for this information?
I use the FINDSTR command frequently. You can use it on live open log files and on closed log files. I'm fortunate in that I don't have any applications that require POST on my Web servers, so I can search for any line that matches the word POST to determine who is snooping around my Web server. For example, the command
FINDSTR /i /c:"POST" ex000312.log
displays to the console anything that matches POST in the file ex000312
.log. From there, I can pipe the output into a file or another FINDSTR command, such as
FINDSTR /i /c:"POST" ex000312.log | FINDSTR /I /v /c:"goodapp.dll"
This command displays all POST entries that aren't involved with goodapp
.dll. This command might not display someone trying to test your application by flooding it with input (a buffer overrun condition), but you get the picture. With some careful DOS commands and scripting, you can make a great screening tool to help you parse your logs. You might be able to parse for all the exceptions and have the server mail the file to you regularly.
Here's a word of caution: As you parse logs, you might run across something that doesn't look right. Be cautious when you react. Don't overreact just because someone is rattling the doors around your Web server. It happens all the time to a lot of us. However, if someone has definitely accessed your Web server, investigate the event calmly but thoroughly until you have peace of mind.
End of Article
Prev. page
1
[2]
next page -->
