Just understood you. Really appreciate for your feedback.
How do we judge it's a robot? item1: we find the request IP is always the same one. item2: our page may contains several keep-alive connections. But the attack connection only focus on connection. Based on these 2 items, we think the client is a robot. I think maybe putting these 2 items together to consider it as a robot is a bit complex. Let's do it from the simple point. If we alway find there is a same IP request our website the same url for many times, can I block this request at httpd level? Thanks, At 2015-05-19 20:01:00, "David kerber" <dcker...@verizon.net> wrote: >On 5/19/2015 7:53 AM, javalishixml wrote: >> >> >> >>> I doubt you're going to be able to do this in httpd, unless you have a very >>> simple, straight forward way of identifying the robots. >> Yes. I just want to have a way to block the duplicated requests at httpd >> level. After all, my website has to face the the big concurrency issue. > >I understand that's what you want. What we're telling you is that you >probably won't be able to do that. > >Let me ask the question again, that Chris asked before: how do you tell >that a given request is from a robot? > >The answer to that question will determine if you can block it with httpd. > >> >> >> >> >> >> At 2015-05-19 19:35:26, "David kerber" <dcker...@verizon.net> wrote: >>> On 5/19/2015 1:03 AM, javalishixml wrote: >>>> Thanks a lot for your information. >>>> >>>> >>>> This solution is based on tomcat level. If I always handle this issue at >>>> java level, I'm afraid it has performance issue. Because this web site >>>> afford a very big concurrency access. >>>> >>>> >>>> Taking a consideration on its basic architect tomcat+apache, I think the >>>> best way to move this solution from tomcat to apache. So do you have some >>>> good solution at apache's configuration? I understand this is a mail list >>>> for tomcat.. but just want to get any information >>> >>> I doubt you're going to be able to do this in httpd, unless you have a >>> very simple, straight forward way of identifying the robots. >>> >>> >>> >>>> >>>> >>>> Thanks, >>>> >>>> >>>> At 2015-05-19 04:00:28, "Christopher Schultz" >>>> <ch...@christopherschultz.net> wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA256 >>>>> >>>>> To whom it may concern, >>>>> >>>>> On 5/18/15 11:44 AM, javalishixml wrote: >>>>>> I have a website. It is built by apache + tomcat. >>>>>> >>>>>> Now we make a lottery activity at this website. But we find that >>>>>> some robots always raise the duplicated requests to hit this >>>>>> lottery activity. It causes that robots almost get all the awards. >>>>>> >>>>>> So we just want to block these kind of duplicated requests at every >>>>>> interval unit. For example, we set the interval unit is 3 seconds. >>>>>> The if the robot want to hit the lottery activity in 3 seconds, the >>>>>> website could block this action. >>>>>> >>>>>> So how to do it? I suppose if we do it at tomcat level, is it a >>>>>> very low performance? Can I do it at apache level? how to do it? If >>>>>> I could not do it apache level, can I do it by setting sth at >>>>>> tomcat? >>>>> >>>>> If you have a way to identify a "duplicate" request (e.g. using a >>>>> fingerprint of the request that you can check during that 3-second >>>>> interval), then this is conceptually very easy. >>>>> >>>>> It may not be great for performance, but you'll have to weigh that >>>>> against your own requirements. (For example, which is worse: poor >>>>> performance, or a site where only robots ever win the lottery?) >>>>> >>>>> This will not be something you can configure in Apache httpd or >>>>> Tomcat. This will have to be an application thing (unless you can >>>>> describe the fingerprint technique to some httpd module such as >>>>> mod_security or mod_qos and then allow it to discard duplicates). >>>>> >>>>> Back to the solution: >>>>> >>>>> 1. Take a fingerprint of the request >>>>> 2. Lookup the fingerprint in a database of previous requests >>>>> ( fingerprint -> latest timestamp ) >>>>> 3. If the fingerprint appears in your database and the timestamp is >>>>> less than 3 seconds ago, discard the request >>>>> 4. Otherwise, store the current timestamp and fingerprint in the databas >>>>> e >>>>> >>>>> For a database, I might recommend something like memcached or another >>>>> in-memory-style database. An in-memory key-value store is really what >>>>> you are looking for. Memcached has a nice feature where values can >>>>> automatically time-out (e.g. they are invalid after 3 seconds), so you >>>>> can make your application code a bit simpler because you'll never have >>>>> a value in the database that is not valid. >>>>> >>>>> Hope that helps, >>>>> - -chris >>>>> -----BEGIN PGP SIGNATURE----- >>>>> Version: GnuPG v2 >>>>> Comment: GPGTools - http://gpgtools.org >>>>> >>>>> iQIcBAEBCAAGBQJVWkTcAAoJEBzwKT+lPKRYnW0QAIeRbfJtsTKtUZHUig9sIRre >>>>> y1mgJkPxBXjcRTfoZkZkTPhasYzINE1mb1mTPKfPbQveH+OmpawDREWJxg/6dFeg >>>>> af734ZRpBOAs4MtlCyTXgBUWpWka5CcpeIRYeEwx5GKPFLJfTBbGpswV3HwLaoEC >>>>> /NqMByVfwHnixBxSTGAM2GIOyrPf+Ii1Z0JpQyDEYcZUS3Dc3IFFeHPTvzQUb1SO >>>>> NB84fwjDT6GG/YerrlRV3GHL3WYhAw1n+tQ9cCpSWDvz8/KLUyKXqVjX5s/FbuB+ >>>>> S+krz2jzKqxG8bdeixW4s0i/9gyA/KcSSDgwmBnRwHsIUDvfF3pzk1Vq7rfGNpmQ >>>>> L9V4brxL41H+ZMIDt2NjkVJb/UjgMnL5RpfQ1t+MdNvys/7UYav+vOv8jWqI3Mse >>>>> AXNv46mQZAiMFzs/nsR7OIVLLxU70l+wbys4mK6u34uDip5gzxvVSaYKviqgKspx >>>>> LT6MUHOpgmBhsiCUxjJ5odA4Q6mYhMfQxOB+6Ej8jRfKMT2uDTlwvU8gZ+/7TcUX >>>>> JXngjQLQyjj+gAO+7jS7sWpaakV1ojy8/nFBVWH/3tWoo0YD89DJCRWxA8x8slfx >>>>> oI9BGA0T7EwuX1CnqM90OLw7dymMQvwsTlkPAZnIvnWw3Xz29hIRazxQ7NR3AdCk >>>>> vNXsseUzO18IJ4n+By1G >>>>> =Q/ki >>>>> -----END PGP SIGNATURE----- >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>>> For additional commands, e-mail: users-h...@tomcat.apache.org >>>>> >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >> > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >For additional commands, e-mail: users-h...@tomcat.apache.org >
