Elasticsearch Clusters Face Attacks From Multiple Hacker Groups (csoonline.com) 28
itwbennett writes: If you're running Elasticsearch 1.4.2 and lower, you should make sure your patches are up to date. That's because researchers from Cisco's Talos group have "detected an increase in attacks targeting unsecured Elasticsearch clusters." At least six different groups are responsible for the increase, each deploying different malware, but regardless of the method, the potential impact of a breach is huge because Elasticsearch is designed to work with big data and companies use it to process sensitive data. "Given the size and sensitivity of the data sets these clusters contain, the impact of a breach of this nature could be severe," the Talos researchers warned.
Re: (Score:2)
NPR? Literally founded by CIA operatives, directly funded by the State, and obsessed with politics (they relegate science to 2 hours a week, when that's what fuels our economy). The economics show is purely Keynesian, for instance - anything not pro-State is verboten.
Re: (Score:2)
This is a little bit off-topic, but there's some interesting stuff on that interview about big tech, and especially the references to the person who rage-quit Facebook, took the deplatforming documents with her, and gave it to Veritas. Not to mention Google's collaboration with China and tech centralization which both are tangentially relevant to Elastic Search (we all know these crappy unsecure sites are usually run by numbskulls on AWS).
That aside, this podcast is so hilarious at times that I laughed un
monetization (Score:4, Insightful)
One problem is that Elasticsearch is insecure by default. It's part of their "open core" monetization strategy. The FOSS core of ES has no security whatsoever - it's wide open to the world. Security functionality is available only as part of the proprietary X-Pack extensions.
AWS managed ES, probably the most widely used flavor of ES, adds very crude IP-based all-or-nothing security. Which IIRC is wide open by default. Unfortunately AWS seems intent on leaching. They charge their users handsomely for hosted ES, but are unwilling to contribute a dime - or any code - back to the Elasticsearch project. So they get zero cooperation from Elastic Co. And AWS ES remains a security nightmare.
It's a shame that Elastic choose to make basic security a monetized feature. And it's a shame that AWS is so enthusiastic about leaching. And finally it's also a shame that the Law in most cases imposes little or no penalty at all on companies who fail to protect all the personally identifiable information they hoard.
Expect more data spillage in the future!
Re: monetization (Score:2)
We had a temporary misconfiguration on some of our ES hosts leaving them open to the public and discovered it from what appeared to be some gray hat hacker who was triggering periodic crashes as a way of communicating the problem.
It wasn't unknow that ES is not secure by design, so it's not the fault of ES, but they do make it easy to accidentally fuck up.
It originally didn't even have passwords or TLS (Score:2)
Speaking of Elasticseach and security, up until a relatively short time ago the community release of Elasticsearch didn't even have passwords or TLS. To hear news like this makes me think that running an operation like that undermined its security culture.
The add-on is called X-Pack and only became freely available in the June 2018 with Elasticsearch 6.3.
Re: It originally didn't even have passwords or TL (Score:2)
I can understand the argument though. We (nix users, at least) all know monolithic software sucks and that each app should do one thing well.
Authentication, encryption, and firewalls are all different problems with a lot of different tools and approaches. ES just takes a hard stance on this and says that you handle those issues somewhere else in the stack.
It's not hard to put ES behind nginx and handle all your needs that way. But if you're more comfortable with other proxies, you can do that instead. ES is
Re: (Score:2)
While I agree on the premise, there are literally no other services that I can think of that expect to you put a proxy in front of them to provide security with the possible exception of Tomcat.
Re: (Score:1)
While I agree on the premise, there are literally no other services that I can think of that expect to you put a proxy in front of them to provide security with the possible exception of Tomcat.
MySQL
....
Oracle
DB/2
Any of the Queue software
SAP
CORBA
Re: (Score:2)
No. Each of those has built-in security. I think you read my post incorrectly.
Re: (Score:1)
Simple single password security, or frameworks that provide security. Not security like you'd need for ElasticSearch type services. In some ways, the security used by systems such as MySQL are even worse than no security at all. CORBA has no built in security, it's a separate component layered on top but not necessary. Neither do some queue services, they're added on but not required. The DBs have at least basic security, but their use is generally single password based. When's the last time you saw an app
Re: (Score:2)
Both MySQL and PostgreSQL provide for public key encryption, in other words, not just "single password security."
Re: (Score:1)
It you are running ELK (Score:1)
Even in internal enterprise deployments, you should know better than not listening only to 127.0.0.1, and sanitising the inputs on the frontend, and not allowing people to query them at will abusing the frontends.
But hey, common sense seems to be a commodity nowadays....
Re: (Score:2)