On Nov 19, 2014, at 11:47 PM, Dan Scott wrote:
> On Wed, Nov 19, 2014 at 4:06 PM, Kyle Banerjee <kyle.baner...@gmail.com>
> 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)
