RE: Non-IP Based Institutional Subscriptions?

[Ann Okerson <ann.okerson@yale.edu>]

Liblicense-l readers:  this message was sent to the list on the 12th and
was garbled up in going through the listproc software, for some
inexplicable reason.  So, for those interested in EZProxy, here it is
re-formatted and re-sent to you again.

---------- Forwarded message ----------
Date: Wed, 12 Dec 2001 18:46:10 EST
From: Tom Murray <tmurray@engr.wisc.edu>
To: liblicense-l@lists.yale.edu
Subject: RE: Non-IP Based Institutional Subscriptions?

Thanks to our Wisconsin-Madison technical staff, I offer the email below
from the ezproxy discussion list, re some of the concerns raised here
about ezproxy.  The stated concern is followed by a discussion of why, in
the responder's opinion, 'it is a non-issue' (go to the place that phrase
appears).

Our campus library technology group agrees with that assessment and we are
using ezproxy.

Tom Murray
Wendt Engineering Library
University of Wisconsin-Madison


>From: Chris Hoogendyk <<choogend@library.umass.edu>
>Date: Tue Dec 11, 2001  10:29:16 AM US/Central
>To: "EZProxy discussion list" <<ezproxy@ls.suny.edu>
>Subject: [ezproxy] Re: EZProxy security issues

>comments below.

>Terry Nikkel wrote:
>
>We are looking at switching from AutoProxy to EZProxy, but a member of
>my department has looked at the configuration information and has the
>following objection:
>
>"For ease and convenience EZProxy requires the following record to be
>added to the DNS (Domain Name Server) of your local network:-
>
>   Server Name Server IP
>   www.yourlibrary.com IN A 1.2.3.4
>   *.www.yourlibrary.com IN A 1.2.3.4
>
>Using the first record everyone in the world knows that
>www.yourlibrary.com goes to the associated IP 1.2.3.4 and so all
>requests on your network are then routed to the machine with the IP
>1.2.3.4 ..
>
>However, the second record is needed to be added to the DNS for EZProxy
>not requiring a seperate port for authentication, where EZProxy
>randomly gives a unique name for each request and so you need the *
>(wildcard) in front of the server name so that all those requests are
>again routed to your server.
>
>The problem with the above however is that imagine the repercussions of
>
>having such a record in the DNS. Now anyone in the world could have a
>name of the sort baduser.www.yourlibrary.com and take over your IP for
>their use.  They could go and hack machines all over the world and the
>blame would come to your server or your network; would that be
>acceptible?
>
>The above is just one example of what could be a potential problem,
>however I could think up a lot more problems with this and so we are
>trying to convince our libraries to stick with the traditional
>AutoProxy, even though it may be a bit problematic with a few of the
>browsers around."
>
>How do others deal with this issue?  Do you go with the URL rewriting
>strategy?  If so, how do you configure firewalls to support the range of
>required ports?
>
>I think it is a non issue.
>
>As a public service institution, we have to have a known address. People
>on the outside need to be able to reach us. To remain totally hidden is
>to not provide any services.
>
>So, what if someone knows your address? If that was all that was needed
>to cause trouble, we could all pack up and go home.
>
>A hacker still needs some kind of foot in the door. If your system is
>secure, locked down, with up to date patches, with unnecessary services
>and ports turned off, then you have little to worry about. Hackers are
>going to find the easy systems to break into. Or the really juicy ones.
>
>A plain vanilla library server that is reasonably well secured isn't a
>particularly desirable target. Of course, there are no guarantees.
>
>People with the skills to do IP spoofing and hijacking still need to get
>a foot in the door somewhere. If the campus DNS server were not secured,
>and they could get into it, then they could redirect any of your
>addresses to themselves. Don't need a wild card entry to do that. I
>believe that the Microsoft network was taken down earlier this year by
>the hacking of an insecure DNS server (both easy and juicy).
>
>Anyway, the existence of a DNS entry with a wildcard does not, in itself,
>constitute a security hole. All it is saying is that if someone
>requests the address of any server name in that domain space (say
>ralph.ezproxy.yourlibrary.edu or george.ezproxy.yourlibrary.edu) then
>the DNS server should direct them to the same IP address as
>exproxy.yourlibrary.edu.
>
>hmmm. Wasn't there a primitive tribe somewhere, or some religion or
>ethnic group, that thought if you knew a persons name you could control
>them?
>
>Chris Hoogendyk
>
>Network Specialist & Unix Systems Administrator
>Library Information Systems & Technology Services
>W.E.B. Du Bois Library
>University of Massachusetts, Amherst
><choogend@library.umass.edu>