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

Reply via email to