Procedure
|
Rationale
|
Physical Security Procedures
| |
| * Keep systems in a secure office or preferably a dedicated room. | No-one but system administrators should have direct access to your servers. Dedicated server rooms are generally necessary for larger infrastructures for proper air conditioned environments. |
| Disable booting from diskette, optical drives, & USB devices. | Prevents the booting of the system with another OS and attacking the file system (e.g. password changers). NB this is less of an issue if a secure server room is used. |
| Password System CMOS/BIOS | Prevents reversal of step immediately above. |
| Consider disabling unused hardware device ports. | Can be used to attach unauthorised devices. |
| * Review backup policies and procedures | Hardware (and software) can fail, ALWAYS make backups of important data and store the tapes in a fireproof safe and preferably not in the same location as the server. |
| * Check and review restore procedures. | Backups are useless if you cannot restore the data and restore it in a timely manner. Make sure that you can restore all data and in sensible sized segments. |
| * Use Separate Discs for system and data. | The system should be installed on a separate disc from your data - if the system fails (it will eventually) the data should not be affected in any way. Allows restoration of system without having to restore data which is normally much more time consuming. |
| * Provide redundancy. | You should be prepared for the worst, always! Expect a server to fail and have a plan for what you will so when it does. See; Disaster Planning and Strategy for Windows Domains |
| * Ensure a UPS is on all critical Servers and make sure that they can shutdown cleanly. | If there is a power failure it will enable you to perform a normal shutdown, rather than a rough (and possibly damaging) shutdown. If at all possible the system should be capable of shutting down automatically before the UPS runs out if power has not been restored. |
Operating System Procedures
| |
| * Apply the latest Service Pack | Service packs contain or enable security (and bug) fixes |
| * Apply the latest post-service pack hotfixes |
Hotfixes address security issues - Currently Microsoft release these on the second Tuesday of every month and can also release additional emergency patches.
There are very few reasons to not update your systems.
|
| * Use Group Policy and Domain security polices to secure the Domain and your systems. | There are a large number of possible security enhancements and restrictions you can make using Group Policy and the Domain Security Policys, including using complex passwords and minimum password length, restricting anonymous access to user & share names etc. Some examples are listed below for recommended settings |
| * Security Options - Network Access | Allow anonymous SID/Name translation [Disabled] : Do not allow anonymous enumeration of SAM accounts and shares [Enabled] : (Now default on modern versions of Windows Server) |
| * Security Options - Network Security |
Do not store LAN Manager hash value on next password change [Enabled] : NOTE : This setting will require all existing passwords to be changed to take effect.
(Now default on modern versions of Windows Server)
|
| Security Options - Recovery Console | Allow floppycopy and access to all drives [Enabled] |
Disable Autorun
| Malware which spreads by the autorun feature is still prevalent. Seehttp://support.microsoft.com/kb/967715/ to disable. |
| Limit the number of running Services and if possible make them run under a less privileged account than the 'system' account. |
Reduce the number of exploitable services. If a service is compromised a hacker will have the same level of privilege as the service, you can limit the immediate damage if a service is compromised and it is running in a less privileged account as it also requires the hacker to escalate their rights. This is particularly important for applications which should not need full system privileges.
|
Account Related Procedures
| |
| * Set account lockout after X number of failed attempts (3-5 recommended) | Helps prevent dictionary attacks on all acounts (including Administrator), you can still logon as Administrator locally when the account is locked out, just not remotely |
| * Make Administrative passwords very complex and minimum length 15 | Slows dictionary attacks and makes brute force attacks harder. |
| * Keep guest account disabled | Guest is one of the two built-in accounts which cannot be deleted. The Guest account provides a known, unprivileged account which can be attacked. Disabling the account removes this vulnerability (Windows 2000 and later all come with this account disabled by default) |
| * Create Global Groups for all classes of user privilege, and assign users to groups. Never assign a right or permission to an individual user - always use a group, even if it is for one account only | Rights assigned to individual users can be overlooked. It is easier to review group membership than to audit every single user's rights. |
| * Set Account/Group Policies | Ensure strict control over what users can do on a system |
| Password Restrictions | Make sure passwords are enforced to a good standard (see below) |
| * Minimum Password Age (14) | Passwords should not be changed frequently, can cover hacking activity and encourages users to use simple and easy to remember passwords. |
| * Minimum Password Length (8) | Longer passwords are harder to crack (and guess). For users with more access increase password length |
| * Users should be encouraged to use complex passwords, but allow them to write it down and don't implement frequent changes. Just make sure passwords are not left on open display. | Users will try to use as simple a password as possible which should be discouraged. Forcing users to change complex passwords frequently is normally very unhelpful. The strength of the password is more important that a frequently changed weak password. Passwords can be written down so long as they are not left on a post-it note on the monitor. Storage in a locked draw is suitable. |
| *Password Uniqueness (5) | Do not allow the same password to be used for five consecutive changes. |
| * Enable Account Lockout: Lockout after x bad logon attempts (3-5) | Helps prevent or slow down high-speed dictionary/brute attacks |
| Reset Count after x minutes (60 minimum) | Helps prevent or slow down high-speed dictionary/brute attacks |
| Lockout duration field (60 minimum) | Helps prevent or slow down high-speed dictionary/brute attacks |
| Set logon hours. | Systems should be idle over night, and most users do not need to login at midnight. This makes hacker activity easier to spot and limit accessible accounts. Preferably encourage shutdown of desktop systems. |
| Other: Forcibly disconnects remote users from server when logon hours expire | Enabled hacker activity to be seen clearly, prevents compromised accounts being used out of hours when direct observation is not possible. |
Set User Rights Policies
| |
| Set Auditing Policies (Success/Failure) for the following: | Lots of failed logon attempts can indicate a hacking attack |
| Logon and Logoff | Important for tracking user logons look for strange logon times in the log (is 3 am a common working time?) |
| File and Object Access | Lets you check to see if users NOT authorised to use applications and access files are doing so |
| * Remove any old/unused/unnecessary user accounts | Old accounts should be disabled as soon as is practical after someone leaves. |
| |
| * Check user accounts for any disabled accounts (why are they disabled, and can they be deleted?) | |
| Check logon hours | Restrict logon hours to reasonable working hours. |
| * Check Profile Directory (Delete profiles for old users) | No need to store or have available on network |
| Check the Logon To | Does user need access to all computers or only a few? If limited access required make sure this is the case. |
| Set account expirations for graduating students, temp employees or any temporary account | Helps ensure that accounts are not active once a user has left. |
| Periodically evaluate Operator and Administrator Group members | Makes sure that correct users have access, additional or unexpected users can indicate security issues. |
| All Administrators should have 2 accounts, one for administrative and one for normal usage. Only use Administrative when necessary | For day to day use its not necessary to use Administrator privileges. |
| * When taking over a system or when a member of IT staff leaves change administrative password immediately | Passwords should be changed for any common accounts if a member of staff leaves. |
| |
File System Procedures
| |
| * Format all volumes as NTFS | You can only set file system permissions on NTFS volumes, FAT systems have no security. |
| * Set ACLs on file system | Control access to folders and files as necessary, do not just give blanket access to a whole shared area with full control rights. |
| * Set User Rights | Ensure users only have access to the shares files and folders they need. |
| Set Audits - Enable individual Directory auditing if necessary. | Useful for tracking access and usage of files and resources. Can cause a lot of logging. |
| * On Application servers, Programs and Data should be in different locations. | Data should always be isolated from OS and Applications and be backed up and restorable as such. |
| * Never share the root directory of a drive, except for CD-ROMS | Access should be restricted, VERY dangerous if you share the root of the drive where the OS is installed, otherwise just dangerous! |
| * Periodically check all file share permissions for correctness | Useful for tracking possible compromise internally and externally. |
Notes for Internet Information Server (IIS)
| |
| * If using Active X controls make sure they are correctly secured. It is very easy to write insecure IIS and IE Active X (and other) components. | Badly written Active X components are a very common source of entry to IIS systems. |
| Set appropriate virtual directory permissions | |
| Do not accept defaults for data directory | Store the web site on a different volume from the OS |
Other Updates and Maintenance
| |
| * Keep up to date with patches! | All software will (probably) need updating for security and bug fixes. This means allsoftware. Browser plug-ins are especially susceptable to security problems, as are the web browsers, but all software you have should be updated. Most vendors have email alerts and similar options for being alerted to updates, use them. |
| * Update BIOS and Firmware | *System BIOS and associated firmwares (such as for SCSI cards) often have updates and fixes. You should keep these up to date |
Network & Infrastructure
| |
| Use Private IP addresses. | If a system doesnt need to be contactable from outside your own network or the CUDN use a private IP address to restrict access. |
| Keep externally accessible services isolated from the general network (Create a DMZ). | Also known as defending in depth. If a server or service is accessible from outside the CUDN, put it on an IP range separate from your internal machines. If the external service machine is compromised the machine will not be on the same network as your other machines. In practice this is easier to achieve by putting your internal devices on a private IP range and making them less accessible from outside the CUDN. |
| *Use a firewall/portblocking on exposed servers to protect non service ports. | There is no point in exposing ports such as 445 (Windows Logon) to systems which do not need it. Any server which is exposed (to the internet especially but even within the CUDN) should be isolated to your own IP ranges only
http://www.ucs.cam.ac.uk/support/windows-support/winsuptech/srvrsecchk |
