740 lines
35 KiB
Plaintext
740 lines
35 KiB
Plaintext
|
|
Computer underground Digest Wed July 22, 1998 Volume 10 : Issue 40
|
|
ISSN 1004-042X
|
|
|
|
Editor: Jim Thomas (cudigest@sun.soci.niu.edu)
|
|
News Editor: Gordon Meyer (gmeyer@sun.soci.niu.edu)
|
|
Archivist: Brendan Kehoe
|
|
Shadow Master: Stanton McCandlish
|
|
Shadow-Archivists: Dan Carosone / Paul Southworth
|
|
Ralph Sims / Jyrki Kuoppala
|
|
Ian Dickinson
|
|
Field Agent Extraordinaire: David Smith
|
|
Cu Digest Homepage: http://www.soci.niu.edu/~cudigest
|
|
|
|
CONTENTS, #10.40 (Wed, July 22, 1998)
|
|
|
|
Subject: REVIEW: Protecting Networks w/SATAN
|
|
Subject: REVIEW: "Web Security and Commerce", Simson Garfinkel/Gene Spaff
|
|
Subject: REVIEW: "3001: The Final Odyssey", Arthur C. Clarke
|
|
Subject: REVIEW: "Maximum Security", Anonymous
|
|
Subject: REVIEW: "Death Dream", Ben Bova
|
|
Subject: REVIEW: "Web Security", Rohit Khare
|
|
Subject: REVIEW: "PCWeek Microsoft Windows NT Security", Nevin Lambert/Ma
|
|
Subject: REVIEW: "Java Security", Scott Oaks
|
|
Subject: Cu Digest Header Info (unchanged since 25 Apr, 1998)
|
|
|
|
CuD ADMINISTRATIVE, EDITORIAL, AND SUBSCRIPTION INFORMATION ApPEARS IN
|
|
THE CONCLUDING FILE AT THE END OF EACH ISSUE.
|
|
|
|
---------------------------------------------------------------------
|
|
|
|
Date: Mon, 8 Jun 1998 15:45:11 -0700 (PDT)
|
|
From: Lisa Mann <lisam@oreilly.com>
|
|
Subject: REVIEW: Protecting Networks w/SATAN
|
|
|
|
For immediate release
|
|
Fore more information contact:
|
|
Lisa Mann lisam@oreilly.com
|
|
(707)829-0515 ext. 230
|
|
|
|
PROTECTING NETWORKS WITH SATAN
|
|
|
|
Because SATAN (Security Administrator's Tool for Analyzing Networks)
|
|
could detect weaknesses on other systems (as well as your own) through
|
|
its web interface, it earned notoriety when released in April 1995 as
|
|
the tool that would "wreak havoc" on the Internet. The Oakland Tribune
|
|
even wrote: "It's like randomly mailing automatic rifles to 5000
|
|
addresses. I hope some crazy teen doesn't get ahold of one."
|
|
|
|
But as more and more "mission critical" applications are accessible
|
|
through the web, administrators are turning their attention to the
|
|
danger of attempted intrusion from outside the networked host. SATAN
|
|
is a powerful aid for system administrators. It performs "security
|
|
audits," scanning host computers for security vulnerabilities caused by
|
|
erroneous configurations or by known software errors in frequently used
|
|
programs. O'Reilly's latest release, "Protecting Networks with SATAN",
|
|
is an invaluable tool for network and security administrators working
|
|
with SATAN.
|
|
|
|
Wietse Venema, SATAN co-author, says "In this handy book, Martin Freiss
|
|
explains the workings of SATAN and provides a helping hand with
|
|
customizing and extending the system to match local conditions." This
|
|
concise guide also discusses how you can defend your site against
|
|
potential abuse by SATAN.
|
|
|
|
|
|
###
|
|
Protecting Networks with SATAN
|
|
By Martin Freiss
|
|
1st Edition June 1998 (US)
|
|
112 pages, 1-56592-425-8, $19.95 (US$)
|
|
http://www.oreilly.com
|
|
|
|
------------------------------
|
|
|
|
Date: Mon, 22 Jun 1998 14:02:15 -0800
|
|
From: "Rob Slade, doting grandpa of Ryan and Trevor" <rslade@sprint.ca>
|
|
Subject: REVIEW: "Web Security and Commerce", Simson Garfinkel/Gene Spaff
|
|
|
|
BKWBSCCM.RVW 980411
|
|
|
|
"Web Security and Commerce", Simson Garfinkel/Gene Spafford, 1997,
|
|
1-56592-269-7, U$32.95/C$46.95
|
|
%A Simson Garfinkel simsong@aol.com
|
|
%A Gene Spafford spaf@cs.purdue.edu
|
|
%C 103 Morris Street, Suite A, Sebastopol, CA 95472
|
|
%D 1997
|
|
%G 1-56592-269-7
|
|
%I O'Reilly & Associates, Inc.
|
|
%O U$32.95/C$46.95 800-998-9938 707-829-0515 nuts@ora.com
|
|
%P 483 p.
|
|
%T "Web Security and Commerce"
|
|
|
|
Anyone who does not know the names Spafford and Garfinkel simply does
|
|
not know the field of data security. The authors, therefore, are well
|
|
aware that data security becomes more complex with each passing week.
|
|
They note, in the Preface, that the book cannot hope to cover all
|
|
aspects of Web security, and therefore they concentrate on those
|
|
topics that are absolutely central to the concept, and/or not widely
|
|
available elsewhere. Works on related issues are suggested both at
|
|
the beginning and end of the book.
|
|
|
|
Chapter one, which is also part one, introduces the topic, and the
|
|
various factors involved in Web security. The topic is examined from
|
|
the perspective of the user and vendor, and also looks at
|
|
vulnerabilities at the server site, client computer, and the network
|
|
in between.
|
|
|
|
Part two concerns the user. Chapter two looks at the various possible
|
|
problems with browsers, not all of which are related to Web page
|
|
programming. Java security is only marginally understood by many
|
|
"experts," and not at all by users, so the coverage in chapter three
|
|
is careful to point out the difference between safety, security, and
|
|
the kind of security risks that can occur even if the sandbox *is*
|
|
secure. ActiveX and the limitations of authentication certificates
|
|
are thoroughly explored in chapter four. Chapter five looks briefly
|
|
but analytically at the possible invasions of privacy that can occur
|
|
on the Web.
|
|
|
|
Part three deals more completely with the question of digital
|
|
certificates. Chapter six explains the various techniques for
|
|
identification confirmation. The use of certification authorities is
|
|
reviewed in chapter seven, including the activity this can generate on
|
|
Web browsers. Chapter eight covers the steps needed to obtain a
|
|
client-side digital certificate from Verisign. Microsoft's
|
|
Authenticode code signing system is detailed in chapter nine.
|
|
|
|
Cryptography must be invoked at some point for any kind of data
|
|
security, and particularly for security over insecure networks, so
|
|
part four invests some depth in the topic. Chapter ten starts with
|
|
cryptographic basics, simply in terms of the various functions
|
|
cryptography can provide. Functional limitations of cryptography,
|
|
various existing systems, and US and international regulation with
|
|
respect to the technology are discussed in chapter eleven. SSL
|
|
(Secure Sockets Layer) and TLS (Transport Layer Security) are
|
|
described in chapter twelve.
|
|
|
|
Part five details technical aspects of securing Web servers.
|
|
Traditional host security weaknesses are reviewed in chapter thirteen.
|
|
Chapter fourteen looks at specific strengthening measures for Web
|
|
servers. Rules for secure CGI (Common Gateway Interface) and API
|
|
(Application Programmer Interface) programming are promulgated in
|
|
chapter fifteen, along with tips for various languages.
|
|
|
|
Commercial and societal concerns are major areas in Web security, so
|
|
part six reviews a number of topics related to commerce, as well as
|
|
other social factors. Chapter sixteen looks at current non-cash
|
|
payment systems, and the various existing, and proposed, digital
|
|
payment systems for online commerce. Censorship and site blocking are
|
|
carefully examined in chapter seventeen. A variety of legal issues
|
|
are discussed, civil in chapter eighteen, and criminal in nineteen.
|
|
|
|
In reviewing books I very often find that appendices are often filler.
|
|
The most useful tend to be bibliographies or lists of vendor contacts.
|
|
Too many seem to be mere self-indulgent filler used by the author to
|
|
pad out the book. Although it has almost nothing to do with Web
|
|
security as such, I very much enjoyed Appendix A, Garfinkel's
|
|
recounting of the lessons learned in setting up a small ISP (Internet
|
|
Service Provider). (I suppose that this could be considered valid
|
|
coverage of Web commerce.) The other appendices are more directly
|
|
related to the topic, including information on the installation of Web
|
|
server certificates, the SSL protocol, the PICS (Platform for Internet
|
|
Content Selection) specification, and references.
|
|
|
|
In comparison to Stein's "Web Security" (cf. BKWEBSEC.RVW) I find it
|
|
very difficult to choose between the two. Each is readable, and each
|
|
is aimed pretty much at the same target audience. There is little to
|
|
choose between them for technical depth: each has useful information
|
|
that the other does not. Both are excellent: what the heck, buy two,
|
|
they're small.
|
|
|
|
copyright Robert M. Slade, 1998 BKWBSCCM.RVW 980411
|
|
|
|
------------------------------
|
|
|
|
Date: Tue, 7 Jul 1998 09:51:16 -0800
|
|
From: "Rob Slade, doting grandpa of Ryan and Trevor" <rslade@sprint.ca>
|
|
Subject: REVIEW: "3001: The Final Odyssey", Arthur C. Clarke
|
|
|
|
BK3001.RVW 980510
|
|
|
|
"3001: The Final Odyssey", Arthur C. Clarke, 1997, 0-345-42349-6
|
|
%A Arthur C. Clarke
|
|
%C 101 Fifth Avenue, New York, NY 10003
|
|
%D 1997
|
|
%G 0-345-42349-6
|
|
%I Ballantine/Fawcett/Columbine Books/Del Rey
|
|
%O http://www.randomhouse.com/delrey delrey@randomhouse.com
|
|
%P 274 p.
|
|
%T "3001: The Final Odyssey"
|
|
|
|
"You know those Rama books? The ones he did with somebody else?" he
|
|
asked.
|
|
|
|
"Yes." I said.
|
|
|
|
"Well, they were really terrible. Not much of Clarke at all."
|
|
|
|
"True."
|
|
|
|
"But he's put out a new one. `3001.' Another in the `2001' series.
|
|
It's vintage Clarke. You'll have to get it."
|
|
|
|
So I looked forward to it with great anticipation. We all enjoy
|
|
Clarke a lot. I mean Heinlein is OK for adventure junkies and Ayn
|
|
Rand fans, and Niven has a few interesting astrophysics tricks, but
|
|
Clarke is the only one for techies when they want to avoid gnashing
|
|
their teeth every three pages over some egregious scientific error.
|
|
|
|
He was right. This is vintage Clarke. And that is not altogether
|
|
good.
|
|
|
|
For one thing, those familiar with the Clarke corpus will know that
|
|
Clarke is at his best in the short story. His novels, and
|
|
particularly the more recent, tend to have story lines that zig, and
|
|
zag, and wander up blind alleys and cul de sacs. At times Clarke
|
|
seems to get bored and will fast forward thirty years over a chapter
|
|
break. (Of course, some may object that many of the more recent
|
|
Clarke books are collaborations, but this tendency is also noticeable
|
|
in the 2001 series, the original "Rendezvous with Rama," and others
|
|
stretching back a ways.) Therefore, "3001" bears less resemblance to
|
|
a novel than to a collection of short stories with a few common
|
|
characters.
|
|
|
|
Another problem is that Clarke is good with technology, but he is not
|
|
as good with people, and particularly society. Yes, it is true that
|
|
we could not communicate with an English-speaker of a thousand years
|
|
ago, but that was because there *was* no English that long ago: it was
|
|
basically Saxon, and was about to get an infusion of French. Even
|
|
without sound recordings we can still understand English of four
|
|
centuries back with little difficulty. (I know: I've been to
|
|
Newfoundland.) What would be difficult is not only idiom (and
|
|
reasonable marks to Clarke for that) but also concepts. How would you
|
|
explain "clockwise motion," "running like clockwork," and "weekend" to
|
|
King Harold?
|
|
|
|
Clarke has a very optimistic view of society. I will agree with
|
|
Feynman's assessment, in "The Meaning of it All" (cf. BKMEANNG.RVW),
|
|
that psychology is only just starting, and that current theories will
|
|
no doubt seem as quaint as phlogiston and a periodic table with four
|
|
elements in the several hundred years that it has taken physics to
|
|
come up with some reasonably useful laws. However, the world of 3001
|
|
seems to have no social problems at all, aside from minor and isolated
|
|
aberrations. The poor, or any other social strata, are no longer with
|
|
us. I assume that Clarke would dismiss that objection out of hand,
|
|
since he is so adamant (and patronizingly so, in the valediction) that
|
|
mankind will have finally outgrown religion. (Odd, though, that the
|
|
evils of the Inquisition, the Crusades, female genital circumcision,
|
|
and the Indian subcontinent have nothing to do with politics or other
|
|
sociological pathologies.) I am not sure how the death of "religion"
|
|
fits in with a tremendous push for, oh, shall we call it
|
|
"spirituality?"
|
|
|
|
The science is reasonably strong, though spotty. Clarke seems to be
|
|
very conservative in many areas, given the vast gulf he has to play
|
|
with. If information storage has grown through nine orders of
|
|
magnitude in forty years, a mere handful in a millennium seems
|
|
pikerish. Nanotechnology is non-existent. Medicine, and particularly
|
|
microbiology, seems to have had a very lucky time of it. While there
|
|
is a nod to Mad Cow disease (and the obligatory sermon on
|
|
vegetarianism), virulent new diseases seem to have stopped happening
|
|
and antibiotic (and whatever follows antibiotics) resistance is a non-
|
|
issue. I can handle vacuum energy and inertia drives, although I
|
|
don't see why an inertia drive can't run a shuttle on earth, as it
|
|
does in other places.
|
|
|
|
However, I would have kept my big keyboard shut, had Clarke not
|
|
dropped one heck of a clanger in *my* field: computer viruses. I
|
|
don't care whether ID4 or 3001 had the idea first (and did either of
|
|
you thank Fred Cohen? No, I didn't think so) but the concepts are
|
|
still equally invalid. Turing, and his machines, proved that whatever
|
|
algorithm one machine can compute another can compute: he didn't say
|
|
that any machine can run another machine's programs. (The creation of
|
|
this super virus/trojan reminds one of Monty Python's military use of
|
|
The Perfect Joke.) Alright, I can accept that there will be all kinds
|
|
of wonderful, and not so wonderful, developments in computing over the
|
|
next millennia, but for the same reason that you cannot have a perfect
|
|
virus defence, you can't have an undetectable virus. (There's never
|
|
an AV that'll always recover: there's never a virus that can't be
|
|
discovered.) The tricks that Clarke proposes are all the mathematical
|
|
equivalents of asking the super-deluxe-really-smart computer the well-
|
|
beloved trick question "why?" (Didn't Clarke use that one once
|
|
already?) And I don't care if you do have an agent inside the
|
|
machine; the "Firstborn" seem to be just a tad older and smarter than
|
|
you, and MonolithOS 3.14159... probably has a thread killing daemon
|
|
that will keep the machine from chasing its CPU up its own
|
|
multiplicity. (Nice parallelism, mind. Bit hard on the desktop
|
|
models, maybe.)
|
|
|
|
copyright Robert M. Slade, 1998 BK3001.RVW 980510
|
|
|
|
------------------------------
|
|
|
|
Date: Tue, 30 Jun 1998 14:51:22 -0800
|
|
From: "Rob Slade, doting grandpa of Ryan and Trevor" <rslade@sprint.ca>
|
|
Subject: REVIEW: "Maximum Security", Anonymous
|
|
|
|
BKMAXSEC.RVW 980501
|
|
|
|
"Maximum Security", Anonymous, 1997, 1-57521-268-4,
|
|
U$49.99/C$70.95/UK#46.95
|
|
%A Anonymous
|
|
%C 201 W. 103rd Street, Indianapolis, IN 46290
|
|
%D 1997
|
|
%E Mark Taber newtech_mgr@sams.mcp.com
|
|
%G 1-57521-268-4
|
|
%I Macmillan Computer Publishing (MCP)
|
|
%O U$49.99/C$70.95/UK#46.95 800-858-7674 http://www.mcp.com
|
|
%P 885 p. + CD-ROM
|
|
%T "Maximum Security"
|
|
|
|
Rather loudly promoted on the net these days, the major selling point
|
|
of this book is that it was written "by an experienced hacker."
|
|
Supposedly one who spent some time as a guest of Uncle Sam for
|
|
fiddling bank machines. (Some of what we are told about the author
|
|
does not fit with the contents of the book, but then, as an old
|
|
professional paranoid, I may be unduly suspicious.) Leaving aside
|
|
questions of morality and definitions of the term "hacker," let us
|
|
merely observe that these people are the gnostics. They are the
|
|
devotees of the hidden, esoteric, and arcane knowledge. Such
|
|
knowledge, of course, is cheapened and weakened by being revealed.
|
|
Which may explain a certain reticence on a number of points in the
|
|
book. The introduction makes this mindset clear: Anonymous assumes
|
|
that if you will not work diligently at his direction you do not
|
|
deserve to secure your system. One can almost feel his glee at the
|
|
expectation that thousands of sysadmins around the world will be
|
|
wracking their brains and flooding Usenet with discussions of the
|
|
significance of his clues to the vital encrypted message he has hidden
|
|
on the CD-ROM. This does, of course, presume that his direction, and
|
|
the contents of the book, warrant the effort to try and guess his
|
|
riddle.
|
|
|
|
Part one might be characterized as a social background to security.
|
|
Chapter one is essentially an extension of the introduction,
|
|
continuing to try to convince the reader that the book is worthwhile.
|
|
But it also states that the author wishes to raise the awareness of
|
|
security in the general public. I rather doubt that this will be the
|
|
book to do so: the average user will be put off by both the size and
|
|
the subtitle's emphasis on Internet sites and networks, neither of
|
|
which the average user will run. The (very verbose) sales pitch
|
|
continues in chapter two with rather generic promises of the goodies
|
|
offered to all manner of readers, and a list of chapters to come. (Of
|
|
course, nudge, nudge, wink, wink, some unethical people might use this
|
|
information for cracking, nudge, nudge, but none of *us* upstanding
|
|
people would do that, right? wink, wink) Having been rather careless
|
|
with the term "hacker" up to this point, chapter three belatedly
|
|
attempts to distinguish between hackers and crackers. It doesn't
|
|
succeed very well, being a pretty faint-hearted try. Chapter four
|
|
lists a number of security penetrations in an bid to prove that anyone
|
|
can be attacked.
|
|
|
|
Part two moves into more of a technical background to security.
|
|
Chapter five looks at the complexity of current network systems and
|
|
other factors militating against safety. A brief introduction to the
|
|
TCP/IP protocol suite is given in chapter six. Chapter seven gives
|
|
some random material on the Internet, programming, and UNIX. A
|
|
variety of Internet problems are briefly mentioned in chapter eight.
|
|
|
|
Part three looks at a number of the more common security penetration
|
|
tools. Chapters nine through fourteen discuss scanners, password
|
|
crackers, trojans, password sniffers, identity tools, and malicious
|
|
software respectively. Advice on how to deal with these problems
|
|
varies in depth, but generally is not extensive. As only one example,
|
|
the author does recommend that Web browsers be set to alert the user
|
|
when a cookie is being set, but fails to give the slightest indication
|
|
of how this is to be accomplished. The section on viruses is the book
|
|
in miniature: not necessarily *all* wrong, but overly verbose, lacking
|
|
in insight, and missing those points that would really be helpful to
|
|
the computer user or manager.
|
|
|
|
Part four reviews a number of operating system platforms. Chapter
|
|
fifteen presents the concept of vulnerabilities (termed as "holes").
|
|
In spite of the fact that MS-DOS, Windows 3.x, and Windows 95 have no
|
|
appreciable security, chapter sixteen lists a large number of security
|
|
penetration programs for them. (It also has a rather odd reference
|
|
demonstrating that the author does not actually understand how the
|
|
CMOS password functions work.) Chapter seventeen does contain a
|
|
collection of the more common suggestions for securing a UNIX box.
|
|
Tools for breaking Novell NetWare are displayed in chapter eighteen.
|
|
Cracking tools for VMS are listed in chapter nineteen. Chapter twenty
|
|
has both cracking and some protection software for the Mac. The
|
|
installation of the Plan 9 operating system is discussed in chapter
|
|
twenty one.
|
|
|
|
Part five gives some advice on what to go after when you crack a
|
|
system. Chapter twenty two suggests that root access is a suitable
|
|
target. Chapter twenty three points out that it is easier to crack a
|
|
system with partial access or inside information. Consultants seem to
|
|
be the topic of chapter twenty four.
|
|
|
|
Part six gives information on how to penetrate a system from outside.
|
|
Chapter twenty five looks at gathering information about the target.
|
|
Rather obvious statements about levels of attack are made in chapter
|
|
twenty six. Chapter twenty seven is a simple review of packet
|
|
filtering firewalls. IP spoofing is discussed in chapter twenty
|
|
eight. Telnet attacks cover a wide range, so it is surprising that
|
|
chapter twenty nine is so short. Chapter thirty looks at loopholes in
|
|
Web page programming.
|
|
|
|
Part seven, chapter thirty one, reviews legal aspects, and for once
|
|
even mentions laws outside the US.
|
|
|
|
Basically, there is a whole lot of partial information here. It is a
|
|
handy list of security related Web sites, but made less useful by the
|
|
bulked out verbiage between the listings. In addition, it is rather
|
|
plain to see that there is far greater emphasis on cracking than on
|
|
protection. (After all, how vital is it to securing your system to
|
|
know the algorithm for generating fake Microsoft software registration
|
|
keys?) All you teenage-mutant-cyberscofflaw-wannabes might be
|
|
disappointed, though: the information is almost never complete.
|
|
|
|
copyright Robert M. Slade, 1998 BKMAXSEC.RVW 980501
|
|
|
|
------------------------------
|
|
|
|
Date: Thu, 16 Jul 1998 09:54:09 -0800
|
|
From: "Rob Slade, doting grandpa of Ryan and Trevor" <rslade@sprint.ca>
|
|
Subject: REVIEW: "Death Dream", Ben Bova
|
|
|
|
BKDTHDRM.RVW 980519
|
|
|
|
"Death Dream", Ben Bova, 1994, 0-553-57256-3, U$5.99/C$7.99
|
|
%A Ben Bova
|
|
%C 1540 Broadway, New York, NY 10036
|
|
%D 1994
|
|
%G 0-553-57256-3
|
|
%I Bantam Books/Doubleday/Dell
|
|
%O U$5.99/C$7.99 800-323-9872 http://www.bdd.com webmaster@bdd.com
|
|
%P 560 p.
|
|
%T "Death Dream"
|
|
|
|
Viruses, artificial intelligence, and virtual reality are the
|
|
mainstays of the thriller world, where it touches on technology at
|
|
all. This book uses, and abuses, VR.
|
|
|
|
I am willing to accept high resolution imagery, and short latency
|
|
times. I am willing to accept that vision, sound, and minor physical
|
|
sensations can have an impact out of all proportion to reality.
|
|
(Wanna know how Disney forces you into your seat when you take off on
|
|
a rocket? The base of the seat sinks. You really feel like you are
|
|
rising. Maybe more like an elevator than a rocket, but you really
|
|
seem to move.) I am less willing to accept that this makes a
|
|
simulation so indistinguishable from reality that you have to ask your
|
|
wife for a password.
|
|
|
|
I have a hard time accepting the undefined but non-intrusive means of
|
|
generating specific physical sensations. Not only is this well beyond
|
|
the technology that we have available now, but even with physical
|
|
probes the ability to stimulate a particular tactile response (or any
|
|
other, really) is very much a hit and miss affair. (To be strictly
|
|
fair, the book does allow that this requires some brain mapping, and
|
|
does not transfer accurately from person to person.)
|
|
|
|
(Oh, and by the way, someone who is aphasic from a stroke probably
|
|
would be paralysed on the right side of the body. I have both
|
|
professional and personal reasons for knowing this.)
|
|
|
|
I am much less willing to accept that a team of technicians, looking
|
|
for faults in equipment, cannot recognize a transmitter of some sort
|
|
where none should be.
|
|
|
|
I am little short of astounded that a primarily visual simulation
|
|
system has no external monitors.
|
|
|
|
However, I am willing to forgive all of this, given the extremely
|
|
important point that is central to this book. Presentation of
|
|
information, in our age, has become more important than content.
|
|
Control of information shapes, and may cripple, leaders and
|
|
governments. The hand that holds the clicker may well rule the world.
|
|
|
|
copyright Robert M. Slade, 1998 BKDTHDRM.RVW 980519
|
|
|
|
------------------------------
|
|
|
|
Date: Thu, 18 Jun 1998 10:21:46 -0800
|
|
From: "Rob Slade, doting grandpa of Ryan and Trevor" <rslade@sprint.ca>
|
|
Subject: REVIEW: "Web Security", Rohit Khare
|
|
|
|
BKW3JI23.RVW 980411
|
|
|
|
"Web Security", Rohit Khare, 1997, 1-56592-329-4 ISSN 1085-2301,
|
|
U$29.95/C$42.95
|
|
%E Rohit Khare editor@w3j.com
|
|
%C 103 Morris Street, Suite A, Sebastopol, CA 95472
|
|
%D 1997
|
|
%G 1-56592-329-4 ISSN 1085-2301
|
|
%I O'Reilly & Associates, Inc.
|
|
%O U$29.95/C$42.95 800-998-9938 fax: 707-829-0104 nuts@ora.com
|
|
%P 272 p.
|
|
%S World Wide Web Journal
|
|
%T "Web Security: A Matter of Trust"
|
|
|
|
Many issues of the World Wide Web Journal coincide with major
|
|
specification announcements: Web standards that have been in process,
|
|
and anticipated, for some time determine the topic. That does not
|
|
seem to be the case with this issue, although the first report covers
|
|
the use of PICS (Platform for Internet Content Selection) 1.1 labels
|
|
for DSig 1.0 signature labels, the second gives more detail on DSig,
|
|
and the third reports on the Joint Electronic Payment Initiative
|
|
(JEPI).
|
|
|
|
Still, the "technical" papers in this issue seem to have a decidedly
|
|
philosophical bent. This emphasis is not necessarily a bad thing,
|
|
since it serves to redirect attention from the minutiae of Web server
|
|
"hole patching" and towards a more fundamental question, that of
|
|
trust. An interesting reversal of perspective occurs when you turn
|
|
from the concept of a closed and opaque system to one where
|
|
everything, including identity, is transparent.
|
|
|
|
Topics included in the papers include a cryptography primer, the
|
|
REFEREE system for trust management, SSL (Secure Sockets Layer) and
|
|
the free SSLeay implementation, security for the DNS (Domain Name
|
|
System), name server security in BIND, security in CGI (Common Gateway
|
|
Interface) and API (Application Programmer Interface) programming,
|
|
secure electronic business with E2S (End-to-End Security), concerns
|
|
and benefits with medical record availability, digital signature
|
|
legislation and regulation, and the risks and government promotion of
|
|
key escrow and recovery.
|
|
|
|
copyright Robert M. Slade, 1998 BKW3JI23.RVW 980411
|
|
|
|
------------------------------
|
|
|
|
Date: Thu, 9 Jul 1998 12:11:33 -0800
|
|
From: "Rob Slade, doting grandpa of Ryan and Trevor" <rslade@sprint.ca>
|
|
Subject: REVIEW: "PCWeek Microsoft Windows NT Security", Nevin Lambert/Ma
|
|
|
|
BKPWNTSG.RVW 980514
|
|
|
|
"PCWeek Microsoft Windows NT Security", Nevin Lambert/Manish Patel,
|
|
1997, 1-56276-457-8, U$39.99/C$56.95/UK#36.99
|
|
%A Nevin Lambert nevinl@primenet.com
|
|
%A Manish Patel manishp@primenet.com
|
|
%C 201 W. 103rd Street, Indianapolis, IN 46290
|
|
%D 1997
|
|
%G 1-56276-457-8
|
|
%I Macmillan Computer Publishing (MCP)
|
|
%O U$39.99/C$56.95/UK#36.99 800-858-7674 http://www.mcp.com
|
|
%P 388 p.
|
|
%T "PCWeek Microsoft Windows NT Security: Security Administrator's
|
|
Guide"
|
|
|
|
I always get a bit worried at a book written by two cofounders of a
|
|
consulting startup related to the topic of the book. My alarm level
|
|
rises when the sarcasm starts right away in the acknowledgements. I
|
|
am not comforted by the fact that the authors are enthralled by the
|
|
glories of Microsoft.
|
|
|
|
Chapter one, however, is a very reasonable look at the different
|
|
levels of security that a situation may demand. Physical security,
|
|
warnings, accounts, and backups are part of the picture that is
|
|
presented. Some of the advice is questionable (the use of NTFS
|
|
sometimes involves a tradeoff between access control and recovery) but
|
|
the overall scenario has good range and scope. The system history
|
|
given in chapter two is rather biased in favour of Microsoft and its
|
|
products, but the system overview is useful background. Account and
|
|
group concepts and maintenance are covered well in chapter three. The
|
|
discussion of filesystems in chapter four still hews closely to the
|
|
Microsoft party line, but it does provide information that can be very
|
|
helpful for decisions regarding reliability. In the Trusted Computer
|
|
System Evaluation Criteria (Orange Book) the term "Trusted Path"
|
|
refers to at least B2 level systems, which NT cannot approach.
|
|
However, in the review of the NT security subsystem in chapter five,
|
|
the authors do a credible job of justifying the use of the phrase
|
|
through the level of detail they provide of the logon process, as well
|
|
as other operations. Chapter six looks at access to local resources
|
|
and gives significant detail and information in such areas as well
|
|
known SIDs (Security IDs). However, as is too often the case, the
|
|
book fails to furnish a clear explanation of assessment of effective
|
|
rights to an object.
|
|
|
|
The review of basic networking concepts takes up about half of chapter
|
|
seven, with the remainder looking at shares and network security
|
|
provisions. RAS (Remote Access Service) and the related encryption
|
|
schemes are discussed in chapter eight, but the lack of details of the
|
|
encryption process make it difficult to assess levels of security and
|
|
operational needs. Coverage of printer management in chapter nine is
|
|
good, but the implications of options such as spooling and redirection
|
|
are not completely addressed. Chapter ten deals with a number of
|
|
Registry related topics, including editing, Registry tools, backup,
|
|
and security related keys.
|
|
|
|
Chapter eleven provides a thorough and helpful explanation of
|
|
profiles, although, again, extra material on the security implications
|
|
of specific choices could be more helpful. The ramifications of
|
|
auditing could be discussed forever, of course, but I would have to
|
|
say that chapter twelve's coverage is quite appropriate for the target
|
|
audience level of the book. Internet security could (and does) fill
|
|
other books, so it is acceptable that only concepts and warnings are
|
|
raised in chapter thirteen. Chapter fourteen reviews security aspects
|
|
of BackOffice but only in a brief and limited manner.
|
|
|
|
Chapter fifteen provides information on NT's use of cryptography, but
|
|
this data is not very helpful since it is not backed up with
|
|
conceptual material on cryptographic strengths and key management.
|
|
Enterprise policies are reviewed quickly in chapter sixteen. Chapter
|
|
seventeen looks to the future delivery of Distributed Security
|
|
Services (DSS). The security references and resources listed in the
|
|
appendices are not extensive, but they are of reasonably good quality.
|
|
|
|
The book has both a readable style and useful information. The lack of
|
|
formal security concepts means that there are gaps in coverage, but
|
|
overall this work can provide both new users and non-specialist
|
|
administrators with a measure of protection that would reduce
|
|
vulnerability considerably. Security specialists who are not familiar
|
|
with Windows NT would likely find the most benefit from using the text
|
|
as a tutorial, since they would be able to fill in the blanks from
|
|
their own conceptual background.
|
|
|
|
copyright Robert M. Slade, 1998 BKPWNTSG.RVW 980514
|
|
|
|
------------------------------
|
|
|
|
Date: Fri, 10 Jul 1998 11:11:58 -0800
|
|
From: "Rob Slade, doting grandpa of Ryan and Trevor" <rslade@sprint.ca>
|
|
Subject: REVIEW: "Java Security", Scott Oaks
|
|
|
|
BKJAVASC.RVW 980520
|
|
|
|
"Java Security", Scott Oaks, 1998, 1-56592-403-7, U$32.95/C$46.95
|
|
%A Scott Oaks scott.oaks@sun.com
|
|
%C 103 Morris Street, Suite A, Sebastopol, CA 95472
|
|
%D 1998
|
|
%G 1-56592-403-7
|
|
%I O'Reilly & Associates, Inc.
|
|
%O U$32.95/C$46.95 707-829-0515 fax: 707-829-0104 nuts@ora.com
|
|
%P 456 p.
|
|
%T "Java Security"
|
|
|
|
As the author notes, security means many different things to many
|
|
different people. In the general public, Java security tends to mean
|
|
browser and applet security, and the default applet "sandbox."
|
|
Therefore I feel obliged to point out that this book is primarily
|
|
concerned with the programming of security into systems, and the
|
|
security APIs (Applications Programming Interfaces) built into the
|
|
language to ease that task.
|
|
|
|
Chapter one looks at the overall security model for Java, and
|
|
particularly at the invocations of programs. Basic enforcement and
|
|
verification is covered in chapter two. Class loaders, in chapter
|
|
three, provide the programmer with a means to specify an almost
|
|
arbitrary level of security protection for a program. Chapter four
|
|
details the workings of the security manager, again providing the
|
|
programmer with the ability to set specific protections. The access
|
|
controller is new to Java 1.2, is the mechanism that the security
|
|
manager now uses to actually permit or deny use of resources, and the
|
|
object calls are discussed in chapter five. Implementation of access
|
|
and security policies through the class loader and security manager is
|
|
covered in chapter six.
|
|
|
|
Chapter seven looks at the need for authentication over open networks,
|
|
and the security provisions of digital signatures. The discussion of
|
|
cryptography itself is essentially non-existent since, as Oaks notes,
|
|
it is not necessary to understand it in order to use it. Those who
|
|
wish to test or implement strong encryption will need to go elsewhere.
|
|
Implementation of standard cryptographic protection is via security
|
|
providers, reviewed in chapter eight. Some simple message digest
|
|
implementations are described in chapter nine. Key management is an
|
|
important part of cryptography so chapter ten deals with keys and
|
|
certificates while chapter eleven reviews the handling of them.
|
|
Chapter twelve looks at the functions provided for dealing with
|
|
digital signatures. Specifics for encryption are listed in chapter
|
|
thirteen.
|
|
|
|
Appendices deal with security tools, identity based key management,
|
|
resources, and a quick reference chart.
|
|
|
|
While the book is well written it is not light, and is probably best
|
|
suited to those who are well familiar not only with Java programming,
|
|
but also the internals of the language. On the other hand, dealing
|
|
with security is a great way to learn the internals of a language.
|
|
|
|
copyright Robert M. Slade, 1998 BKJAVASC.RVW 980520
|
|
|
|
------------------------------
|
|
|
|
|
|
------------------------------
|
|
|
|
Date: Thu, 25 Apr 1998 22:51:01 CST
|
|
From: CuD Moderators <cudigest@sun.soci.niu.edu>
|
|
Subject: Cu Digest Header Info (unchanged since 25 Apr, 1998)
|
|
|
|
Cu-Digest is a weekly electronic journal/newsletter. Subscriptions are
|
|
available at no cost electronically.
|
|
|
|
CuD is available as a Usenet newsgroup: comp.society.cu-digest
|
|
|
|
Or, to subscribe, send post with this in the "Subject:: line:
|
|
|
|
SUBSCRIBE CU-DIGEST
|
|
Send the message to: cu-digest-request@weber.ucsd.edu
|
|
|
|
DO NOT SEND SUBSCRIPTIONS TO THE MODERATORS.
|
|
|
|
The editors may be contacted by voice (815-753-6436), fax (815-753-6302)
|
|
or U.S. mail at: Jim Thomas, Department of Sociology, NIU, DeKalb, IL
|
|
60115, USA.
|
|
|
|
To UNSUB, send a one-line message: UNSUB CU-DIGEST
|
|
Send it to CU-DIGEST-REQUEST@WEBER.UCSD.EDU
|
|
(NOTE: The address you unsub must correspond to your From: line)
|
|
|
|
CuD is readily accessible from the Net:
|
|
UNITED STATES: ftp.etext.org (206.252.8.100) in /pub/CuD/CuD
|
|
Web-accessible from: http://www.etext.org/CuD/CuD/
|
|
ftp.eff.org (192.88.144.4) in /pub/Publications/CuD/
|
|
aql.gatech.edu (128.61.10.53) in /pub/eff/cud/
|
|
world.std.com in /src/wuarchive/doc/EFF/Publications/CuD/
|
|
wuarchive.wustl.edu in /doc/EFF/Publications/CuD/
|
|
EUROPE: nic.funet.fi in pub/doc/CuD/CuD/ (Finland)
|
|
ftp.warwick.ac.uk in pub/cud/ (United Kingdom)
|
|
|
|
|
|
The most recent issues of CuD can be obtained from the
|
|
Cu Digest WWW site at:
|
|
URL: http://www.soci.niu.edu/~cudigest/
|
|
|
|
COMPUTER UNDERGROUND DIGEST is an open forum dedicated to sharing
|
|
information among computerists and to the presentation and debate of
|
|
diverse views. CuD material may be reprinted for non-profit as long
|
|
as the source is cited. Authors hold a presumptive copyright, and
|
|
they should be contacted for reprint permission. It is assumed that
|
|
non-personal mail to the moderators may be reprinted unless otherwise
|
|
specified. Readers are encouraged to submit reasoned articles
|
|
relating to computer culture and communication. Articles are
|
|
preferred to short responses. Please avoid quoting previous posts
|
|
unless absolutely necessary.
|
|
|
|
DISCLAIMER: The views represented herein do not necessarily represent
|
|
the views of the moderators. Digest contributors assume all
|
|
responsibility for ensuring that articles submitted do not
|
|
violate copyright protections.
|
|
|
|
------------------------------
|
|
|
|
End of Computer Underground Digest #10.40
|
|
************************************
|
|
|