Yes, your proxy seems to work. The only thing that bothers me is anyone can query your Solr installation.
The world is not a nice place and I can't tell you how many DOS attacks I've fended off in the last 30 years. If I thought you were an a-hole I could set up a few machines and query your server to a standstill. About ten years ago I was working on a contract. The competitor that lost the bid did a email DOS attack on me after they took out a whole bunch car adds (hot deals) in the local paper. My email was f###'d and my phone was ringing off the hook. Cheers, GW On 25 December 2015 at 21:55, Doug Turnbull < dturnb...@opensourceconnections.com> wrote: > Yeah I prefer a whitelist of locked down query request handlers via a > proxy that are reasonably well protected. I would never expose update to > the web or allow any updating over a public interface. > > If you want an example, you can checkout > > > http://solr.quepid.com/solr/statedecoded/select?q=*:*&qt=update&stream.body= > <delete><query>*:*</query></delete>&commit=true > > http://solr.quepid.com/solr/statedecoded/update?stream.body= > <delete><query>*:*</query></delete>&commit=true > > But still get search results back: > http://solr.quepid.com/solr/statedecoded/select?q=*:* > > Click all those all day long. And do let me know if you find holes... I'm > sure there's room for improvement > > Cheers, > -Doug > > On Friday, December 25, 2015, GW <thegeofo...@gmail.com> wrote: > > > 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 <javascript:;>> 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 > > <javascript:;>> 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. > > > > > > > > -- > *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. >
