Not all remote access technologies are created equally, and until encrypted networks become the standard, cleartext protocols should be eliminated where possible. Although newer equipment and savvy network administrators can help mitigate the risk of eavesdropping on network traffic, the real risk of catching that traffic still exists, especially on the same broadcast domain for the networking types.
Certain protocols such as FTP and Telnet transmit all information in cleartext, including User ID and password. This could allow someone to obtain this information by eavesdropping on the network. Cleartext communications should be minimized or eliminated. Nonessential remote access connections should be limited or eliminated. These two are commonsense security practices today. Exceptions should be limited to business-driven cases where senior management is willing to sign off on and formally accept the risk of cleartext and remote access.
Modems in particular, or RAS access, bypass corporate perimeter security (e.g., firewalls) and allow direct access to the machine from outside the network. They present significant risk to the security of the machine on which they reside and also may allow the modem user to access the rest of the network. Allowing dial-in modems to be placed on a production machine is usually a bad idea. It is almost always preferable to have access to a machine channeled through standard corporate external access mechanisms such as a virtual private network (VPN) or remote access server (RAS).
View the output of the services and port-mapping tools, and discuss these with the administrator. Ask the administrator about the remote access policies and the different methods of access. Question the need for any cleartext communications that aren't driven by business needs. There are cases where cleartext communications exist and are hard to remove because of a legacy application or the traffic just isn't that important. However, where possible, an encrypted protocol should be used instead. For Microsoft hosts, encrypted protocols include the Remote Desktop Protocol (RDP), Citrix (ICA protocol), SSH, and SSL among many others.
On a Windows server, you can find information about remote access by going to Start | Administrative Tools | Routing and Remote Access.
The use of secure protocols is particularly important in a DMZ and other high-risk environments. The auditor may determine that they are of less importance on the internal network. However, it is still advisable to use secure protocols even on internal networks in order to minimize attacks from within.
A legal logon notice is a warning displayed whenever someone attempts to connect to the system. This warning should be displayed prior to actual login and basically should say, "you're not allowed to use this system unless you've been authorized to do so." Verbiage of this sort may be needed to prosecute attackers in court.
Log into your account using each available service that provides access, such as remote desktop, Telnet, and SSH. Determine whether a warning banner is displayed. Interview the system administrator to determine whether the verbiage for this warning banner has been developed in conjunction with the company's legal department.
Inappropriate or open shares may needlessly compromise personal or company data. You need to identify all shares, shared directories, and permissions. For example, it's not uncommon to find open shares on a network with personal, group ranking, or payroll information. These data never should be kept on an open share.
Use the Microsoft Management Console (MMC) snap-in under Start | Administrative Tools or by typing compmgmt.msc at the command line. When the MMC opens, go to Computer Management | System Tools | Shared Folders to view open shares, sessions, and files.
Alternatively, you can script this with DumpSec. The first command lists the shares, and the second lists the shared directories. You still should verify the share permissions manually, especially for manually created shares.
DumpSec.exe /rpt=shares /saveas=fixed /outfile=TempFile01 DumpSec.exe /rpt=allsharedirs /saveas=fixed /outfile=TempFile02
You also can view a list of shares by running the command net share. You can view remotely opened files by running psfile from SysInternals or use the command net file. If you have a large set of shares on a server and want to spot check it for inappropriate content, consider indexing the shared volume using a tool such as dtSearch. After the indexing is completed, you can run instant searches across the entire volume. This tool is familiar to forensic examiners and built into several products. You can find out more about it at http://www.dtsearch.com.
For each share you find, determine if the permissions are appropriate. Disallow public shares where the NT authenticated users group has full control permissions.
Auditing provides evidence in the aftermath of an event and helps with troubleshooting issues on the host. Ideally, an event-correlation engine would filter and produce meaningful data for the system administrator. Until that day comes, it is important to have auditing enabled to provide a record for what happens on the host.
You should view your audit settings manually with the MMC Group Policy snap-in. If you want, you can export the settings by right clicking the folder icon that says "Audit Policy" and selecting "Export List." Our recommended settings are shown in Table 6-6.
Audit account logon events
Audit account management
Audit directory service access
Audit logon events
Audit object access
Not defined or failure
Audit policy change
Audit privilege use
Audit process tracking
Audit system events
Only enable object access auditing if you know how to use this feature. If you do, then we suggest monitoring only as much as is necessary to meet your needs. You can quickly fill your logs and tax your system with meaningless overhead if this is misused.
You would use the following syntax for DumpSec at the command line:
DumpSec.exe /rpt=policy /saveas=fixed /outfile=policies.txt
If the system administrator doesn't monitor his or her systems for changes or regularly attempt discovering issues in his or her systems, security holes could exist, and security incidents could occur without his or her knowledge. By monitoring, we mean actively watching for issues (detection) and actively searching them out (finding vulnerabilities).
Monitoring also provides a snapshot of the current security level of the system (from a network services standpoint). The world of network vulnerabilities is an ever-changing one, and it is unrealistic to create a static audit program that will provide an up-to-date portrait of vulnerabilities that should be checked. Therefore, a scanning tool that is updated frequently is the most realistic mechanism for understanding the current security state of the machine. In addition, if the system administrator has a security patching process in place, this scan will provide at least some validation as to the effectiveness of that process.
Interview the system administrator and review any relevant documentation to get an understanding of security monitoring practices. There are numerous levels and methods of security monitoring that can be performed. They don't all need to be performed, but they should have some level of monitoring. The level of monitoring required should be consistent with the criticality of the system and the inherent risk of the environment (e.g., a web server in the DMZ should have more robust security monitoring than a print server on the internal network). The system administrator is responsible for monitoring his or her hosts for issues such as those you have been auditing for throughout the other audit steps in this chapter.
If security monitoring is performed, assess the frequency of the monitoring and the quality with which it is performed. Look for evidence that the security monitoring tools are actually used and acted on. Review recent results, and determine whether they were investigated and acted on. Leverage the results of the rest of the audit in performing this assessment. For example, if you found significant issues in an area they were supposedly monitoring, it might lead to questions as to the effectiveness of that monitoring.
Listed below are a few types of security monitoring to consider. You might have others, including external sources such as network security appliances.
This is monitoring in order to detect unauthorized entry (or attempts at unauthorized entry) into the system. Baseline monitoring tools (e.g., Tripwire) can be used to detect changes to critical files, and log-monitoring tools can be used to detect suspicious activities via the system logs.
This is a type of monitoring that detects an attempted attack and stops the attack before it compromises the system. Examples include host IPS tools and network-based IPS tools.
This is probably the most important type of security discovery or monitoring in most environments. These vulnerabilities can be exploited by anyone on the network. There are several great scanners on the market such as eEyes Retina and Tenable Network Security's Nessus scanner. Auditing a host with a scan for vulnerabilities enables you to see the host from the network's perspective, validates your findings, and may show you things that you didn't find. This is true for both Windows and Unix systems. Many of these companies offer free trial versions of the scanner prior to purchase. The Nes-sus scanner is practically free depending on your needs, but you need a Linux host on which to install the scanner. The Retina scanner is particularly easy to use for Windows users (Figure 6-2). Both have received positive reviews from industry peers. There are also several others out there on the market.
Figure 6-2: Retina scanner.
See the "Tools and Technology" section below for information on potential network vulnerability-scanning tools. Even though many of these tools are designed to be non-disruptive and to not require access to the system, you always should inform the appropriate IT personnel (e.g., the system administrator, the network team, and IT security) that you plan to run the tool, receive their approval, and schedule with them execution of the tool. There is always a chance that the scanning tool will interact in an unexpected fashion with a port and cause a disruption, so it is important that others be aware of your activities. These tools almost always should be run in a "safe" (nondisruptive) mode in a production environment such that the tools do not attempt to exploit any vulnerabilities discovered. There may be rare occasions when you will want to run an actual exploit to get more accurate results, but this should be done only with buy-in from and coordination with the system owner and administrator.
This is scanning for vulnerabilities that would allow someone who's already on the system to escalate his or her privileges (e.g., exploit the "root" account), obtain inappropriate access to sensitive data (e.g., owing to poorly set file permissions), or disrupt the system. This type of scanning generally is more important on systems where there are many nonadministrative end users.
One of the best ways to propagate security throughout an environment is to ensure that new systems are built correctly before moving into testing or production.
Through interviews with the system administrator, determine the methodology used for building and deploying new systems. If a standard build is used, consider auditing a newly created system using the steps in this chapter. At the very least, consider structuring an approval process for new standard builds in which an auditor would look over the changes and perform a full audit of new images. This is a great way for the audit team to create a working relationship with the Windows server team.
In addition to auditing the logical security of the system, it is important to ensure that appropriate physical controls and operations are in place to provide for system protection and availability.
Reference the steps from Chapter 4, and perform those that are relevant to the system being audited. For example, the following topics are likely to be pertinent:
Disaster recovery planning
The following steps provide a very quick way to verify the image used for provisioning new computers to the end user. This isn't designed to cover or catch everything, only to give the auditor a "warm, fuzzy feeling" that the clients are following policy properly. These checks lean heavily on the Microsoft Baseline Security Analyzer and your external scanner of choice. If you would like a more comprehensive view of the system, you can perform many of the steps in the preceding section pertaining to servers.
Determine the following steps using a freshly built computer and through interviews with a local technician responsible for provisioning new computers.
Running different software than company-provisioned software may cause instabilities in the enterprise software environment on the laptop or desktop. Failure to have a firewall subjects the client to network attacks from malware, attackers, and curious people.
Most of the time, a visual check of the processes in the task manager shows that the company-provisioned firewall is installed and running on the system. An easy way to script this check is to run pslist from SysInternals on the system and search for the service you're looking for. See the same step executed for servers in the preceding section for more information.
If you are using the Windows firewall, then learn the netsh command set, which allows scripted output and changes to the firewall. Try running netsh firewall show config to see the overall configuration of the firewall on the host and whether the firewall is configured for particular adapters. Use netsh firewall show to see other available options for the netsh firewall tool.
Running different software than company-provisioned software may cause instabilities in the enterprise software environment on the laptop or desktop. Failure to have anti-virus software may allow harmful code or hacking tools to run on the computer that violate company policy.
A visual check of the system tray shows that antivirus software is installed and running on the system. As mentioned earlier, an easy way to script this check is to run pslist from SysInternals on the system and search for the specific running process. Be wary of customized configurations such as excluding directories and files from normal protections offered by the antivirus software.
Again, running different software than company-provisioned software may cause instabilities in the enterprise software environment on the laptop or desktop. Failure to have a company-provisioned patch-management solution may prevent the client from receiving the latest patches, allowing harmful code or hacking tools to run on the computer.
A visual check of the processes in the task manager usually shows that the company-provisioned patch-management system for client computers is installed and running on the system. For example, this may be evidenced by the existence of the process in the task manager or pslist. Some organizations like to enable automatic updates, which is also easily checked by looking for Automatic Updates in the Control Panel.
Failure to have the latest hotfixes and service pack as recommended by Microsoft or other software vendors you use in your environment may allow harmful code to run on the computer or prevent legitimate software from working properly.
Perhaps the easiest way to check this is with the utility psinfo. This utility has several powerful switches that allow for checking for installed software or hotfixes and then outputting the information into a comma-separated file that opens nicely in Excel. Keep in mind that the pstools, psinfo included, are designed to be run remotely to manage hosts across the network. The options allow for checking against all computers in the local domain, in a file, or on a single host. The following is a partial output of psinfo:
The current directory is C:\PERL> psinfo PsInfo v1.73 - Local and remote system information viewer Copyright (C) 2001-2005 Mark Russinovich SysInternals - http://www.SysInternals.com System information for \\CA-CDAVIS: Uptime: 0 days 10 hours 42 minutes 25 seconds Kernel version: Microsoft Windows XP, Multiprocessor Free Product type: Professional Product version: 5.1 Service pack: 2 Kernel build number: 2600 Registered organization: Registered owner: Christopher Davis Install date: 4/19/2006, 1:57:31 PM IE version: 6.0000
The MBSA does a great job auditing a single host quickly for some of the more grievous errors we commit as administrators. For example, we know that incomplete patch installations may cause instabilities in the enterprise software environment on the laptop or desktop. MBSA will check for this and many other common mistakes, such as
Active accounts with blank or weak passwords. Blank and weak passwords create easy targets for attackers.
Using file systems older than NTFS. Older file systems are easier to compromise because they don't support granular file permissions.
Autologin enabled. Autologin allows attackers to easily boot directly into the computer.
Guest accounts enabled. Guest accounts usually have weak passwords and are easily compromised.
Anonymous access. Anonymous access allows attackers to access and profile the computer without an audit trail.
Logon auditing. When enabled, logon auditing provides an audit trail of who has attempted to log onto the computer.
IIS enabled. IIS is complicated to correctly configure securely, and there are always some users who don't take the time to do this even if they know they should.
Consult the results of the MBSA scan for these and other common errors. You should get back results stating that
No incomplete software update installations were found.
No users have blank or simple passwords.
All hard drives are using the NTFS file system.
Autologin is not configured on the computer.
Guest account is disabled on the computer.
Computer is properly restricting anonymous access.
Logon success and logon failure auditing are both enabled.
IIS is not running on the computer.
Remotely scanning the computer allows you to have a more complete picture of the computer's possible avenues of compromise than just checking everything locally to the host.
There are several great scanners on the market such as eEyes Retina and Tenable Network Security's Nessus scanner. You need to scan your hosts. Auditing a host with a scan for vulnerabilities
Enables you to see the host from the network's perspective
Validates your findings
May show you issues that you didn't find during the onbox audit
This is true for both Windows and Unix systems. Many of these companies offer free trial versions of the scanner prior to purchase. The Nessus scanner is practically free depending on your needs, but you need a Linux host on which to install the scanner. The Retina scanner is particularly easy to use for Windows users. Both have received positive reviews from industry peers. There are also several others out there on the market.
Physical security controls are required usually according to some company policy, and just as important, they help to protect computers from easy physical compromise. There are three common areas for improving physical security inside the building:
Cable locks should be used on laptops.
Users should be logged out of their workstations.
Passwords should not be written down anywhere.
Conduct a random walk-through of the work site once during working hours and once after working hours. During the walk-through, observe the use of cable locks, users logged out of their workstations, and whether or not passwords are written down in plain site.
Cable locks may not be an issue if you have other controls in place, but most companies can relate to the occasional laptop walking off the job site. Cable locks are cheap and a great deterrent to "honest thieves."
Users should show the company some love and log out of their workstations using [Windows] + [L]. This key combination quickly locks the computer and prevents others from walking behind you and using your privileges.
Users quite often write down passwords and place them in readily available or obvious locations. There are too many stories of people who never intended to be dishonest, but then they couldn't resist the "open password" and got into trouble. Consider the use of second-factor authentication tokens or free utilities such as keepass (http://www.keepass.sourceforge.net) that store passwords inside an encrypted vault.