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