98
edits
Changes
m
→Securing EZproxy
==Securing EZproxy==
(Mag II)At the request of several individuals I'm keeping actual names of individuals involved in the discussion private. If you contribute or add to these notes, feel free to identify yourself, but please don't identify others
There was a mixture of general discussion on ezproxy, as several individuals haven't had experience with any security issues but came to the breakout hoping to learn more about ezproxy. The notes below are a bit disjointed for that reason. Started some general discussion based off of recent issues an institution had with a large-scale of compromised accounts being used by two different organizations. Organization 1: a website called scihub.org that acts as a web search/proxy itself and rotates through compromised accounts to fetch articles. Organization 2: a group based in China that seem to be employing actual humans to go and downloaded lists of contents. (Downloading is during Chinese business hours, there's no traffic on Chinese holidays, etc) Some approaches taken by this University have been: * rsyslog the ezproxy logs w/ campus IT. The campus IT runs the Shibboleth instance, which feed into a splunk system with several other inputs including VPN and machine usage. Allows for detection of compromised accounts logging in from different areas of the world near the same time. Also allows more folks to aid in detecting compromises.* x-forwarded-for turned on with cooperating vendors. This allowed them to spot ip addresses used multiple times w/ a proxy.* some ip address of compromised accounts. VPN blocking was brought up, but not many people practicing. There's been issues with organizations using compromised accounts of other schools to make tracking the origin ip harder. There's a github project for this (I believe the person was talking about https://github.com/bertrama/ezproxy-config/blob/master/reject-ip-vpn). Some folks are looking for excessive downloads via scripts. Also if the same name from different ip addresses in roughly the same time is flagged for suspicious behavior/possibly compromised accounts. Also common to have campus IT looking for multiple logins from same spot. Some more general discussion on maintaining ezproxy came up: Several schools have web interfaces for specifying resources which then create the config files automatically. A backup is made of the last config file. Allows librarians to edit without having IT be a bottleneck. Most common problem is actually issues w/ space due to logs. Political/cost issue more than technical. Logrotate w/ bz2ip can help, but will hinder analysis. Retention policy is important. One school keeps logs for 90 days to aid with detection from vendor complaints, then anonymization/sanitizing them to allow analysis without individual details. Several schools do not include identifying information ever in logs, for various political and privacy concerns. (Linking identity w/ urls searched). Makes more difficult than necessary. some questions on how difficult it is to maintain EzProxy. General consensus is pretty easy. Will lock up and require restarts, but is pretty rarely. At least on eschool uses version control w/ the config files to make sure easy to roll back from mistakes. One place also using puppet to push out some of these files. Alumni configuration a common issue, most folks seem to break apart into own group and hten either have local logins or a shibboleth attribute. Several schools using shibboleth. Some other points that came up: Also important: making sure that the entire stack of the authentication/authorization is properly protected, harder to even trust inside of the network. Some discussion also came up on password policies (or what to try to get campus IT to enforce): * Make sure strong passwords enforced* Make sure that checking for similar passwords as previous passwords, to avoid easily guessable password once an account is already compromised) ==Tech serviceservices==(Pine Oak) We shared projects, challenges, and areas of interest *Linked data for acquisitions info and the Global Open Knowledgebase*Changing roles for catalogers -- description of unique resources, data extraction and manipulation, linked data*ILS migrations*Managing multiple systems and silos (ERM, ILS, ERP, archives)*Managing DDA (demand driven acquisitions)*Skills for catalogers -- computational thinking*Trends toward fewer professional librarians in tech services*Accepting ambiguity*CORAL open source ERM A few discussion topics emerged '''Ticketing systems''' *We use different ones -- mostly we get whatever our IT department already has*Helpful for representing electronic resources -- there's no physical presence to remind you to do the work*Helpful for metrics*One barrier to use can be training others to use the systems rather than contacting an individual directly '''DDA''' *A lot of people have to be involved -- collections, tech services, IT*Duplicate records between existing collection and DDA records -- we don't always realize where duplication exists*People want to be able to activate DDA records in their e-resources knowledgebase -- ideally we'd have our book jobber help with updating the kb*Important to a have a good vendor rep*We weren't able to understand the entire process at the start -- every step was like a new discovery*A challenge is getting quality records and identifying records that need additional work '''MARC record services -- how do you evaluate quality?''' *For ebooks, they can be really bad*Many people are using MARC edit to do batch processing of records, find things that need to be fixed*Suggested use of regular expressions to pull things out of leader field*Another common practice is to use various methods to convert MARC records to Excel and look at errors there*Some of us are using OpenRefine to find problems*Some of us are becoming more error tolerant, but the cool stuff that people do is dependent on good data
==AngularJS==
