One problem I have seen in the past is cultural. Back when solr was mostly a .war file it was very easy to say "secure your own tomcat" but in the era of "solr is a database not a web app" it needs to embrace the entirety of that distinction.
You can't have it both ways and I am not sure the culture shift was fully embraced. Another point of feedback is that we have built apps with both solr "clients" and a lot of diy with curl so any security settings need to be sane. Listen on 0.0.0.0 but only accept traffic from private addresses? Respect x-forwarded-for (and its aliases) in that case. > On May 6, 2021, at 7:02 PM, Eric Pugh <ep...@opensourceconnections.com> wrote: > > I think that part of the challenge goes to the deeper issue that configuring > Solr isn’t easy. We don’t really have the concept of a environment specific > settings file. I’d love to see a -env=production.yml or -env=development.yml > type file that was the single place for all settings, and had sane defaults > for each environment. Something that worked across Docker, classic > installed service, or just via a bin/solr start command line ;-). > > I am constantly finding new command line config options that I didn’t know > about ;-) > > >> On May 6, 2021, at 5:58 PM, matthew sporleder <msporle...@gmail.com> wrote: >> >>> On Thu, May 6, 2021 at 5:25 PM David Smiley <dsmi...@apache.org> 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. > > _______________________ > Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | > http://www.opensourceconnections.com <http://www.opensourceconnections.com/> > | My Free/Busy <http://tinyurl.com/eric-cal> > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed > <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> > > 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. >
