[NEWSENDER] - Re: Is there a way to protect login page against a frequent submit? - Message is from an unknown sender

Li Wei Nan liweinan at chinaedu.net
Fri Feb 8 21:57:13 EST 2008


Thank you all very much. I'll try to use  
ThrottledSubmissionByIpAddressHandlerInterceptorAdapter firstly to  
see the performance. If there's any modifications
I'll send it back.

- Li Wei Nan

Le 2008-2-9 à 上午1:41, Scott Battaglia a écrit :

> Hopefully it works for you.  If you have any updates to it, please  
> feel free to contribute them back.
>
> On a side note, while the ThrottledSubmissionByIpAddress can  
> prevent requests from completely making it down the stack,  
> completely protecting yourself from DDOS attacks would require more  
> than this simple handler, as users are still making it to the CAS  
> server and can overload that. The request is dropped pretty early  
> before any heavy work is done, but enough could still take the  
> machine down.  True prevention and mitigation would most likely  
> require a more hardware based approach.
>
> -Scott
>
> On Feb 8, 2008 12:38 PM, Li Wei Nan <liweinan at chinaedu.net> wrote:
> Thank you all for your advices, it's really give me a lot of  
> inspirations :-)
>
> Considering that most of our clients are in-home guys using ADSL  
> instead of sitting behind a firewall of a big company, the chance  
> they share same IP address are rather small. So it may suitable for  
> me to use "ThrottledSubmissionByIpAddressHandlerInterceptorAdapter"  
> for now.
>
> I think both 'IP' and 'User' way have their pros and cons.
>
> Ole's concept for banning the submission by user is an alternative  
> way to achieve the similar goal. And it may give user a better  
> experience.
> From Ole's reply I didn't find the impl method to identify each  
> 'user', I guess it's using the session or the 'username' the user  
> entered in the login form.
> No matter how it's implemented, banned the request by 'user' has  
> another problem: it cannot protect the CAS server from DDOS attack,  
> if an attacker write a tcp program and sending a large amount of   
> random generated username/password(and surely he/she can re- 
> establish session each time),  the server cannot recognize it as  
> the same user and it will have to deal with those garbage infos,  
> and make server stop responding to normal users - actually that's  
> what really happened in our company recently.
>
> The IP way is obviously safer under this circumstance. Certainly if  
> the attcker is really working hard, the IP address can also be  
> faked, but our firewall can
> detect most of those forged tcp packages.
>
> So, In my opinion, the IP way is safer and the 'User' way is better  
> in user experience. For OUR COMPANY, since the CAS server now  
> bearing a dozen of universites login request, and considering the  
> DDOS attack happened before, I think  
> ThrottledSubmissionByIpAddressHandlerInterceptorAdapter is enough  
> for OUR COMPANY's PURPOSE.
>
> BTW, The following default value in  
> ThrottledSubmissionByIpAddressHandlerInterceptorAdapter seems  
> resonable to make it function properly. 100 thresshold will be  
> enough for us even if behind one IP there's hundreds of users.
>
>  /** Default value for the failure threshhold before you're locked  
> out. */
> 36
>     private static final BigInteger DEFAULT_FAILURE_THRESHHOLD =  
> BigInteger
> 37
>         .valueOf(100);
> 38
> 39
>     /** The default timeout (in seconds) to clear one failure  
> attempt. */
> 40
>     private static final int DEFAULT_FAILURE_TIMEOUT = 60
>
>
> I'll try to use  
> ThrottledSubmissionByIpAddressHandlerInterceptorAdapter soon and if  
> there's any problem I'll report it here :-)
>
> Thank you all for your helps~~
>
> Best Regards,
> Li Wei Nan
>
>
> Le 2008-2-9 à 上午12:15, Ole Ersoy a écrit :
>> I've been toying with the idea of making a filter as well.  I  
>> think it could be done by creating a CAS ServletContextLister that  
>> creates a data structure for storing:
>>
>> - user
>> - number of attempts
>> - time of last attempt
>>
>> The filter then grabs this data structure from the CAS  
>> ServletContext and uses it like this:
>>
>> If a user has made an attempt to login within say the last 15  
>> minutes, the number of attempts is incremented, given that it's  
>> not already at the max.  If it's at the max then the user gets a  
>> message saying that they have to wait X minutes before trying to  
>> login again.  If the user has made a login attempt before, but the  
>> attempt was made more than 15 minutes ago, then the filter resets  
>> the number of attempts to 1, and the cycle starts over again.
>>
>> If this were made as a component to CAS it should probably be an  
>> Action that is invoked before the initialFlowSetup.  So if user is  
>> allowed to attempt to login, then the next step is the  
>> initialFlowSetup, otherwise it's the too many attempts view-state.
>>
>> Cheers,
>> - Ole
>
>
> Le 2008-2-8 à 下午11:48, Ole Ersoy a écrit :
>
>> Scott,
>>
>> I did some research a while back, and one of the concerns  
>> regarding restrictions by IP is that a large number of users may  
>> sit behind a common IP / gateway / proxy, and that that IP will  
>> come through as the IP doing something funky.  So if that IP is  
>> blocked, then there's a possibility that other users will be  
>> automatically blocked as well.  Do you know if the interceptor  
>> mentioned below solves this concern by chance?
>>
>> Thanks,
>> - Ole
>>
>>
>>
>>
>> Scott Battaglia wrote:
>>> You may be able to use something like this:
>>>
>>> http://developer.jasig.org/source/browse/jasigsvn/cas3/trunk/cas- 
>>> server-core/src/main/java/org/jasig/cas/web/support/ 
>>> ThrottledSubmissionByIpAddressHandlerInterceptorAdapter.java?r=42053
>>>
>>> It hasn't been heavily tested but its supposed to restrict number of
>>> requests by IP Address.  If you do try and use it, please feel  
>>> free to
>>> provide us with any feedback or improvements :-)
>>>
>>> -Scott
>>>
>>> On Feb 8, 2008 12:03 AM, ??? <liweinan at chinaedu.net
>>> <mailto:liweinan at chinaedu.net>> wrote:
>>>
>>>     Thanks for your advice Ole, I've done some researches on  
>>> Geronimo and it
>>>     seems overkill to me.
>>>     It seems best for me to write a simple filter using session to
>>>     control the
>>>     attempting.
>>>
>>>     Thanks,
>>>     Li Wei Nan
>>>
>>>     ----- Original Message -----
>>>     From: "Ole Ersoy" <ole.ersoy at gmail.com  
>>> <mailto:ole.ersoy at gmail.com>>
>>>     To: "Yale CAS mailing list" <cas at tp.its.yale.edu
>>>     <mailto:cas at tp.its.yale.edu>>
>>>     Sent: Friday, February 08, 2008 4:26 AM
>>>     Subject: Re: Is there a way to protect login page against a  
>>> frequent
>>>     submit?
>>>
>>>
>>>> Hi Li,
>>>>
>>>> You can do this with a servlet filter that intercepts cas login
>>>     requests.
>>>> You would have to get the principal user, see if they have
>>>     attempted to
>>>> login with a specified time period, and redirect them to another  
>>>> page
>>>> explaining that they have made too many login attempts and that
>>>     they must
>>>> wait X minutes before attempting again.  I think Geronimo has
>>>     something
>>>> like this built in, but I'm still looking around for a standalone
>>>> implementation.
>>>>
>>>> Cheers,
>>>> - Ole
>>>>
>>>>
>>>>
>>>> Li Wei Nan wrote:
>>>>> Hi Everyone,
>>>>>
>>>>> Is there a plug-in or something like custom view could be used in
>>>>> cas-webapps to protect cas from malicious credential/principal
>>>     sniffer?
>>>>>
>>>>> Or maybe there's some configuration I can do in tomcat to achieve
>>>>> this goal which I don't know yet?
>>>>>
>>>>> Thank you for your helps,
>>>>>
>>>>> Li Wei Nan
>>>>> _______________________________________________
>>>>> Yale CAS mailing list
>>>>> cas at tp.its.yale.edu <mailto:cas at tp.its.yale.edu>
>>>>> http://tp.its.yale.edu/mailman/listinfo/cas
>>>>>
>>>> _______________________________________________
>>>> Yale CAS mailing list
>>>> cas at tp.its.yale.edu <mailto:cas at tp.its.yale.edu>
>>>> http://tp.its.yale.edu/mailman/listinfo/cas
>>>>
>>>
>>>
>>>     _______________________________________________
>>>     Yale CAS mailing list
>>>     cas at tp.its.yale.edu <mailto:cas at tp.its.yale.edu>
>>>     http://tp.its.yale.edu/mailman/listinfo/cas
>>>
>>>
>>>
>>>
>>> -- 
>>> -Scott Battaglia
>>> PGP Public Key Id: 0x383733AA
>>> LinkedIn: http://www.linkedin.com/in/scottbattaglia
>>>
>>>
>>> -------------------------------------------------------------------- 
>>> ----
>>>
>>> _______________________________________________
>>> Yale CAS mailing list
>>> cas at tp.its.yale.edu
>>> http://tp.its.yale.edu/mailman/listinfo/cas
>> _______________________________________________
>> Yale CAS mailing list
>> cas at tp.its.yale.edu
>> http://tp.its.yale.edu/mailman/listinfo/cas
>
>
> _______________________________________________
> Yale CAS mailing list
> cas at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas
>
>
>
>
> -- 
> -Scott Battaglia
> PGP Public Key Id: 0x383733AA
> LinkedIn: http://www.linkedin.com/in/scottbattaglia
> _______________________________________________
> Yale CAS mailing list
> cas at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas/attachments/20080209/84397499/attachment.html 


More information about the cas mailing list