The purpose of this document is to provide guidelines for best security practices when installing new servers (or reconfiguring old servers) on the ITD campus network. This document is "OS-agnostic". In other words, the specifics of HOW to implement these practices on a particular OS are left to the ITD Server Managers responsible for those servers and operating systems.
It is not the purpose of this document to provide the information necessary to correctly administer a server. It is assumed that the ITD Server Managers responsible for implementing these practices are knowledgeable of the operating system they have chosen, the hardware on which it runs and any applications that they intend to install on it. The ITD Server Manager is expected to already have that expertise or to obtain it before administering servers on the ITD network.
No server should be connected to the ITD network until the following items have been accomplished:
What is the name of the server?
Is this a Physical or Virtual server? (Note: If either physical server or virtual host is required, see ITD Purchasing Procedure for tender process)
Is this a physical to virtual conversion of an existing server [Y/N]?
Application & Operating System Selection / Design
What application(s) will run on the server?
What operating system does the application require
What processor(s) (GHz) does the application require?
What memory (RAM) does the application require?
What hard disk space (gigabytes) does the application require?
Does the server require SAN connectivity [Y/N]?
If yes, please state if a LUN has been allocated [Y/N].
If yes, please state the disk space required (FC or SATA).
If yes, please state whether the server is to be mirrored.
Network & Security (VLAN) Design:
What VLAN is to be assigned?
Define the inter-VLAN access required. Complete the attached form and return with this Pre-Deployment Check List email: http://www2.ul.ie/pdf/449600964.doc (Form to be completed in consultation with CommNet ) and IP address assigned and recorded.
A separate VLAN has been set aside for the purpose of building new servers. Only this VLAN should be used until all patches have been applied.
Has all documentation (licenses, vendor-supplied documents, etc.) been sealed in a lockable plastic bag with details of the server name, server manager and contact details. This documentation to be located in a fire-proof safe.
Has the OS been properly installed and configured and all relevant security patches and anti-virus software applied?
Have all "network application" services not essential to the prime function of the server have been disabled – (HTTP, telnet, FTP, SMTP, DNS, etc?
Have all the services been patched to current levels?
Has a viable plan been designed to maintain the server properly, (including consistent regular patching of the OS and all applications)?
Has ITD’s password policy been adhered to?
Has the server been correctly labelled?
Define the backup / DR policy
Define the power requirements of the server. Every server should be plugged in to an Uninterruptible Power Supply (UPS).
No server should be connected to the ITD network unless it has adhered to the ‘Installation and Patching’ guidelines outlined above.
Every server should have an appropriate name and a fixed IP address.
The appropriate VLAN is assigned
Define the inter-VLAN access that is required.
Only those services necessary to accomplish the task assigned to a server should be enabled. In practice this will mean disabling many services which are enabled by default. The specifics of any particular server are left to the Server Manager to determine.
No servers are allowed to run LDAP, DNS, DHCP, NIS+ or a Windows Domain Controller without prior coordination with Commnet.
Those services that are enabled should have been patched fully and secured properly before being enabled. Consult the vendor's documentation for proper security procedures for the application in question.
If the OS provides a stateful firewall (such as ipchains, iptables, ipfw, etc.), it should be enabled where possible, and only those ports necessary to allow the server to function should be open. If the OS does not provide a stateful firewall, consider purchasing one.
Services which should be restricted, such as ssh, should also have tcpwrappers or a similar program enabled to limit access to authorized personnel only.
ALL default passwords should be changed immediately. The Server Manager should be thoroughly familiar with the OS and all applications and what the password parameters are for each of them. Consult vendor documentation for the details.
Passwords should not be written down anywhere.
Access to administrator passwords should be limited to the smallest number of people necessary to properly maintain the server and access it in case of emergencies. Post Installation Checklist
Once server is deployed by Technology Solutions, the Application Manager must:
Install, configure and test the application software.
If data is to be backed up by Commvault:
Identify the data (folders, files) that need to be backed up (these are specified in the Contents of the Sub-client for the server in the Commcell Console)
Decide on the frequency (weekly, monthly, or quarterly – to disk or tape) of the backup (the frequency determines which Storage Policy is assigned to the Sub-client of the server in the Commcell Console).
Install the Commvault client on the server using this information either directly or by logging an RMS call to the Data Centre Officer, Technology Solutions. If logging an RMS call, specify the server name, the data to be backed up (list of folders, files), the required frequency of the backup (weekly, monthly, or quarterly – to disk or tape).
Has the Storage Policy been selected and set up in CommVault?
Has data been identified for backup and set up on CommVault?
Has the server been added to the Master Server List?
Has the server been set up in Password Manager Pro?
If this is a web server, has the server gone through vulnerability scanning?
This information is sent to the Quality Officer as part of the Change Control procedure.
All servers should have access logging enabled.
Logs should be checked regularly (at least weekly) for unusual access attempts.
Remote logging (sometimes called sysloging) should be enabled.
Remote Access to Servers
If it is determined to be necessary, remote access to servers should be highly restricted.
The use of encryption for remote access is not optional. SSH and VPN should be used.
Remote host access should be limited by single IP or by the smallest IP range possible.
Special attention must be given to remotely accessible machines. Host-based intrusion detection should be installed, logging should be increased, accounts on the server should be limited to responsible administrators only and the server should be syslogged.
Vendor Access to Servers
It is sometimes necessary for external vendors to gain remote access to servers for which they perform maintenance functions (hardware of software), such access will only be via the ITD supplied SSL / VPN system and external vendors will have to request specifically when they wish to gain access.
The electronic version of this document is the latest version. It is the responsibility of the individual to ensure that any paper material is the current version. Printed material is uncontrolled documentation.