[NEWSENDER] - Re: Is there a way to protect login page against a frequent submit? - Message is from an unknown sender
Scott Battaglia
scott.battaglia at gmail.com
Fri Feb 8 12:41:31 EST 2008
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<http://developer.jasig.org/source/browse/jasigsvn/cas3/trunk/cas-server-core/src/main/java/org/jasig/cas/web/support/ThrottledSubmissionByIpAddressHandlerInterceptorAdapter.java?r=42053#l36>
> *private* *static* *final*
> BigInteger DEFAULT_FAILURE_THRESHHOLD = BigInteger
> 37<http://developer.jasig.org/source/browse/jasigsvn/cas3/trunk/cas-server-core/src/main/java/org/jasig/cas/web/support/ThrottledSubmissionByIpAddressHandlerInterceptorAdapter.java?r=42053#l37>
> .valueOf(100);
> 38<http://developer.jasig.org/source/browse/jasigsvn/cas3/trunk/cas-server-core/src/main/java/org/jasig/cas/web/support/ThrottledSubmissionByIpAddressHandlerInterceptorAdapter.java?r=42053#l38>
> 39<http://developer.jasig.org/source/browse/jasigsvn/cas3/trunk/cas-server-core/src/main/java/org/jasig/cas/web/support/ThrottledSubmissionByIpAddressHandlerInterceptorAdapter.java?r=42053#l39>
> */** The default timeout (in seconds) to clear one failure attempt. */
> *
> 40<http://developer.jasig.org/source/browse/jasigsvn/cas3/trunk/cas-server-core/src/main/java/org/jasig/cas/web/support/ThrottledSubmissionByIpAddressHandlerInterceptorAdapter.java?r=42053#l40>
> *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 <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<ole.ersoy at gmail.com>
> >>
> To: "Yale CAS mailing list" <cas at tp.its.yale.edu
> <mailto:cas at tp.its.yale.edu <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 <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 <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 <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas/attachments/20080208/fa0e5797/attachment.html
More information about the cas
mailing list