THE seeds of the global network that we call the Internet were sown over
twenty-five years ago when Bob Taylor, who was working for the US Advanced
Research Projects Agency thought that it would be a good idea to connect all the
seriously expensive machines that ARPA was funding. He commissioned a network
called ARPANET, the world’s first wide area network for computer-to-computer
communication. ARPANET consisted of fast land lines connected to dedicated
computers known as Interface Message Processors or IMPs. We now call such
machines “routers”. At each networked site, a local host was interfaced to the
IMP and not directly to the network. At the time the idea of IMPs was
revolutionary.

The contract to do the work was won by a consulting company in Cambridge,
Massachusetts, called Bolt Beranek and Newman (BBN) in the face of stiff
competition from 12 other bidders. They commissioned IMP hardware from
Honeywell. The hardware had to be student-proof and was originally designed to
US Navy battlefield specifications. BBN seems to have not only written the
software but also redesigned and debugged the hardware. The design and
construction of the interface between the hosts and the IMPs was left to the
institution hosting the network connection.

By 1971, the network had 16 IMPs with at least two routes between each site.
The network was “producer heavy” with most sites donating services. BBN
generated a new IMP, a terminal concentrator, called a Terminal IMP or TIP. The
TIP meant that users at sites could sit at a terminal and access services on
processors elsewhere in the US. At this point, savings on machine purchases were
made. For example, the University of Illinois abandoned its plan to buy a large
Burroughs processor in favour of a TIP.

ARPANET did not originally use the protocols that we use today. The Transport
Control Protocol (TCP) now provides a connection between two hosts and runs on
top of the Internet Protocol (IP). The protocols were proposed in 1974, but it
took nine years before the network was switched to use them as the basic method
of communication.

By then ARPANET had disappeared as an entity, after a brief attempt at
translating it into a commercial network. It was replaced by several other
networks. The other networks adopted the ARPANET protocols, formed gateways and
became the Internet.

Where Wizards Stay Up Late by Katie Hafner and Matthew Lyon is a
history of the early development of ARPANET. It is written as faction, using the
narrative style that was pioneered in books about computing by John Markoff and
Katie Hafner, such as in Cyberpunk (1991). Wizards is
an easy read and would make a good companion on a long train journey or
flight.

The book is rich in tiny details. Most are personal trivia, trying to put
flesh on the bones of the personalities involved. For example, it begins by
telling us that Taylor’s car was a BMW 503. I don’t object to the personal
details, but sometimes it’s not clear where the trivia collection is leading.
You wonder when we’ll get back to the story.

The technical details are well explained—there’s a real attempt to make
some of the complexities accessible to that mythical passenger on the Clapham
omnibus. There are only a couple of places where the authors’ lack of technical
expertise shows through.

But the publicity blurb claims that this is the “never-before-told story” of
the growth of the ARPANET. Well, that claim is simply untrue. Wizards
leans heavily on Peter Salus’s Casting the Net: From ARPANET to INTERNET and
Beyond (Addison-Wesley, 1995). Casting the Net covered much more
ground and so the ARPANET story is perhaps more thinly described. However, it is
manifestly the work of a historian, taking original sources and piecing the
story together.

Still, I’m glad to have both books on my shelves. Both are “cracking good
reads”, as Wallace might say to Grommit.

Suddenly, the world is going mad about the Internet. People are piling
on the bandwagon, joining up without giving much thought to the security
of their systems, which are now linked into a global network. The Internet
was designed as a research tool, and it is fair to say that system security
was not the prime concern of the implementors.

Now we have a new breed of computer hackers, people who travel the net
trying to get into your system and poke about. Sometimes they are malevolent,
sometimes simply curious – what is certain is that you do not want them
invading your machines.

Firewalls and Internet Security is essential reading for anyone who
is connected to the Internet. You do, however, need a basic understanding
of the various protocols and services used when linking to the net. The
book is not aimed at beginners trying to find out what the problems might
be, but it is excellent for readers with a passing knowledge of how things
work and a desire to find out how to stop the bad guys from getting in.
The ‘bad guys’ appear frequently in the book.

Bill Cheswick and Steve Bellovin are researchers at AT&T Bell Laboratories
in Murray Hill, New Jersey. They have spent a lot of time time defending
the systems inside Bell Labs from unwanted intrusions, and paint a grim
picture of continuous probes from unknowns out on the net. They work at
a prominent site, which I can’t help feeling acts as a honey pot to would-be
intruders.

Early on in the book, they point out that they can log all attempts
at invasion and watch them happening. No commercial systems provide adequate
logging of network activity, so most of us have no idea of who is trying
to get in and what they are trying to do, whether legitimate or not.

What Cheswick and Bellovin have developed is a sophisticated defence,
a ‘firewall’. A firewall hides all the machines on your local network from
outside gaze while allowing your machines to see out. Firewalls and Internet
Security gives considerable detail on how to set up firewalls, examining
the problems that exist with various protocols and services. I found a
great deal of very useful, practical material here. The authors also cover
authentication services and other defence mechanisms.

Cheswick and Bellovin work in the Unix room at Bell Labs, and their
book suffers from the anti-Berkeley feelings that are prevalent there. You
only have to sit in the Unix room for a morning to hear people berating
Berkeley. It is not quite clear why. The current ethos in the Labs is ‘small
is beautiful’ and without doubt the Berkeley code writers have created large
systems. A strong message from the book is that simple, small programs are
less of a security risk because you can understand what is happening more
easily.

Anyway, a particular target of the book is Sendmail, the mail-handling
program originating in Berkeley that is used by most Unix workstations to
process electronic mail. It has received a number of attacks from the network
over the years; it is big, complicated and a good place to begin hacking
into a system because it runs with ‘super-user’ privilege, which means that
it can access any file on the machine.

Reading the book, you might get the feeling that Sendmail is the last
program that you want to run on your supposedly secure system. But it is
too easy to be smart with hindsight. Yes, there have been problems, but
the holes have been plugged. It would have been better not to dismiss Sendmail
out of hand, but to provide readers with the simple tests that demonstrate
the holes so that they can go to their vendor for replacement code.

Many important passages in the book are marked with an exploding bomb
symbol, signifying that they are amplified at the back of the book. This
lets you skip parts of the text whose content you are familiar with, and
get down to the problem. Also to be found at the back of the book is a good
selection of security software and an extensive bibliography. If you are
on the net, you need this book.

Peter Collinson runs his own Unix consultancy, Hillside Systems, which
allows him to write articles and programs, teach and sell software.