Written by John Jasen and posted to the Old Bay Sage list on June 12, 2002. Reprinted with permission of the author.

Section 1: Network Server Security Considerations

1.A) What security precautions should be taken for a network server?

Advanced instruction on securing equipment and services for deployment on a client network is beyond the scope of this document. Please consult your site security standards, if available, or look into creating them. An excellent introduction to computer and network security, including standards, incident response plans, FAQs, HOWTOs and training can be found on http://www.sans.org/.

However, at the very least, please take these following areas into consideration: physical security; network security; systems hardening; access control; encryption; authentication; logging and log reviews; testing and auditing, and keeping current.

Some of the areas above will overlap. For example, systems hardening can be seen as an extention of network security; access control is both a function of network security and host-based security; etc.

1.A.1) Physical Security

High end servers and workstations are very valuable in and of themselves, let alone the value they add to the business. As such, they must be physically protected from theft, damage, and/or interference. Larger companies generally invest in a 'computer room' with raised floors, UPS power systems, dedicated HVAC, and secured entrances.

1.A.2) Network Security

Any system, no matter how secure it might be on its own, when added to a network becomes as secure as the least secure system on that network. Thus, security needs to be addressed on a network level, on a host level for each individual system deployed, and on the server itself.

Again, instructions on securing border routers, firewalls and other such equipment is beyond the scope of this document, as is discussions on implementing network-based intrusion detection systems (IDS or NIDS) and/or virtual private networks (VPN), access control and/or authentication mechanisms, IPsec and so forth.

1.A.3) Systems Hardening

These are general suggestions. Guidelines for securing most OSes and network equipment can be found on the internet, with a good selection available at http://www.sans.org/.

Again, these are recommendations to consider in comparison to the existing networked environment, not hard and fast rules.

First, turn off services that are not needed. For example, if dhcp isn't used in the environment, the dhcp server and clients should not be running, or even installed.

Second, investigate services that you, the systems administrator, are unsure about. Make a determination as to the function of unknown services, the functionality thereof, and the utility, and from there, react accordingly as to whether it should be kept or disabled.

Third, audit the system for programs and utilities that are not necessary, and/or may pose a security risk. The simplest step on a UNIX system is to look for programs that have either the SUID or SGID bit set, find out what they do, and determine a course of action from there (remove the program? keep it and worry? remove the SUID or SGID bit?)

<p>Fourth, apply the latest vendor updates to the remaining system

installation, and give thought to installing the latest packages from source.

<p>There are also recommendations in encryption, authentication,

logging, and auditing that apply to both host and network security.

1.A.6) Access Control

On a network level, routers and firewalls can sometimes be configured to only allow access or enhanced action after satisfying some criteria (be it via IP address or via authenticating to the network device, or some other method). Again, VPN may be a viable option, depending on the environment.

Some switches can support 'virtual lans' or VLANs, which offer another layer of access control.

On a host level, look into using access control on each of the network services offered on the system. TCPwrappers is a good solution for some services, SSH comes with its own, as do apache httpd, sendmail and a few others.

Some operating systems can be supplemented with host-based firewalls, such as iptables for Linux, ipf for BSD and Solaris, port filtering for Windows 2000, and so forth.

1.A.5) Encryption

On a network level, consider the use of VPN solutions where possible, or consider moving to IPsec or IPv6.

On a host level, attempt to replace unencrypted programs with their encryption-capable alternatives, where possible. For example, telnet and rlogin can be almost completely replaced by SSH products. As another example, web servers can be run unencrypted or through SSL. Mail protocols, such as SMTP, POP and IMAP can be tunnelled through SSL.

1,A.6) Authentication

To sound repetitive, VPN solutions may offer authentication, as well as access control and encryption on a network level.

Use strong authentication where possible for host services. Some protocols, such as NFS, do not provide for authentication, some methods, such as .htaccess files, provide very weak authentication, and some solutions, such as kerberos, offer very strong authentication.

1.A.7) Logs and Log Review

Most operating systems and higher end network devices have some facility to write information to a logging utility. This is very important to do if you ever wish to scan for anomolies, or need to trace back a security incident.

In an ideal network, from a security point of view, all devices on the network would send logged information to a hardened log host, which would massage, parse and mine the information for unusual occurances and/or unauthorized access attempts, and would present the information to the systems administrator and/or the security officer.

Please take time and occasionally review the log files for anomolies, as sometimes they provide the first and only warning of an occuring security incident.

1.A.8) Testing and Auditing

After a networked environment has been implemented with security in mind, it should be tested, to ensure that the tools and proceedures work together, according to plan. For example, if a portscan is run against a system, the portscanner should only detect services that have been deliberately left available if the portscanning system is allowed (via access control) to use that service. Meanwhile, any IDS that has been deployed should detect the portscan attempt and react accordingly, and data should be accumulating on the hardened log host to be discovered during the next parsing session.

Testing is an ongoing task, where periodically, the systems administrator probes the networked environment to match the expected results.

Auditing is also a periodic and ongoing task, where the network and the systems on it are audited, or compared against the documentation stating how they should be configured.

Discrepencies in either testing or auditing should be documented and resolved, either by fixing the system or by updating the documentation.

1.A.9) Keeping Current

New vulnerabilities are being discovered constantly, and vendors frequently release updates for their products in response to them, but they don't protect the business infrastructure unless they are applied in a timely fashion.

For example, Code Red and Nimda were covered extensively in the media and caused a lot of damage, but they were using exploits patched by Microsoft a few months previously!

Please subscribe to vendor security alert mailing lists, locate where updates are available, and frequent those sites regularly.

No Comments | #733

Unless noted, all content on epistolary.org is © Copyright 1999-2008 to Rob Carlson with all rights reserved. All information is verified when possible, cited as appropriate and applied in the real world at your own risk. Send all feedback to rob@vees.net.