433 lines
13 KiB
HTML
433 lines
13 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
|
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>Putting the Pieces together</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
|
|
REL="HOME"
|
|
TITLE="The Mock Mainframe Mini-HOWTO"
|
|
HREF="index.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="The Support Machines"
|
|
HREF="x337.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="Life With Multiple Users"
|
|
HREF="x407.html"></HEAD
|
|
><BODY
|
|
CLASS="section"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
SUMMARY="Header navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>The Mock Mainframe Mini-HOWTO</TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="x337.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
></TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="x407.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><H1
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN346"
|
|
></A
|
|
>6. Putting the Pieces together</H1
|
|
><P
|
|
> 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.
|
|
</P
|
|
><DIV
|
|
CLASS="section"
|
|
><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN349"
|
|
></A
|
|
>6.1. Security</H2
|
|
><P
|
|
> 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 <EM
|
|
>Secrets & Lies</EM
|
|
>
|
|
by Bruce Schneier.
|
|
</P
|
|
><DIV
|
|
CLASS="section"
|
|
><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN353"
|
|
></A
|
|
>6.1.1. Needs revisited</H3
|
|
><P
|
|
> 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.
|
|
</P
|
|
><P
|
|
> <STRONG
|
|
>What are you trying to protect?</STRONG
|
|
> 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.
|
|
</P
|
|
><P
|
|
> <STRONG
|
|
>Who or what are the forces of evil?</STRONG
|
|
> 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?
|
|
</P
|
|
><P
|
|
> 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?
|
|
</P
|
|
><P
|
|
> Once you know what you are afraid of and how probable an attack is, you
|
|
should have a feeling for the <EM
|
|
>risks</EM
|
|
> you are facing. There are three ways
|
|
of handling risk: You can <EM
|
|
>take it</EM
|
|
>, <EM
|
|
>minimize it</EM
|
|
>, or <EM
|
|
>insure against it</EM
|
|
>.
|
|
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.
|
|
</P
|
|
><P
|
|
> The second option is touches the three major parts of any security process:
|
|
<EM
|
|
>prevention</EM
|
|
>, <EM
|
|
>detection</EM
|
|
>, and <EM
|
|
>response</EM
|
|
>. 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 <TT
|
|
CLASS="literal"
|
|
>/var/log/</TT
|
|
>? — 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.
|
|
</P
|
|
><P
|
|
> Even if you decide that detection systems like <TT
|
|
CLASS="literal"
|
|
>tripwire</TT
|
|
> 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?
|
|
</P
|
|
><P
|
|
> 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 <EM
|
|
>reinstall from scratch</EM
|
|
>
|
|
as the standard response all problems great or small (but
|
|
make sure that your backups are not compromised).
|
|
</P
|
|
><P
|
|
> 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.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN376"
|
|
></A
|
|
>6.1.2. Security Principles</H3
|
|
><P
|
|
> Back to prevention: When you design your system, keep these security
|
|
principles in mind:
|
|
</P
|
|
><P
|
|
> <STRONG
|
|
>Building better baskets.</STRONG
|
|
> 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 <EM
|
|
>very, very good</EM
|
|
> basket.
|
|
</P
|
|
><P
|
|
> <STRONG
|
|
>Avoiding complexity.</STRONG
|
|
> 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.
|
|
</P
|
|
><P
|
|
> <STRONG
|
|
>Encapsulation.</STRONG
|
|
> 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.
|
|
</P
|
|
><P
|
|
> <STRONG
|
|
>Defense in Depth.</STRONG
|
|
> 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.
|
|
</P
|
|
><P
|
|
> 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.
|
|
</P
|
|
><P
|
|
> 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.
|
|
</P
|
|
><P
|
|
> <STRONG
|
|
>Choke Points.</STRONG
|
|
> 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,
|
|
<EM
|
|
>provided it is really the only access point</EM
|
|
>. 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.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN393"
|
|
></A
|
|
>6.2. Network Hardware</H2
|
|
><P
|
|
> 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.
|
|
</P
|
|
><P
|
|
> 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.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN397"
|
|
></A
|
|
>6.3. Network Geography</H2
|
|
><P
|
|
> 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.<STRONG
|
|
>.</STRONG
|
|
> 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.
|
|
</P
|
|
><P
|
|
> Combine this with a naming system that is easy to use. For example, you can
|
|
name the mock mainframe <EM
|
|
>fatcat</EM
|
|
> and the terminals <EM
|
|
>kitten00</EM
|
|
> to <EM
|
|
>kitten99</EM
|
|
>
|
|
(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 <EM
|
|
>claws</EM
|
|
> for a guardian machine or
|
|
<EM
|
|
>mamacat</EM
|
|
> for a terminal mother.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
SUMMARY="Footer navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="x337.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
ACCESSKEY="H"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="x407.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>The Support Machines</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
> </TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>Life With Multiple Users</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |