Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Monitor Basic Services

Your Windows Server 2003 network may or may not incorporate every bit of functionality that it can provide. However, you should understand how to determine when the operations of these services can impact security and what to do about it. Many freely available Microsoft tools can be used to monitor these services and are discussed in this section. Sources of these tools are described in Table 19-1. Start the process by determining what services should be running on which machines, and then use tools and logs to determine if they are operating correctly. This chapter only covers services that provide or directly support the operation of security services.

Table 19-1. Tools for Monitoring Services

Source

Description

Available

Built-in command line tools

Many tools and utilities are executable files installed by default.

By default. Many of them are located in %windir%\system32.

MMC, browser- based, or other console-based tools

Many administrative tools are provided that can be snapped-in to a Microsoft Management Console, or loaded in IE.

Many are available directly from the Start\Administrative Tools folder. Others are added when a specific services is installed, or may be added by opening an MMC and using the File menu Add\Remove Snap-in selection.

Support tools

Support tools are additional utilities that are not installed by default.

Located on the Windows Server 2003 installation CD-ROM.

Resource kit tools

Tools provided as part of a server-specific resource kit. Resource kits are compiled technical references on a specific Microsoft product. They may or may not include utilities.

Purchase of the resource kit provides a copy of the tools. Some, if not all, tools may be downloaded from http://www.microsoft.com/downloads/details.aspx?familyid=9d467a69-57ff-4ae7-96ee-b18c4790cffd&displaylang=en.

Monitoring DNS and Network Connectivity

Proper DNS operation is critical to security services. DNS is used to determine the names and locations of domain controllers and services such as ldap, Kerberos, and global catalog servers (GCs). If DNS fails, or if its service records are not correct, basic security fails. Authentication, replication, Universal group membership, and other domain services cannot function without it. Testing and monitoring DNS can also provide confirmation of basic network connectivity.

TIP: Monitor Network Connectivity Using the Application and System Event Logs

Events 1058 and 1030 in the Application Event log can be indications of basic network connectivity problems. Event 1058 indicates that Windows cannot access the gpi.ini file that is necessary for applying GPOs. It may also indicate that the DC cannot be reached or that access is denied. Event 1030 "Windows cannot query for the list of Group Policy objects" and the System Event log event warning 11197 can indicate DNS issues but can be due to other problems.

To test DNS, you must test not only the ability of DNS to resolve computer names to IP address, but also the proper registration of domain services. DNS can be correctly configured and operating perfectly, but if domain services are not properly registered, security services will not work well or will not work at all. Use the following tests to verify DNS operation.

nslookup

Use nslookup to verify SRV records in DNS. These records locate AD services on the network and DCs use them to find replication partners:

1.
Open a command prompt on the DNS server, type nslookup, and then press Enter.

2.
Type set type=all and press Enter.

3.
Type ldap.tcp.dc._msdcs.domain_name and press Enter. (domain_name should be the name of a domain in your Active Directory forest.) The LDAP SRV record, as shown in Figure 19-1, will be returned. While other SRV records must be present for proper operation, if nslookup does not return the LDAP SRV record for each DC, SRV records are not complete. Use DNSLint and/or dcdiag to check further or examine DNS records directly.

ipconfig

Check TCP/IP configuration on DCs using ipconfig /all to ensure that the DNS server listed is the appropriate one. (Each DC should point to a DNS server for its domain.) In the forest root domain, if DNS is integrated with Active Directory, make sure that DCs running the DNS service do not all point to themselves for DNS services. If they do, each may only record its own IP information. Replication between DCs may not occur because only one DC record will be in each DNS server. Instead of pointing each DC to itself, a good basic rule is to point all DCs to the same DNS server and point that DC to itself. (For more information, see KB article 275278.)

DNSLint

Use DNSLint to diagnose DNS errors. DNSLint can also be used to find replication errors. To diagnose DNS errors, run the DNSLint command. DNSLint /d domain_name looks on the Internet to find registered DNS domains. If your Active Directory domain is not registered, you must provide DNSLint with the IP address of a DC. Use the command DNSLint /d domain_name /s ipadressofdomain_nameDC. This command will access the DNS records on the ipaddressofdomain_nameDC you provide. To produce a text file in addition to an HTML report, use the /t switch. DNSLint produces a report that includes this information:

Domain authoritative DNS servers.

Source of Authority (SOA) records.

Host records for DNS servers.

Mail server (MX) records for the domain.

If multiple authoritative DNS records are located, DNSLint will compare the information provided looking for differences.

It will also document the following errors if present:

Lame delegation
A DNS server delegates authority for a sub-domain to a DNS server that cannot be reached, does not exist, or is not configured to be authoritative for the sub-domain.

Missing glue records
Glue or host records are needed for name resolution.

Non-authoritative DNS servers
Provides the information needed to troubleshoot lame delegation issues.

Non-responsive DNS servers
If DNSLint cant reach them, neither can clients.

Improperly configured TCP/IP
The DNS server location in TCP/IP does not represent an authoritative server for the domain.

Missing CNAME or host (glue or A) record
Records for DCs do not exist in DNS. Clients search for a DC by finding the DCs GUID and resolving this to the associated CNAME and finally obtaining an IP address from the host record.

Missing service location records
Some or all SRV records are missing.

You can obtain more information and download DNSLint from http://support.microsoft.com/default.aspx?scid=kb;EN-US;321045. Table 19-2 lists and describes DNSLint parameters.

Table 19-2. DNSLint Parameters

Parameter

Description

/ad

Tests LDAP and SRV records.

/c SMTP

Checks for SMTP server records and check connectivity for POP, SMTP, and NNTP.

/no_open

Dont open the dnslint file at the end of processing.

/s

Checks locally. Do not use a Internic whois command.

/t

Produces a text file.

/test_tcp

Tests the response of DNS to TCP port 53.

/v

Verbose reporting.

Figure 19-2 displays part of a DNSLint report.

dcdiag, netdiag, and portqry

Network connectivity problems can disrupt Active Directory and Group Policy function. Dcdiag is a general purpose DC and Active Directory diagnostic tool. It can also be used to test basic DNS and network function because if these services are not operating properly, many if not most dcdiag tests will fail. Use dcdiag /test:DomainDNSzones and dcdiag /test:ForestDNSZones to check DNS for proper domain SRV records.

If dcdiag tests fail, check network connectivity. Use neTDiag to test network services related to Active Directory. Entering neTDiag without any parameters performs a number of network function tests. To test DNS, use the command netdiag /test:DNS. This test checks DNS function and checks that DC information is properly registered in DNS. Other useful tests are dclist, which produces a list of DCs, and Kerberos, which checks Kerberos. Both dcdiag and netdiag have useful fix commands that may fix DNS domain registration problems.

Use portqry to determine if DCs are listening on appropriate ports. portqry -n dc1.nomain_name.extension -p udp -e 53 will determine if the DC is listening on UDP port 53. Although portqry is a simple port tester and can be used to test if the DC is listening on specific ports, it is often unnecessary because this can be verified when other tests or tools are used. For example, if you can successfully use the utility ldp.exe to search and modify Active Directory on a specific DC, you already have proof that that DC is listening on an LDAP port. Ldpexe connects and binds to either LDAP port 389 or the LDAP SSL port 3268. There is no need to perform a separate test.

Monitor DHCP

DHCP automatically assigns an IP address and other TCP/IP configuration information to clients on the network. DHCP can also be used to register DNS information to DNS. When DHCP servers fail or run out of addresses and when rogue DHCP servers are able to interfere with your network operation, this can be a serious security problem as well as a network operation problem. A rogue DHCP server can direct clients to a DNS server that incorrectly resolves addresses and potentially directs clients to servers and sources where information of a sensitive nature goes to the wrong people, or incorrect information may be perceived by clients as correct. If clients cannot obtain an IP address, they cannot participate on the network. What if the client that cannot participate needs to do so to monitor security, to administer sensitive systems, or to otherwise communicate information that may protect the network and its resources?

The Product Operations Guide at http://www.microsoft.com/technet/itsolutions/cits/mo/winsrvmg/dhcppog/dhcppog3.mspx#EGAp provides information on how to use System Monitor to monitor DHCP server performance. Monitoring performance and disk utilization for DHCP servers can provide early warnings of possible failure. It cannot provide information about rogue DHCP servers, however.

The DHCP logs should also be reviewed for information that may indicate performance issues or even attacks. In addition to using the DHCP logs and System Monitor to monitor DHCP function, the Windows Support tool, dhcploc.exe (the DHCP Server Locator Utility), displays active DHCP servers on a subnet. It can also alert you to unauthorized DHCP servers (it actually beeps and can send out messages). It can also be used to display packets from DHCP servers.

dhcploc does not rely on DHCP registration with Active Directory to determine which DHCP servers are authorized. Instead, you create a list of authorized DHCP servers, and dhcploc lets you know if DHCP servers that are not on the list are active on your network. Table 19-3 lists the parameters that can be used with the dhcploc.exe command.

Table 19-3. dhcploc Parameters

Parameter

Description

/p

Suppress display of packets from authorized DHCP servers as listed in your valid DHCP server list.

/a:"alertname"

Sends alert messages to the names in alertname, a list of user names.

/I:alertinterval

Alert interval is the alert frequency in seconds.

ComptuerIPAddress

The IP address on which you run dhcploc.exe. Specify the IP address of the adapter on the subnet on which you want to run the test.

ValidDHCPServerList

The IP addresses of authorized DHCP servers.

An example command that will run dhcploc on server 192.168.5.55 and produce alerts if rogue DHCP servers (those other than 192.168.5.100) are found and display packets from them is as follows:

dhcploc /p 192.168.5.55 192.168.5.100

Once dhcploc is running, type the letter d to display packets.

Packet information includes the time, IP address to which the DHCP offer is made, the server that made the offer, and the DHCP message (OFFER, NACK, ACK). Do not run dhcploc on a DHCP server because it will interfere with operations. To send an alert to the user Administrator, use the following command:

dhcploc /p /a:Administrator 192.168.5.55 192.168.5.100

Monitor PKI

If a public key infrastructure (PKI) is installed and used on your network, it is important to know that it is properly operating. If the PKI includes Microsoft enterprise certification authorities (CAs), use the PKI Health Tool (pkiview.msc) to monitor PKI health. PKI Health is an MMC snap-in that gathers information from each CA and reviews the status of their CA certificates to make sure they are working correctly. The utility can also be used to view CA root and issuing CA certificates, identify the AIA location (the locations from which the CA certificate can be downloaded), view cross certificates, display the CRL distribution point, and identify key recovery agent certificates. If you have many CAs in your organization that are integrated with Active Directory, pkiview can be used to collect information about all of them. Comparing this information can also help you discover any unauthorized CAs that may have been integrated with AD.

To use the tool, add the Enterprise PKI tool to an MMC console. (The tool is available from the Add/Remove Snap-ins command if re-source kit tools have been installed on the computer.) When opened in a console, pkiview displays the CA hierarchy, providing a node for each CA, as shown in Figure 19-3. In the figure, the rootA CA is marked by an xd circle. This means that pkiview has identified an error. Select the CA to view the error in the detail pane. In this case, pkiview has attempted to download certificates from AIA locations and has found that one location is inaccessible. Downloading certificates is necessary when checking certificate signatures and when adding the CA to the computers trusted CAs.

The figure also shows a warning. In this case, opening the SubCA CA node, as shown in Figure 19-4, reveals that the delta CRL is nearing expiration. Reviewing errors in pkiview can help you see where problems may be or about to be that can cause problems with certificate services.

Monitor Routing and Remote Access

The Resource Kit tool RRAS Server Monitor (RASSrvMon.exe) is a GUI tool that can be used to review remote access service activity in detail. It can provide summary information on the server as well as individual connection information. Connection information for every connection includes user name, computer name, IP address, connection start time, duration, bytes transmitted, error count, and line speed. You can also configure alerts, for example, to warn if the remote access server is unreachable or non-responsive. Alerts can be configured to run a program, such as to send an email or a page.

RASSrvMon generates three files for each monitored RRAS server: a summary file, servername.webstatus; a user connection file, servername.userdetails; and a file used to generate the data dumps, servername.userlist.

To start the monitor, enter the command rassrvmon /s: servername_or_IP_address /t:TimeOffset where TimeOffset is the length of time that the server has been running before the monitor was started. Because one of the purposes of RASSrvMon is to alert you if a RRAS server is not working, it is best to monitor the RRAS server from another computer. If you must run the monitor on the RRAS server, use the /p:svchost_Pid parameter instead of the /s: parameter. svchost_Pid is the process ID of the svchost process under which the remote access server is running. Because multiple svchost processes may be running, determine the one that is running the RRAS service by using the tasklist /svc command. The command produces a list of running processes, their PID, and the name of the service, as shown in Figure 19-5. Each svchost.exe process is listed along with the services it has loaded. Use tasklist on the RRAS server, identify the RRAS service, and record the PID. Then, use the PID with the RASSrvMon command.

In the figure, PID 860 is the PID for the svchost running the Remote Access service. To start RASSrvMon, enter the command:

Rassrvmon /p:860 /t:TimeOffset

The RAS Monitor GUI is displayed. In Figure 19-6, the Monitor configuration page is displayed to show two important alert settings: MprAdminPortEnum Failure and No Incoming Calls. These settings, if configured to send an alert, can warn you of a non-functioning RRAS server. MprAdminPortEnum is a call to list the connections on the RRAS server ports. RASSrvMon can be configured to poll all ports. If the call fails, it may be an indication that the server is malfunctioning. If the server is in constant use and yet receives no calls over some time period you configure, this may also indicate that the server is down.

Monitor Shares

In addition to monitoring access to sensitive files using object auditing, monitor server shares with the Server Share Check Tool (Srvcheck.exe). This tool lists non-hidden shares, as shown in Figure 19-7, and the permissions set on each. There are two uses for this information. First, if you keep a record of which shares should be available on the server, you can compare this information to ensure that only the proper shares are available. Second, you can compare the ACLs with those authorized for the shares. If you send the results of using srvcheck to a file, as shown in the following command, you can compare future results (also recorded in a file) and note differences:

Srvcheck \\server_name > shares.txt

Figure 19-7 displays the shares.txt file in Notepad.

TIP: Comparing Files

The GUI tool windiff.exe provided with Windows Server 2003 can be used to compare two files. To compare two files from the command prompt, enter the command Windiff filepath1 filepath2. Enter windiff at a command prompt to open the tool. An included help file explains its use.

Monitor All Active Services

While monitoring tools for specific services exist, its helpful to be able to determine if the appropriate services for any particular server are up and running and to determine if any new services have been added. The Resource Kit tool srvinfo.exe can report services information on remote servers. Use the command srvinfo.exe to display services and devices and whether they are stopped or started. Other information is also displayed, such as forest information for this server and network configuration. Use the -s parameter to display shares. Compare this information with what should be available on the server. Figure 19-8 displays partial results from the use of the command srvinfo \\motorin from another computer on the network.