You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@solr.apache.org by David Smiley <ds...@apache.org> on 2021/05/06 21:25:13 UTC
Security: Better secure defaults?
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
Re: Security: Better secure defaults?
Posted by David Smiley <ds...@apache.org>.
> 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 <ms...@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 <ms...@gmail.com>
> wrote:
> >>
> >>> On Thu, May 6, 2021 at 5:25 PM David Smiley <ds...@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.
> >
>
Re: Security: Better secure defaults?
Posted by matthew sporleder <ms...@gmail.com>.
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 <ms...@gmail.com> wrote:
>>
>>> On Thu, May 6, 2021 at 5:25 PM David Smiley <ds...@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.
>
Re: Security: Better secure defaults?
Posted by David Smiley <ds...@apache.org>.
I didn't propose a new configuration file, I proposed a "mode". Even if
there was some new env-specific file, it would end up being yet another
configuration file -- no thanks. Solr still needs solr.xml &
solrconfig.xml & schema.xml (and more), plus Jetty's many config files, and
they are mostly for different purposes. Even if we were to hypothesize a
brand new system that had one configuration file, what does the code
reading this file do if the particular named setting isn't present?
*That* question is where a "mode" might in some cases yield a different
default depending on the setting.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Thu, 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 <ms...@gmail.com>
> wrote:
> >
> > On Thu, May 6, 2021 at 5:25 PM David Smiley <ds...@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.
>
>
Re: Security: Better secure defaults?
Posted by Eric Pugh <ep...@opensourceconnections.com>.
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 <ms...@gmail.com> wrote:
>
> On Thu, May 6, 2021 at 5:25 PM David Smiley <ds...@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.
Re: Security: Better secure defaults?
Posted by matthew sporleder <ms...@gmail.com>.
On Thu, May 6, 2021 at 5:25 PM David Smiley <ds...@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.
Re: Security: Better secure defaults?
Posted by Gus Heck <gu...@gmail.com>.
Perhaps Solr should come up with a basic auth wrapper requiring a randomly
generated token from the logs as a password printed at the very end of
startup messages. This of course needs to show up in zookeeper too so that
inter-node requests work. Nice if the UI at some point handles it, but as a
temporary "until you set this up" type of feature, letting the browser
throw up a 401 based login seems fine. This of course could be disabled
either by a configuration in security.json or a system property named
something like no.security.at.all
From a first tutorial perspective requests via the admin ui (or direct
browser url) only get asked once per session, and sending a basic auth
header is a very normal thing in curl. (and people who don't like typing
don't use curl anyway). Things like Postman also handle this smoothly.
Additionally it might be good to add a header to query responses something
like:
"insecure": [
"This cluster is running without https, communications with and among
this cluster are easily spied upon by third parties. Configuring https
removes this message",
"This cluster is running with default log token basic auth. Anyone with
access to the logs can gain full control of Solr. Configuring security.json
with an authentication plugin removes this message"
"This cluster is running such that every user is a super-user and can
create/delete/update all collections and any data or configuration.
Configuring an authorization plugin in security.json removes this message"
]
possibly also messages about zookeeper acls, or whatever else we think is
important.
All such messages should be removable via properties like:
"no.security.advice.all", "no.security.advice.https",
"no.security.advice.authn", "no.security.advice.authz" etc. for backwards
compatibility and dev/testing of course.
This should ensure that the users (or at least one user in the
organization) will be aware of their own insecure practices.
-Gus
On Fri, May 7, 2021 at 3:53 PM David Smiley <ds...@apache.org> wrote:
> > I would like to be able to define core specific permissions with
> rule-based
> > authorization in security.json in the same way you can do for
> collections.
>
> PRs/Patches welcome... but I think you're going to have to accept migrating
> to SolrCloud. SolrCloud has gotten better year over year.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Fri, May 7, 2021 at 3:39 AM Thomas Corthals <th...@klascement.net>
> wrote:
>
> > I would like to be able to define core specific permissions with
> rule-based
> > authorization in security.json in the same way you can do for
> collections.
> >
> > Thomas
> >
> > Op do 6 mei 2021 om 23:25 schreef David Smiley <ds...@apache.org>:
> >
> > > 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
> > >
> >
>
--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
Re: Security: Better secure defaults?
Posted by David Smiley <ds...@apache.org>.
> I would like to be able to define core specific permissions with
rule-based
> authorization in security.json in the same way you can do for collections.
PRs/Patches welcome... but I think you're going to have to accept migrating
to SolrCloud. SolrCloud has gotten better year over year.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Fri, May 7, 2021 at 3:39 AM Thomas Corthals <th...@klascement.net>
wrote:
> I would like to be able to define core specific permissions with rule-based
> authorization in security.json in the same way you can do for collections.
>
> Thomas
>
> Op do 6 mei 2021 om 23:25 schreef David Smiley <ds...@apache.org>:
>
> > 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
> >
>
Re: Security: Better secure defaults?
Posted by Thomas Corthals <th...@klascement.net>.
I would like to be able to define core specific permissions with rule-based
authorization in security.json in the same way you can do for collections.
Thomas
Op do 6 mei 2021 om 23:25 schreef David Smiley <ds...@apache.org>:
> 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
>