 |
 |
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)