Logging user ID's has a benefit if it's used properly (access tightly
controlled to a select group)

If campus ID's are being used by bots to harvest content, it means that you
have users whose credentials are compromised. Whoever obtained this
information also has access to e-mails, student records, and personal
information. It's a benefit to everyone if this information gets recorded
and reported to campus IT (so the user can have their password reset etc..).

The worst part is, this happens much more then you would expect. I
developed an application (https://github.com/ryersonlibrary/EZ-Analyzer) to
help analyze logs for suspect behavior (it still requires your judgement,
but it helps identify users with very high usage, or show if they are
logging in from different parts of the world)

-Steven

On Thu, Nov 20, 2014 at 3:14 PM, Joe Hourcle <[log in to unmask]>
wrote:

> On Nov 19, 2014, at 11:47 PM, Dan Scott wrote:
>
> > On Wed, Nov 19, 2014 at 4:06 PM, Kyle Banerjee <[log in to unmask]>
> > wrote:
> >
> >> There are a number of technical approaches that could be used to
> identify
> >> which accounts have been compromised.
> >>
> >> But it's easier to just make the problem go away by setting usage
> limits so
> >> EZP locks the account out after it downloads too much.
> >>
> >
> > But EZProxy still doesn't let you set limits based on the type of
> download.
> > You therefore have two very blunt sledge hammers with UsageLimit:
> >
> > - # of downloads (-transfers)
> > - # of megabytes downloaded (-MB)
>
>
> [trimmed]
>
> I'm not familiar with EZProxy, but if it's running on an OS that you have
> control of (and not some vendor locked appliance), you likely have other
> tools that you can use for rate limiting.
>
> For instance, I have a CGI on a webserver that's horribly resource
> intensive and takes quite a while to run.  Most people wonder what's taking
> so long, and reload multiple times, thinking the process is stuck ... or
> they know what's going on, and will open up multiple instances in different
> tabs to reduce their wait.
>
> So I have the following IP tables rule:
>
>         -A INPUT -p tcp -m tcp --dport 80 --tcp-flags FIN,SYN,RST,ACK SYN
> -m connlimit --connlimit-above 5 --connlimit-mask 32 -j REJECT
> --reject-with tcp-reset
>
> I can't remember if starts blocking the 5th connection, or once they're
> above 5, but it keeps us from having one IP address with 20+ copies running
> at once.
>
> ...
>
> And back from my days of managing directory servers -- brute forcing was a
> horrible problem with single sign-on.  We didn't have a good way to
> temporarily lock accounts for repeatedly failing passwords at the directory
> server (which would also cause a denial of service, as you could lock
> someone else) ... so it had to be up to each application to implement ...
> which of course, they didn't.
>
> ... so you'd have something like a webpage that required authentication
> that someone could brute force ... and then they'd also get access to a
> shell account and whatever else that person had authorization for.
>
> -Joe
>
>
> (and on that 'wow, I feel old' note ... it's been 10+ years since I've had
> to manage an LDAP server ... it's possible that they've gotten better about
> that issue since then)
>



-- 
Steven Marsden - Library Systems Analyst
Tel: 416-979-5000 x 4635
Ryerson University Library
350 Victoria Street.  Toronto, ON.  M5B 2K3