Use WMI to Monitor Your Web Site for Changes

Many Internet users are eager to deface your Web site. If an attacker succeeds in vandalizing your Web site despite your security measures, you can reduce your losses and minimize embarrassment by responding quickly. A variety of third-party tools can help you monitor your server for changes to your Web site files, but most of these products are resource-intensive or expensive. However, you have another choice: Use VBScript to write a simple, efficient script that uses Windows Management Instrumentation (WMI) on your Windows XP or Windows 2000 Web server to watch for changes to your Web site files and that immediately alerts you when it detects a change.

Configuring Auditing
Before using the script, you need to configure auditing so that Win2K records an event in the Security log when someone opens one of your Web site files. To begin, open Local Security Settings under Administrative Tools. Enable the Audit object access audit policy for success and failure: Right-click Audit object access, click Security to open the Local Security Policy Setting window, click Success and Failure, then click OK. (If your Web server is a domain member, you should enable auditing through Group Policy instead of through Local Security Settings.) At a command line, type

secedit /refreshpolicy machine_policy

to apply your changes. To verify that your new audit policy is in effect, right-click Security Settings in Local Security Settings and select Reload. The Effective Setting column in the detail pane should reflect your new policy.

Next, enable auditing on your Web site's content files by opening Windows Explorer and navigating to your Web site's parent folder. Right-click that folder, select Properties, and select the Security tab. Click Advanced and select the Auditing tab. Click Add, then double-click Everyone. When Windows displays the Auditing Entry dialog box, select Files only from the Apply onto drop-down menu. In the Successful and Failed columns, select Create Files / Write Data and Create Folders / Append Data, as Figure 1 shows.

Enabling object-access auditing can burden your system if you don't limit the objects and type of access you audit. In this case, you audit only attempts to open existing files for Write or Append access. If you want to know when someone creates new files in this folder, you'll need to select This folder, subfolders and files from the Apply onto drop-down menu. If you want to be notified of changes to file attributes or file deletions, select the appropriate accesses in the Successful and Failed columns. However, I recommend that you start with the settings that Figure 1 shows and tweak the auditing policy after you gain experience with the script.

The Script and the Log
Whenever Windows audits an object-access event, it writes the event to the Security log with event ID 560, as Figure 2 shows. Alerter.vbs uses the code that callout A in Listing 1 shows to set up a WMI event filter that looks for new instances of event ID 560. The script then initiates a Do loop. Within the loop, the code at callout B asks the event filter for the next event that matches the criteria specified in the Set events statement. While it waits for an occurrence of event ID 560, the script uses no resources. (Web Listing 1 at http://windowswebsolutions.com, InstantDoc ID 25235, shows alerter.vbs in its entirety.)

When the OS records an object-access event, Windows loads the event into the NTEvent WMI event object and the script continues. After you enable object auditing, Win2K starts logging on the SAM certain object-access operations that aren't relevant to what we're looking for. The script weeds out those extraneous event ID 560s by checking the event's object type to determine whether the accessed object was a file. Each detail in the event's log-entry Description in Figure 2 corresponds to an element in the InsertionStrings zero-based array. For example, InsertionStrings(1) contains the Object Type, and InsertionStrings(2) contains the Object Name. To conserve resources, you should configure WMI to do as much of the filtering as possible; however, WMI doesn't permit reference to InsertionStrings in the event filter, so you need to do that filtering in the script.

When the event is a file-access event, the script uses the Blat utility to send an email message alerting you to the problem. Blat, a public domain utility available at http://gepasi.dbs.aber.ac.uk/softw/blat.html, lets you use SMTP to easily email files. The email message's Subject line shows the message recipient that someone opened the file for Write or Append access and the name of the user who opened it. The attached file (alertermessage.txt) contains the full details of the event. To prevent an overflow of messages, the script won't send more than 10 alerts per hour. The file attached to the tenth alert will read NOTE: This is the 10th alert of this hour. No more messages will be sent until the next hour.

   Previous  [1]  2  Next