You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@solr.apache.org by mtn search <se...@gmail.com> on 2022/03/08 21:09:31 UTC
How to clear vulnerability test errors
Hello,
Our company recently started running vulnerability tests against our Solr 6
servers by sending api calls to create cores with the core names being
a nefarious string. This string is actually an invalid core name and so
the core is not actually created (which is good). However, it adds the
core init error to the SolrCore Initialization Failures list which is at
the top of every Solr Admin UI page. Overtime this list gets large...
Restarting the Solr instance will clear these init errors from the list.
However, I am wondering if there is another way to clear these errors.
Thanks,
Matt
Re: How to clear vulnerability test errors
Posted by mtn search <se...@gmail.com>.
Hi Shawn,
Regarding the original question we are using Solr 6 and not SolrCloud (thus
the core admin api call). Yes, we are in the midst of planning for a move
to Solr 8 SolrCloud, but that will be a ways out for deployment.
For our current production Solr 6 servers it would be great if there is a
way to clear these errors shown in the Admin UI without a restart.
Thanks,
Matt
On Wed, Mar 9, 2022 at 10:19 AM Isabella Trevisan <
isabella.trevisan@infocamere.it> wrote:
> Thank you Mattew.
> I have detected the IPs that are currently accessing solr in the
> request.log.
> Do I need to put them in the jetty whitelist ?
> I don't see among the IPs found , those of zookeeper, do I have to put
> zookeeper IPs in the whitelist too?
>
> Best regards
> Isabella
>
> Il giorno mer 9 mar 2022 alle ore 17:45 matthew sporleder <
> msporleder@gmail.com> ha scritto:
>
> > Whatever magic string escaping/encoding got the core *in* should allow
> > you to get the core *out*. ;). I'm afraid you might need to just
> > brute-force it.
> >
> > Find your version of jetty in the solr war file and then look up how
> > to do the access stuff.
> >
> >
> https://stackoverflow.com/questions/8924102/restricting-ip-addresses-for-jetty-and-solr
> > has some hints.
> >
> > On Wed, Mar 9, 2022 at 11:10 AM Isabella Trevisan
> > <is...@infocamere.it> wrote:
> > >
> > > Thank you Mattew,
> > > yes I am using solrcloud and what I see is that I have this name in
> > > clusterstate.json
> > >
> > > "ldap://log4shell-generic-0QCXG8pYHe3RzoBwsUhT${::-
> > ten.w.nessus.org/nessus}":{
> > > "router":{"name":"implicit"},
> > > "shards":{"shard1":{
> > > "range":null,
> > > "state":"active",
> > > "parent":null,
> > > "replicas":{"core_node1":{
> > > "state":"down",
> > > "core":"ldap://log4shell-generic-0QCXG8pYHe3RzoBwsUhT${::-
> > ten.w.nessus.org/nessus}",
> > > "node_name":"solrhostname:solrport_solr",
> > > "base_url":"http://solrhostname:solrport/solr"}}}}}}
> > >
> > >
> > > and I don't see anything in /collections and /configs.
> > >
> > >
> > > But however, I cannot delete it even if I see it in the LIST
> collection.
> > >
> > > I think the problem is in the special characters contained in the name
> > > / and maybe ${}:
> > >
> > > If I tried to issue a delete collection I have
> > >
> > > Invalid path string
> > > "/collections/ldap://log4shell-generic-Lme4AEk3XG3WHYjMaBl8${lower:
> > > ten.w.nessus.org/nessus}" caused by empty node name specified @19
> > > How I could delete it ?
> > >
> > > How to restrict IP at jetty level in solrcloud (2 nodes) ?
> > > Must I restrict access only to the IPs of the two solr nodes and and
> > > zookeeper ?
> > >
> > > Best Regards
> > > Isabella
> > >
> > > Il giorno mer 9 mar 2022 alle ore 16:06 matthew sporleder <
> > > msporleder@gmail.com> ha scritto:
> > >
> > > > I think these names get written to a core.properties file or a
> > > > directory gets created with the offending name (unless you are using
> > > > solrcloud), right? Check for evidence under the solr home.
> > > >
> > > > The most straightforward defense here is to do IP-based restriction
> on
> > > > the jetty-level to only allow admin calls from localhost + (maybe)
> > > > other solr servers.
> > > >
> > > > Different versions of solr use different versions of jetty (5.x is
> > > > still war-file/tomcat era sometimes as well) so find the correct
> > > > versions and secure from there.
> > > >
> > > >
> > > > On Wed, Mar 9, 2022 at 9:40 AM Isabella Trevisan
> > > > <is...@infocamere.it> wrote:
> > > > >
> > > > > Hi ,
> > > > > I have the same error but with the restart of solr it does not
> > disappear.
> > > > > My solr version is 5.2.1.
> > > > > what can i do to fix the problem?
> > > > >
> > > > > Thank you
> > > > > Regards
> > > > > Isabella
> > > > >
> > > > > Il giorno mer 9 mar 2022 alle ore 00:20 Shawn Heisey <
> > > > apache@elyograg.org>
> > > > > ha scritto:
> > > > >
> > > > > > On 3/8/22 14:09, mtn search wrote:
> > > > > > > Our company recently started running vulnerability tests
> against
> > our
> > > > > > Solr 6
> > > > > > > servers by sending api calls to create cores with the core
> names
> > > > being
> > > > > > > a nefarious string. This string is actually an invalid core
> name
> > > > and so
> > > > > > > the core is not actually created (which is good). However, it
> > adds
> > > > the
> > > > > > > core init error to the SolrCore Initialization Failures list
> > which
> > > > is at
> > > > > > > the top of every Solr Admin UI page. Overtime this list gets
> > > > large...
> > > > > > >
> > > > > > > Restarting the Solr instance will clear these init errors from
> > the
> > > > list.
> > > > > > > However, I am wondering if there is another way to clear these
> > > > errors.
> > > > > >
> > > > > > I do not know of a way right now. Seems like there ought to be a
> > way
> > > > to
> > > > > > clear that list, even if the overall low-level container isn't
> > > > > > restarted. Life and work are conspiring against me and I won't
> > have
> > > > > > time to look deeper until a lot later this evening (US Mountain
> > > > > > timezone). I don't think upgrading Solr would help, but version
> 6
> > is
> > > > > > quite old now. You should start planning and testing for a major
> > > > > > upgrade to 8.x.
> > > > > >
> > > > > > Thanks,
> > > > > > Shawn
> > > > > >
> > > > > >
> > > >
> >
>
Re: How to clear vulnerability test errors
Posted by Isabella Trevisan <is...@infocamere.it>.
Thank you Mattew.
I have detected the IPs that are currently accessing solr in the
request.log.
Do I need to put them in the jetty whitelist ?
I don't see among the IPs found , those of zookeeper, do I have to put
zookeeper IPs in the whitelist too?
Best regards
Isabella
Il giorno mer 9 mar 2022 alle ore 17:45 matthew sporleder <
msporleder@gmail.com> ha scritto:
> Whatever magic string escaping/encoding got the core *in* should allow
> you to get the core *out*. ;). I'm afraid you might need to just
> brute-force it.
>
> Find your version of jetty in the solr war file and then look up how
> to do the access stuff.
>
> https://stackoverflow.com/questions/8924102/restricting-ip-addresses-for-jetty-and-solr
> has some hints.
>
> On Wed, Mar 9, 2022 at 11:10 AM Isabella Trevisan
> <is...@infocamere.it> wrote:
> >
> > Thank you Mattew,
> > yes I am using solrcloud and what I see is that I have this name in
> > clusterstate.json
> >
> > "ldap://log4shell-generic-0QCXG8pYHe3RzoBwsUhT${::-
> ten.w.nessus.org/nessus}":{
> > "router":{"name":"implicit"},
> > "shards":{"shard1":{
> > "range":null,
> > "state":"active",
> > "parent":null,
> > "replicas":{"core_node1":{
> > "state":"down",
> > "core":"ldap://log4shell-generic-0QCXG8pYHe3RzoBwsUhT${::-
> ten.w.nessus.org/nessus}",
> > "node_name":"solrhostname:solrport_solr",
> > "base_url":"http://solrhostname:solrport/solr"}}}}}}
> >
> >
> > and I don't see anything in /collections and /configs.
> >
> >
> > But however, I cannot delete it even if I see it in the LIST collection.
> >
> > I think the problem is in the special characters contained in the name
> > / and maybe ${}:
> >
> > If I tried to issue a delete collection I have
> >
> > Invalid path string
> > "/collections/ldap://log4shell-generic-Lme4AEk3XG3WHYjMaBl8${lower:
> > ten.w.nessus.org/nessus}" caused by empty node name specified @19
> > How I could delete it ?
> >
> > How to restrict IP at jetty level in solrcloud (2 nodes) ?
> > Must I restrict access only to the IPs of the two solr nodes and and
> > zookeeper ?
> >
> > Best Regards
> > Isabella
> >
> > Il giorno mer 9 mar 2022 alle ore 16:06 matthew sporleder <
> > msporleder@gmail.com> ha scritto:
> >
> > > I think these names get written to a core.properties file or a
> > > directory gets created with the offending name (unless you are using
> > > solrcloud), right? Check for evidence under the solr home.
> > >
> > > The most straightforward defense here is to do IP-based restriction on
> > > the jetty-level to only allow admin calls from localhost + (maybe)
> > > other solr servers.
> > >
> > > Different versions of solr use different versions of jetty (5.x is
> > > still war-file/tomcat era sometimes as well) so find the correct
> > > versions and secure from there.
> > >
> > >
> > > On Wed, Mar 9, 2022 at 9:40 AM Isabella Trevisan
> > > <is...@infocamere.it> wrote:
> > > >
> > > > Hi ,
> > > > I have the same error but with the restart of solr it does not
> disappear.
> > > > My solr version is 5.2.1.
> > > > what can i do to fix the problem?
> > > >
> > > > Thank you
> > > > Regards
> > > > Isabella
> > > >
> > > > Il giorno mer 9 mar 2022 alle ore 00:20 Shawn Heisey <
> > > apache@elyograg.org>
> > > > ha scritto:
> > > >
> > > > > On 3/8/22 14:09, mtn search wrote:
> > > > > > Our company recently started running vulnerability tests against
> our
> > > > > Solr 6
> > > > > > servers by sending api calls to create cores with the core names
> > > being
> > > > > > a nefarious string. This string is actually an invalid core name
> > > and so
> > > > > > the core is not actually created (which is good). However, it
> adds
> > > the
> > > > > > core init error to the SolrCore Initialization Failures list
> which
> > > is at
> > > > > > the top of every Solr Admin UI page. Overtime this list gets
> > > large...
> > > > > >
> > > > > > Restarting the Solr instance will clear these init errors from
> the
> > > list.
> > > > > > However, I am wondering if there is another way to clear these
> > > errors.
> > > > >
> > > > > I do not know of a way right now. Seems like there ought to be a
> way
> > > to
> > > > > clear that list, even if the overall low-level container isn't
> > > > > restarted. Life and work are conspiring against me and I won't
> have
> > > > > time to look deeper until a lot later this evening (US Mountain
> > > > > timezone). I don't think upgrading Solr would help, but version 6
> is
> > > > > quite old now. You should start planning and testing for a major
> > > > > upgrade to 8.x.
> > > > >
> > > > > Thanks,
> > > > > Shawn
> > > > >
> > > > >
> > >
>
Re: How to clear vulnerability test errors
Posted by matthew sporleder <ms...@gmail.com>.
Whatever magic string escaping/encoding got the core *in* should allow
you to get the core *out*. ;). I'm afraid you might need to just
brute-force it.
Find your version of jetty in the solr war file and then look up how
to do the access stuff.
https://stackoverflow.com/questions/8924102/restricting-ip-addresses-for-jetty-and-solr
has some hints.
On Wed, Mar 9, 2022 at 11:10 AM Isabella Trevisan
<is...@infocamere.it> wrote:
>
> Thank you Mattew,
> yes I am using solrcloud and what I see is that I have this name in
> clusterstate.json
>
> "ldap://log4shell-generic-0QCXG8pYHe3RzoBwsUhT${::-ten.w.nessus.org/nessus}":{
> "router":{"name":"implicit"},
> "shards":{"shard1":{
> "range":null,
> "state":"active",
> "parent":null,
> "replicas":{"core_node1":{
> "state":"down",
> "core":"ldap://log4shell-generic-0QCXG8pYHe3RzoBwsUhT${::-ten.w.nessus.org/nessus}",
> "node_name":"solrhostname:solrport_solr",
> "base_url":"http://solrhostname:solrport/solr"}}}}}}
>
>
> and I don't see anything in /collections and /configs.
>
>
> But however, I cannot delete it even if I see it in the LIST collection.
>
> I think the problem is in the special characters contained in the name
> / and maybe ${}:
>
> If I tried to issue a delete collection I have
>
> Invalid path string
> "/collections/ldap://log4shell-generic-Lme4AEk3XG3WHYjMaBl8${lower:
> ten.w.nessus.org/nessus}" caused by empty node name specified @19
> How I could delete it ?
>
> How to restrict IP at jetty level in solrcloud (2 nodes) ?
> Must I restrict access only to the IPs of the two solr nodes and and
> zookeeper ?
>
> Best Regards
> Isabella
>
> Il giorno mer 9 mar 2022 alle ore 16:06 matthew sporleder <
> msporleder@gmail.com> ha scritto:
>
> > I think these names get written to a core.properties file or a
> > directory gets created with the offending name (unless you are using
> > solrcloud), right? Check for evidence under the solr home.
> >
> > The most straightforward defense here is to do IP-based restriction on
> > the jetty-level to only allow admin calls from localhost + (maybe)
> > other solr servers.
> >
> > Different versions of solr use different versions of jetty (5.x is
> > still war-file/tomcat era sometimes as well) so find the correct
> > versions and secure from there.
> >
> >
> > On Wed, Mar 9, 2022 at 9:40 AM Isabella Trevisan
> > <is...@infocamere.it> wrote:
> > >
> > > Hi ,
> > > I have the same error but with the restart of solr it does not disappear.
> > > My solr version is 5.2.1.
> > > what can i do to fix the problem?
> > >
> > > Thank you
> > > Regards
> > > Isabella
> > >
> > > Il giorno mer 9 mar 2022 alle ore 00:20 Shawn Heisey <
> > apache@elyograg.org>
> > > ha scritto:
> > >
> > > > On 3/8/22 14:09, mtn search wrote:
> > > > > Our company recently started running vulnerability tests against our
> > > > Solr 6
> > > > > servers by sending api calls to create cores with the core names
> > being
> > > > > a nefarious string. This string is actually an invalid core name
> > and so
> > > > > the core is not actually created (which is good). However, it adds
> > the
> > > > > core init error to the SolrCore Initialization Failures list which
> > is at
> > > > > the top of every Solr Admin UI page. Overtime this list gets
> > large...
> > > > >
> > > > > Restarting the Solr instance will clear these init errors from the
> > list.
> > > > > However, I am wondering if there is another way to clear these
> > errors.
> > > >
> > > > I do not know of a way right now. Seems like there ought to be a way
> > to
> > > > clear that list, even if the overall low-level container isn't
> > > > restarted. Life and work are conspiring against me and I won't have
> > > > time to look deeper until a lot later this evening (US Mountain
> > > > timezone). I don't think upgrading Solr would help, but version 6 is
> > > > quite old now. You should start planning and testing for a major
> > > > upgrade to 8.x.
> > > >
> > > > Thanks,
> > > > Shawn
> > > >
> > > >
> >
Re: How to clear vulnerability test errors
Posted by Isabella Trevisan <is...@infocamere.it>.
Thank you Mattew,
yes I am using solrcloud and what I see is that I have this name in
clusterstate.json
"ldap://log4shell-generic-0QCXG8pYHe3RzoBwsUhT${::-ten.w.nessus.org/nessus}":{
"router":{"name":"implicit"},
"shards":{"shard1":{
"range":null,
"state":"active",
"parent":null,
"replicas":{"core_node1":{
"state":"down",
"core":"ldap://log4shell-generic-0QCXG8pYHe3RzoBwsUhT${::-ten.w.nessus.org/nessus}",
"node_name":"solrhostname:solrport_solr",
"base_url":"http://solrhostname:solrport/solr"}}}}}}
and I don't see anything in /collections and /configs.
But however, I cannot delete it even if I see it in the LIST collection.
I think the problem is in the special characters contained in the name
/ and maybe ${}:
If I tried to issue a delete collection I have
Invalid path string
"/collections/ldap://log4shell-generic-Lme4AEk3XG3WHYjMaBl8${lower:
ten.w.nessus.org/nessus}" caused by empty node name specified @19
How I could delete it ?
How to restrict IP at jetty level in solrcloud (2 nodes) ?
Must I restrict access only to the IPs of the two solr nodes and and
zookeeper ?
Best Regards
Isabella
Il giorno mer 9 mar 2022 alle ore 16:06 matthew sporleder <
msporleder@gmail.com> ha scritto:
> I think these names get written to a core.properties file or a
> directory gets created with the offending name (unless you are using
> solrcloud), right? Check for evidence under the solr home.
>
> The most straightforward defense here is to do IP-based restriction on
> the jetty-level to only allow admin calls from localhost + (maybe)
> other solr servers.
>
> Different versions of solr use different versions of jetty (5.x is
> still war-file/tomcat era sometimes as well) so find the correct
> versions and secure from there.
>
>
> On Wed, Mar 9, 2022 at 9:40 AM Isabella Trevisan
> <is...@infocamere.it> wrote:
> >
> > Hi ,
> > I have the same error but with the restart of solr it does not disappear.
> > My solr version is 5.2.1.
> > what can i do to fix the problem?
> >
> > Thank you
> > Regards
> > Isabella
> >
> > Il giorno mer 9 mar 2022 alle ore 00:20 Shawn Heisey <
> apache@elyograg.org>
> > ha scritto:
> >
> > > On 3/8/22 14:09, mtn search wrote:
> > > > Our company recently started running vulnerability tests against our
> > > Solr 6
> > > > servers by sending api calls to create cores with the core names
> being
> > > > a nefarious string. This string is actually an invalid core name
> and so
> > > > the core is not actually created (which is good). However, it adds
> the
> > > > core init error to the SolrCore Initialization Failures list which
> is at
> > > > the top of every Solr Admin UI page. Overtime this list gets
> large...
> > > >
> > > > Restarting the Solr instance will clear these init errors from the
> list.
> > > > However, I am wondering if there is another way to clear these
> errors.
> > >
> > > I do not know of a way right now. Seems like there ought to be a way
> to
> > > clear that list, even if the overall low-level container isn't
> > > restarted. Life and work are conspiring against me and I won't have
> > > time to look deeper until a lot later this evening (US Mountain
> > > timezone). I don't think upgrading Solr would help, but version 6 is
> > > quite old now. You should start planning and testing for a major
> > > upgrade to 8.x.
> > >
> > > Thanks,
> > > Shawn
> > >
> > >
>
Re: How to clear vulnerability test errors
Posted by matthew sporleder <ms...@gmail.com>.
I think these names get written to a core.properties file or a
directory gets created with the offending name (unless you are using
solrcloud), right? Check for evidence under the solr home.
The most straightforward defense here is to do IP-based restriction on
the jetty-level to only allow admin calls from localhost + (maybe)
other solr servers.
Different versions of solr use different versions of jetty (5.x is
still war-file/tomcat era sometimes as well) so find the correct
versions and secure from there.
On Wed, Mar 9, 2022 at 9:40 AM Isabella Trevisan
<is...@infocamere.it> wrote:
>
> Hi ,
> I have the same error but with the restart of solr it does not disappear.
> My solr version is 5.2.1.
> what can i do to fix the problem?
>
> Thank you
> Regards
> Isabella
>
> Il giorno mer 9 mar 2022 alle ore 00:20 Shawn Heisey <ap...@elyograg.org>
> ha scritto:
>
> > On 3/8/22 14:09, mtn search wrote:
> > > Our company recently started running vulnerability tests against our
> > Solr 6
> > > servers by sending api calls to create cores with the core names being
> > > a nefarious string. This string is actually an invalid core name and so
> > > the core is not actually created (which is good). However, it adds the
> > > core init error to the SolrCore Initialization Failures list which is at
> > > the top of every Solr Admin UI page. Overtime this list gets large...
> > >
> > > Restarting the Solr instance will clear these init errors from the list.
> > > However, I am wondering if there is another way to clear these errors.
> >
> > I do not know of a way right now. Seems like there ought to be a way to
> > clear that list, even if the overall low-level container isn't
> > restarted. Life and work are conspiring against me and I won't have
> > time to look deeper until a lot later this evening (US Mountain
> > timezone). I don't think upgrading Solr would help, but version 6 is
> > quite old now. You should start planning and testing for a major
> > upgrade to 8.x.
> >
> > Thanks,
> > Shawn
> >
> >
Re: How to clear vulnerability test errors
Posted by Shawn Heisey <ap...@elyograg.org>.
On 3/9/2022 7:39 AM, Isabella Trevisan wrote:
> I have the same error but with the restart of solr it does not disappear.
> My solr version is 5.2.1.
> what can i do to fix the problem?
If an error during core startup is still there after you restart, then
you didn't fix the problem, and it happened again after the restart.
You have to actually fix whatever problem caused the error before you
restart.
Thanks,
Shawn
Re: How to clear vulnerability test errors
Posted by Isabella Trevisan <is...@infocamere.it>.
Hi ,
I have the same error but with the restart of solr it does not disappear.
My solr version is 5.2.1.
what can i do to fix the problem?
Thank you
Regards
Isabella
Il giorno mer 9 mar 2022 alle ore 00:20 Shawn Heisey <ap...@elyograg.org>
ha scritto:
> On 3/8/22 14:09, mtn search wrote:
> > Our company recently started running vulnerability tests against our
> Solr 6
> > servers by sending api calls to create cores with the core names being
> > a nefarious string. This string is actually an invalid core name and so
> > the core is not actually created (which is good). However, it adds the
> > core init error to the SolrCore Initialization Failures list which is at
> > the top of every Solr Admin UI page. Overtime this list gets large...
> >
> > Restarting the Solr instance will clear these init errors from the list.
> > However, I am wondering if there is another way to clear these errors.
>
> I do not know of a way right now. Seems like there ought to be a way to
> clear that list, even if the overall low-level container isn't
> restarted. Life and work are conspiring against me and I won't have
> time to look deeper until a lot later this evening (US Mountain
> timezone). I don't think upgrading Solr would help, but version 6 is
> quite old now. You should start planning and testing for a major
> upgrade to 8.x.
>
> Thanks,
> Shawn
>
>
Re: How to clear vulnerability test errors
Posted by Shawn Heisey <ap...@elyograg.org>.
On 3/8/22 14:09, mtn search wrote:
> Our company recently started running vulnerability tests against our Solr 6
> servers by sending api calls to create cores with the core names being
> a nefarious string. This string is actually an invalid core name and so
> the core is not actually created (which is good). However, it adds the
> core init error to the SolrCore Initialization Failures list which is at
> the top of every Solr Admin UI page. Overtime this list gets large...
>
> Restarting the Solr instance will clear these init errors from the list.
> However, I am wondering if there is another way to clear these errors.
I do not know of a way right now. Seems like there ought to be a way to
clear that list, even if the overall low-level container isn't
restarted. Life and work are conspiring against me and I won't have
time to look deeper until a lot later this evening (US Mountain
timezone). I don't think upgrading Solr would help, but version 6 is
quite old now. You should start planning and testing for a major
upgrade to 8.x.
Thanks,
Shawn