So after reading this far, you know what you want, know where to get it, how to set it up, and want to get going. There are few things you should think about, however, before you start editing configuration files and stringing cables.
There is only a limited amount I can tell you about your security needs: Everybody faces different threats. All I can do here is give some basic background on how to secure a mock mainframe setup. If you are looking for a good general introduction to security, try the book Secrets & Lies by Bruce Schneier.
In most books on securing computer systems, there comes a point where the author tells you to sit down and "formulate a security policy". This sounds like such a bureaucratic nightmare that most people skip the whole chapter. I'm not going to suggest you formulate anything. But the next time you're taking a shower, ask yourself what kind of defenses you need.
What are you trying to protect? Are you worried about somebody hacking into the mock mainframe and stealing your data, the classic Hollywood threat to computers? Or that your hardware could be destroyed by lightning? Or that somebody will sit down in front of a terminal when the user is off to the bathroom and write emails in his name? Or that people will open the computer cases and steal the processors? Another way to look at this is to figure out what parts of the system would be hard or even impossible for you to do without. For example, the digital photos and films of my daughter when she was a baby are simply irreplaceable.
Who or what are the forces of evil? Once you know what you are trying to protect, think about whom you are protecting it against, maybe while you are brushing your teeth. Are you worried about crackers from the Internet, or that the flaky power company you are stuck with will zap your computers with a power surge? Remember those little kids with popsicle sticks?
If your system is connected to the Internet 24/7, you need to worry about worms and crackers. If you are only online for as long as it takes to pick up those three emails from your mother, you risk in this area is drastically reduced. This shows how the "probability" of an attack figures in. How likely is it for somebody to hit your system during those 20 seconds? If an attack is highly improbable, you won't want to go to the effort of protecting yourself against it. Some things you will probably dismiss without even thinking: Just how were you going to defend your system against attacks by rust monsters?
Once you know what you are afraid of and how probable an attack is, you should have a feeling for the risks you are facing. There are three ways of handling risk: You can take it, minimize it, or insure against it. The first option is not as negligent as you might think: Given our budget, most of us are simply taking the risk of meteor strikes. The third option usually costs money, which we don't have, so we will ignore it here.
The second option is touches the three major parts of any security process: prevention, detection, and response. Most computer security deals with prevention: Making sure the cases are locked so nobody can steal the CPUs, for example. Detection is usually skimped — when is the last time you looked at one of the files in /var/log/? — and usually little thought is given to the response, because people figure none of this is going to happen anyway. Unfortunately, you need all three, always, at least to some extent.
Even if you decide that detection systems like tripwire are too much of a hassle to install and you don't have the time to read log files every day, give some thought to how you could tell that your system has been compromised. In some cases, it will be hard to miss, say, when men with badges knock at your door and take you away because your computer has been sending spam related to an improbable sexual act with squirrels to all of South Korea. Other intrusions might be more subtle. Would you know if somebody copied the files from your letter folder?
Think about how you would respond to at least the most likely attacks and failures. What would you do if your hard disk crashed? If you logged in as root and the system told you that your last log in was on Friday — except that you were still in London, England on Friday, singing drinking songs as you happily stumbled from one pub to the next. With a normal home system and good backups, you might be able to get away with reinstall from scratch as the standard response all problems great or small (but make sure that your backups are not compromised).
By the time you are putting on your socks, you'll have probably found out that your greatest risks are quite different from those the press talks about all of the time. If you have no Microsoft products on your network, you don't have to worry too much about anti-virus software or Active X vulnerabilities. However, Linux does not enjoy any special bonuses when it comes to power surges, flooding, or broken fans.
Back to prevention: When you design your system, keep these security principles in mind:
Building better baskets. Putting all of your files on one computer might seem like putting all of your eggs in one basket, which proverbial grandmothers say is a bad thing to do. In fact, from a security point of view, this can actually be a good strategy: Since it is almost always easier to defend one thing than it is to defend many, one basket my be fine as long as you make sure that is a very, very good basket.
Avoiding complexity. A centralized system is usually less complex to set up and to administer: If you have all of your users on one machine, you don't have to worry about network file systems, network logins, network printers, and all other kinds of clever but complicated ways to connect computers. Keeping things simple keeps things safe. This is true as well for the support machines: They should do one job and one job only.
Encapsulation. This is the process of isolating a part of the system so that if it is compromised, the whole of the system doesn't go down with it. The Guardian is an example of encapsulation: The dangerous work of connecting to the Internet is handled by a cheap, expendable machine that gives attackers few tools to work with. Another example is taking those parts of the system that the user can actually touch with his grubby little hands — monitor, keyboard, and mouse — and putting them on a Linux Terminal. The mock mainframe setup, however, is obviously not that good at encapsulation: The whole idea of doing everything on one machine runs contrary to this concept.
Defense in Depth. Preventative security measures are only ways of buying time until your response kicks in — given enough uninterrupted time, the attacker will always win. To increase the time you have to respond, deploy your defenses in depth: After the attacker has trekked through kilometers of dense jungle, he reaches the moat which surrounds a twenty meter high outside wall, which is followed by a mine field and poisoned bamboo spikes. And in the end, the secret plans to your magical chocolate machine will not only be in code, but also written in invisible ink. That's defense in depth.
The guardian is an extention of your defenses; installing a second firewall on the mock mainframe is another one. It might sound trivial, but use different passwords for the mock mainframe and the guardian. If you have other support machines, putting them on a different network also means more room between them and the attacker. If you have data that you have to keep confidential at all costs (wink-wink nudge-nudge), encrypt it, or at least those backup CDs. After a few years of backups, you won't know where they have all ended up.
But keep in mind that even the deepest defenses only buy you more time. As Indiana Jones and Lara Croft will tell you, getting by the preventative measures is the easy part: All you need is a whip or a few well-timed jumps. The problems start when the locals start shouting and the guys with the guns arrive.
Choke Points. If there is only one way to get into the system and you can control that way completely, that system will be easier to secure in time of danger. We turn to the guardian one more time for an example of a choke point: Turn off the machine, and you are safe from Internet villains, provided it is really the only access point. The problem with many networks is that somewhere, somebody has a connection to the outside that the system administrator doesn't know about. Think of all the laptops that now come with a modem or, even worse, a wireless LAN card built in. Connect those laptops to your net, and you have an instant back door. Remember your history: Your main gate can be high and strong and crawling with orcs, but miss one single little spider hole, and two hobbits can ruin your whole day.
If you are setting up a network from scratch, go with Fast Ethernet. The cables and network cards are not that much more expensive than the older, 10 MBit/sec Ethernet. X Windows is bandwidth-hungry, and needs always grow before they shrink.
One note about running X terminals over a wireless LAN: I have been told in no uncertain words to avoid this. Two problems are mentioned: Variable bandwidth, which can leave your session slowing to a crawl when your neighbor does something major, and dropouts, which can lead to the whole session being shut down with all X programs using the connection terminated and your work gone. There are also the usual caveats about the security of WiFi connections.
You can make life a little easer for yourself by picking a sane and systematic way to name your computers: Pick a set of addresses for your system based on what each machine does. Internally, use the IPv4 address space of 192.168.. that is reserved for networks without direct contact to the Internet. For example, let's take 192.168.1.*. The mock mainframe could be 192.168.1.1, the support machines 192.168.1.10 to 192.168.1.19, and the terminals 192.168.1.100 to 192.168.1.199. This way, you can immediately see the type of computer based on the IPv4 number, and the less trusted a machine is, the larger the last number will be.
Combine this with a naming system that is easy to use. For example, you can name the mock mainframe fatcat and the terminals kitten00 to kitten99 (with IPv4 numbers from 192.168.1.100 192.168.1.199). Giving the support machines names based on their function is probably easier than something systematic. In the feline theme, try claws for a guardian machine or mamacat for a terminal mother.