> Listen on 0.0.0.0 but only accept traffic from private addresses? Respect x-forwarded-for (and its aliases) in that case.
+1 ! Feel free to file a JIRA issue; maybe there is one already. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Thu, May 6, 2021 at 8:39 PM matthew sporleder <msporle...@gmail.com> wrote: > 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. > > >
