# Anonymous Access Unexpectedly Allowed **URL:** \ **Category:** Elasticsearch\ **Tags:** elastic-stack-security\ **Created:** [March 31, 2020, 1:11am UTC](https://discuss.elastic.co/t/anonymous-access-unexpectedly-allowed/225765 "2020-03-31T01:11:09Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![diggitydug](https://avatars.discourse-cdn.com/v4/letter/d/958977/32.png) [@diggitydug](https://discuss.elastic.co/u/diggitydug)\ **Post date:** [March 31, 2020, 1:11am UTC](https://discuss.elastic.co/t/anonymous-access-unexpectedly-allowed/225765/1 "2020-03-31T01:11:09Z")
Hello - We deployed a trial version of an ElasticSearch 6.5.3 and Kibana stack from the Azure marketplace and everything was running fine. Everything was configured properly, and we were using a username & password to connect ElasticSearch to Kibana using [https://clusterIP:9200](https://clusterIP:9200). Then one day we discovered that [https://clusterIP:9200](https://clusterIP:9200) was allowing anonymous connections! In talking to the application team, they do not remember making any configuration changes. My Ops team was able to confirm that it doesn't look like the security configuration was changed since the initial build. Does any of this make sense or sound possible? Is it possible that the trial license expires on 6.5.3 that could inadvertently enable anonymous access? If so, that seems like a huge security hole. The only reason I think this may be license-related is because when I hit the [https://clusterIP:9200/security/role](https://clusterIP:9200/security/role) endpoint, I receive the following 403: ```auto { "error": { "root_cause": [{ "type": "security_exception", "reason": "current license is non-compliant for [security]", "license.expired.feature": "security" } ], "type": "security_exception", "reason": "current license is non-compliant for [security]", "license.expired.feature": "security" }, "status": 403 } ``` ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [March 31, 2020, 2:51am UTC](https://discuss.elastic.co/t/anonymous-access-unexpectedly-allowed/225765/2 "2020-03-31T02:51:40Z")
> [@diggitydug](#): > > Is it possible that the trial license expires on 6.5.3 that could inadvertently enable anonymous access Please see [here](https://www.elastic.co/guide/en/elastic-stack-overview/6.5/license-expiration.html) for what happens when the license expires. It does not automatically open the cluster up. FYI 6.5 is not far off EOL - [Elastic Product End of Life Dates | Elastic](https://www.elastic.co/support/eol). If you must use 6.X then use 6.8, otherwise the latest is 7.6. As a bonus, [Security is free](https://www.elastic.co/blog/security-for-elasticsearch-is-now-free) in 6.8 and above! 🙂 ---
**Author:** ![diggitydug](https://avatars.discourse-cdn.com/v4/letter/d/958977/32.png) [@diggitydug](https://discuss.elastic.co/u/diggitydug)\ **Post date:** [March 31, 2020, 4:21am UTC](https://discuss.elastic.co/t/anonymous-access-unexpectedly-allowed/225765/3 "2020-03-31T04:21:57Z")
I agree that we did not expect it to open up the cluster, but we can't figure out any other explanation. As far as I can tell, no changes were made to the config files after the trial was started, and yet we can hit the following search API and return records unauthenticated: `https://clusterIP:9200/_search?q=*NAME*` ```auto { "took": 9857, "timed_out": false, "_shards": { "total": 160, "successful": 160, "skipped": 0, "failed": 0 }, "hits": { "total": 16065835, "max_score": 1.0, "hits": {<>} } } ``` And it definitely returns results without prompting for a username or password. We checked the documentation for enabling anonymous access and do not see any of the required settings in the elasticsearch.yml. Here's our config file `elasticsearch.yml` ```auto cluster.name: "<>" node.name: "<>" path.logs: /var/log/elasticsearch path.data: /datadisks/disk1/elasticsearch/data discovery.zen.ping.unicast.hosts: ["<>"] node.master: true node.data: true discovery.zen.minimum_master_nodes: 1 network.host: [_site_, _local_] node.max_local_storage_nodes: 1 node.attr.fault_domain: 0 node.attr.update_domain: 0 cluster.routing.allocation.awareness.attributes: fault_domain,update_domain xpack.license.self_generated.type: trial xpack.security.enabled: true bootstrap.memory_lock: true ``` Is there anywhere else besides the settings documented in [this reference article](https://www.elastic.co/guide/en/elasticsearch/reference/6.5/anonymous-access.html) for enabling anonymous access? If not then I'm really concerned this is a bug in 6.5 when a trial license somehow rolls back to a basic. Here's a sample of what is returned from xpack license endpoint (which also returns unauthenticated): `https://clusterIP:9200/_xpack/license` ```auto { "license" : { "status" : "active", "uid" : "<>", "type" : "basic", "issue_date" : "2019-02-27T18:20:06.581Z", "issue_date_in_millis" : 1551291606581, "max_nodes" : 1000, "issued_to" : "<>", "issuer" : "elasticsearch", "start_date_in_millis" : -1 } } ``` ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [March 31, 2020, 4:28am UTC](https://discuss.elastic.co/t/anonymous-access-unexpectedly-allowed/225765/4 "2020-03-31T04:28:49Z")
Is there any `.security` indices in the cluster? That would indicate that someone setup [a native realm](https://www.elastic.co/guide/en/elasticsearch/reference/6.5/configuring-native-realm.html), and it might contain your answer. Otherwise one of the folks that do our security engineering might be able to pop in with some ideas. ---
**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\ **Post date:** [March 31, 2020, 4:33am UTC](https://discuss.elastic.co/t/anonymous-access-unexpectedly-allowed/225765/5 "2020-03-31T04:33:31Z")
It looks like you have a basic license in the cluster, not a trial license. It would seem someone has reverted to a basic license at some point, which does not include security in Elasticsearch 6.5 (only 6.8 onwards). This does not happen automatically but can if I recall correctly be done through Kibana. I would recommend you upgrade to 6.8 as security is available for free there with the Basic license. ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [March 31, 2020, 4:41am UTC](https://discuss.elastic.co/t/anonymous-access-unexpectedly-allowed/225765/6 "2020-03-31T04:41:59Z")
Ahh good catch! ---
**Author:** ![diggitydug](https://avatars.discourse-cdn.com/v4/letter/d/958977/32.png) [@diggitydug](https://discuss.elastic.co/u/diggitydug)\ **Post date:** [March 31, 2020, 4:48am UTC](https://discuss.elastic.co/t/anonymous-access-unexpectedly-allowed/225765/7 "2020-03-31T04:48:44Z")
Thanks for the quick reply. But where is it picking up the 'basic' license if we have the following configured in our elasticsearch.yml? ```auto xpack.license.self_generated.type: trial xpack.security.enabled: true ``` Are you saying our theory holds water that after trial expired it automatically rolled back to 'basic' thus turning off authentication and making the search API open to unauthenticated sessions? ---
**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\ **Post date:** [March 31, 2020, 5:01am UTC](https://discuss.elastic.co/t/anonymous-access-unexpectedly-allowed/225765/8 "2020-03-31T05:01:42Z")
It does not automatically roll back to a basic license, but this rollback can be triggered through Kibana by a superuser. It seems like someone did this on the 27th of February. ---
**Author:** ![diggitydug](https://avatars.discourse-cdn.com/v4/letter/d/958977/32.png) [@diggitydug](https://discuss.elastic.co/u/diggitydug)\ **Post date:** [March 31, 2020, 5:02am UTC](https://discuss.elastic.co/t/anonymous-access-unexpectedly-allowed/225765/9 "2020-03-31T05:02:34Z")
Ah, I see... Would that be a logged operation in Kibana? ---
**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\ **Post date:** [March 31, 2020, 5:03am UTC](https://discuss.elastic.co/t/anonymous-access-unexpectedly-allowed/225765/10 "2020-03-31T05:03:22Z")
It should definately be logged in Elasticsearch if you have logs going back that far. It could possibly also be logged by Kibana. Have you had users mainly log in as superusers? ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [April 28, 2020, 5:03am UTC](https://discuss.elastic.co/t/anonymous-access-unexpectedly-allowed/225765/11 "2020-04-28T05:03:29Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.