Security Implications of Network Services

Network servers are the portals through which the outside world accesses the information stored on your computer. Every server must:

Determine what information or action the client requests.
Decide whether or not the client is entitled to the information, optionally authenticating the person (or program) on the other side of the network that is requesting service.
Transfer the requested information or perform the desired service.

root privileges. A bug or an intentional back door built into a server can therefore compromise the security of an entire computer, opening the system to any user of the network who is aware of the flaw. Even a relatively innocuous program can be the downfall of an entire computer. Flaws may remain in programs distributed by vendors for many years, only to be uncovered some time in the future.

Furthermore, many UNIX network servers rely on IP numbers or hostnames to authenticate incoming network connections. This approach is fundamentally flawed, as neither the IP protocol nor DNS were designed to be resistant to attack. There have been many reports of computers that have fallen victim to successful IP spoofing attacks or DNS compromise.

Given these factors, you may wish to adopt one or more of the following strategies to protect your servers and data:

Use encryption to protect your data. If it is stolen, the data will do your attacker no good. Furthermore, making alterations in your data that you will not notice will be difficult, if not impossible.
Avoid using passwords and host-based authentication. Instead, rely on tokens, one-time passwords, or cryptographically secure communications.
Use a firewall to isolate your internal network from the outside world.
Disconnect your internal network from the outside world. You can still relay electronic mail between the two networks using UUCP or some other mechanism. Set up separate network workstations to allow people to access the WWW or other Internet services.
Create a second internal network for the most confidential information.

Bringing Up an Internet Server Machine: Step-by-Step

Although every site is unique, you may find the following step-by-step list helpful in bringing up new servers as securely as possible:

Don't physically connect to the network before you perform all of the following steps. Because some network access may be needed to FTP patches, for example, you may need to connect as briefly as possible in single-user mode (so there are no daemons running), fetch what you need, disconnect physically, and then follow steps 2-12.
Erase your computer's hard disk and load a fresh copy of your operating system.
Locate and load all security-related patches. To find the patches, check with both your vendor and with CERT's FTP server, ftp.cert.org.
Modify your computer's /etc/syslog.conf file so that logs are stored both locally and on your organization's logging host.
Configure as few user accounts as necessary. Ideally, users should avoid logging into your Internet server.
If your server is a mail server, then you may wish to have your users read their mail with POP. You will need to create user accounts, but give each user a /bin/nologin (or a shell script that simply prints a "no logins allowed" message) as their shell to prevent logins.
Check all /etc/rc* and other system initialization files, and remove daemons you don't want running. (Usenetstat to see what services are running.)
Look through /etc/inetd.conf and disable all unneeded services. Protect the remaining services with tcpwrapper or a similar program.
Add your own server programs to the system. Make sure that each one is based on the most up-to-date code.
Get and install Tripwire, so you can tell if any files have been modified as the result of a compromise. (See Integrity Management, for details.)
Get and run Tiger to look for other problems.
Monitor your system. Make sure that log files aren't growing out of control. Use the last command to see if people have logged in. Be curious.

Disable all services that you are not sure you need, and put wrappers around the rest to log connections and restrict connectivity.