Checklist

Checklist: Restrict access to prevent insider hacks

Insiders are often to blame for more computer compromises than outsiders. That means your employees and fellow workers create more havoc for your network than all the malicious people on the Internet. Limit your losses by preventing users from accessing sensitive systems and logging on to machines other than those assigned to them.

WARNING: You can seriously hamper user ability to log on by setting the wrong user rights. Please do the following steps in a test environment.

You may download a printer-friendly version.

Checklist: Restrict access to prevent insider hacks
Step 1: Keep users out of systems that don't concern them.

You'll want to set file permissions, but before you do, quarantine users so they can only access and log on to a limited number of computers. To do so, open their account property pages in Active Directory Users and Computers, select Account tab and click the Log On To button. Next click "The following computer" button, enter the name of a computer the user is allowed to access and click the Add button. If users must have access to multiple desktop computers and laptops, simply add those computer names. This works well when multiple people need to use any one of several computers in a lab or department.

If you want to keep an account from logging on at any computer, just enter the name of a non-existent computer. Setting log-on-to computers does not restrict users from accessing data on other computers across the network. To limit network access, configure user rights.

User rights specify what a user can do on a computer. Set them in the default domain controller Group Policy Object (GPO) to limit access on domain controllers, and in GPOs linked to organizational units when you want to impact a subsection of computers joined in the domain. User rights are located in the GPO under Windows Settings --> Security Settings --> Local Policy --> User Rights Assignment.

Step 2: Restrict rights that directly impact computer access.
User rights configuration is similar to file permission settings; if the right is not granted, the user does not have it. The following rights directly impact access to computers and should be limited.
   •  Access this computer from the network
This right only allows identified user groups access to the computer. By default, the Everyone group has this right, and may not want that. To restrict this right, add groups that should have the right to access the computer, and then remove the Everyone group. Be careful not to lock out service accounts.
   •  Deny access to this computer from the network
Remember, by default, if a user does not have the right to access the computer, he is denied access implicitly. Use this right sparingly to define those accounts that should never, under any circumstances, access the computer from the network. By default, Windows Server 2003 locks out the support_388945a0 account. You could use this right to prevent the local administrator account from being used on the network.
Step 3: Harden log on and deny logon rights.
Be careful handling log on and deny logon rights. Each right has an associated counterpart -- a deny user right. Use deny rights sparingly, usually only to manage those accounts that should never have the right. Follow the table below for recommendations.

User right Meaning Recommendation
Allow log on locally If a user has this right, he can sit at the console and log on. Restrict access to all servers by adding groups that represent those authorized to configure or manage the server. Then remove the users group. Be cautious here. If the machine is a terminal server, locking up local log on is not the choice to make. The SUPPORT_388945a0 account is denied this right.
Allow log on through terminal services If this machine is a terminal server, users need this right. Restrict terminal services to those users who are actually authorized to use the servers.
Log on as a batch job Batch jobs are jobs that run in the background. They are often scheduled with the task scheduler. Limit this right only to accounts that might be used to run these types of jobs -- and then only if the accounts need it. Accounts used for SUPPORT_388945a0, local service and Internet Information Services-related (IUSR, IWAM and IIS) WPG (Microsoft Word for Windows vector graphics) are given this right. Don't remove these groups unless the tasks they perform are no longer necessary on these computers.
Log on as a service Services also run in the background. Limit this right to services that may need it (by default the network service account is given this right). Ordinary users do not need it.

Windows Security Checklists offer you step-by-step advice for planning, setting up and hardening your Windows security infrastructure.
E-mail the editor
to suggest additional checklist topics.


ABOUT THE AUTHOR:   Go back
Roberta Bragg is author of "Hardening Windows systems" and a SearchWindowsSecurity.com resident expert. She is an MCSE, CISSP and Microsoft MVP, and a well-known information systems security consultant, columnist and speaker.

Click to ask Roberta a question or purchase her book here. Also, if you have specific questions or comments about any of Roberta's checklists, click to e-mail her directly. Copyright 2004

Reader Feedback

Allan A. writes: I have a couple of additions to your checklist:

1. Restrict the number of systems to minimize administration and the probability of configuration errors.

2. Train and educate all users to lock their PC when leaving it -- even when they are just leaving for two minutes. Administrators can setup PCs connected to a network to lock after a certain number of minutes. But between the time someone leaves a PC to the time the autolock is activated, another person can easily access files and folders on the network.

This was first published in November 2004

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: