Raf Cox Security blog

Looking for unprotected directories (and files)

Raf Cox — Sun, 13 Feb 2011 15:34:00 GMT

When checking if a system is secure, you often want to validate if there are no locations that are writeable for standard users (non-admins); for example, on a website, you want to make sure that all application files and directories are read-only (unless you have a specific directory in which you would allow users to upload files). Even on content management systems where users can store their own files (such as SharePoint), user-documents are stored in the database and never on the file system, so no need there to grant users any kind of write access on the server.

What can go wrong if users do have write access to application files?

Well, by default, they won't be able to upload anything, so it might seem not too harmful. But what if for some reasons you open up a file-share (e.g. to allow server-administrators to upload new files)? Or somebody enables WebDav authoring access on a website? Enforcing least privilege access is often a defense-in-depth measure that will limit the damage if somebody makes a configuration mistake later on.

So, how can we check the access rights on the file-system and identify those directories (and files) where users have write-access on?

One tool that might help you is AccessEnum from SysInternals: "This simple yet powerful security tool shows you who has what access to directories, files and Registry keys on your systems. Use it to find holes in your permissions."

If you're just interested in finding to which directories and files, standard users have write-access, you can use the script below. It will enumerate all directories (if you want to include files, remove the where-clause ?{$_.PSIScontainer -eq $true}) and for each one, check if standard users (identified as "Builtin\Users", "Domain Users", "NT AUTHORITY\Authenticated Users" and "everyone" in the code-sample) have some kind of write-access to the directory. Write-access also includes the right to create or delete a file in a directory, change a file, take ownership, modify permissions, etc.

The script can probably be further optimized for performance (scanning all directories in c:\windows takes less than 2 minutes on my W7 machine), but it does the job.

What does the script do? In short:

Check ACL of the given root-directory, including inherited ACEs
Get a listing of all subdirectories
Check the ACL for each of the subdirectories, excluding inherited ACEs (since these were checked at the root)

(Check also my first post on AppLocker: this script might help you identifying writeable directories under C:\Windows and c:\program files, so you can add them as exceptions)

Function CheckACLStrength([string]$FromDir) {

#enumerate all groups you want to check (add your own groups)
$Grps= @("BUILTIN`\Users","DomainUsers","NTAUTHORITY`\AuthenticatedUsers","Everyone")

$ListViolations = @()

#Check the ACL of the root-directory, including inherited ACEs
$acl=(Get-Acl $FromDir)
if(CheckACLViol $acl $Grps $True) {$ListViolations += $FromDir}

#enumerate all subdirectories and check ACLs (excluding inherited ACEs)
$allDirs = Get-ChildItem –path $FromDir -recurse | ?{$_.PSIScontainer –eq $true}
foreach($DirOrFile in ($allDirs)){
  $acl=(Get-Acl $DirOrFile.FullName)
  if(CheckACLViol $acl $Grps $false){
   $ListViolations += $DirOrFile.FullName
  }
}

Return $ListViolations
}

Function CheckACLViol($acl, [String[]] $Groups, [boolean] $InclInherited){

#create an array of all unwanted access types (valid for both files & directories)
$InvalidAccessTypes=([system.Security.AccessControl.FileSystemRights]::AppendData,`
[system.Security.AccessControl.FileSystemRights]::ChangePermissions,`
[system.Security.AccessControl.FileSystemRights]::CreateDirectories,`
[system.Security.AccessControl.FileSystemRights]::CreateFiles,`
[system.Security.AccessControl.FileSystemRights]::Delete,`
[system.Security.AccessControl.FileSystemRights]::DeleteSubdirectoriesAndFiles,`
[system.Security.AccessControl.FileSystemRights]::FullControl,`
[system.Security.AccessControl.FileSystemRights]::Modify,`
[system.Security.AccessControl.FileSystemRights]::TakeOwnership,`
[system.Security.AccessControl.FileSystemRights]::WriteData)

# check if any of the ACE matches any of the unwanted access types for the list of groups
$count=0
$AceAllow=[System.Security.AccessControl.AccessControlType]::Allow
$AceDeny=[System.Security.AccessControl.AccessControlType]::Deny
foreach($ace in $acl.access){
  if ($ace.AccessControlType –eq $AceAllow –and (($InclInherited –and $ace.IsInherited) –or –not $ace.IsInherited)){
   $tmpmtch=$Groups –contains $ace.IdentityReference.toString()
   if($tmpmtch){
    $isok=$true
    $InvalidAccessTypes | foreach{ $isok = $isok –and –not ($ace.FileSystemRights –match $_)}
    If (-not $isok) {$count++}
   }
  }
}

if($count-gt0) {1} else {0}
}

CheckACLStrength "c:\Windows"

Security Compliance checking with PowerShell: roles, role-combinations and other basic checks

Raf Cox — Wed, 26 Jan 2011 19:41:00 GMT

In my last post, I already pointed out 2 security considerations that apply across roles: which combination of server roles is allowed and is a specific role suited (and preferably installed on) a Windows Server CORE?

Besides these 2, there are a number of other things you might want to check if you want to see if a W2K8R2 server is configured securely. So, a more complete list of checks (summarized from the Windows 2008 R2 Security guide) would look as follows:

Which server-roles allowed on your networks? Which features do you want to allow?

Some organizations might not want to allow specific server roles on their networks. For example Certificate Server: this is normally a role that you only install on a limited number of highly secured servers. Or maybe you might only want to allow a server role if you have security guidance and checklists available for them? The same might be true for server features, such as the "Wireless Lan Service" or "Telnet Server".

What role combinations are allowed?

A general recommendation from the security guides is to limit role-combinations. Combining roles will increase the attack surface of a server. Further, it will also complicate the management of servers, especially if role A is managed by another team than role B. Some other roles on the other hand are often combined, such as application-server roles or Domain Controller and DNS.

Should the server be installed on Windows Server CORE?

Windows Server CORE significantly reduces the attack surface of a server, since all UI-related binaries are not installed: no Internet Explorer vulnerabilities, no GDI vulnerabilities, etc. Therefore, you might want to have your most critical servers installed on Windows Server CORE, such as your Domain Controllers, Hyper-V servers, but maybe also the infrastructure servers (DNS, DHCP, File, Print, etc).

Is the computer joined to a domain?

Joining a computer to a domain brings a large number of immediate security benefits: users are managed on a central infrastructure (AD), you automatically use a strong network authentication protocol (Kerberos), you can control the security configuration of your servers centrally (apply security baseline GPOs), etc.

Has the security baseline GPO been applied?

You do want to check quickly if you haven't forgotten to move the server to the right OU to ensure that all security baseline GPOs are applied correctly to the server. There are multiple ways to do this (e.g. you could use SCCM/DCM functionality to validate each setting), but a quick check might be to just check if a policy names xyz has been applied. Or if the legal notice has been set (the legal notice is not set by default and is typically unique for an organization, so easily identifiable).

Are security updates installed on a regular basis?

While you're checking if a server is secure, you might as well quickly want to check if its WSUS configuration (or SCCM) is correct or at least, that the server has received security updates recently. A quick check ("when has the latest patch been applied?") is in no way a replacement for a full check of course (using MBSA or equivalent tools). But at least, you know that the server is receiving security updates.

How many users are in the "administrator" role on the server?

A last thing you might want to check is the number of users that have administrative rights on the server; normally, this should only be a small group and membership of the local "administrators" group on a server should be limited to only those users that really need it (i.e. server administrators)

Does all of this sound obvious?

Well, it is actually. But it wouldn't come to a surprise that in any organization, you will find servers that are not configured correctly and/or securely. Even IT-Pro's do make a mistake every now and then :-).

So, how to check all of this using PowerShell?

Let's start with allowed server roles, server-role combinations and features.

Windows Server 2008 R2 has a great build-in module to support all this: ServerManager.

Following code allows you to retrieve all installed roles on server

Import-module ServerManager

$installedRoles = Get-WindowsFeature | where {$_.featureType -eq "Role" -and $_.Installed -eq $true} | select name, DisplayName

The FeatureType property could have any of the following values:

Role
Role Service
Feature

To compare with your list of approved roles (or role-combinations), you could work with an array or hash-list that contains all allowed roles, and for each role, the allowed role-combinations. The sample script (at the end of this blog) shows how to implement this in PowerShell for a case where you would allow only 5 roles and specific role-combinations (IMPORTANT NOTE: the script does not give any security recommendations for role-combinations or allowed roles; it's just a sample how you can use PowerShell to check compliancy with your security policies).

While checking the roles, you can as well check if each role is required to be installed on Windows Server CORE (and hence if the combination of all (allowed) roles on the server is required to be installed on Windows Server CORE).

To check if a server is installed as Windows Server CORE, you can use the OperatingSystemSKU property of the Win32_OperatingSystem WMI object. The values 12, 13 and 14 refer to Windows Server CORE OS SKU's (Datacenter CORE, Enterprise CORE and Standard Server CORE).

If you want to have a quick check (really superficial) to see if your company's security policy GPOs have been applied, you could check for specific registry values that are set within the policies. I prefer to use the Legal Notice, since that value is mostly unique for each company (if used of course). The values set by GPOs can be easily checked in the registry (for the majority of the settings); for example, the Legal Notice Caption can be found as follows:

$LegalNoticeCaption = Get-ItemProperty -path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" -name LegalNoticeCaption

Another check would be to quickly validate if security updates are being installed; if you want to do a full check (which you should from time to time), use MBSA or equivalent tools. As a quick check, you could just validate when the last update was installed:

$AllQFEs = Get-WmiObject -Namespace "root\CIMV2" -class "win32_QuickFixEngineering" |sort -Property @{Expression={[dateTime]$_.InstalledOn};Ascending=$false}

$lastQFEDate = [datetime]$AllQFEs[0].InstalledOn # check first if $AllQFEs is not empty!

Further, you can find in the script 2 other checks:

Check how many users (local or domain) are member of the administrators group (I will explain that in more depth in future)
Check if the computer is joined to a domain: this is accomplished by checking the PartOfDomain property on the Win32_ComputerSystem WMI object; the domain property gives you the name of the domain.

Below you can find the full script (including the DNS part of my previous post). For better readability, copy to notepad or PowerShell ISE and validate on your test-environment. (ps: I don't check if DNS is installed or not, so it might fail if DNS is not installed on the server; I leave it up to you to add the code to check first if DNS role is installed before calling the CheckSecCompl-DNS function)

#--------------------------------------------------------------------
# Sample Security Compliancy Check Script for Windows 2008 R2 Roles
# Raphael Cox, Microsoft Consulting Services Belgium-Luxembourg
# http://blogs.technet.com/b/raf_cox_security_blog/
# January 2011
#
# Parameters:
#   none
#--------------------------------------------------------------------

Function New-CompliancyResult
{
Param(
    [string]$Category,
    [string]$SubCategory,
    [string]$setting,
    [boolean]$IsCompliant
)

# create a new object and set the noteproperties using a hash-table
$x = New-Object PSObject -Property @{
   Computer = (Get-WmiObject -Class Win32_ComputerSystem).name
   Category = $Category
  SubCategory = $SubCategory
  Setting = $setting
  IsCompliant = $IsCompliant }

return $x
}

function CheckSecCompl-DNS {
$CompliancyResList = @()

$DNSServer = Get-WmiObject -Namespace "root\MicrosoftDNS" -Class "MicrosoftDNS_Server"

$CompliancyResList += New-CompliancyResult "DNS" "Server Configuration" "Secure Cache Against Pollution" $DNSServer.SecureResponses

$DNSZones = Get-WmiObject -Namespace "root\MicrosoftDNS" -Class "MicrosoftDNS_Zone"


foreach ($DNSzone in $DNSZones) {
     $SubCategory = "DNS Zone: " + $DNSzone.Name

  # To check if a DNS zone only accepts secure dynamic updates, use the property: AllowUpdate
  # AllowUpdate can have following values:
  # 0: no dynamic updates allowed
  # 1: secure and insecure dynamic updates allowed --> not secure
  # 2: only secure dynamic updates allowed
  $CompliancyResList += New-CompliancyResult "DNS" $SubCategory "Secure or no dynamic updates" ($DNSzone.AllowUpdate -eq 1)

  # To check if a DNS zone is Active-Directory-integrated, use the property: DsIntegrated
  $CompliancyResList += New-CompliancyResult "DNS" $SubCategory "Zone is AD integrated" $DNSZone.DsIntegrated

  # To check if a DNS zone doesn't allow zone transfers to any computer, use the property: SecureSecondaries
  # SecureSecondaries can have following values:
  # 0: Allow zone transfers to any server --> not secure
  # 1: Allow zone transfers only to specific servers (listed in the name-servers tab)
  # 2: Allow zone transfers only to specific servers (listed in the zone-transfers tab)
  # 3: Do not allow Zone Transfers
  $CompliancyResList += New-CompliancyResult "DNS" $SubCategory "Zone transfers only to known secondaries" ($DNSZone.SecureSecondaries -ne 0)

}
return $CompliancyResList
}

function Getlocalgroupmembers ([string]$localcomputername, [string]$localgroupname) {
    $groupobj =[ADSI]"WinNT://$localcomputername/$localgroupname"
    $localmembers = @($groupobj.psbase.Invoke("Members"))
    $localmembers | foreach {$_.GetType().InvokeMember("AdsPath","GetProperty",$null,$_,$null)}
}

function GetAllUserMembers ($group) {
    # $group is string in format "LDAP://CN=..."
    $UserList = @()
    $groupMembers = ([adsi]$group).member
    foreach ($PrincipalPath in $groupMembers) {
        $principal = [adsi]"LDAP://$PrincipalPath"
        if ($principal.SchemaClassName -eq "group") {
            # if a group, recursively add all members of this group to the list
            $UserList += GetAllUserMembers $principal.Path
        } else {
            # if not a group, it is either user or workstation
            $UserList += $PrincipalPath
        }
    }
    return $UserList

}

Function CountAllUsersInLocalGroup ($LocalGroupName) {
    $Members = Getlocalgroupmembers . $LocalGroupName
    $countLocalUsers = 0
    $MemberInDomain = @()
    $CheckMembersInOtherDomains=$false

    if ($Members.count -gt 0) {
        foreach ($Principal in $Members) {
            # break up the string of each principal "WinNT://domain\username"
            $spl = $Principal -split "WinNT://"
            $UserDomain = ($spl[1] -split "/")[0]
            $UserName = ($spl[1] -split "/")[1]

            $domain = [System.DirectoryServices.ActiveDirectory.domain]::GetCurrentdomain()
            $root = $domain.GetDirectoryEntry()

            # create object to search in AD
            $search = [System.DirectoryServices.DirectorySearcher]$root
            if (-not ($UserDomain -eq (gwmi "Win32_Computersystem").caption) ) #check $userdomain equals local computername
            {
                #user, workstation or group is domain member
                $search.Filter = "(cn=$UserName)"
                $result = $search.FindOne()

                if ($result -ne $null)
                    {$MemberInDomain += GetAllUserMembers $result.Path}
                else { #user is in other domain of the forest or in other forest; not counted here
                }
            }
            else {
                #local users
                $countLocalUsers +=1
             }
        }
    }

#count all users found locally and in domain (eliminate duplicates)
return $countLocalUsers + ($MemberInDomain | sort -Unique).count
}

function CheckSecCompl-BaseChecks {

Import-module ServerManager

$CompliancyResList = @()
# Get all installed roles
$installedRoles = Get-WindowsFeature | where {$_.featureType -eq "Role" -and $_.Installed -eq $true} | select name, DisplayName

    # sample data structure that lists allowed roles, allowed role-combinations and if required for CORE install
    # This is not a security recommendation, just a sample!
    $RoleData = @()
    $RoleData += New-Object PSObject -Property @{Role="AD-Domain-Services";combine=@("DNS"); CORErequired=$true }
    $RoleData += New-Object PSObject -Property @{Role="Print-Services”;combine=@("DHCP","File-Services"); CORErequired=$true}
    $RoleData += New-Object PSObject -Property @{Role="File-Services”;combine=@("DHCP","Print-Services"); CORErequired=$true}
    $RoleData += New-Object PSObject -Property @{Role="DHCP";combine=@(”File-Services”,”Print-Services”); CORErequired=$true}
    $RoleData += New-Object PSObject -Property @{Role="DNS";combine=@("AD-Domain-Services"); CORErequired=$true}

    $COREReqForAllRoles = $true
    foreach ($installedRole in $installedRoles) {
        $roleFound=$false
        foreach ($RoleItem in $RoleData) {
            if ($RoleItem.Role -eq $InstalledRole.Name) {
                $roleFound=$true
                break;
            }
        }
        if ($roleFound) {
            $CompliancyResList += New-CompliancyResult "Base Configuration" "Role Allowed" $installedRole.DisplayName $true
            foreach ($otherRole in $installedRoles) {
                if ($otherRole.name -ne $InstalledRole.name) {
                    $roleCombStr = $installedRole.name + " & " + $otherRole.DisplayName
                    if ($RoleItem.combine -contains $otherRole.name) {
                        $CompliancyResList += New-CompliancyResult "Base Configuration" "Role combination allowed" $roleCombStr $true
                    } else {
                        $CompliancyResList += New-CompliancyResult "Base Configuration" "Role combination allowed" $roleCombStr $false
                    }
                }
            if ($roleItem.CORERequired -eq $false) { $CoreReqForAllRules = $false}
            }
        } else {
            $CompliancyResList += New-CompliancyResult "Base Configuration" "Role Allowed" $installedRole.DisplayName $false
        }


    }

    # Do all installed roles support Windows Server CORE
    $OSSKU = (Get-WmiObject -Namespace "root\CIMV2" -class "Win32_OperatingSystem").OperatingSystemSKU
    $IsCORE = $OSSKU -eq 12-or $OSSKU -eq 13 -or $OSSKU -eq 14

    if ($COREReqForAllRoles) {
        $CompliancyResList += New-CompliancyResult "Base Configuration" "CORE Install" "Windows CORE Install Required" $IsCore
    }

    # Quick check if security policy GPO is applied by checking Legal Notice caption text
    # Warning: this does not guarantee that a security policy is correctly applied! Other quick checks can be added in the same way
    $ApprovedLegalNoticeCaption = "You are about to log on to CONTOSO Networks"
    $SettingText = "Legal Notice Caption set to: " + $ApprovedLegalNoticeCaption
    $LegalNoticeCaption = Get-ItemProperty -path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" -name LegalNoticeCaption
    if ($LegalNoticeCaption.LegalNoticeCaption -eq "" -or $LegalNoticeCaption.LegalNoticeCaption -eq $null){
        $CompliancyResList += New-CompliancyResult "Base Configuration" "Security GPO applied" $SettingText $false
    }
    else {

        if ($LegalNoticeCaption -ne $ApprovedLegalNoticeCaption) {
            $CompliancyResList += New-CompliancyResult "Base Configuration" "Security GPO settings" $SettingText $false
        }
        else {
            $CompliancyResList += New-CompliancyResult "Base Configuration" "Security GPO settings" $SettingText $true
        }
    }


    # Quick check if Windows Update is enabled by checking time of last update
    # Warning: this check doesn't guarantee that all Security Updates have correctly been installed and no important ones are missing
    # you can extend this part, e.g. by checking against a list of must-have hotfixes; for a full check, use MBSA or equivalent tools
    $AllQFEs = Get-WmiObject -Namespace "root\CIMV2" -class "win32_QuickFixEngineering" |sort -Property @{Expression={[dateTime]$_.InstalledOn};Ascending=$false}
    $AllowedNrDaysSinceLastUpdate = 40 # 40 Days is NOT a recommendations, just an example
    $SettingText = "Last update installed less than " + $AllowedNrDaysSinceLastUpdate + " days ago"
    if ($AllQFEs -eq $null) {
        $CompliancyResList += New-CompliancyResult "Base Configuration" "Security updates" $SettingText $false
    } else {
        $lastQFEDate = [datetime]$AllQFEs[0].InstalledOn
        if ($lastQFEDate -lt [datetime]::now.AddDays(-30)) {
            $CompliancyResList += New-CompliancyResult "Base Configuration" "Security updates" $SettingText $false
        } else {
            $CompliancyResList += New-CompliancyResult "Base Configuration" "Security updates" $SettingText $false
        }
    }

    # Check number of Administrators on the machine: List members of local Administrators group (local and in domain)
    # you can extend this part by checking other local groups
    $PrivGroupToCheck = "Administrators"
    $MaxNrOfMembers = 5 # a maximum number of 5 admins is just an example;not a security recommendations!
    $NrOfAdministrators = CountAllUsersInLocalGroup $PrivGroupToCheck

    $SettingText = "Nr of members of $PrivGroupToCheck <= $MaxNrOfMembers"
    if ($NrOfAdministrators -le $MaxNrOfMembers) {
        $CompliancyResList += New-CompliancyResult "Base Configuration" "Privileged Access" $SettingText $true
    } else {
        $CompliancyResList += New-CompliancyResult "Base Configuration" "Privileged Access" $SettingText $false
    }

    # Check if the computer is joined to domain
    $WMIComputerSystem = Get-WmiObject -Namespace "root\CIMV2" -class "Win32_ComputerSystem"
    if ($WMIComputerSystem.PartOfDomain) {
        $ComputerDomain = $WMIComputerSystem.domain
        $CompliancyResList += New-CompliancyResult "Base Configuration" "Domain Joined" "Joined to domain ($ComputerDomain)" $true
    } else {
        $CompliancyResList += New-CompliancyResult "Base Configuration" "Domain Joined" "Joined to domain (none)" $true
    }



    return $compliancyResList
}

$CompliancyResList = @()
$CompliancyResList += CheckSecCompl-BaseChecks

$CompliancyResList += CheckSecCompl-DNS

$CompliancyResList | select computer, category, subcategory, setting, iscompliant |Out-GridView

Security Compliance checking with PowerShell: DNS

Raf Cox — Fri, 07 Jan 2011 20:39:00 GMT

I guess most of you will agree that DNS is a critical component in a Windows infrastructure. It's not only the basis for a good working AD, but also the first target for anybody who wants to attack your systems and communication-channels, using Man-in-the-Middle techniques. E.g., suppose an (internal) hacker could advertise a compromised system as your company portal or proxy server by changing the A-records? Or inserting false A-records?

If your DNS configuration is not secure, these types of attacks are easy to perform. E.g. if you allow un-authenticated and un-authorized updates in a DNS zone, an attacker could insert e.g. an A-record for the "wpad.company.com" (wpad = Web Proxy Autodiscovery Protocol) which points to a malicious proxy that could intercept all internet traffic for those clients whose internet proxy settings are not explicitly configured ("automatically detect settings" is enabled in the browser). And when an attacker succeeds in bringing down your DNS servers, Active Directory will stop functioning too ...

Security configuration settings for the DNS role in Windows Server 2008 R2 can be found in 2 areas. First, there is the server configuration itself for which you can configure for example the setting "Configure DNS to Configure DNS to ignore non-authoritative resource records" (a.k.a. cache poisoning).

This setting is enabled by default, but you do want to ensure that it stays enabled. The setting can be found under the "advanced" tab of the DNS server properties:

To validate if this setting is set correctly using powershell, you can use the "SecureResponses" property of the DNS-server WMI object. The script below can be used to check on the local host.

$DNSServer = Get-WmiObject -Namespace "root\MicrosoftDNS" -Class "MicrosoftDNS_Server"

if ($DNSServer.SecureResponses) {

$result = "DNS Option *Secure Cache Against Pollution* is enabled on server."

}

else

{

$result = "DNS Option *Secure Cache Against Pollution* is not enabled on server."

}

(run this script using a PowerShell prompt that runs with elevated privileges; see also at the end of this post).

As you can see, I use the WMI interface to query the DNS configuration, since DNS role in Windows Server 2008 R2 doesn't have a direct interface for PowerShell. DNS has however very good and simple WMI support, so the scripts are straightforward to implement.

(note: the SCM Document also make recommendations about 2 other server configuration settings: "Enable recursion to only the appropriate DNS servers" and "Configure root hints for the internal DNS namespace"; these are not handled in this post).

Next, you have the security configuration settings for each DNS zone; following the best-practices in SCM documentation, following should be checked for each zone:

Preferably use AD-integrated DNS zone replication. This won't be possible in all environments, e.g. when you have a combination of Windows DNS and BIND.
DNS-zones must be configured to only allow secure dynamic updates or no dynamic updates; under no circumstances, insecure (=un-authenticated and/or not-authorized) updates should be allowed.
Restrict Zone Transfers to Specific Computers Running DNS

Some other recommendations will be handled in a next post in this blog. Specifically checks about role-combinations and use of Windows Server CORE amongst other server security recommendations that apply to multiple server roles. Specifically for DNS, we can already identify:

Combine DNS with DC: only a DNS that runs on a DC, supports secure dynamic updates and the zone replications relies on the secure AD-replication mechanisms.
Run DNS on Windows Server CORE.

The code for the DNS security compliancy check as described above looks as follows:

# The function New-CompliancyResult is used to create an array of ps-objects that store the compliancy-checks information

Function New-CompliancyResult
{
Param(
    [string]$Category,
    [string]$SubCategory,
    [string]$setting,
    [boolean]$IsCompliant
)

# create a new object and set the noteproperties using a hash-table
$x = New-Object PSObject -Property @{
         computer = (Get-WmiObject -Class Win32_ComputerSystem).name
         Category = $Category
         SubCategory = $SubCategory
         Setting = $setting
         IsCompliant = $IsCompliant }

return $x
}

function CheckSecCompl-DNS {
$CompliancyResList = @() #array of compliancy-checks results

$DNSServer = Get-WmiObject -Namespace "root\MicrosoftDNS" -Class "MicrosoftDNS_Server"

# check if the server is protected against DNS cache pollution using the property: SecureResponses

$CompliancyResList += New-CompliancyResult "DNS" "Server Configuration" "Secure Cache Against Pollution" $DNSServer.SecureResponses

CheckSecCompl-DNS | Out-GridView

The result will appear in a PowerShell GridView.

Copy the script above to a powershell script file (e.g. SecCompl_DNS.ps1) and run using a Powershell-prompt under elevated privileges (All Programs --> Accessories --> Windows Powershell --> Windows PowerShell --> right-click and select:"run as administrator"). Be aware: I've only tested these scripts on Windows Server 2008 R2, not earlier versions. But feel free to try on other versions...

Was this post useful for you? Let me know through the feedback!

Security Compliance checking with PowerShell

Raf Cox — Sun, 02 Jan 2011 20:07:00 GMT

This is just a quick intro to a number of short articles that I will post in this blog over the coming months where I will show you some examples on how to check Security Compliance using PowerShell scripts. The main focus will be on the different roles offered by Windows Server 2008 R2 (DNS, DHCP, IIS, etc) and how to check if they are configured in a secure way (using PowerShell scripts).

Quick note: I work as a Microsoft consultant with many large organizations to help them improve their security and the last couple of years I've been mainly working with NATO's Computer Incident Response Center (NCIRC). Although the security best-practices outlined in these posts are pulled from the Security Compliance Manager documents, the rest of the information you will find in these posts is not directly endorsed by the Solution Accelerators team (although, through my work at NCIRC, I have a very good working relationship with that team).

Have you already seen the Security Compliance Manager?

For anybody who is involved in defining and creating security policies for large organizations, this is THE tool for you:

"The Microsoft Security Compliance Manager (SCM) tool is the next evolution of the Microsoft Security Compliance Management Toolkit (SCMT) Series. We've taken our extensive guidance and documentation and incorporated it into this new tool, enabling you to access and automate all of your organization's security baselines in one centralized location."

http://social.technet.microsoft.com/wiki/contents/articles/microsoft-security-compliance-manager-scm.aspx

SCM incorporates all the data and documents of the former Microsoft security guides and Group Policies into a single database, which can be accessed and managed through the SCM user-interface. The tool allows you to import settings, customize them, create multiple versions and export them into different formats, such as Group Policies, System Center Configuration Manager Desired Configuration Management (SCCM/DCM) packs and others. Do you want to learn more about it? Follow the link above...

So, for 90% of the security guidance, SCM helps you with defining, implementing (GPO) and checking compliance (SCCM/DCM) with your security policies. The remaining 10% is documented as best-practices in the security documents that are part of the security baselines in SCM.

This 10% is however becoming increasingly important. The Windows platform, as well as the most of the server-applications (Exchange, Office, SQL, ...) are designed to be secure by default. Way back in time, during the Windows NT4 prehistoric times, configuring security policies was a number 1 priority for anybody in IT Security. There were lots of settings that could be set to a stricter value (given that you wanted to sacrifice some application or network compatibility (e.g. with Windows 95)).

This has however dramatically evolved. When comparing nowadays, the most strict settings (so called SSLF: Specialized Security, Limited Functionality) with the default (out-of-the-box) settings, you will see a decreasing difference going from Windows 2000 to Windows 2008 R2 or Windows 7.

Does this imply, that you no longer have to define security policies?

Of course not! It's not because the initial installation of your system is secure, that it will stay secure over time. Admins might "temporary" change some settings for testing purposes (but forget to reset it); a system might have been upgraded from an old OS version and this might have left some old (less secure) settings in place; an application or installation package might have changed some of the settings, etc ... Through GPOs (defined in SCM), you can ensure that your systems stay secure.

So, what to do with the remaining 10% of the security best-practices that cannot be automatically enforced through GPO or other means?

Well, that's what I try to tackle in this blog in the coming months. Most of the best-practices documented in SCM are either architectural guidance for a specific role (e.g. how to separate your external from your internal DNS) or specific role configurations (e.g. how to configure a server to avoid DNS cache poisoning). The focus in this blog will be on automating the compliancy checks on the role configurations using PowerShell scripts...

For those not familiar with PowerShell, well, there's tons of information out there. Some links you can find in near future in a separate post. One book I liked particular myself (certainly if you have to start from scratch with PowerShell) is "Windows PowerShell 2.0 Administrator's Pocket Consultant" by William Stanek.

So, stay tuned ... next post will be: validating security of a DNS configuration using PowerShell scripts.

First post: a pragmatic approach towards AppLocker policies

Raf Cox — Wed, 15 Dec 2010 20:42:00 GMT

AppLocker is a very powerful security tool within Windows 7 and Windows 2008 R2. You can control and audit every program, MSI or script that a user (tries) to start. A good overview of what AppLocker is and does, can be found here (but I’m sure you’ll find a lot of other interesting sites when Bing’ing it)

Looks great, but how do you deploy AppLocker in a large environment, where you have lots of system administrators in many sites and you’re the security guy that needs to set the policy?

Best approach is (as usual): keep it simple!

In short: how does it work?

AppLocker allows you to control which applications can be started by (specific groups of) users; you identify the applications by “publisher rules” (e.g. WinWord.exe, version 12.0.0.0 or higher, Publisher: Microsoft, etc), “hash rules” (SHA256 hash) or “path rules” (C:\program files\CompanyX\AppY.exe).

The rule can be either an “allow rule” or a “deny rule” and each rule allows you to specify exceptions (e.g. in a path rule, you can specify that users are allowed to execute anything under the “c:\program files” directory, except e.g. “C:\program files\CompanyX\AppY.exe”). Exceptions only exist for Publisher and Path rules, but the exceptions themselves can be specified in any combination of the 3 rule categories.

And last but not least, the rule can apply to a certain group of users (default: everyone).

Ok, but how do I define now an AppLocker policy for 20.000+ computers, in 200 locations, managed by 100 different system administrators with no common application baseline?

Well, if you have a very motivated, skilled and very security aware staff of System Administrators who’s first concern is security and are willing to support you, you might want to start with identifying all applications + versions, create AppLocker publisher rules for each one of them, combine everything in a nice, big policy and have 1 or more FTEs available to update the AppLocker policy on a daily basis.

If you don’t have that, following pragmatic and simple approach might you get started anyway with AppLocker:

The basic idea for this approach is to prevent as much as possible that non-admin users would be able to execute files (.exe's) they downloaded themselves.

In order to do that, you create a simple AppLocker policy that allows users only to execute programs from "trusted locations": c:\windows and c:\program files (actually %windir% and %programfiles%) using path-rules.

Next, add all writeable sub-directories in those 2 directories as exceptions on these path-rule. To find the user-writeable subdirectories, you can use the AccessEnum tool from sysinternals. So, the %windir%\temp directory amongst others should be part of this exception list (this way, you can also blocked users from using utilities like arp.exe, etc). On a newly installed Windows 7, I identified following directories under %windir% that are writeable for normal users (non admin) and should be added to the exception list:

%WINDIR%\debug\WIA

%WINDIR%\PCHEALTH\ERRORREP\QHEADLES\*

%WINDIR%\PCHEALTH\ERRORREP\QSIGNOFF\*

%WINDIR%\PLA\Reports\*

%WINDIR%\PLA\Rules\*

%WINDIR%\PLA\Templates\*

%WINDIR%\Registration\CRMLog\*

%WINDIR%\System32\catroot2\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\*

%WINDIR%\System32\com\dmp\*

%WINDIR%\System32\FxsTmp\*

%WINDIR%\System32\LogFiles\WMI\*

%WINDIR%\System32\spool\drivers\color\*

%WINDIR%\System32\spool\PRINTERS\*

%WINDIR%\System32\Tasks\*

%WINDIR%\System32\Tasks\Microsoft\Windows\CertificateServicesClient\UserTask-Roam\*

%WINDIR%\System32\Tasks\Microsoft\Windows\MemoryDiagnostic\CorruptionDetector\*

%WINDIR%\System32\Tasks\Microsoft\Windows\MemoryDiagnostic\DecompressionFailureDetect

%WINDIR%\System32\Tasks\Microsoft\Windows\PLA\*

%WINDIR%\System32\Tasks\Microsoft\Windows\PLA\System\*

%WINDIR%\System32\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update\*

%WINDIR%\System32\Tasks\Microsoft\Windows\SideShow\SessionAgent\*

%WINDIR%\System32\Tasks\Microsoft\Windows\SyncCenter\*

%WINDIR%\System32\Tasks\Microsoft\Windows\WindowsColorSystem\Calibration Loader\*

%WINDIR%\System32\Tasks\User_Feed_Synchronization-{F3998D1D-6B67-45B6-BE78-9A1176A90B

%WINDIR%\Tasks\*

%WINDIR%\Temp\*

%WINDIR%\Temp\Cookies\*

%WINDIR%\Temp\History\*

%WINDIR%\Temp\Temporary Internet Files\*

%WINDIR%\tracing\*

Local site admins can create exceptions on this base policy using a delta-GPO in which they list additional directories using AppLocker path-rules, e.g. for apps that are installed in a subdirectory directly under the c:\ or e.g. for the App-V Q:-drive. The advantage of this approach is that it is very lightweight, easy to understand and maintain. (For some other apps, e.g. exe's on thumb-drives to unlock the drive (e.g. IronKey), you must create publisher rules or hash-rules, since path rules won’t work in this situation.)

If your focus is mainly "policy-enforcement", this approach works pretty well (so far in my experience); you have to assume though that, even with a lot of testing, malicious users (or hackers) will find some day a writeable directory that is not excluded in the path rules; but it does protect against somebody trying to download something occasionally and execute it; or against the majority of automated attacks... (or against less skilled hackers ;-); and it does also prevent users from downloading and installing Google Chrome or Firefox themselves under their profile-directories (thereby circumventing all the IE security policies you have created).

Did this post help you? Let me know ...