| Downloads |
|---|
| 25235.zip |
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.
Before Using the Script
Before you use alerter.vbs, create a folder in \%systemdrive% called FileChangeAlerter and put blat.exe and alerter.vbs into the folder. Next, configure Blat with your SMTP server's address and sender's email address from a command line. Simply run
blat -install smtphost.acme.com [email protected]
For smtphost.acme.com, substitute the DNS or IP address of your SMTP server. Replace [email protected] with the email address from which you want to send the alert emails. Finally, edit alerter.vbs to clarify the documentation. Locate the line
WshShell.Run "blat " & _ msgFileName & chr(34) & _ subject & chr(34) & _ "-t [email protected]" , 3, 1
and replace [email protected] with the email address that you want to send the alerts to.
Using the Script
You can now start and run the script in GUI mode with WScript alerter.vbs or in command-prompt mode with CScript alerter.vbs. To test the script, open some files in the folder that you're auditing. You should soon receive an email message with a Subject line similar to ALERT: C:\Inetpub\wwwroot\error.html successfully opened on \\NT2. If the event is a failed audit event (because you lack the appropriate permissions), the subject line will read ALERT: C:\Inetpub\wwwroot\error.html UNsuccessfully opened on \\NT2. The message body will contain the Security log entry.
If you want alerter.vbs to start and run in the background whenever your server starts, configure it as a startup script. Open Microsoft Management Console (MMC) and select Console, Add/Remove Snap-in from the menu bar. Click Add, then double-click Group Policy. In the Select Group Policy Object dialog box, click Finish. Click Close, then click OK to close all windows. In the MMC console, navigate to Local Computer Policy\Computer Configuration\Windows Settings\Scripts (Startup/Shutdown), as Figure 3 shows, then double-click Startup in the right-hand pane. In the Startup Properties dialog box, click Add, then click Browse. Select alerter.vbs and click Open. Click OK twice. Now, your server will run alerter.vbs in the background whenever the server starts up.
If you want to run alerter.vbs as a startup script, I recommend that you change the file association for .vbs files so that the script runs in character mode. To run a script in character mode, you need to execute it with CScript instead of WScript. By default, Win2K associates .vbs files with WScript. To associate alerter.vbs with CScript, open Windows Explorer and select Tools, Folder Options from the menu bar. Select the File Types tab, then select VBScript File in the Registered file types list. Click Change and Browse, then select cscript.exe, which you'll find in \%systemroot%\system32. Changing the file association ensures that if the script encounters a problem, it won't produce an error dialog box, which would cause the script to hang—instead, the script will simply terminate.
Enhancements and Miscellany
If you're comfortable with scripting, you might want to enhance alerter.vbs so that it reports errors to a text file. Should you need to terminate the script, you can do so from Task Manager—to locate the script, look for a CScript or WScript process.
Keep in mind that when alerter.vbs sends a successful audit message, that message doesn't necessarily indicate that someone has changed the file. If a user simply opens a file for Write access, that action generates event ID 560, even if the user immediately closes the file without making any changes. Also, be aware that when you legitimately update content on your Web site, you could trigger the maximum 10 alerts per hour. When you update Web site content, you should probably terminate alerter.vbs temporarily.
