Chapter 15: Terminal Server System Auditing

 

 

This chapter introduces Terminal Server System Auditing strategies using Microsoft Baseline Security Analyzer and Nmap. The goal of this chapter is to introduce security auditing strategies for Terminal Server while providing direction to satisfy information security and regulatory mandates.

 

 

All production servers should undergo regular security audits to ensure compliance with security policies and regulatory mandates. Pre- and post-production audits validate that a server is configured to specifications, eliminating possible security holes and missing hotfixes or patches. All servers should undergo pre-production audits whereas the frequency of production audits depends on business and regulatory requirements.

 

The following sections will introduce system auditing using Microsoft Baseline Security Analyzer (MBSA) and Nmap. We will walk through how to execute a scan against a Terminal Server then analyze and compare the results against security policies. Although there are countless commercial and Open Source auditing and scanning solutions, I selected Microsoft Baseline Security Analyzer and Nmap because of their performance, price (they are both free) and widespread industry adoption.

 

The next section will introduce Microsoft Baseline Security Analyzer and follow with an example scan.

 

Microsoft Baseline Security Analyzer is part of the Microsoft trustworthy computing initiative. It is a tool to help determine the security posture of Windows servers and many other Microsoft products. The results from a Microsoft Baseline Security Analyzer scan include Microsoft’s security recommendations and presents detailed remediation steps. Microsoft Baseline Security Analyzer is built on the Windows Update Agent and Microsoft Update infrastructure and supports Windows NT 4.0 SP4 or above, Windows 2000, Windows XP, Windows Server 2003, IIS 4.0 or above, SQL 7.0 and above, and Office 2000 and above. To run the Microsoft Baseline Security Analyzer, you must have local administrator rights to the computer you want to scan. Remote scans will require the Remote Registry service to be enabled.

 

Note: The Terminal Server Security Baseline from Chapter 11 explicitly disabled the Remote Registry for security reasons. To enable remote administration while configuring the Server Role with the Security Configuration Wizard, enable Remote Windows Administration from the Select Administration and Other Options screen. The registry setting is located:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteRegistry]

The “Start” dword controls the start up type. 00000002 is automatic, 00000003 is manual, and 00000004 is disable.

 

List 15.1 shows the prerequisites and assumptions to use Microsoft Baseline Security Analyzer.

 

The next example walks through executing a scan on a Terminal Server, followed by an explanation of how to validate the scan against a security policy.

 

Please Note: Never run scanners without explicit permission (preferably written) from your employer. Auditors and network and security administrators with the best intentions have been fired for running scanners without the proper authority to do so.

 

1- Log on to the host and run the executable, which by default is installed to “C:\Program Files\Microsoft Baseline Security Analyzer 2\mbsa.exe.” You will see the “Welcome to the Microsoft Baseline Security Analyzer” screen as shown in Figure 15.1.

 

Figure 15.1

 

From the welcome screen you can select “Scan a computer”, “Scan more than one computer”, or “View your existing reports” from computers you have scanned in the past. In this example, click the “Scan a single computer” option to proceed.

 

Figure 15.2 shows the “Pick a computer to Scan” screen.

Figure 15.2

 

2- From the “Pick a computer to scan” screen, ensure that the computer name is selected in the “Computer name” text box. Accept the default setting for the report name and select the following options:

 

Once you make the selections, click “Start Scan.”

 

List 15.2 lists the security settings that Microsoft Baseline Security Analyzer checks. If a product is not installed on the host that is being scanned, the related product checks will not be run or reported.

 

Windows checks

 

IIS checks

 

SQL Server checks

 

Desktop application checks

 

Security update checks

 

After the scan is complete, a summary page will appear as shown in Figure 15.3.

 

Figure 15.3

On the View security report screen, vulnerabilities are grouped under one of six categories. List 15.3 shows the categories from the example scan:

 

 

Each vulnerability is displayed under its respective category with its score, issue and result. There are a total of five scores: Check Failed (Critical), Check Failed (None-critical), Check passed, Additional Information and Best practice.

 

Figure 15.4 shows the five score images with its explanation.

 

Figure 15.4

 

The issue section defines the topic of each vulnerability. The result section includes an explanation of the scan and, in many cases, links to additional information and remediation steps.

 

The View Security Report page allows us to view, print or copy the summary to compare and analyze it against our Enterprise Architecture security policies. If the analysis validates policy compliance, there are no further steps to be made. If the scan analysis shows discrepancies between the scan summary and our security policies, the policies should define how to remediate the deficiencies, such as repair locally on the host or via Group Policy. After the deficiencies have been fixed, rerun the Microsoft Baseline Security Analyzer to validate policy compliance.

 

 

By default the Microsoft Baseline Security Analyzer stores the summary data in the “%userprofile%\SecurityScans” directory. Each time a scan is executed a report with a time stamp is saved in the “%userprofile%\SecurityScans” directory. Reports can be viewed in the Microsoft Baseline Security Analyzer by double clicking the desired file. If a report needs to be deleted, it must be done using Windows Explorer.

Microsoft Baseline Security Analyzer Download: http://www.microsoft.com/technet/security/tools/mbsahome.mspx

 

The next section will provide an introduction to port scanning and TCP/IP stack fingerprinting with Nmap and present one example scan executed against a Terminal Server to audit it for compliance.

 

 

This section begins with an introduction of port scanning and port scanning techniques, followed with a review of Nmap. It concludes with an example scan executed against a Terminal Server to audit it for compliance. This section shows how port scanning with Nmap can assist to quickly audit the configuration of a Terminal Server.

 

Scanners are essential tools for auditors, security and network administrators to quickly determine if a host is running and which services it offers. Scanning software allows us to scan a single machine or an entire network showing which hosts are running, their respected operating systems and what ports they are listening on. For example, let’s say a port scan revealed that a machine is listening on port 3389. An intruder knows that it is Terminal Services and could craft an attack against a known Terminal Services vulnerability.Scanning allows us to quickly audit network gear and servers in terms of their respected roles to validate if they are properly configured.

 

Discovering open ports does not entirely indicate what services are listening and active as illustrated in the example scan. Port numbers range from 0 to 65535 and are separated into three categories: Well Known Ports, Registered Ports, and Dynamic and/or Private Ports. The Well Known Ports range from 0 through 1023. If one or more of these ports are found open, it indicates the assigned service(s) is listening. Registered Ports range from 1024-49151 and Dynamic and/or Private Ports range from 49152 through 65535. Well Known Ports0 through 1023 are well defined and static in contrast to ports 1024 through 65535 which in some circumstances vary. Registered Ports sometimes vary because many services rely on remote procedure calls (RPC) or Distributed COM (DCOM) features in Windows to assign them dynamic TCP ports. Dynamic TCP port assignment is commonly referred to as random RPC ports.

 

The assignment of ports is managed by a U. S. association named Intermodal Association of North America (IANA). The port assignment list is a set of recommended portsthat is largely followed by the vendors and developers. Quite often vendors or developers select ports for different applications or protocols other than their official IANA designation. This, along with random RPC ports, emphasizes the importance to select a reliable scanner and to thoroughly understand port scanning analysis.

 

Port scanning techniques have become very sophisticated. Scanning software allows us to create and transmit basic TCP/IP packets and sequences and unusual TCP/IP packets and sequences. Basic scanning techniques are logged by the remote host and canbe easily identified by an Intrusion Detection System (IDS). Stealth scanning techniques allow us to craft unusual TCP/IP packets and sequences that can go undetected on a remote system or by an Intrusion Detection System.

 

With a basic scan, an operating system uses a TCP connect() call to attempt to initiate a TCP connection to a specific port on a remote system. This scan is named after the connect() call used by an operating system to initiate a TCP connection to a remote device. A TCP connect() scan uses a standard TCP connection to verify which ports are open. TCP connect() scans uses the same TCP handshake connection that other networked TCP-based applications use. This type of scan will be logged by the remote host and can be easily identified by an Intrusion Detection System or event log.

 

There are various scanning techniques to test for open ports on a remote system without being logged. One of these stealth techniques is the SYN scan, which is often referred to as "half open" scanning. A SYN scan uses standard methods of port-identification without completing the TCP handshake. As soon as an open port is identified, the TCP handshake is reset before it is completed. With a SYN scan, the host never actually creates a TCP session with a remote system. A SYN scan allows a remote system to be scanned without being logged.

 

The FIN, NULL or XMAS scans are often grouped together because of their similarities. These scans are stealthy because they send a single frame to a TCP port without any TCP handshaking or additional packet transfers. These scans send a single frame with the expectation of a single response. Sending thesetypes of packets to a closed port will result in an RST response, while an open port will drop these packets. By identifying the closed ports, the open ports can then be extrapolated.

 

Nmap is one of the industries’ most complete free port scanners that issupported on Windows, Linux, Mac OS X, FreeBSD, OpenBSD, Solaris, HP-UX, NetBSD, Solaris, Amiga and more. Nmap is available from www.insecure.org at no cost under the terms of the GNU General Public License. Although there are countless commercial, Open Source, and gratis port scanners, I selected Nmap because of its performance, broad adoption and price.

 

On NIX and Windows platforms, Nmap can be executed from the command line or from a GUI interface called NmapFE. On the Windows platform, Nmap requires the WinPcap libraries; WinPcap requires administrative access to install. WinPcap can be downloaded from http://www.winpcap.org/. After WinPcap is installed on a Windows host, Nmap can be downloaded, unzipped to a directory, and executed from the directory via the command line.

 

Nmap allows us to run a wide variety of port scans and operating system identification scans using TCP/IP stack fingerprinting. Nmap interrogates a system’s TCP/IP stack by sending the operating system different packets and then interpreting and reporting the response. The packets are specifically crafted to make the target operating system TCP/IP stack respond in a unique way. Knowing in advance how an operating system TCP/IP stack will respond allows Nmap to determine relatively accurately which operating system the target system is running and its version number.

 

List 15.5 highlights Nmap's scanning capabilities:

 

Nmap also supports a wide variety of advanced scans.

 

List 15.6 highlights Nmap's advanced scanning capabilities:

 

On the NIX platform, root users enjoy full functionality in contrast to regular user access, which is slightly limited, in part because of the lack of many critical kernel interfaces, such as raw sockets (used for TCP/IP fingerprinting). A lot of effort has been put into Nmap to provide good performance for non-root users, although Nmap should be run as root whenever possible.

 

Nmap can be used to scan a single host or an entire IP range, allowing detailed information to be obtainedabout a single host or all the hosts (routers, switches, hubs, firewalls, etc.) on a network. Nmap's results show a list of what is referred to as “interesting ports” on the system being scanned. Nmap always provides a port’s service name, providing there is a service name, port number, state of the port (either open, filtered, unfiltered) and protocol.

 

List 15.7 shows the state of the port section of an Nmap scan:

 

Nmap supports fifteen separate scanning methods. Each scanning method has its own distinct characteristics, advantages and disadvantages. The majority of the scanning methods are straightforward and simple to execute, while others are more complex, requiring additional information be obtainedbefore a scan can be executed.

 

The syntax of an Nmap scan is as follows:

nmap [Scan Type(s)] [Options] <host or net #1 ... [#N]>

The command “nmap” is what actually executes the scan. Multiple scan types and options can be combined to craft a scan.

 

List 15.8 shows a partial list of Scan Types:

 

List 15.9 shows a partial list of Options:

 

Tip: The help menu can be accessed from the command line by typing nmap –help; or for an exhaustive list of scan types and options, refer to Nmap's man pages. On an NIX system, man pages can be accessed by typing “man nmap” within a terminal window.

 

Next will be a walk through of an example scan to determine if the server role is properly configured. The scan will be executed against an individual Terminal Server to audit which services it offers, and will then use the netstat and tasklist commands to map executables to open ports.The goal of the example is to show how Nmap assists to quickly discover improperly configured and non-compliant computers or devices on anetwork.

 

Please Note: Never run scanners without explicit permission (preferably written) from your employer. Auditors and network and security administrators with the best intentions have been fired for running scanners without proper authority to do so.

 

The first example shows a TCP SYN scan (-sS option) with the -O (OS detection) option executed against a single Terminal Server host:

 

[root@sffc6mtv00 ~]# nmap -sS -O 192.168.1.203

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2006-12-11 20:13 PST

Interesting ports on 192.168.1.203:

Not shown: 1674 closed ports

PORT     STATE SERVICE

135/tcp open msrpc

139/tcp open netbios-ssn

445/tcp open microsoft-ds

1025/tcp open NFS-or-IIS

1050/tcp open java-or-OTGfileshare

3389/tcp open ms-term-serv

MAC Address: 00:0C:29:7F:4F:13 (VMware)

Device type: general purpose

Running: Microsoft Windows 2003/.NET

OS details: Microsoft Windows Server 2003SP1

Nmap finished: 1 IP address (1 host up) scanned in 2.183 seconds

[root@sffc6mtv00 ~]#

 

The result from the example shows that ports 135/tcp, 139/tcp, 445/tcp, 1025/tcp, 1050/tcp, and 3389/tcp are open on the Terminal Server. The open ports confirm the Terminal Server role is properly configured. Ports 135/tcp, 139/tcp, 1025/tcp, and 1050/tcp are needed for intra machine communication. Port 3389/tcp is Terminal Services and port 445/tcp enables file and printer sharing. Port 445/tcp is the only port that could be disabled by disabling File and Printer Sharing for Microsoft Networks in the network adapters’ properties. Let’s review the example in greater detail.

 

Table 15.1 shows the scan line by line.

 

Table 15.1

In many cases we need to know exactly which service is listening on a port in order to determine if it can be disabled, such as ports 1025/tcp and 1050/tcp from the last example. Determining exactly which service is listening on a port can be accomplished using the netstat -ano command to enumerate all of the running network services with their associated process identifier (PID) and the tasklist command to display the translation between PID and executable names.

 

The next example shows the result from netstat -ano onthe same Terminal Server as in the first example. The output is truncated to save space. 

 

C:\>netstat -ano

Active Connections

 

Proto Local Address        Foreign Address           State                   PID

TCP    0.0.0.0:1025                    0.0.0.0:0              LISTENING      748

TCP    0.0.0.0:1050                    0.0.0.0:0              LISTENING      144

 

Note ports 1025/tcp PID 748 and 1050/tcp PID 144. Next the tasklist command is executed to display the translation between process identifiers and executable names. The output is truncated to save space.

 

C:\>tasklist

Image Name           PID Session Name Session#    Mem Usage

============= ============== ======= ==========

lsass.exe                   748 RDP-Tcp#3           0           3,848 K

svchost.exe               144 RDP-Tcp#3          0            2,448 K

 

The result from the tasklist command shows that the lsass.exe executable is bound to port 1025/tcp and that svchost.exe is bound to 1050/tcp. Lsass.exe is a system process of the Microsoft Windows security mechanisms that specifically deals with local security and login policies. Svchost.exe is a system process belonging to the Microsoft Windows Operating System, which handles processes executed from DLLs.

 

Using the netstat -ano and tasklist commands allow precise identification of which executables are bound to a port. Identifying which executables are bound to a port comes in handy in trying to identify Registered Ports, Dynamic and/or Private Ports and random RPC Ports.

 

Nmap is an extremely useful tool that allows the scanning of individual servers and networks to determine which hosts are up and what ports they are listening on. The information gathered from Nmap scans allows the auditing of systems in order to validate if they are correctly configured by identifying what is running on a system.

 

 

 

This chapter discussed Terminal Server system auditing. The chapter began with an introduction of pre- and post-auditing strategies and ended with an overview of Microsoft Baseline Security Analyzer, including an example scan against a Terminal Server. Next port scanning techniques were reviewed, followed by a review of Nmap and its usage, including an example scan against a Terminal Server.

 

Pre- and Post-Production Auditing

 

Microsoft Baseline Security Analyzer

 

 

Port Scanning Techniques

 

Nmap

 

Netstat and tasklist

 

The next chapter will introduce security log management strategies.

TCP/IP stack fingerprinting written by Fyodor

http://www.insecure.org/nmap/nmap-fingerprinting-article.html