Security Issues

---

No computer system is more important than the data it processes and stores, and so it's just as important to protect that data from theft as from damage. This section outlines some security-related issues related to this case study system. As you read this section, it's important that you keep in mind your own situation, because unless your environment is exactly like this one, you'll have to adapt the details to your own situation.

Understanding the Local Network's Security

Securing a computer workstation that is a part of a complex network such as the case study system is rather different than securing an individual, home desktop system (such as the case study discussed in Chapter 14). After all, when the system relies so much on the configurations and correctness of other systems and software, it becomes vulnerable to the weaknesses in those programs and systems.

This case study uses the Network Filesystem (NFS) to store users' data and the Network Information Services (NIS) to authenticate users and log them into the system. Each of these tools is extremely valuable, but the tradeoff is that they can reduce the security of the system.

In the case of NIS, the workstation is essentially a slave to the NIS server. This means that if an attacker compromises the NIS domain servers, that attacker will have access to any and all servers and workstations that are configured to authenticate with NIS. In the industry jargon, this is a "single point of failure", and it is to be feared much. However, it is a necessary evil.

NFS can also be a single point of failure; if the file server on which the users' data is stored is compromised, then all the users' data is available to the attacker. However, even if the NFS server itself is completely secure, the NFS clients can still be made vulnerable. For example, being an NFS client (such as this workstation case study) requires the portmap and nfs.statd services. These services have a history of security vulnerabilities, and so running them exposes the workstations themselves to attack, possibly even in cases where the server itself is secure.

Unfortunately, there isn't much the workstations can do about these situations. The value of NIS and NFS (that is, the value of centralized management and data storage) outweigh the security risks. Additionally, most such networks are protected by a firewall. The firewall will prevent casual attacks from the Internet, but it will not protect against a determined intruder who gains access some other way, such as through a wireless network or simple deception. (For more information on this topic, you may wish to read the next chapter, Chapter 16, which presents a firewall case study.)

In other words, in the case study's network environment, the workstations are only as secure as the servers and the software they run. Unfortunately, there isn't much else you as the administrator of a single workstation can do. If your own environment uses different software (such as Kerberos instead of NIS and AFS instead of NFS), then your security issues will also be different. This isn't a book on security, so there isn't room to say more than this: Know your network, and even if you can't secure it entirely, know what you can and can't secure.

Securing the Workstation

Given the constraints imposed by the network environment, the individual workstation in this case study can only be secured to a degree. However, it still pays to take some rudimentary precautions, which this section outlines. The main objective in securing your workstation is just this: Make sure your workstation isn't the one that lets an attacker compromise the network. Two basic tasks will go a long way toward keeping your workstation secure: Keep your software up-to-date, and don't disable the firewall.

The primary mode of attack against systems is exploits against known bugs in software. The only defense against this is to make sure that the software you run isn't the same version that the attackers are trying to exploit. That means that keeping your system secure is an ongoing process, and you have to follow the updates released for your distribution to make sure you upgrade to a bug-free version as soon as exploits are discovered and repaired.

One way to help reduce your system's vulnerability to attacks—even if exploits are discovered—is to keep the system's local firewall running. (Red Hat Linux 7.3, for example, includes a configuration that applies a "personal firewall" to the system.) However, depending on your environment, a local firewall may not be practical. (For example, it may block access to a required service, such as portmap.) You can always tweak the firewall configuration (by modifying the /etc/sysconfig/ipchains file), but this may not be worth the effort in some cases. (As it happens, the actual case study workstation does not run the standard Red Hat firewall.)

In the end, though, there's only so much you can do when you're not in charge of the entire network. (Of course, if you are in charge of the entire network, there are a lot more options open to you!) You may find yourself in the position of having to delegate security responsibility to the network administrator. This is largely the case with the case study system.

That's it! You can develop software, exactly the same way I do. Of course, that's not going to be especially useful to you if you have different needs. The next section points out some ways in which you could tweak this case study to adapt it to differing needs. These ideas may provide you with the seeds you need to cultivate your own custom workstation.

---