Internet security

[R124C41 at aol.com]

With regard to [metart1 at metgate.metro.org] Floyd T. Sweeting III's question
about Internet Security and so forth, here is a lengthy response that will
bore all the experts on this list but may be helpful to other beginners, so
press that delete key now if you are in the first category and read on if you
are in the second.  Experts are welcome to correct my errors, as always, of
course.

--David Ritchie
--R124C41 at AOL.COM
--Naperville, IL 60563

=======================================================

Here's my take on the questions specifically concerning museum libraries as
asked by Sweeting.  I am having to do a lot of guessing but hopefully I will
be approximately right.

>My institution is currently planning a LAN (Novell) which will 
>connect PCs to one another and to a CD server and to the OPAC 
>(Unix box) and to some local databases (such as STAR) and to 
>bibliographic utilities (mainly RLIN) via a leased line to the 
>Internet. 

>Do we need a separate server to run TCP/IP (Internet 
>clients..email, telnet, ftp, web browser) or can those be 
>installed on the LAN server?

You need some sort of software to let your PC's talk TCP/IP protocol over the
wires which hook them together to make your Novell LAN.  

Your leased line from "the Internet" will have to connect to some box--either
the unix box that runs your OPAC or the LAN server or some other box (like a
router or some such thing).  Since you didn't mention the latter (unless it's
the firewall but you only refer to software, not hardware), I am going to
assume that such a box is not planned.  Generally, in small installations,
that is the case.

Normally, the "clients...email, telnet, ftp, web browser" are programs that
are placed on the individual hard drives of the PC's.  The up side of this is
that the arrangement provides the best speed in launching the programs.  The
down side is that someone has to install those programs on the PC's and keep
them up to date.

Another alternative is to place those client programs on the LAN server.  The
down side is that launching them on an individual PC requires bringing the
programs across the LAN which takes some time.  The up side is that
installing them can be done once on the LAN so updating them is simpler.

For a small installation with a few PC's (<15 or so), I would tend to prefer
the first alternative over the second but it is clearly a judgement call that
is dependent on how often such activity is done, the speed of the LAN, etc.
 The nice thing is that one can change one's mind and do it the other way
without buying much more hardware, etc. if one wants.  A hybrid approach is
even possible.  [Library Director with stuff on hard disk; other folks with
stuff on LAN server.]

>The library, of course, plans to offer access to our OPAC and 
>in-house research databases, with a Home Page envisioned at a
>later stage. 

I find this a strange order of tasks.   I would begin with doing a home page
(presumably hosted off your OPAC unix box or your LAN server).  When that is
in place, I would move to providing access to the OPAC and in-house research
databases.  

The first reason is that I think it is easier.  

The second reason is that it gives you an early presence and visibility--even
if it is only a relatively static text home page with a few graphics.  

The third reason is that your home page development is more likely to
influence how you provide your follow-on access than the other way around so
you will get a more integrated look and feel via this order.  

Finally, the fourth reason is that the home page is more of a concept,
generalized info, sort of thing into which the librarians can have a lot of
input and put the stamp of the library on it as a driving force.   The other
way the computer types will have more of a influence early on.  So this order
lets the librarians stay more in the driver's seat.

>(Security, firewall software, etc. Gauntlet)

Someone else will have to answer in regard to Gauntlet as I am not familiar
with it.  I will make the following general comments.  Others are welcome to
disagree.

With security, it's always a question of balancing risks of potential loss
against costs of protection.  

The first worry is hacking into systems.  In general, if you don't allow
mechanism to "login" to the PC's or LAN server on the LAN (e.g., no software
that allows FTP from the net *into* the PC's or LAN), it is my opinion that
you will be pretty secure against someone hacking their way into the systems.
 

I assume that the PC's will be used mostly to go out to other places via web
browsers, ftp client, telnet, etc.  So, you should have no reason to provide
in-bound mechanisms and should be ok.

The second worry is files being able to be read from other PC's on the LAN,
the Unix box, or from over the net.  Your biggest concern here is PC to PC or
PC into LAN server files and for this  whoever sets up your LAN network needs
to do a good job and know who is supposed to be able to share files with
whom.  

In my opinion, there is relatively little concern about getting at files from
the net, provided you keep login ability off the PC's.  That is, no one
should be running an FTP *server* on their PC--FTP client is ok, of course,
assuming that any server piece is disabled.

The third worry is web browsers being able to access more than what the
server is supposed to provide.  If the web server is on your unix OPAC box
and most of your sensitive files are on your PC's, then this nicely isolates
things.  Care should be taken to set the server up correctly in any case.  

If you choose to have your web server s/w on your LAN server and if your
sensitive files are there, then you will have to be more careful.  Much
depends on what is kept in files and where.  Personnel files need very
special treatment.  Financial files need special treatment.  Other sorts of
files perhaps need ordinary care.   But that really you have to decide.

All these comments should not put you off of doing things.  You simply need
to get educated and/or buy expertise if you are going to get into the
sensitive areas early--such as keeping files of a personnel or financial
character on the LAN server *and* also maintain a web server on the same LAN
disks.

>How was a balance of access (for library resources meant to 
>be shared) vs. protection (for sensitive museum collection 
>information) achieved?  

My own bias would be towards having the unix box be the place for sharing and
the PC/LAN server be the place for business confidential matters.  In recent
mail to this list, one person has described a successful method of updating
web server files on a unix box from PC's that are used to author the files.
 Looking into tools that would aid that approach (compose in word perfect on
PC's, convert to HTML, etc., and put in place on web server through the
services of one individual acting as web server editor) would be something I
would do.

>Do you provide access to "live" databases (I'm thinking of >providing a port
or two designated for anonymous "query-only" >access to the OPAC).  

Sure.  Why not?  If your OPAC vendor is with it, they will have already
provided web-to-OPAC interface s/w.  If they haven't, then you should be
looking at replacing your OPAC product and vendor. [Sort of just joking but
not quite...]   I would question "ports" unless you need to provide
non-Internet access (e.g., dial-in access).  Probably that is the case but I
think over time that will go away (how long?) and we can get rid of all those
modem banks.

Keeping a basic level of information hidden from the web is only asking for
obscurity.  If there is information which is somehow more expensive to
provide, then you can always have a portion of your web offering restricted
by patron name and password and make it available only to those patrons who
pay a fee, etc.

>How is this configured? 

You obtain web server software for your unix box, either the free stuff from
CERN or NCSA or the for fee stuff from some vendor.  Your OPAC vendor
provides you with appropriate scripts or software that lets the web server
s/w make requests of the OPAC on behalf of a remote browser.  The browser out
there talks over TCP/IP to your web server on your unix box.  The web server
software talks to the OPAC, using the vendor scripts or s/w.  Any info the
OPAC passes back to the server, the server provides to the browser.

>Where does it sit in relation to the firewall? 
If the leased line comes into the LAN server (assuming it can handle that
sort of thing), then the LAN server is your "firewall" (maybe it runs this
Gauntlet software?) and it stands  in a logical software sort of way between
the external browser and the web server running on the unix box. 

>I've heard that the safest option is to run a copy of the OPAC
>on a separate server.  Wouldn't this need constant update and 
>be expensive. 

Of course, more isolation is always safer and reduces the technical
opportunity for nasty business.  But at some point the procedures required to
get around the isolation for legitimate purposes become extremely burdensome
(like having to do constant updates and stuff).  You still need motive in
addition to opportunity.  You had better have some awfully important state
secrets that you are protecting.

A well versed systems librarian *with* management backing to enforce proper
account/password procedures (e.g., not even the library director should be
allowed stupid easily guessed passwords) and set up and monitor accesses and
backups is the first thing to arrange.  Usually, it's poor physical security
that gets you, first. (And that includes poor physical security with respect
to your backup tapes!) Then, it's sloppy system management practices
(loginless accounts, easily guessed passwords, etc.) that get you, second.
 After that, come the backdoor, hacker exploitations of bugs.

I am a little puzzled by your focus on a firewall.  Although it can do a
certain amount of filtering of appropriate access, etc., I am of the opinion
is that its main purpose is to insure that there is one and only one
connection from the net to your facility so that in dire circumstances you
can sever the connection, get isolated, and fix whatever hole has been found
that causes things to be "dire".  What you don't want is each PC having their
own "special" TCP/IP access to the internet because then you have to run
around, find all those connections and break them.  In small installations,
this circumstance is unlikely simply because of cost issues.

--David Ritchie
--R124C41 at AOL.COM
--Naperville, IL 60563