7 ms·

I've been using ES off and on since before 1.0 came out. It has always baffled me that ES doesn't require a username and password by default. ES is a database

by jerrac 7y ago

I've been using ES off and on since before 1.0 came out. It has always baffled me that ES doesn't require a username and password by default. ES is a database that has to exist on a network to be usable. Heck, it expects that you have multiple nodes, and will complain if you don't. So one of the first things you do is expose it to the network so you can use it. Yes, it takes some serious incompetence to not realize you need to secure your network, but why in the world would you not add basic authentication into ES from the start? I'd never design a tool like a database without including authentication. I am serious about my question. Could anyone clue me in?

ibirman 7y ago
They offer security as a paid feature.
- jillesvangurp 7y ago
  Actually it comes for free now with the standard ES distribution. https://www.elastic.co/blog/security-for-elasticsearch-is-now-free https://www.elastic.co/blog/security-for-elasticsearch-is-no...
  - ThePowerOfFuet 7y ago
    >Security for Elasticsearch is now free What a horrific title. Even simply typing that should have been a blinking neon sign to them that they had their priorities in the wrong order.
- lmilcin 7y ago
  That's incorrect. The usual way of using this service is to have backend network configured that connects your services that is not available from outside (ie you have to traverse through services to reach it). The so called "security" is just a paid feature for companies that want to use ElasticSearch but want to use it in "legacy" way because, presumably, they don't have people to design it correctly.
  - dtech 7y ago
    That's still really insecure, because it means that as soon as someone manages to gain any access to that network or any of the services on that network has a security issue your database is wide open. That means that if someone manages to get access to the. I'd say public internet with proper (encrypted) password auth is more secure than that.
    - m00x 7y ago
      If an attacker gets a hold of your app server, they will be able to get the connection details for that DB, including the username/password. Having a password adds a small layer of protection to databases that the affected app wasn't meant to connect to. It adds some protection in that case, but the user should use best judgement if it's worth doing.
    - lmilcin 7y ago
      If attacker has access to app server it is already game over. App server typically already has access to all of the data. The pods are akin to localhost networking where there is only one externally available application with multiple networked components.
      - rbanffy 7y ago
        That's true, but there are usually multiple ways to compromise protected networks. You still need to protect the database against attacks that don't go through the app server.
jillesvangurp 7y ago
It has to exist on a private network behind a firewall with ports open to application servers and other es nodes only. Running things on a public ip address is a choice that should not be taken lightly. Clustering over the public internet is not a thing with Elasticsearch (or similar products). If you are running mysql or postgres on a public ip address it would be equally stupid and irresponsible regardless of the useless default password that many people never change unless you also set up TLS properly (which would require knowing what you are doing with e.g. certificates). The security in those products is simply not designed for being exposed on a public ip address over a non TLS connection. Pretending otherwise would be a mistake. Having basic authentication in Elasticsearch would be the pointless equivalent. Base64 (i.e. basic authentication over http) encoded plaintext passwords is not a form of security worth bothering with. Which is why they never did this. It would be a false sense of security. At some point you just have to call out people for being utter morons. The blame is on them, 100%. The only deficiency here is with their poor decision making. Going "meh http, public IP, no password, what could possibly go wrong?! lets just upload the entirety of linkedin to that." That level of incompetence, negligence, and indifference is inexcusable. I bet, MS/Linkedin is considering legal action against individuals and companies involved. IMHO they'd be well within their rights to sue these people into bankruptcy.
- jerrac 7y ago
  That does give me some food for thought. Not sure I agree a username and password is pointless though.
- LaGrange 7y ago
  > It has to exist on a private network behind a firewall with ports open to application servers and other es nodes only. Running things on a public ip address is a choice that should not be taken lightly. Clustering over the public internet is not a thing with Elasticsearch (or similar products). I've met at least one cloud provider in the past (small Dutch thing) that provides _only_ public IP addresses. They do have customers, though one less now. Clustering over the public Internet is a thing. It shouldn't, but I could say the same thing about this website and yet here we are.
lacker 7y ago
If you set up elasticsearch on a cloud service like AWS, by default your firewall will prevent the outside world from interacting with it, and no authentication is really necessary. If you do use authentication, you probably wouldn't want username+password, you would probably want it to hook into your AWS role manager thing. So to me, username+password seems useful, but it isn't going to be one of the top two most common authentication schemes, so it seems reasonable that it should not be the default. MongoDB also by default does not have username+password authentication turned on. I think defaulting to username+password is a relic of the pre-cloud era, and nowadays is not optimal.
- thegeomaster 7y ago
  I don't see why, though. It's much safer to start with a secure setup and then have the user disable the security explicitly (hopefully knowing what they're doing). Yes, username/password auth is not that common, but isn't it better than having no auth at all?
  - outworlder 7y ago
    Ok, let's say username/password is mandatory and enabled by default. I see to options. Option one, they generate an unique password for every installation – non trivial to do, because at which point do you do it? It can't be before a cluster is formed, as you'll have a split brain generating a bunch of credentials. If you do it afterwards, then there is a period of time when you cluster is not yet protected. Worse yet, unprotected and handshaking authentication. So you don't do that. You could make the user input the credentials. What is to prevent them from creating weak credentials? And worse, they have to do that for every node (or at least the masters). Not a good experience and lost credentials will probably be the subject of a good many support calls. So most products don't do that. What they do is default passwords. Which is arguably no security at all and doesn't protect anything. It may make it just a tiny bit easier to do the right thing afterwards (by changing to better credentials). Still, there's a period of time while the cluster is unprotected (default credentials are as good as no credentials). Authentication does little to protect against the sort of people who are exposing databases to the public. If it is easily disabled, then they will be doing just that. Because they are already doing that by forcing databases to bind to publicly accessible interfaces.
dmos62 7y ago
Password auth over HTTP is horrible. Short of binding a public IP address to your instance, basic auth without HTTPS setup is probably the worst thing you can do.
paco_sinbad 7y ago
It's a marketing ploy by ES. They aggregated the data and published it so that the viral breach would spread their name around because all publicity is good publicity. Just riffing of course.
0ld 7y ago
> It has always baffled me that ES doesn't require a username and password by default. because auth was a part of their paid service (and by paid i mean 'very goddamned expensive') until like half a year ago when they made it free because of freshly emerged amazons opendistro free auth plugin

by jerrac 7y ago

ibirman 7y ago

They offer security as a paid feature.

jillesvangurp 7y ago
Actually it comes for free now with the standard ES distribution. https://www.elastic.co/blog/security-for-elasticsearch-is-now-free https://www.elastic.co/blog/security-for-elasticsearch-is-no...
- ThePowerOfFuet 7y ago
  >Security for Elasticsearch is now free What a horrific title. Even simply typing that should have been a blinking neon sign to them that they had their priorities in the wrong order.
lmilcin 7y ago
That's incorrect. The usual way of using this service is to have backend network configured that connects your services that is not available from outside (ie you have to traverse through services to reach it). The so called "security" is just a paid feature for companies that want to use ElasticSearch but want to use it in "legacy" way because, presumably, they don't have people to design it correctly.
- dtech 7y ago
  That's still really insecure, because it means that as soon as someone manages to gain any access to that network or any of the services on that network has a security issue your database is wide open. That means that if someone manages to get access to the. I'd say public internet with proper (encrypted) password auth is more secure than that.
  - m00x 7y ago
    If an attacker gets a hold of your app server, they will be able to get the connection details for that DB, including the username/password. Having a password adds a small layer of protection to databases that the affected app wasn't meant to connect to. It adds some protection in that case, but the user should use best judgement if it's worth doing.
  - lmilcin 7y ago
    If attacker has access to app server it is already game over. App server typically already has access to all of the data. The pods are akin to localhost networking where there is only one externally available application with multiple networked components.
    - rbanffy 7y ago
      That's true, but there are usually multiple ways to compromise protected networks. You still need to protect the database against attacks that don't go through the app server.

jillesvangurp 7y ago

It has to exist on a private network behind a firewall with ports open to application servers and other es nodes only. Running things on a public ip address is a choice that should not be taken lightly. Clustering over the public internet is not a thing with Elasticsearch (or similar products). If you are running mysql or postgres on a public ip address it would be equally stupid and irresponsible regardless of the useless default password that many people never change unless you also set up TLS properly (which would require knowing what you are doing with e.g. certificates). The security in those products is simply not designed for being exposed on a public ip address over a non TLS connection. Pretending otherwise would be a mistake. Having basic authentication in Elasticsearch would be the pointless equivalent. Base64 (i.e. basic authentication over http) encoded plaintext passwords is not a form of security worth bothering with. Which is why they never did this. It would be a false sense of security. At some point you just have to call out people for being utter morons. The blame is on them, 100%. The only deficiency here is with their poor decision making. Going "meh http, public IP, no password, what could possibly go wrong?! lets just upload the entirety of linkedin to that." That level of incompetence, negligence, and indifference is inexcusable. I bet, MS/Linkedin is considering legal action against individuals and companies involved. IMHO they'd be well within their rights to sue these people into bankruptcy.

jerrac 7y ago
That does give me some food for thought. Not sure I agree a username and password is pointless though.
LaGrange 7y ago
> It has to exist on a private network behind a firewall with ports open to application servers and other es nodes only. Running things on a public ip address is a choice that should not be taken lightly. Clustering over the public internet is not a thing with Elasticsearch (or similar products). I've met at least one cloud provider in the past (small Dutch thing) that provides _only_ public IP addresses. They do have customers, though one less now. Clustering over the public Internet is a thing. It shouldn't, but I could say the same thing about this website and yet here we are.

lacker 7y ago

If you set up elasticsearch on a cloud service like AWS, by default your firewall will prevent the outside world from interacting with it, and no authentication is really necessary. If you do use authentication, you probably wouldn't want username+password, you would probably want it to hook into your AWS role manager thing. So to me, username+password seems useful, but it isn't going to be one of the top two most common authentication schemes, so it seems reasonable that it should not be the default. MongoDB also by default does not have username+password authentication turned on. I think defaulting to username+password is a relic of the pre-cloud era, and nowadays is not optimal.

thegeomaster 7y ago
I don't see why, though. It's much safer to start with a secure setup and then have the user disable the security explicitly (hopefully knowing what they're doing). Yes, username/password auth is not that common, but isn't it better than having no auth at all?
- outworlder 7y ago
  Ok, let's say username/password is mandatory and enabled by default. I see to options. Option one, they generate an unique password for every installation – non trivial to do, because at which point do you do it? It can't be before a cluster is formed, as you'll have a split brain generating a bunch of credentials. If you do it afterwards, then there is a period of time when you cluster is not yet protected. Worse yet, unprotected and handshaking authentication. So you don't do that. You could make the user input the credentials. What is to prevent them from creating weak credentials? And worse, they have to do that for every node (or at least the masters). Not a good experience and lost credentials will probably be the subject of a good many support calls. So most products don't do that. What they do is default passwords. Which is arguably no security at all and doesn't protect anything. It may make it just a tiny bit easier to do the right thing afterwards (by changing to better credentials). Still, there's a period of time while the cluster is unprotected (default credentials are as good as no credentials). Authentication does little to protect against the sort of people who are exposing databases to the public. If it is easily disabled, then they will be doing just that. Because they are already doing that by forcing databases to bind to publicly accessible interfaces.

dmos62 7y ago

Password auth over HTTP is horrible. Short of binding a public IP address to your instance, basic auth without HTTPS setup is probably the worst thing you can do.

paco_sinbad 7y ago

It's a marketing ploy by ES. They aggregated the data and published it so that the viral breach would spread their name around because all publicity is good publicity. Just riffing of course.

0ld 7y ago

> It has always baffled me that ES doesn't require a username and password by default. because auth was a part of their paid service (and by paid i mean 'very goddamned expensive') until like half a year ago when they made it free because of freshly emerged amazons opendistro free auth plugin