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 < [email protected]> 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 > <[email protected]> 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 < > [email protected]> > > 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 > > > > > > >
