98
edits
Changes
→Securing EZproxy
==Securing EZproxy==
(Mag II) {warn}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{warn} 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 services==
