Brute force attacks aren't the problem. There's a simple param in EZproxy
that blocks an IP and/or user account after a certain number of failed
logins. I suspect that the problem is that attackers already have valid
login credentials from one of the thousands of security breaches in the
last few years.

Josh Welker


-----Original Message-----
From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of
Joe Hourcle
Sent: Thursday, November 20, 2014 2:15 PM
To: [log in to unmask]
Subject: Re: [CODE4LIB] Balancing security and privacy with EZproxy

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)