Unfortunately, windows doesn't have a lot of detection countermeasures (WhatIsACountermeasure) built into it, but one of the features that comes close is auditing. On a secure production system, auditing is one way an administrator can detect that an attack has occurred or is in progress. A good sysadmin will turn on auditing to detect password-guessing attacks, attempts to access sensitive resources, null session connections (WhatIsANullSession), and so on.

The security audit log can also be helpful to a developer in tracking down security problems where an authorized user is accidentally denied access. For example, I've always recommended auditing of logon events on all lab machines. A logon event occurs when a new logon-session (WhatIsALogonSession) is created on the machine, which means that some user successfully authenticated. But it also occurs when authentication fails for some reason—and there are loads of reasons. A classic example is where a developer recently created a new user account for a daemon but forgot to uncheck the option "User must change password at next logon." Countless hours are spent trying to track down silly misconfigurations like this one, when the security audit log often gives you all the detail you need (see Figure 10.1 for another typical example). But these audit entries won't show up unless you've turned on auditing on the machine!

Figure 10.1 Auditing: It's a developer's best friend.

Let me show you how to turn on auditing in Windows. Auditing is part of security policy, and you can get to the machine's security policy by looking in the Administrative Tools folder for "Local Security Policy." To launch this from your admin command prompt (HowToDevelopCodeAsANonAdmin) just run secpol.msc. I've shown how to find the auditing settings in Figure 10.2. In a lab setting, I recommend at least turning on auditing of failed logon events; on a production server, you'll want to audit failed object access as well. You'll also need to put a SACL on any file or registry key you want to watch (see HowToAuditAccessToFiles for details).

Figure 10.2 Finding the auditing settings

In many scenarios, the administrator uses group policy to control the auditing settings for a particular machine. In that case, changing the local policy for the machine may have no effect because it's being overridden by upstream group policy. To learn more about group policy, see WhatIsGroupPolicy.

PortedBy JohnSands