On Thu, May 6, 2021 at 5:25 PM David Smiley <[email protected]> wrote: > > I'm reaching out to our user community to get opinions on what Solr should > do to be more secure-by-default. > > TL;DR: Solr 9 has better secure-by-defaults, but maybe we should do more > like have Solr pick some of it's default settings dependent on a new > env=dev|prod. > > I was shown a glimpse of a massive list of Solr servers exposed on the > public internet by a security researcher. I'm kinda blown away that so > many people would be so careless. I think Solr could and should run with > better "secure-by-default" settings. > > The situation will be much better in Solr 9 -- and I'll give a shout-out of > thanks to Rob Muir for helping make this so. Here's a couple prominent > ones: > * Solr's Jetty now binds to localhost by default, configurable via > SOLR_JETTY_HOST. Before 9, you can configure a similar thing in the Jetty > config files. SOLR-13985 > * Java's SecurityManager sandbox is enabled by default. -- SOLR-13984. > This option also exists in Solr since 8.5, toggle-able > via SOLR_SECURITY_MANAGER_ENABLED. Mostly this prevents the worst of > security bugs -- RCE. > > I wonder if users will promptly set SOLR_JETTY_HOST=0.0.0.0 to get anything > done? I think so... but it's something, protecting some users. > > Perhaps Solr ought to default to requiring a username/password? I've heard > this suggestion and it's an obvious one even if some of us (me included) > worry that it would make it too annoying to play with Solr when getting > started. I think the concerns could be mitigated based on the approach. > If Solr had an opt-in env=dev setting, for example, then Solr could not > insist on authentication, whereas a default env=prod would insist. Of > course the authentication or lack thereof could be explicitly configured or > disabled at the user's prerogative. What I like about an "env" setting is > that many other settings could be gated on this as well. > > I particularly like the idea of an env=dev|prod setting because a variety > of settings in Solr could have a default that is dependent on this value. > In particular I argue that a env=prod should result in Solr's config APIs > being disabled -- equivalent to -Ddisable.configEdit=true. I believe a > minority of Solr users actually use these APIs, yet they are frequently a > step in exploiting weaknesses in Solr. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley
I have also found open solr servers and normally send an email like "shall I delete your data or wait for you to do it?" As solr is primarily an index of other data the primary issue is data disclosure. Config editing, inserting data, etc are all pretty secondary. HTTP Basic Auth with a first-boot-random password is a massively simple thing built into jetty that will solve 99% of exposed solr servers. secure-by-default will decrease adoption without major east-to-follow warning messages so tread lightly.
