Auditing

[Previous] [Next]

Auditing is one of the cornerstones of any secure application. Frankly, without auditing, you have no idea what's going on from a security standpoint. Auditing serves two main purposes:

• Provides the ability to determine whether, how, and when you were attacked and what was attacked
• Provides the ability to troubleshoot security issues

The second bullet point is the subject of an entire chapter, Chapter 11, "Troubleshooting Secure Solutions." The rest of this section deals with the security implications of auditing and describes some best practices.

Windows 2000 includes many different types of log files, such as the Web server logs, Windows 2000 event logs, SQL Server logs, and perhaps logs from firewalls, proxy servers, and intrusion detection software. We'll refer to this entire group as the audit logs. An audit log records events in chronological order such that the details that lead up to the event can be determined at a later date. It is this point that makes audit logs interesting for forensics.

Securing Log Files Against Attack

Because audit logs contain so much important and potentially sensitive information, you must secure them from attack—most notably, from tampering—and back them up regularly. You can achieve the first goal by using appropriate ACLs. For example, the three log files that make up the Windows 2000 event logs—AppEvent.evt, SecEvent.evt, and SysEvent.evt in \WINNT\System32\config—have an ACL like this:

• SYSTEM (Full Control)
• Administrators (Full Control)

No user but an administrator can read or modify the log files.

The SQL Server logs have similar ACLs. However, the IIS logs inherit ACLs from the parent directory. Make sure the IIS log ACLs are similar to the ACLs on the SQL Server logs. The IIS audit logs reside at \WINNT\System32\LogFiles.

Audit log files are a precious resource, and backing up audit logs is paramount. You should have a rigorous backup plan and back up to tape or a write-once medium, such as a writable CD-ROM. One of the authors employs a Windows Script Host (WSH) script that runs four times a day as a task under the control of the Windows Task Scheduler. The script drives NTBackup.exe with command line arguments. Here is the script:

 Option Explicit ' Build up the name of the backup file ' from the date and time. Dim dDate, strYear, strMonth, strDay, strHour, strName dDate = Now strYear = DatePart("yyyy", dDate) strMonth = DatePart("m", dDate) strDay = DatePart("d", dDate) strHour = DatePart("h", dDate) if strMonth < 10 Then strMonth = "0" & strMonth if strDay < 10 Then strDay = "0" & strDay if strHour < 10 Then strHour = "0" & strHour ' Filename is LogBackup-YYYYMMDD-HH.bkf. strName = "LogBackup-" & _ strYear & _ strMonth & _ strDay & "-" & _ strHour & ".bkf" ' Build up the backup command line. ' We will also back up the system state information. Dim strShell strShell = "ntbackup backup systemstate " strShell = strShell & _ """c:\LogBack\LogBackup.bks"" /J ""LogBack"" /F & _ ""c:\LogBackup\" & _ strName & """ /L:f /M incremental" ' Run the backup. dim sh Set sh = WScript.CreateObject("Wscript.shell") sh.Run strShell, 1, 1 ' Move the file to a secure remote server. sh.Run "cmd.exe /c move *.bkf \\BackupServer\Logs", 1, 1 

The script and the temporary copy of the backed-up log files reside in a strongly ACLd directory—only administrators have read access—called C:\LogBackup. The contents of the LogBackup.bks file determine which files are backed up. In this case, the file references these three directories:

• C:\Winnt\System32\LogFiles (Web server audit files)
• C:\Winnt\System32\Config (Windows 2000 audit files)
• C:\MSSQL7\LOG (SQL Server log files)

NOTE

---

You can define your own .bks file by running NTBackup.exe, selecting the directories you are interested in, and saving the resulting .bks file.

Finally, the script moves the backup file to another well-protected server. The share named Logs is ACLd such that administrators have write-only access, and the directory to which Logs points is ACLd such that only administrators have read access. To protect the computer even more, only administrators have the Logon Locally and Logon Across The Network logon rights. No other users can access the computer, and there are no other local accounts on the server.

Refer to the Windows 2000 online help for details about using NTBackup.exe and the meaning of the command line options. Chapter 12, "Securing Against Attack," has guidelines about what you should audit for in IIS, SQL Server, and Windows.

Windows Script Host Logging

Using WSH, you can write your own custom events to the Windows 2000 event log. This JScript code will write an audit failure event to the security log:

 var oWsh = new ActiveXObject("WScript.Shell"); oWsh.LogEvent(16, _ "Unable to log the user onto the application."); 

The same script written in Visual Basic is:

 oWsh = CreateObject("WScript.Shell") oWsh.LogEvent(16, _ "Unable to log the user onto the application.") 

The first argument is the event type. Possible values are 0 (success), 1 (error), 2 (warning), 4 (information), 8 (audit success), and 16 (audit failure). Note that this code will not necessarily work in ASP because the user might not have the privilege to write to the event log.