Designing Security for Network Management in Visual C#.NET

Creation Quick Response Code in Visual C#.NET Designing Security for Network Management

4

Always use administrative workstations for administration. These stations are locked down and protected, so there is less risk of introducing malware or of exposing sensitive systems or information about sensitive systems than when using unprotected workstations. Furthermore, accounts with administrative privi leges should be used only to log on to computers that have known trust states. Never reduce security for convenience. Security might mean extra work is involved in the administrative process, but security is established for a reason and should not be reduced without serious consideration. The competing pressures of demands for increased performance, efficiency, ease of access, and many others can tempt the administrator to change security practices. For example, persistently storing passwords for Web applications might be convenient, but it also introduces a new threat to the network. When possible, take systems offline to troubleshoot them. If you cannot take the system offline, take steps to reduce the risks associated with changes that might be made or tools that might be used to troubleshoot these systems. Never log on to a computer that you believe might have been compromised while it is attached to the network. You cannot trust a computer that has been compromised. Do not add troubleshooting tools to servers. Where possible, use external tools. Where tools must be loaded directly on the server, remove tools after prob lems are resolved. Use administrative tools that can be secured, and use their security fea tures. If tools cannot be secured, use additional security practices to secure their operations. For example, use IPSec to secure telnet sessions.

A few months ago, I was doing some work for a public school system. The LAN administrator was concerned because it appeared as if a student had obtained his password and used it to attempt to change a grade. The administrator couldn t fig ure out how the student did this because he never wrote his password down or used it when students were present. When questioned, the administrator told me that he had to frequently work on the student lab computers because students are constantly attempting and sometimes succeeding to add software, change settings, and so forth. To make some changes, he had to log on using his administrative account. At this point, his face brightened and then twisted with a strange smile. Keystroke logger, he remarked. Later that week, the administrator told me that when he asked the student why he used a keystroke logger and recorded the administrator password, the student confessed and produced the device used. The administrator now monitors the lab computers for evidence of tampering and manages them remotely.

4-27

Many administrative tools are snap-ins for the Microsoft Management Console (MMC). Other administrative tools are special administrative programs designed for a specific program or service. Still others are command-line tools that are either installed by default, provided as part of the support tools collection on the Windows Server 2003 installation disk, or provided as part of the Windows Server 2003 Resource Kit. Part of securing administrative practices is to secure the use of administrative tools. This con sists of making sound choices in the tools that are used, in using their security features appropriately, and in adding security where necessary. The following sections describe the guidelines for securing the use of administrative tools. Secure Administrative Tools In addition to specifying practices for securing individual tools, you should take the following precautions:

Install tools only when necessary. If a tool is not necessary and not installed by default, don t install it. Think of auxiliary tools as you would the wide array of services that might be used on a specific computer. Restrict access by setting Access Control Entries (ACEs). Where tools must exist, limit their use by controlling access. Reduce access to a particular tool to only those who need to use it. Disable or restrict features of tools. Understand the risk of using specific tool parts, and reduce the risk by disabling unnecessary parts if possible. Control access by disallowing remote access. Performing administration from the console reduces the risks involved with those activities because no infor mation can be gained, nor credentials captured, over the network. In addition, remote access provides a way for an attacker to attempt to compromise the system or some part of it, and doing so is easy if the attacker has the proper credentials. If an attacker must go to a datacenter, however, he will have a harder time using these credentials without being discovered. Provide a secure communication channel. Requiring SSL or IPSec to protect communications between the administrator s workstation and the server will prevent many types of attacks. Specify that all administration either take place at the console, via a hardened and trusted computer on the LAN, or via a VPN. Making a dis tinction between internal computers and external computers or between spe cially prepared systems and those that are not can reduce the risks associated with administration. Use administrative accounts only for administration. Use runas to tempo rarily authenticate using the privileged account to run administrative tools.

4-28