Slashdot Mirror
Elasticsearch Clusters Face Attacks From Multiple Hacker Groups (csoonline.com)
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.
What? These are different companies with different data and different algorithms operating on that data... You should *expect* different results. Censoring would be completely removing the content. Private companies are allowed to do that. It's not even outrageous. There are more companies that put limits ("censorship") on what content they allow than companies that are completely free of rules. That's because companies care about what their paying customers have to say, and since any major customer or segment of customers will be outraged at something, you end up with limits that reflect the union of complaints the company has received or expects it would receive if it didn't have those limits. Plus, some companies have their own motivation for those limits, like the beliefs or sensibilities of the executives. All this is ok.
But it's also the reason that we need independent, non-profit organizations to deliver real news and "free search". Google and Twitter are not up for the job.
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!
So like Duck Duck Go and NPR models? They exist.
The strawman is strong with this one.
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.
Kriston
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 isn't going to add anything to the HTTP security space of any value, so why bother?
ES is currently on version 6 and v7 is in beta. If you are still running version 1, you deserve anything that happens to you.
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.
Kriston
You should know better than directly exposing Elastic search/ELK to the Internet, if at all.
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....
Ive got an elasticsearch cluster every time I open my underwear drawer.
Always hackers! Never our own fault! Hackers! They're everywhere! Hackers! They can do anything! Hackers! You can't blame it on me! Because it was! Hackers!
I'm TELLling YOu! HACKERS!!!!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
The cesspool just got a check and balance.
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.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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 until there were tears in my eyes several times.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
No. Each of those has built-in security. I think you read my post incorrectly.
Kriston
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 use a per-user to DB connection authentication?
So effectively, everything listed (except maybe SAP since you'd need to define exactly what part of SAP you're talking about) needs some sort of proxy to handle individual security concerns.
But all of that is moot, really - why would you ever expose an ElasticSearch service directly to the internet? About as often as directly exposing a DB or messaging service.
The cesspool just got a check and balance.
Both MySQL and PostgreSQL provide for public key encryption, in other words, not just "single password security."
Kriston
Duck Duck Go is a well known honeypot, said to be operated by US naval intelligence.
Are you drunk, or just ignorant? MySQL has fine-grained security built in.
You're right, it has absolutely useless fine-grained security for 99% of the uses people use it for.
The cesspool just got a check and balance.
this sort of "news" isn't useful - the current version of elasticsearch is 6.6, so why is 1.x newsworthy? are a lot of people running 1.x? "news" like this without context isn't useful - put it into context - what % of ES installs are 1.x? if something hasn't been updated in five versions, is it super old, or is it like chrome where that's a slow night of releases?