Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống
1
/ 12 trang
THÔNG TIN TÀI LIỆU
Thông tin cơ bản
Định dạng
Số trang
12
Dung lượng
311,33 KB
Nội dung
Chapter 17: Windows 2000 Security Issues 331 USER MANAGEMENT The management of users on a Windows 2000 system is critical to the security of the system and the organization. Proper procedures should be in place within the organization to identify the proper permissions each new user should receive. When an employee leaves the organization, procedures should be in place to make sure that the employee loses access rights to the organization’s systems. Adding Users to the System When adding new users to the system, make sure you follow your User Management procedures. These procedures should define who may request new accounts and who may approve these requests. New users are added to a system or domain through the Figure 17-6. Using the Local Security Settings tool to establish account lockout policy Computer Management tool. Select the Users item from Local Users and Groups. Then select New User from the Action menu (see Figure 17-7). As with Windows NT, each user should have a unique user ID and their own account. If two users require the same access, then two accounts should be created and they should be placed in the same group. Under no circumstances should multiple users be given access to the same user ID. Each new user ID should be given an initial password and the User Must Change Password at Next Logon box should be checked. This will force the user to change the password the first time she logs in. Never check the Password Never Expires box. NOTE: Organizations should not use the same password for each new account. While this may sim - plify the task of establishing new accounts, it opens a potential vulnerability on the systems. If a new user account is established before the new employee has joined the organization, the account may be available for use by unauthorized individuals. All that is needed is the standard new user password. It is a better practice to choose strong and unique new user passwords. Once that account has been created, it must be added to the appropriate groups. This can be done by going to each individual group, double-clicking it, and selecting the Add button (see Figure 17-8). Alternatively, you can right-click on the newly created user and 332 Network Security: A Beginner’s Guide Figure 17-7. New User window select Properties. Select the Member Of tab and add the appropriate groups to the list (see Figure 17-9). Standard user accounts should not be part of the Administrator group. Setting File Permissions Groups should be used to set permissions on files and shares. This will allow easier man - agement of file permissions (as opposed to giving individual users permissions to files and shares). Make sure that only the Guest account is a member of the Guests group and that the Guest account is not found in any other group. Removing Users from the System As with adding users to the system, the administrators should follow the User Manage - ment procedures when removing users. When a user leaves an organization, the user’s account should be immediately disabled by using the Computer Management tool. Select the user in question, right-click, and select Properties. This screen will allow you to disable Chapter 17: Windows 2000 Security Issues 333 Figure 17-8. Adding users to groups by using the groups’ list the account. At the same time, the password should be changed to something completely random. This will prevent the user or someone else from using the account. Since it is possible that this user had files or directories that the organization needs, the account should remain disabled for some period of time (30 days is usually appropri - ate) to allow the user’s superior to access these files and copy any that are of interest. If the user was using the EFS, the local Administrator account can be used to access the files. Af - ter 30 days, the account should be removed from the system along with all files and direc - tories that are owned by the account. SYSTEM MANAGEMENT Security is not only important when a system is configured and set up. It is also important in day-to-day operations. Perhaps the best security mechanism is an administrator who is paying attention to his systems. That said, there are several things that can be done with a Windows 2000 system to enhance the ability of the administrator to detect potential secu - rity problems. 334 Network Security: A Beginner’s Guide Figure 17-9. Adding users to groups by using the user Properties screen The Secedit Command Windows 2000 provides a tool called secedit.exe, which can be used to manage the secu - rity policy on a large number of systems. Secedit provides the following capabilities: ▼ Analysis The policy on the system in question is analyzed and compared to a provided policy. ■ Configuration The policy on the system in question is changed to match a provided policy. ■ Validation A security configuration file can be validated. ■ Refresh A policy is reapplied to a system. ▲ Export A stored template from a security database on a system is exported as a security template file. In the following sections, we will take a look at how these capabilities can be used to manage the security of Windows 2000 systems. Analysis Secedit can be used to compare an existing policy running on a Windows 2000 system with an appropriate policy for the system. To do this, enter the following command from a command prompt: secedit /analyze [/DB filename] [/CFG filename] [/log filename] [/verbose] [/quiet] The following parameters may be provided: ▼ /DB filename This specifies the path to the database file that contains the stored configuration for the analysis. If the filename specifies a new file, the /CFG parameter must also be used. ■ /CFG filename This specifies the path to the security template to be imported into the database. If the parameter is not used, the configuration stored in the database is used. ■ /log filename This specifies the path to the log file that will be created by the command. The log file includes all the information found during the analysis. ■ /verbose This tells secedit to provide details while running. ▲ /quiet This tells secedit not to provide output to the screen while running. Once the run is completed, the log file can be analyzed to determine if the system is in compliance with the organization’s policy. Chapter 17: Windows 2000 Security Issues 335 336 Network Security: A Beginner’s Guide Configuration Secedit can also be used to configure a system. The command syntax for this operation is secedit /configure [/DB filename] [/CFG filename] [/overwrite] [/areas area1 area2…] [/log filename] [/verbose] [/quiet] The following parameters may be provided: ▼ /DB filename This specifies the path to the database file containing the template to be used. ■ /CFG filename This specifies the path to a security template that can be imported into the database and then applied to the system. ■ /overwrite This specifies that the policy in the security template identified by the /CFG command should overwrite the policy in the database. ■ /areas This specifies the security areas of the template that are to be applied to the system. The areas may be: Securitypolicy, Group_mgmt, User_rights, Regkeys, Filestore, Services. If no areas are specified, the default is all areas. ■ /log filename This specifies the path to the log file that will be created by the command. ■ /verbose This tells secedit to provide details while running. ▲ /quiet This tells secedit not to provide output to the screen while running. This command can be used to force a particular security configuration on a system. Validation Secedit can be used to validate a configuration file. This validation makes sure the file syntax is correct. The command to perform this operation is secedit /validate filename Refresh The refresh option of secedit provides a mechanism to refresh the system security policy. This command reapplies the security policy to the local machine. The syntax for the com - mand is secedit /refreshpolicy [machine_policy or user_policy] [/enforce] The following parameters may be provided: ▼ machine_policy This specifies that the security policy for the local machine should be refreshed. ■ user_policy This specifies that the security settings for the local user that is currently logged into the system should be refreshed. ▲ /enforce This specifies that the policy should be refreshed even if there have been no changes. Chapter 17: Windows 2000 Security Issues 337 This command can be used to make sure the system is using the appropriate security policy. Export Secedit can be used to export a configuration from a security database to a security tem - plate. This allows the security template to be used on other computers. The command to do this is secedit /export [/MergedPolicy] [/DB filename] [/CFG filename] [/areas area1 area2…] [/log filename] [/verbose] [/quiet] The following parameters may be provided: ▼ /MergedPolicy This specifies that secedit should export both the domain and local policies. ■ /DB filename This specifies the path to the database file that contains the stored configuration to be exported. ■ /CFG filename This specifies the path where the security template is to be saved. ■ /areas This specifies the security areas of the template to be exported. The areas may be: Securitypolicy, Group_mgmt, User_rights, Regkeys, Filestore, Services. If no areas are specified, the default is all areas. ■ /log filename This specifies the path to the log file for the command. ■ /verbose This tells secedit to provide details while running. ▲ /quiet This tells secedit not to provide output to the screen while running. The output of this command could be used with other commands to make sure the same policy is in place across an entire domain. Auditing a System All Windows 2000 systems should have system auditing turned on. The audit policy on a system is established by using the Local Security Settings tool (see Figure 17-10). Select the event that you wish to audit and double-click to bring up the configuration window. The audit policy should be set according to the organization’s security policy. Gen - erally, it is a good idea to capture the following events: ▼ Audit Account Logon Events, success and failure ■ Audit Account Management, success and failure ■ Audit Logon Events, success and failure ■ Audit Object Access, failure ■ Audit Policy Change, success and failure ■ Audit Privilege Use, failure ▲ Audit System Events, success and failure 338 Network Security: A Beginner’s Guide NOTE: Audit Object Access may generate a significant amount of audit entries even if only the fail - ure event is turned on. Monitor a new system carefully to make sure the event logs are not filling up be - cause of this. Log Files Audit log entries on a Windows 2000 system are written to the security event log, which is located in \%systemroot%\system32\config. The permissions on the security event log limit access to administrators. Administrators should look at the log files on a regular ba - sis. Since the log files are the best location to see if something may be wrong with a system or if a user is attempting to do something inappropriate, if the administrators do not ex - amine the log files, there is no sense in capturing the information (see the next section “Looking for Suspicious Signs” for what to look for). If the system is being backed up on a regular basis, the log files should also be backed up. If the event logs need to be kept for longer periods of time, it may be appropriate to Figure 17-10. Establishing an audit policy on a Windows 2000 system move the event log files off the system periodically. The files can be saved as text files or in a comma-delimited format by choosing Save As from the Action menu in the Event Viewer. Looking for Suspicious Signs There are several indications that something on a Windows 2000 system might not be quite right or that someone may be doing something he should not be doing. Brute-Force Attempts If someone is attempting to guess account passwords (manually or through the use of an automated tool), the security event log will have entries showing failed login attempts. In addition, if the system has been configured to lock out accounts after a certain number of failed login attempts, there will be a number of accounts that are locked out. Failed login attempt messages in the security event log will provide the name of the workstation where the attempt originated. This workstation should form the beginning of your inves - tigation to determine why the failed login attempts were occurring. NOTE: The type of investigation that is begun should depend upon the source of the attempts. If the source is internal, it may be appropriate to find the employee who uses that workstation and speak with her. If the source is external, it may be appropriate to block access from the source IP address at the firewall. Access Failures Access failures may indicate an authorized user who is attempting to access sensitive files. Some single failures may be innocent mistakes. If you find a single user who has logged access failures on a large number of files or directories, there is cause to ask why the attempts were being made. NOTE: The information in the security event log provides a record of the failed attempts. It does not constitute proof that a particular employee was attempting to gain unauthorized access to information. These log messages can be generated by processes that are attempting access without the user’s knowledge or they could be generated by someone using the user’s account or system. Never assume that the log records provide sufficient proof to accuse an employee of inappropriate actions. Missing Log Files or Gaps in the Log Files On a working Windows 2000 system that has audit turned on, the event logs should never be empty. Many intruders empty log files as soon as they enter a system in the hopes of hiding their tracks. If you find an empty log file, you should immediately as - sume that something is wrong with the system and investigate why the logs are empty. You may find that another administrator chose to empty the log files because they were very large. However, you may also find that the system has been compromised. Chapter 17: Windows 2000 Security Issues 339 More recently, tools have appeared that allow intruders to modify particular entries in the log files. If an intruder attempts to do this, you may find a gap in the log file. To spot the gap, simply look for larger than normal time spaces between log entries. If you see large gaps, investigate the reason. Keep in mind that the system does not make log entries when it is turned off. In this case, you should see a shutdown and startup entry around the gap. Unknown Processes Lots of processes run on Windows 2000 systems. Some of them are easy to figure out and some are not. If you look at the Task Manager (see Figure 17-11), you can see the processes that are running and how much CPU and memory they are using. System administrators should periodically examine the Task Manager to see if any unknown processes are running. A good example of something to look for is CMD pro - cesses. The CMD process is the command prompt or DOS Window. If it is running, you should be able to see a window on the screen. In some cases, an intruder will cause a CMD process to start in order to perform other operations on the system. This is a clear in - dication that something unusual is happening on the system. 340 Network Security: A Beginner’s Guide Figure 17-11. The Windows 2000 Task Manager TEAMFLY Team-Fly ® [...].. .PART V Appendixes Copyright 2001 The McGraw-Hill Companies, Inc Click Here for Terms of Use 341 This page intentionally left blank . add the appropriate groups to the list (see Figure 17-9). Standard user accounts should not be part of the Administrator group. Setting File Permissions Groups should be used to set permissions. secedit not to provide output to the screen while running. This command can be used to force a particular security configuration on a system. Validation Secedit can be used to validate a configuration. security event log provides a record of the failed attempts. It does not constitute proof that a particular employee was attempting to gain unauthorized access to information. These log messages