Performing Security Assessments

Performing Security Assessments

In addition to comparing the security configuration of your Windows computers with the baseline security settings defined in security templates, you should assess your computers for common security misconfigurations. You can use different tools for security assessments, including the following:

  • Microsoft Baseline Security Analyzer (MBSA)

    Analyzes common security misconfigurations.

  • Third-party security tools

    Tools such as the Internet Security Systems (ISS) Security Scanner or the eEye Retina Network Security Scanner can detect common vulnerabilities.

  • Port scanners

    Determine which available server ports are exposed to the Internet.

Microsoft Baseline Security Analyzer

The MBSA tool allows you to assess the security configuration of one or more Windows-based computers. MBSA performs two major tasks:

  • Scans for missing service packs and security updates. MBSA uses Shavlik HfNetChk version 3.81 to determine which hotfixes and service packs are not applied to a target computer. The MBSA tool can also filter the list of missing updates and service packs based on approved updates configured at a Microsoft Software Update Services (SUS) server.

    For more information on using the Mbsacli.exe command-line tool to determine which service packs and security updates are applied, please see Chapter 23, Using Patch Management Tools.

  • Scans the Windows OS, Microsoft Internet Information Services (IIS), Microsoft SQL Server, desktop applications, Windows Media Player, and Microsoft Exchange Server for common security misconfigurations.

Tests Performed

The MBSA tool can be executed from both a GUI and from the command line. Both versions of MBSA perform the tests outlined in this section.

Security Update Checks

MBSA performs checks for security updates and service packs released for the following Windows operating systems, Windows components, and applications:

  • Microsoft Windows NT 4.0

  • Microsoft Windows 2000

  • Microsoft Windows XP

  • Microsoft Internet Explorer version 5.01 and later

  • Windows Media Player 6.4 and later

  • IIS 4.0 and 5.0

  • SQL Server 7.0 and SQL Server 2000

  • Exchange Server 5.5 and Exchange 2000 Server

Windows OS Tests

MBSA will perform various OS security checks for Windows NT 4.0, Windows 2000, and Windows XP target computers. The specific tests include the following:

  • Administrators group membership

    MBSA identifies and lists all members of the local Administrators group. If more than two accounts are detected, MBSA reports a potential vulnerability.

  • Auditing

    MBSA determines whether auditing is enabled at the target computer. The tool does not look for specific audit settings it only ensures that some form of auditing is enabled.

  • Auto Logon feature

    MBSA reports whether Auto Logon is enabled at a target computer. If Auto Logon is enabled, MBSA determines how user credentials are stored. If user credentials are stored in an encrypted format in the registry, the tool reports the enabling of Auto Logon as a potential vulnerability. If user credentials are stored in plaintext, the tool reports a high-level vulnerability.

  • Unnecessary services

    You can configure MBSA to scan for specific services by editing the %Systemdrive%\Program Files\Microsoft Baseline Security Analyzer\Services.txt file. MBSA will scan the target computer to determine whether any of the listed services are enabled on the target computer.

    When adding service names to the Services.txt file, you must use the registry-based name of the service. You can find the registry-based name for each service in the properties of the specific service in the Services console. For example, the registry-based name for the World Wide Web Publishing service is W3SVC.

  • Domain controller identification

    MBSA identifies whether a target computer is functioning as a domain controller. This allows the scanner to identify nonauthorized domain controllers and further inspect which vulnerabilities are found at the domain controller.

  • File system

    MBSA identifies whether all the target computer s volumes use the NTFS file system. Only the NTFS file system allows for local file security by implementing discretionary access control lists (DACLs) for each file and folder on the disk volume.

    To determine whether a remote computer implements the NTFS file system, the default administrative shares must be enabled on the target computer. For example, the C drive must be shared as C$.

  • Guest account

    MBSA identifies whether the Guest account is enabled on the target computer. An enabled Guest account can allow remote users to access the computer without providing credentials and will be reported as a vulnerability.

  • Local account passwords

    All passwords in the local account database are scanned to determine whether they are weak. MBSA will scan for blank passwords, passwords that match the user s account name, passwords that match the computer name, and commonly used passwords such as password, admin, or administrator.

  • Password expiration

    MBSA determines whether local accounts are configured with nonexpiring passwords.

  • RestrictAnonymous registry key

    MBSA determines whether the target computer restricts anonymous connections. You can allow all anonymous connections (which has an associated value of 0), prevent anonymous connections from enumerating Security Accounts Manager (SAM) accounts and names (which has an associated value of 1), or prevent all access without explicit anonymous permissions (which has an associated value of 2).

    If you configure the RestrictAnonymous registry key to prevent all access without explicit anonymous permissions at a Windows 2000 domain controller, you can prevent downlevel computers from connecting to the domain controller. Downlevel members of the domain cannot set up a Netlogon secure channel for authentication, downlevel domain controllers in trusting domains cannot set up a Netlogon secure channel to allow interdomain authentication, the Browser service cannot retrieve domain and server lists from computers, Windows NT users cannot change an expired password, and Macintosh users can never change their passwords.

  • Enumerate shares

    MBSA reports all shares on the target computer. This includes both manually created shares and administrative shares. For each share, the detected share and NTFS permissions are reported.

IIS Tests

If any IIS components are installed on the target computer, MBSA performs a series of tests to detect common IIS security misconfigurations. These tests include the following:

  • IIS Lockdown tool

    MBSA determines whether the IIS Lockdown tool is used to secure the target computer.

  • Determining whether the target computer is a domain controller

    The existence of the IIS service on a domain controller is considered a high-level vulnerability, unless the target computer is a Microsoft Small Business Server (SBS).

  • IIS logging

    MBSA determines whether IIS logging is enabled on the target computer. IIS logging provides detailed information about each connection attempt to Web sites hosted on the IIS computer. The test also ensures that the World Wide Web Consortium (W3C) extended log file format is implemented.

  • IIS parent paths

    MBSA determines whether the ASPEnableParentPaths setting is enabled on the target computer. If enabled, this setting allows attackers to use the .. syntax in URLs, permitting them to access files not available, by default, from the Web service. (The .. syntax attempts to access files and folders in the parent folder of the current folder.)

  • Virtual directories

    MBSA scans for Microsoft Advanced Data Connector (MSADC) and Scripts virtual directories. These directories contain sample scripts that attackers can use to compromise IIS. The tool also looks for the IISadmpwd virtual directory on IIS 4.0 target servers. This virtual directory allows users to change their Windows passwords from a Web site.

    Virtual directories can be removed by running the IIS Lockdown tool. For more information on the IIS Lockdown tool, please see Chapter 21, Implementing Security for Microsoft IIS 5.0.

  • IIS sample applications

    MBSA determines whether the default IIS sample applications are installed on the target server. The sample applications provide script samples that attackers can use to compromise the target server. These sample applications can be removed by running the IIS Lockdown tool against the IIS server.

Microsoft SQL Server Checks

MBSA scans for SQL Server security configuration issues if SQL Server is detected on a target computer. SQL Server tests are run against each SQL Server instance found on the computer. The specific tests include the following:

  • Sysadmin membership

    MBSA scans the target server to identify all members of the Sysadmin role on the server running SQL Server. MBSA also determines whether the local Administrators group is assigned the Sysadmin role.

  • CmdExec rights

    MBSA ensures that only members of the Sysadmin role are assigned the CmdExec right.

  • SQL Server local account password checks

    MBSA determines whether any SQL Server accounts implement poor passwords. In addition to the checks performed for Windows OS passwords, the password check looks for a password of SA. The password check will also report any locked out or disabled SQL Server accounts.

  • SQL Server authentication mode

    MBSA reports whether the server running SQL Server is configured to implement Windows authentication mode or mixed mode. When Windows authentication mode is implemented, the instance of SQL Server depends on Windows authentication for all user authentication. In mixed mode, users might be authenticated by using Windows authentication or by the server running SQL Server. If authenticated by the server running SQL Server, the users account and password pairs are maintained within the SQL Server system tables.

  • SQL Server directory permissions

    MBSA verifies that only the SQL Server service account and members of the target computer s local Administrators group have access to the following folders within the %Systemdrive%\Program Files folder:

    • Microsoft SQL Server\MSSQL$InstanceName\Binn

    • Microsoft SQL Server\MSSQL$InstanceName\Data

    • Microsoft SQL Server\MSSQL\Binn

    • Microsoft SQL Server\MSSQL\Data

  • SA password protection

    MBSA determines whether the SA password or SQL Server service account and password are stored in plaintext in the Setup.iss, Sqlsp.log, or Sqlstp.log files found in the %Windir%\Temp and %Temp% folders.

  • SQL Server guest account

    MBSA determines whether the Guest account is assigned access to any databases other than Master, Tempdb, and Msdb. All databases that enable Guest access are included in the security report.

  • SQL Server registry key permissions

    MBSA ensures that the Everyone group is assigned only Read permissions for the HKLM\Software\Microsoft\Microsoft SQL Server and HKLM\Software\ Microsoft\MSSQLServer registry keys.

  • Service account check

    MBSA determines whether the SQL Server service account is a member of the local Administrators group or is assigned membership in the domain s Administrators or Domain Admins groups.

    If you receive a No permission to access database error message when scanning a server running SQL Server, the account used to execute MBSA does not have sufficient permissions for the Master database on the target SQL Server computer.

Desktop Application Checks

MBSA also checks for security issues with commonly used desktop applications. Specifically, MBSA scans for the following:

  • Internet Explorer security zones

    MBSA scans all defined Internet Explorer security zones and identifies zones not defined at the recommended level. We recommend you implement Medium security for the Local Intranet, Trusted Sites, and Internet zones and High security for the Restricted Sites zone.

    A custom level might be reported as a false positive by MBSA. MBSA does not evaluate individual settings within a custom security level to determine whether security meets or exceeds recommended settings.

  • Microsoft Office macro settings

    MBSA issues a warning if the macro security is not at the recommended level for Office applications. You should implement High macro security for Microsoft Word, Microsoft Outlook, and Microsoft PowerPoint, and Medium macro security for Microsoft Excel.

  • Microsoft Outlook security zones

    MBSA issues a warning if the Outlook security zone is not set to the recommended security level. The same recommendations for the Internet Explorer security zones apply to Outlook.

Requirements for Running MBSA

The requirements for running MBSA vary, depending on the type of scan you are performing and whether you are scanning the local computer or performing a scan against remote computers. To perform a security assessment of the local computer, the following requirements must be met:

  • The user must be a local Administrator of the target computer.

  • The computer must be running Windows 2000 or Windows XP.

  • The computer must have Internet Explorer 5.01 or later.

    Alternatively, you can use an older version of Internet Explorer or a different Web browser if you have an XML parser installed. You can download a stand-alone version of the Microsoft XML Parser (MSXML) from http://msdn.microsoft.com/downloads/sample.asp?url=/msdn-files/027/001/772/ msdncompositedoc.xml.

Additional requirements exist when you perform a scan of a remote computer:

  • The user must be a member of the local Administrators group on all target computers.

  • To allow remote IIS scanning, IIS Common Files must be installed on the computer running MBSA.

  • The Workstation service and the Client for Microsoft Networks must be installed.

Requirements also exist for the target computers of the MBSA scan. The remote computer must meet the following requirements:

  • The remote computer must be running Windows NT 4.0 Service Pack 4 or later, Windows 2000, or Windows XP.

  • The remote computer must have the Workstation, Server, and Remote Registry services running. In addition, File And Print Sharing must be enabled.

  • The remote computer must be running Internet Explorer 5.01 or later.

  • To inspect for IIS vulnerabilities, the target computer must be running IIS 4.0 or IIS 5.0.

  • To inspect for SQL Server vulnerabilities, the target computer must be running SQL Server 7.0 or SQL Server 2000.

  • To inspect for desktop application vulnerabilities, the target computer must be running applications from Microsoft Office 2000 or Microsoft Office XP.

Performing Graphical MBSA Assessments

The primary reason for utilizing MBSA is to run security assessments from the GUI. To perform a scan against a single computer, the following procedure can be used:

  1. On the desktop, double-click the Microsoft Baseline Security Analyzer shortcut. By default, the MBSA icon is automatically placed on the desktop upon installation.

  2. On the Welcome To The Microsoft Baseline Security Analyzer screen, click Scan A Computer.

  3. On the Pick A Computer To Scan page, you must indicate the computer name or the IP address of the computer, a name for the resulting XML report, and the specific security tests to perform, as shown in Figure 24-2.

  4. Once the options are defined, click the Start Scan link. When the scan is complete, the results of the current scan are shown in the details pane and will include an overall security assessment.

    figure 24-2 defining scanning options for a single computer

    Figure 24-2. Defining scanning options for a single computer

You can choose to scan all computers in a specific domain or all computers within a specific IP subnet. The following procedure is used to scan multiple computers:

  1. On the desktop, double-click the Microsoft Baseline Security Analyzer shortcut.

  2. On the Welcome To The Microsoft Baseline Security Analyzer screen, click Scan More Than One Computer.

  3. On the Pick Multiple Computers To Scan page, you must indicate either the domain or the IP address range to scan, a name format for the resulting XML reports, and the specific tests to perform, as shown in Figure 24-3.

  4. When all options are defined, click the Start Scan link.

    figure 24-3 defining scanning options for a multiple computer scan

    Figure 24-3. Defining scanning options for a multiple computer scan

Once you complete either a single-computer or multiple-computer scan, the resulting reports are stored in XML format in the %UserProfile%\SecurityScans folder, where UserProfile is the full path of the user s profile folder. These reports are best viewed in the MBSA console by clicking the View Existing Security Reports link on the Welcome page.

If a scan is performed against an entire domain or IP subnet, an individual report is produced for each detected computer.

Performing Text-Based MBSA Assessments

To perform a text-based MBSA assessment, you must use the text-based version of MBSA, Mbsacli.exe. This version of MBSA performs security assessments of either a single computer or multiple computers from a command prompt. The results are stored in XML format output files that can be viewed in the graphical version of the MBSA.

The command-line options for Mbsacli.exe include the following:

  • /c domain\computer

    Performs a security assessment of the designated computer.

  • /I xx.xx.xx.xx

    Performs a security assessment of the computer at the designated IP address.

  • /r xx.xx.xx.xx yy.yy.yy.yy

    Performs security assessments of all computers with IP addresses in the designated range.

  • /d domain

    Performs security assessments of all computers in the designated domain.

  • /n options

    Bypasses the designated scanning options. Options include IIS, OS, Password, SQL, or Updates.

    To bypass multiple tests, you can identify the test names in a single option. For example, to bypass IIS and SQL tests, you would use /n IIS+SQL.

  • /sus

    SusServer Filters security updates so that only security updates approved at the designated SUS server are displayed.

  • /s

    Suppresses output for scan options. If you designate /s 1, all security update check notes are suppressed. If you designate /s 2, both security update check notes and warnings are suppressed.

  • /nosum

    Bypasses testing of file checksums when determining whether a security update is installed on the target computer or computers.

  • /o

    Defines the format of the output XML file name. You can use a combination of %domain%, %computername%, and %date% when designating the format. The default format name is %domain% - %computername% (%date%).

    If no options are provided when running Mbsacli.exe, a security assessment of the local computer is performed, using all default options.

For a complete listing of all Mbsacli.exe command-line switches, see the MBSA Help file, available from the Welcome screen of the MBSA graphical tool.

For details on using the Mbsacli.exe text-based tool to scan for security updates by using a HfNetChk-style scan, see the Scanning for Updates with the Command-Line Version of MBSA section in Chapter 23.

Third-Party Tools

Third-party tools also perform network security assessments. These tools offer downloadable updates for new security issues and provide more tests than those currently offered by MBSA.

You might consider using the following tools to perform security assessments:

  • ISS Security Scanner

    Scans for security vulnerabilities and configuration issues on the local computer. This tool also records baseline settings for the registry, file system, currently running services, processes, existing users, existing groups, and existing file shares. This baseline allows you to determine whether files are modified by viruses. A trial version of the ISS Security Scanner is included in the Microsoft Windows 2000 Server Resource Kit (Microsoft Press, 2000) in the \apps\systemscanner folder.

    The application of a service pack or security update can lead to false positives for file and registry modification. Any time you apply a service pack or security update, you should reset the security baseline in the tool.

  • ISS Internet Scanner

    The ISS Internet Scanner allows you to scan remote computers for security policy compliance. Within the IIS Internet Scanner, you can reflect your company s security policies by defining custom scan policies. These scan policies define the baseline security requirements for your company and indicate which vulnerability checks are included in a scan session. Once you define a scan policy, you can implement the scan against one or more hosts on the network, depending on your ISS Internet Scanner license.

    An evaluation version of the ISS Internet Scanner can be obtained at http://www.iss.net/download/.

  • eEye Retina Network Security Scanner

    The eEye Retina scanner is a network security scanner that allows the creation of custom scanning policies. These policies define which ports are scanned and which security audits are performed during a security assessment. The report generated by the Retina scanner includes audit results, open port analysis, detected services, share enumeration, and user account enumeration. You can download a free 15-day evaluation version of the eEye Retina scanner at http://www.eeye.com/html/Products/Retina/Download.html.

Port Scanning

Another common security assessment task is to determine which ports are open to the Internet. Attackers can use port information to determine which services are accessible from the Internet. A port scanner inspects a target computer on the network and probes each port to determine whether the target computer is listening for connections on the scanner ports. A port scanner also identifies which ports are available to the scanner.

As part of your network security assessment, you should periodically perform external scans of your network to ensure that only authorized ports are exposed to the Internet. For example, if you perform a scan against the IP address of your company s Web server, the only ports open should be the ports for HTTP on TCP port 80 and for Secure Sockets Layer protected HTTP on TCP port 443. Assuming you are not running any other services on the Web server, no other ports should be visible.

Common Windows Ports

When you perform a port scan, the main goal is to identify all open ports on the target computer. Ideally, if the computer is exposed to the Internet, the only exposed ports will be those the firewall publishes to the Internet.

When performing port scans, it is useful to identify common ports used by Windows and Windows services. Some of the more common ports on Windows 2000 Servers are listed in Table 24-2.

The ports listed in Table 24-2 are the listening ports at a server. Typically, a client computer will use a random Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) port above port 1023 when connecting to the server s listening port.

Table 24-2. Common Windows Ports

Port

Application

TCP port 20

FTP data

TCP port 21

FTP control

TCP port 23

Telnet

TCP port 25

Simple Mail Transfer Protocol (SMTP)

TCP port 53

Domain Name System (DNS) zone transfer

UDP port 53

DNS name resolution

UDP port 67

Dynamic Host Configuration Protocol (DHCP) server

UDP port 68

DHCP client

TCP port 80

HTTP

TCP port 88/UDP port 88

Kerberos authentication

TCP port 110

Post Office Protocol version 3 (POP3)

TCP port 119

Network News Transfer Protocol (NNTP)

UDP port 123

Network Time Protocol (NTP)

TCP port 135/UDP port 135

Microsoft remote procedure calls (RPCs)

UDP port 137

NetBIOS Name Service

UDP port 138

NetBIOS Datagram Service

TCP port 139

NetBIOS Session Service

TCP port 143

Internet Message Access Protocol (IMAP) version 4

UDP port 161

Simple Network Management Protocol (SNMP)

UDP port 162

SNMP traps

TCP port 389/UDP port 389

Lightweight Directory Access Protocol (LDAP)

TCP port 443

Hyper Text Transfer Protocol with Secure Sockets Layer (HTTPS)

TCP port 445/UDP port 445

Microsoft Common Internet File System (CIFS)

TCP port 464/UDP port 464

Kerberos password

UDP port 500

Internet Key Exchange (IKE) for IP Security (IPSec)

TCP port 563

NNTP with Secure Sockets Layer (SSL)

TCP port 636

LDAP with SSL (LDAPS)

TCP port 993

IMAP4 SSL

TCP port 995

POP3 SSL

TCP port 1433

SQL Server

UDP port 1701

Layer Two Tunneling Protocol (L2TP)

TCP port 1723

Point-to-Point Tunneling Protocol (PPTP)

UDP port 1812

Remote Authentication Dial-In User Service (RADIUS) authentication

UDP port 1813

RADIUS accounting

UDP port 2504

Microsoft Network Load Balancing (NLB) service remote control

TCP port 3268

LDAP Global Catalog

TCP port 3269

LDAP Global Catalog with SSL

TCP port 8080

Microsoft Internet Security and Acceleration (ISA) Server proxy port

For a complete listing of assigned port numbers, see the Internet Assigned Numbers Authority (IANA) Web site at http://www.iana.org/assignments/port-numbers.

Determining Open Ports on the Local Computer

On the local computer, you can use the Netstat.exe command-line tool to show all open TCP and UDP ports. To show all open ports on the current computer, you can use the following Netstat command syntax:

Netstat a n

The -a indicates that all TCP and UDP listening ports are enumerated. The -n forces the output to show the actual open port numbers, rather than translating the port numbers to protocol names from the %swindir%\system32\ drivers\etc\services file.

If you are running Netstat on a Windows XP based computer, you can also use the -o switch, which shows the process that is listening on each open port. This can help identify rogue applications on the local computer.

Determining Open Ports on a Remote Computer

When performing security assessments, you can use a port scanner from the Internet to ensure that only required ports are open on an externally accessible server, such as a Web server.

To perform the port scan, you must acquire a port scanner from a third-party source, such as the Prosolve WinScan 2.0. In its most basic form, a port scanner will scan a designated computer to determine which ports are open on the target computer.

Depending on the manufacturer, a port scanner might also attempt attacks that target known vulnerabilities with open ports. For example, if TCP port 139 (the NetBIOS Session Service) is detected by the port scan, a port scanner might attempt to enumerate shares on the target server.

To scan a computer with Prosolve Winscan 2.0, use the following procedure:

  1. From the Start menu, point to Programs, point to Prosolve, point to WinScan 2.0, and then click Winscan 2.0. (See Figure 24-4.)

  2. In the Target section of the Winscan window, enter the Host/IP and Netmask for the port scan.

  3. In the Operation section of the Winscan window, click Scan.

  4. In the Port Range section, enter the Start and End port numbers for the scan.

  5. In the Options section, enable both the TCP and UDP options. You can increase the speed of the scan by disabling the Prescan option.

  6. Click Start Scan to start the port scan of the target computer.

    figure 24-4 the prosolve winscan 2.0 port scanner

    Figure 24-4. The Prosolve Winscan 2.0 port scanner

    Other freeware port scanners are available on the Internet. These include the Foundstone SuperScan v3.0 utility (http://www.foundstone.com/knowledge/scanning.html) and Portqry.exe (http://www.microsoft.com/downloads/release.asp? ReleaseID=37344), a command-line port scanner from Microsoft.



Microsoft Windows Security Resource Kit
Microsoft Windows Security Resource Kit
ISBN: 0735621748
EAN: 2147483647
Year: 2003
Pages: 189

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net