Agreed, it is pretty easy to create a large variety of denial of service attacks with sorts, wildcards, requesting a large number of results, or a page deep in the results.
We have protected against several different DoS problems in our front-end code. wunder On 11/16/08 3:12 PM, "Ian Holsman" <[EMAIL PROTECTED]> wrote: > Erik Hatcher wrote: >> >> On Nov 16, 2008, at 5:41 PM, Ian Holsman wrote: >>> First thing I would look at is disabling write access, or writing a >>> servlet that sits on top of the write handler to filter your data. >> >> We can turn off all the update handlers, but how does that affect >> replication? Can a Solr replicant be entirely read-only in the HTTP >> request sense? >> >>> Second thing I would be concerned about is people writing DoS queries >>> that bypass the cache. >>> >>> >>> so you may need to write your own custom request handler to filter >>> out that kind of thing. >> >> Is this a concern that can be punted to what you'd naturally be >> putting in front of Solr anyway or a proxy tier that can have DoS >> blocking rules? I mean, if you're deploying a Struts that hits Solr >> under the covers, how do you prevent against DoS on that? A malicious >> user could keep sending queries indirectly to a Solr through a whole >> lot of public apps now. In other words, another tier in front of Solr >> doesn't add (much) to DoS protection to an underlying Solr, no? > > famous last words and all, but you shouldn't be just passing what a user > types directly into a application should you? > > I'd be parsing out wildcards, boosts, and fuzzy searches (or at least > thinking about the effects). > I mean "jakarta apache"~1000 or roam~0.1 aren't as efficient as a > regular query. > > but they don't let me into design meetings any more ;( >> Erik >> >> >
