If you are using Linux a simple one liner in IP tables iptables -I INPUT \! --src www.yourwebserver.com -m tcp -p tcp --dport 8983 -j DROP
If windows, you can do something similar otherwise it is very easy for anyone to delete all your documents with http://yoursolrserver.com:8983/solr/your-core/update?stream.body= <delete><query>*:*</query></delete>&commit=true On 25 December 2015 at 20:42, Doug Turnbull < dturnb...@opensourceconnections.com> wrote: > Hi Shawn > > Maybe I should have qualified the parameters of scenarios this make me > comfortable just proxying Solr directly w/o an API > > These situations include: > > 1. I've got no qualms about giving the whole world access to every document > in the index. There's nothing protected about anything. > 2. The content can be easily rebuilt , it's not very large. (I can easily > push a button and make a new one) > > Sure you can denial of service Solr, and I might lose my search index. But > you can denial of service anything. This includes just about anything you > put in front of Solr. Moreover, the added complexity of a > Drupal/Wordpress/your API might only add to the security problems with > their own security issues. I'd rather keep it simple and have fewer moving > parts. > > Cases where I would want an API in front of Solr (these are just the > security ones): > - I want to protect the content (ie based on some notion of a "user" or > other permissions) > - Rebuilding the content would be very hard and time consuming > > I would also say to expose Solr directly to everyone you probably should > know about Solr's bugaboos: > - the lovely qt parameter and the request dispatcher (the nginx proxy below > disallows qt) > - deep paging (prevented by the nginx proxy) > - how to lock down a request handler fairly robustly, how to use invariants > - mitigating intentionally malicious queries (such as the lovely "sleep" > function query). > > I'm also curious to hear what the websolr people do, or anyone else that > hosts Solr for the JavaScript app development crowd. > > Cheers > -Doug > > > On Friday, December 25, 2015, Shawn Heisey <apa...@elyograg.org> wrote: > > > On 12/25/2015 12:17 PM, Eric Dain wrote: > > > Does allowing javascript direct access to SolrCloud raise security > > concern? > > > should I build a REST service in between? > > > > > > I need to provide async search capability to web pages. the pages will > be > > > public with no authentication. > > > > End users should never have access to Solr. Access to Solr from the > > end-user machine is required if you want to accept Solr responses > directly. > > > > In one of the other replies that you received, Doug has given you an > > nginx config for proxying access to Solr -- indirect access. This can > > protect against *changes* to the index, and it has protection against > > high start/rows values, but there are many other ways that an attacker > > can construct denial of service queries, which this proxy config will > > not prevent. > > > > I think that indirect access (through a proxy) should not be allowed > > either, unless you can trust all the people that will have access. > > > > If Solr is open to a sufficiently wide audience (especially the > > Internet), someone will find a way to abuse the service even with a > > proxy, either to cause harm or to learn things they shouldn't know. > > > > The most secure option is to only allow the webservers and trusted > > administrators to access Solr. All end user (Internet) access to Solr > > should be handled through a custom web application. This might be > > something that you find and install (such as wordpress, drupal, etc), or > > one that you write yourself. > > > > You can still do AJAX while maintaining security. You'll need to write > > something in a server-side web programming language like PHP, Java, etc. > > This code will need to accept the AJAX requests from your client-side > > javascript code, validate the request parameters to make sure they're > > sane, get a response from Solr, and return relevant data. If the > > parameters don't validate, return an error, and handle that error > > appropriately in the javascript code. > > > > Thanks, > > Shawn > > > > > > -- > *Doug Turnbull **| *Search Relevance Consultant | OpenSource Connections > <http://opensourceconnections.com>, LLC | 240.476.9983 > Author: Relevant Search <http://manning.com/turnbull> > This e-mail and all contents, including attachments, is considered to be > Company Confidential unless explicitly stated otherwise, regardless > of whether attachments are marked as such. >
