[Eril-l] Sci-Hub users asking us to restore their access!

Tue Oct 4 12:59:59 PDT 2016

Well, that would require LDAP/Shibboleth (we use Shib with our ezproxy) to
also keep the country-filter. I figured since ezproxy already has some
config code to resolve and block IPs based on country, it would make more
sense to implement it there, as it would mean a lot more functionality to
add at the other level. We wouldn't want our Shib server to just start
Captcha'ing every single authentication - it would drive the rest of the
campus unrelated to the library services bonkers.

I will check out the EZProxy discussion list.

Melissa

On Tue, Oct 4, 2016 at 4:48 PM, Craig Boman <craig.boman at gmail.com> wrote:

> If I understand this issue correctly, the captcha wouldn't necessarily be
> implemented by EZProxy, but rather the authentication to EZproxy. In most
> cases I would presume this to be either LDAP or Shibboleth. Perhaps we
> should be encouraging these two organizations to use captchas, if they
> haven't already. Another option would be to enable two factor
> authentication for university resources. This is something my university
> has recently done.
>
> All the best,
> Craig
>
>
> Craig Boman, MLIS (Ph.D student)
> Applications Support Specialist
> University of Dayton Libraries
> Cboman1 _ at _ udayton _dot_ edu
> ORCID ID: 0000-0001-7511-4078
> "The reason is that good management itself was the root cause. Managers
> played the game the way it was supposed to be played. The very
> decision-making and resource-allocation processes that are key to the
> success of established companies are the very processes that reject
> disruptive technologies." -- Clay Christensen
>
> On Tue, Oct 4, 2016 at 3:24 PM, Steve Oberg <steve.oberg at wheaton.edu>
> wrote:
>
>> One suggestion I have is to direct this line of inquiry to the EZProxy
>> discussion list, where you might get more exposure to the issue plus a
>> forum that OCLC EZProxy representatives actively engage with. For details
>> see http://www.oclc.org/support/services/ezproxy/documentati
>> on/list.en.html
>>
>> Steve
>>
>> Steve Oberg
>> Assistant Professor of Library Science
>> Electronic Resources and Serials
>> Wheaton College (IL)
>> +1 (630) 752-5852
>>
>> NASIG Vice-President/President-Elect
>>
>> On Oct 4, 2016, at 2:19 PM, Melissa Belvadi <mbelvadi at upei.ca> wrote:
>>
>> That's a good point about demonstrating good faith in licensing terms.
>>
>> I've had a further thought, after having learned from Paul about some of
>> the country-specific options, that what we could really use in ezproxy is
>> the ability not to block an entire country across the board, but perhaps
>> for a given list of countries, require an additional step, and I'm thinking
>> CAPTCHA here rather than personalized second authentication.
>>
>> In this situation at least, it's pretty clear that software is running
>> through our proxy server, not a human being, so a CAPTCHA step might stop
>> it. I know CAPTCHAs are engaged in an escalating war of technologies, and
>> maybe the Sci-Hub hackers would know all of the tricks to beat them, but it
>> might be worth trying.  I don't think it would be a horrible thing to do to
>> our researchers over in Russia, China, etc. to have to answer a CAPTCHA
>> before establishing a proxy cookie - given all the press about
>> international hacking, I'd think they'd understand the need for it quite
>> well.
>>
>> So how does one go about getting OCLC to add new security features to
>> Ezproxy?
>>
>> Melissa
>>
>> On Tue, Oct 4, 2016 at 4:10 PM, Robert Heaton <robert.heaton at usu.edu>
>> wrote:
>>
>>> Thank you, Paul, for giving the great technical details.
>>>
>>>
>>>
>>> Melissa, we have not had this particular situation, but if I did, I
>>> would certainly include the what-you’re-doing-is-illegal messaging in my
>>> response to the users. While the language is different in each case, a
>>> great many of our license agreements require at least a good-faith effort
>>> to stop activities that are in breach of the license terms once we have
>>> become aware of them. Since we don’t know which vendors’ content they are
>>> accessing (then again, I suppose the proxy logs might clue you in), we may
>>> not be liable for not contacting the vendors when we learned of the breach.
>>> But I would hate for a vendor to think that I didn’t do my due diligence
>>> when the question originally came to me.
>>>
>>>
>>>
>>> Robert Heaton
>>> Interim Head of Collection Development
>>> Utah State University Libraries
>>> robert.heaton at usu.edu
>>>
>>>
>>>
>>> *From:* Eril-l [mailto:eril-l-bounces at lists.eril-l.org] *On Behalf Of *Butler,
>>> Paul
>>> *Sent:* Monday, October 03, 2016 2:08 PM
>>> *To:* Melissa Belvadi <mbelvadi at upei.ca>; eril-l at lists.eril-l.org
>>> *Subject:* Re: [Eril-l] Sci-Hub users asking us to restore their access!
>>>
>>>
>>>
>>> Hi Melissa,
>>>
>>>
>>>
>>> I must say this is the first time I have heard users from Sci-Hub
>>> reaching out to a library to request access be restored. That is comical!
>>>
>>>
>>>
>>> A polite educational email seems reasonable, but likely won’t do much to
>>> dissuade them – they just want access to the content by any means.
>>>
>>>
>>>
>>> Some techniques that can be used to secure EZProxy, that depend on you
>>> and your institution’s ability/comfort to tweak EZProxy...
>>>
>>>
>>>
>>> Tracking down and reporting the compromised user account to campus IT is
>>> the first step. While campus IT does their work I generally block the user
>>> account from EZProxy and terminate all active sessions.
>>>
>>>
>>>
>>> I maintain a list of referrers that I block from EZProxy. If you haven’t
>>> done that I would suggest it as another useful step. You can find it here:
>>> https://github.com/prbutler/EZProxy_IP_Blacklist/blob/master
>>> /EZProxy_IfReferer_Blacklist.txt
>>>
>>>
>>>
>>> You can also block access by country, if you are seeing trends and know
>>> a legitimate user would not come from a specific country. This is a good
>>> temporary measure. ALL access from a specific country can be blocked by
>>> adding the following to the top of config.txt. Country codes are the same
>>> as those in the audit logs.
>>>
>>>
>>>
>>> ::Common
>>>
>>> IfCountry US; Stop
>>>
>>> IfCountry BR; Audit Blocking BR; Deny denied.htm
>>>
>>> IfCountry CN; Audit Blocking CN; Deny denied.htm
>>>
>>> IfCountry IR; Audit Blocking IR; Deny denied.htm
>>>
>>> /Common
>>>
>>>
>>>
>>> Using Option BlockCountryChange can also help, see the documentation
>>> here: https://www.oclc.org/support/services/ezproxy/documentation/
>>> cfg/option-blockcountrychange.en.html
>>>
>>>
>>>
>>> Tweaking UsageLimit seems reasonable, it is always a balancing act,
>>> contact me off list if you would like to know what we use, or have any
>>> other questions.
>>>
>>>
>>>
>>> Finally, you can always block access by IP. I maintain the EZProxy IP
>>> Blacklist, which is a community supported effort to share IP addresses that
>>> have been used for fraudulent activity. See here:
>>> https://github.com/prbutler/EZProxy_IP_Blacklist. And if you are
>>> willing to share the IP addresses used for the fraudulent activity please
>>> send them my way and I can add them to the blacklist.
>>>
>>>
>>>
>>> With all of this, be sure to check your messages.txt file after you
>>> restart EZProxy to make sure nothing has broken.
>>>
>>>
>>>
>>> *Caveat emptor! *
>>>
>>>
>>>
>>> Cheers, Paul
>>>
>>> -------------------------------------------------
>>>
>>> Paul R Butler, mlis
>>>
>>> Library Technologies Support Analyst
>>>
>>> Library Information Technology Services (L.I.T.S)
>>>
>>> Ball State University <http://bsu.edu/>
>>>
>>> Muncie, IN  47306
>>>
>>> P: 765.285.8032
>>>
>>> E: prbutler at bsu.edu
>>>
>>>
>>>
>>> University Libraries*...a destination for research, learning, and
>>> friends*
>>>
>>>
>>>
>>> The University Libraries provide services that support student pursuits
>>> for academic success and faculty endeavors for knowledge creation and
>>> classroom instruction.
>>>
>>>
>>>
>>> *From:* Eril-l [mailto:eril-l-bounces at lists.eril-l.org
>>> <eril-l-bounces at lists.eril-l.org>] *On Behalf Of *Melissa Belvadi
>>> *Sent:* Monday, October 03, 2016 12:41 PM
>>> *To:* eril-l at lists.eril-l.org
>>> *Subject:* [Eril-l] Sci-Hub users asking us to restore their access!
>>>
>>>
>>>
>>> We've recently gotten a spate of emails sent to our ezproxy admin
>>> address from various users around the world, all basically complaining that
>>> we've somehow blocked their use of Sci-Hub (!) and asking us to restore
>>> their access.  One of them even sent a screenshot so we know what they're
>>> seeing is the "deny.htm" file in ezproxy.
>>>
>>>
>>>
>>> They are all very polite and seem to think they are entitled to access,
>>> as if they have no idea what they are doing is illegal, or that the address
>>> they are writing to is for an institution that is unwittingly involved as a
>>> result of being hacked.
>>>
>>>
>>>
>>> Here's an example of one such email (leaving off the signature part -
>>> they are all very open as to who they are):
>>>
>>> I’m a French OT student, actually doing litterature researches for my
>>> studies. I’m using scihub to get some articles that I need to reed for that
>>> work. Today my access has been blocked.
>>>
>>>
>>>
>>> I would be very grateful to you if you could open my access.
>>>
>>> And another:
>>>
>>> My access to sci-hub has been temporarily denied, due to excessive
>>> downloads. I am sorry but I am actually writing my thesis and need to read
>>> that many articles.
>>>
>>>
>>>
>>> I would be really grateful if you could give my access back. I cannot
>>> afford paying for all those articles online. My thesis is due for early
>>> November. You guys are my only option.
>>>
>>>
>>>
>>> We've been able to use our ezproxy logs to trace back the most recent
>>> activity to a particular student's compromised account, and dealt with that
>>> one that we could find.
>>>
>>>
>>>
>>> If I understand what's happening, Sci-Hub has collected a huge number of
>>> compromised usernames/passwords from many institutions and tries them
>>> (right through our proxy server) when the article someone requests from
>>> them is not already in their archive. If so, it's probably rare that this
>>> illegal use will even trigger an "excessive use" denial and consequently
>>> any chance of us even knowing this is going on.
>>>
>>>
>>>
>>> Has anyone else gotten emails like this?
>>>
>>>
>>>
>>> If so:
>>>
>>> How do you handle it, aside from trying to find the breached account? Do
>>> you try to explain to the "user" that what they're doing is illegal?
>>>
>>> Are you further lowering your max downloads for major publisher sites to
>>> try to stop it?
>>>
>>>
>>>
>>> --
>>>
>>> Melissa Belvadi
>>>
>>> Collections Librarian
>>>
>>> University of Prince Edward Island
>>>
>>> mbelvadi at upei.ca 902-566-0581
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> Melissa Belvadi
>> Collections Librarian
>> University of Prince Edward Island
>> mbelvadi at upei.ca 902-566-0581
>>
>>
>> _______________________________________________
>> Eril-l mailing list
>> Eril-l at lists.eril-l.org
>> http://lists.eril-l.org/listinfo.cgi/eril-l-eril-l.org
>>
>>
>>
>> _______________________________________________
>> Eril-l mailing list
>> Eril-l at lists.eril-l.org
>> http://lists.eril-l.org/listinfo.cgi/eril-l-eril-l.org
>>
>>
>
> _______________________________________________
> Eril-l mailing list
> Eril-l at lists.eril-l.org
> http://lists.eril-l.org/listinfo.cgi/eril-l-eril-l.org
>
>

-- 
Melissa Belvadi
Collections Librarian
University of Prince Edward Island
mbelvadi at upei.ca 902-566-0581
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.eril-l.org/pipermail/eril-l-eril-l.org/attachments/20161004/14a683f6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 17489 bytes
Desc: not available
URL: <http://lists.eril-l.org/pipermail/eril-l-eril-l.org/attachments/20161004/14a683f6/attachment.png>