CSU Windows Security Group – Securing Windows Server Tasks
Draft 6 – May 20 , 2005
This is a draft prepared by the campus Windows Security Group, which is a sub group of the campus Windows group. It is a cut and paste of separate documents so the formatting is not yet consistent. It is intended to give an overview of the direction the group is taking and to solicit feedback. The intent of this document is to outline basic security steps that the average IT administrator can quickly take to increase the security of their Windows servers. The Windows Security Group plans to host brown bag training sessions throughout Spring 2005 to help administrators master the skills needed to implement these recommendations.
Windows Security Tasks
I. Auditing
II. Physical Security
III. Setup and Patching
IV. Account Management*
V. Restrict Anonymous Access & NTLM Authentication
* One item under Account Management, strong passwords, is now a mandatory requirement under CSU’s Campus IT Security Policy.
I. Auditing
If no auditing is configured, it will be difficult or impossible to determine what took place during a security incident. However, if auditing is configured so that too many authorized activities generate events, the security event log will fill up with useless data. Audit events A-E below typically do not generate large amounts of logs and should be set as recommended by all IT administrators. Audit events F-I will generate large amounts of information and will often fill up the logs, therefore it is recommended that these only be set when detailed logging is required (i.e., under attack, etc.)
The following values can be configured in the Domain Group Policy section of Windows Server 2000/2003 at the following location:
Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy
A. Audit login = S uccess, F ailure (Recommended settings)
The Audit account logon events setting determines whether to audit each instance of a user logging on to or off another computer that validates the account. Authenticating a domain user account on a domain controller generates an account logon event. The event is logged in the domain controller's security log. Authenticating a local user on a local computer generates a logon event. The event is logged in the local security log. There are no Account logoff events logged.
Can be implemented with GPO’s: YES
B. Audit account management = S uccess, F ailure (Recommended settings)
The Audit account management setting determines whether to audit each account management event on a computer. Examples of account management events include:
· A user account or group is created, changed, or deleted.
· A user account is renamed, disabled, or enabled.
· A password is set or changed.
Organizations need to be able to determine who has created, modified, or deleted both domain and local accounts. Unauthorized changes could indicate mistaken changes made by an administrator who does not understand how to follow corporate policies or a deliberate attack.
Can be implemented with GPO’s: YES
C. Audit logon events = S uccess, F ailure (Recommended settings)
The Audit logon events setting determine whether to audit each instance of a user logging on to or off of a computer. Records are generated from the Account logon events setting on domain controllers to monitor domain account activity and on local computers to monitor local account activity.
Configuring the Audit logon events setting to No auditing makes it difficult or impossible to determine which user has either logged on or attempted to log on to computers in the enterprise. Enabling the Success value for the Auditing logon events setting on a domain member will generate an event each time that someone logs on to the system regardless of where the accounts reside on the system. If the user logs on to
a local account, and the Audit account logon events setting is Enabled, the user logon will generate two events. There will be no audit record evidence available for analysis after a security incident takes place if the values for this setting are not configured to Success and Failure.
Can be implemented with GPO’s: YES
D. Audit policy change = Failure (Recommended settings)
The Audit policy change setting determines whether to audit every incident of a change to user rights assignment policies, audit policies, or trust policies. This includes making changes to the audit policy itself.
Configuring this setting to Success generates an audit entry for each successful change to user rights assignment policies, audit policies, or trust policies. Configuring this setting to Failure generates an audit entry for each failed change to user rights assignment policies, audit policies, or trust policies.
Can be implemented with GPO’s: YES
E. Audit system events = S uccess , Failure (Recommended settings)
The Audit system events setting determines whether to audit when a user restarts or shuts down a computer or when an event occurs that affects either the system security or the security log. Configuring this setting to Success generates an audit entry when a system event is executed successfully.
Can be implemented with GPO’s: YES
These recommendations marked with an * identify those settings that will generate a significant amount of log entries.
Audit events F-I will generate large amounts of information and will often fill up the logs, therefore it is recommended that these only be set when detailed logging is required (i.e., under attack, etc.).
F. Audit directory service access = Failure* (Recommended settings)
The Audit directory service access setting determines whether to audit the event of a user accessing a Microsoft Active Directory service object that has its own system access control list (SACL) specified. Setting Audit directory service access to No Auditing makes it difficult or impossible to determine what Active Directory objects may have been compromised during a security incident. There will be no audit record
evidence available for analysis after a security incident if the values for this setting are not set to Success and Failure.
Can be implemented with GPO’s: YES
G. Audit object access = Failure* (Recommended settings)
By itself, this setting will not cause any events to be audited. The Audit object access setting determines whether to audit the event of a user accessing an object — for example, a file, folder, registry key, printer, and so forth — that has a specified SACL.
A SACL is comprised of access control entries (ACEs). Each ACE contains three pieces
· The security principal (user, computer, or group) to be audited.
· The specific access type to be audited, called an access mask.
· A flag to indicate whether to audit failed access events, successful access events,
Configuring this setting to Success generates an audit entry each time that a user successfully accesses an object with a specified SACL. Configuring this setting to Failure generates an audit entry each time that a user unsuccessfully attempts to access an object with a specified SACL.
Corporations should define only the actions they want enabled when configuring SACLs. For example, you might want to enable the Write and Append Data auditing setting on executable files to track the replacement or changes to those files, which computer viruses, worms, and Trojan horses will commonly cause. Similarly, you might want to track changes to or even the reading of sensitive documents.
Can be implemented with GPO’s: YES
H. Audit privilege use = Failure* (Recommended settings)
The Audit privilege use setting determines whether to audit each instance of a user exercising a user right. Configuring this value to Success generates an audit entry each time that a user right is exercised successfully. Configuring this value to Failure generates an audit entry each time that a user right is exercised unsuccessfully.
Can be implemented with GPO’s: YES
I . Audit process tracking = No auditing* (Recommended settings)
The Audit process tracking setting determines whether to audit detailed tracking information for events such as program activation, process exit, handle duplication, and indirect object access. Configuring this setting to Success generates an audit entry each time the process being tracked succeeds. Configuring this setting to Failure generates an audit entry each time the process being tracked fails.
Enabling Audit process tracking will generate a large number of events, so typically it is set to No A uditing. However, these settings can provide a great benefit during an incident response from the detailed log of the processes started and the time when they were launched.
Can be implemented with GPO’s: YES
J. Maximum application log size = 16384 kilobytes
Restrict guest access to application log = enabled
Retention method for application log = As Needed
K. Maximum security log size = 81920 kilobytes
Restrict guest access to security log = enabled
Retention method for security log = As Needed
L. Maximum system log size = 16384 kilobytes
Restrict guest access to system log = enabled
Retention method for system log = As Needed
The log size is a Microsoft recommendation; this value can certainly be changed. The retention method is set to overwrite events as needed. This will keep the logs from filling up and displaying error messages on servers.
Can be implemented with GPO’s: YES
II. Physical Security
Per CSU’s IT Security Policy General IT Security Policies and Guidelines, “servers shall be housed in a physically secure facility where access is limited to only those individuals requiring access to perform routine or emergency maintenance on the system.”
III. Setup and Patching
Following these guidelines will allow you to build and maintain a Windows server that is relatively secure. Windows 2003 server should be installed unless there is a compatibility issue. In place upgrades are discouraged. We recommend adding BIOS password protection and turning off unnecessary ports such as USB, serial, and parallel unless needed. We also recommend that the boot order be modified on Domain Controllers to boot from the operating system volume first and disable booting from PXE and USB.
A. Automate the install process to ensure consistent, complete security. – Create a process document to outline the installation process to insure consistency of server builds. Use Ghost or other imaging techniques, if possible, to have a consistent build process.
Can be implemented with GPO’s: N O
B. Format all partitions as NTFS volumes. – Security is better on an NTFS volume than a FAT volume. Recommended boot drive size is 15-20 GB.
Can be implemented with GPO’s: N O
C. Install operating system while the server is disconnected from the network. – Obtain a CD with the latest operating system version and service packs from Software Cellar. This will mean less patching after the initial install.
Can be implemented with GPO’s: N O
D. Only install TCP/IP for the network transport. – This follows with only installing necessary services.
Can be implemented with GPO’s: N O
E. Do not install SMTP unless necessary. - This follows with only installing necessary services.
Can be implemented with GPO’s: N O
F. Do not install IIS on Domain Controllers. – We recommend that you do not install IIS on anything that isn’t a web server. This follows with only installing necessary services.
Can be implemented with GPO’s: YES
G. Only enable required services. – See Appendix A “Windows 2003 Server Baseline Services Settings” for a list of services and how Microsoft recommends they should be set for baseline servers. You should test any changes in your environment to be sure they work for you.
· Save a list of original Service States – you can export an existing state of the services list before making changes. Use this list as a reference to get back your original configuration in the event of a conflict. Right-Click on Services in the MMC and chose Export List.
Can be implemented with GPO’s: Y ES
The following is a list of additional services which may need to be enabled for various server roles beyond the baseline table in Appendix A. Services can be managed with GPOs with an appropriate OU structure. For example, an Exchange server placed in its own OU can then have Exchange-specific GPOs applied.
Citrix
Terminal Services Licensing
DHCP Server
DHCP Server
Exchange
HTTP SSL
IIS Admin Service
Microsoft POP3 Service
Network News Transfer Protocol (NNTP)
Simple Mail Transport Protocol (SMTP)
World Wide Web Publishing Service
Internet Authentication Server
Internet Authentication Service
Internet Information Server (IIS)
ASP .NET State Service
Distributed Transaction Coordinator
FTP Publishing Service
HTTP SSL
IIS Admin Service
Indexing Service
Simple Mail Transport Protocol (SMTP)
World Wide Web Publishing Service
Remote Installation Server (RIS)
Single Instance Storage Groveler
Trivial FTP Daemon
SQL
Distributed Transaction Coordinator
MSSQLServer
MSSQLServerADHelper
SQLSERVERAGENT
OTHER
Many 3rd party applications require additional services such as Dell OpenManage, Symantec System Center, Symantec Ghost, Webroot SpySweeper, etc.
H. Run anti-virus on all servers. – We recommend this unless you have a known conflict. Test the anti-virus software thoroughly before putting the server into a production environment.
Can be implemented with GPO’s: N O
I. Apply all current service packs and hot fixes and keep up to date. – Connect the server to a firewall before trying to download service packs and hotfixes. This will protect your server from being compromised while obtaining the critical updates. Installing from the most current version of Windows media will cut down on the number of critical updates you will need to download.
Can be implemented with GPO’s: N O
J. Automate an d audit service pack and hot fix levels. – We recommend that you subscribe to Microsoft security bulletins and other popular IT security bulletins. Test service packs and critical updates prior to deploying in a production environment. Hotfixes have a high priority and should be applied no later than when ACNS releases them to their Security Update Server (SUS). Consider building your own SUS server or use the ACNS SUS server for automated critical hotfix updates. Do not lag behind the ACNS SUS server. ACNS maintains a listserv for SUS administrators. To join the list go to: ostate.edu/Services/ACNS/listserv/subother.html and select the SUSADMINS list.
Can be implemented with GPO’s: N O
K. Prevent local guests from accessing application and system logs. – Local guest accounts should not have access to the application and system logs.
Can be implemented with GPO’s: YES
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Event log: Application log SDDL