Could be fun red/blue team exercise. Just watch out for those cryptominors that get in through Solr injection (among many other unsecured methods) and are a real pain to remove.
Regards, Alex. P.s. Don't ask me how I know :-( P.p.s. Read-only docker container may still be a good layer of defence on top of everything. Respawn it every hour, if needed. On Thu, 8 Oct 2020 at 15:05, David Hastings <dhasti...@wshein.com> wrote: > > Welp. Never mind I refer back to point #1 this is a bad idea > > > On Oct 8, 2020, at 3:01 PM, Alexandre Rafalovitch <arafa...@gmail.com> > > wrote: > > > > The update handlers are now implicitly defined (3 or 4 of them). So, > > it actually needs to be explicitly shadowed and overridden with other > > Noop handler. And block Config API to avoid attackers creating new > > handlers. > > > > Regards, > > Alex. > > > >> On Thu, 8 Oct 2020 at 14:54, David Hastings <dhasti...@wshein.com> wrote: > >> > >> Well that’s why I suggested deleting the update handler :) > >> > >>>> On Oct 8, 2020, at 2:52 PM, Walter Underwood <wun...@wunderwood.org> > >>>> wrote: > >>> > >>> Let me know where it is and I’ll delete all the documents in your > >>> collection. > >>> It is easy, just one HTTP request. > >>> > >>> https://gist.github.com/nz/673027/313f70681daa985ea13ba33a385753aef951a0f3 > >>> > >>> wunder > >>> Walter Underwood > >>> wun...@wunderwood.org > >>> http://observer.wunderwood.org/ (my blog) > >>> > >>>> On Oct 8, 2020, at 11:49 AM, Alexandre Rafalovitch <arafa...@gmail.com> > >>>> wrote: > >>>> > >>>> I think there were past discussions about people doing but they really > >>>> really knew what they were doing from a security perspective, not just > >>>> Solr one. > >>>> > >>>> You are increasing your risk factor a lot, so you need to think > >>>> through this. What are you protecting and what are you exposing. Are > >>>> you trying to protect the updates? You may be able to do it with - for > >>>> example - read-only docker container, or with embedded Solr or/and > >>>> with reverse proxy. > >>>> > >>>> Are you trying to protect some of the data from being read? Even harder. > >>>> > >>>> There are implicit handlers, admin handlers, 'qt' to select query > >>>> parser, etc. Lots of things to think about. > >>>> > >>>> It just may not be worth it. > >>>> > >>>> Regards, > >>>> Alex. > >>>> > >>>> > >>>>> On Thu, 8 Oct 2020 at 14:27, Marco Aurélio <aurelio.marco...@gmail.com> > >>>>> wrote: > >>>>> > >>>>> Hi! > >>>>> > >>>>> We're looking into the option of setting up search with Solr without an > >>>>> intermediary application. This would mean our backend would index data > >>>>> into > >>>>> Solr and we would have a public Solr endpoint on the internet that would > >>>>> receive search requests directly. > >>>>> > >>>>> Since I couldn't find an existing solution similar to ours, I would > >>>>> like to > >>>>> know whether it's possible to secure Solr in a way that allows anyone > >>>>> only > >>>>> read-access only to collections and how to achieve that. Specifically > >>>>> because of this part of the documentation > >>>>> <https://lucene.apache.org/solr/guide/8_5/securing-solr.html>: > >>>>> > >>>>> *No Solr API, including the Admin UI, is designed to be exposed to > >>>>> non-trusted parties. Tune your firewall so that only trusted computers > >>>>> and > >>>>> people are allowed access. Because of this, the project will not regard > >>>>> e.g., Admin UI XSS issues as security vulnerabilities. However, we still > >>>>> ask you to report such issues in JIRA.* > >>>>> Is there a way we can restrict read-only access to Solr collections so > >>>>> as > >>>>> to allow users to make search requests directly to it or should we > >>>>> always > >>>>> keep our Solr instances completely private? > >>>>> > >>>>> Thanks in advance! > >>>>> > >>>>> Best regards, > >>>>> Marco Godinho > >>>
