5 ms·
This same article was posted previously, so I will post the same response I posted on the other thread: Elasticsearch until recently did not nudge you to set u
by pevey 5y ago
This same article was posted previously, so I will post the same response I posted on the other thread:
Elasticsearch until recently did not nudge you to set up a username or password by default. I noticed the last time I installed it on a fresh instance that on completion of the install it gives you a warning about this and tells you what to do to set a password. That is a small improvement.
Most people would not have the service bound to a public interface, but for those who do for whatever reason have a set up where they are accessing it remotely, at least now there is a tip off that it is completely open to the world by default. This is different from pretty much any other service you might install. MariaDB for instance by default does not allow remote root login even if you change the config to bind it to 0.0.0.0.
A lot of people are just totally unaware of this issue. When I read about database leakage, I generally assume 90% probability it was elastic, these days. Defaults are so important.
- XorNot 5y agoMy solution to this has always been to auto-generate a password and dump it in a by file. If it's a test instance then this is a nice obvious place to go get it from. If it's not then the service isn't open by default, and in both cases we're not asking people to enable remote access themselves by some scheme which may allow them to do it without setting a password. Same thing with TLS IMO: let certs be specified, or default to generating some - any option is better then default no encryption.
- bryans 5y agoThere are lots of lessons in the internet's limited history that show poorly conceived defaults are the most common and dangerous mistake. Microsoft let Frontpage Extension credentials default to the domain name and a blank password through multiple major versions, without any prompt to change anything (you had to seek out the settings, and it wasn't even obvious where they were). Throughout the late 90s and early 00s, entire hosting companies were continuously compromised because of this, along with nearly every school district in the US and tons of major universities. Schools typically had the worst security and most available processing power and bandwidth, already making them the preferred targets of script kiddies everywhere. That exploit was single-handedly responsible for hundreds of thousands of bots (and more likely millions in later years) which wreaked havoc on the internet as a whole -- these were the days when a handful of bots on good connections could take down the Amazons of the world for lengthy periods (days, not hours). That they let it go on for so long was comical at the time, but in hindsight seems criminally negligent.
- Tabular-Iceberg 5y agoI remember hearing about FrontPage Extensions back in the day. I never had an opportunity to make use of them since I used Dreamweaver at the time, but what exactly were they? I tried googling, but couldn’t find a plain language explanation, only opaque marketing speak.
- bryans 5y agoExtensions were a way of connecting the FrontPage editor directly to an IIS server, which provided publishing functionality (i.e. uploads) and basic server management. Ultimately, they were just a bunch of server scripts that responded to commands from the client over an FTP-like connection.
- Tabular-Iceberg 5y agoI see, so basically a static site deployment platform using today’s buzzwords.
- zurn 5y agoInteresting that ES is still such a widely used component, this is a huge red flag about a software product. And of course there are lots of other regular complaints about it (eg uses a lot of memory and wants a 3-node cluster so costs 4 figures/mo to run on AWS).
- phillu 5y agoI guess there are more things to consider when choosing a software product then poor security defaults and that it feels expensive.
- Chyzwar 5y agoBecause ES cluster should not be on public network. If anything this is red flag for AWS. ES v8 there many improvments to security. It cost that much because AWS is incredibly expensive.
- zurn 5y agoNetwork segregation is your last line of defense. Having anything rely on it is a recipe for a bad security that's always just one step away from someone getting around it due to misconfiguration, request forgery, networks configuration changes over time, malware transiting over via VPNs etc. And of course from the SW vendor POV they don't know if the customer env employs this defense in depth layer, so it's really irresponsible to rely on it. Like is amply demonstrated here... If a product upon unboxing promptly flops on its back with "come here internet" access controls, even if by good fortune it's saved by your network ACLs, it's time to put it back in the box and return it.
- rr808 5y agoOne problem is there is very little reliable best practice on network security. Do you have any good resources?
- pvg 5y agoThis same article was posted previously, so I will post the same response Don't repaste your own comments just because there's been a dupe.
- Tabular-Iceberg 5y agoWhy not? I’m not saying people should do it, but what are the arguments against it?
- OrderlyTiamat 5y ago(not gp) I would prefer having a link to the other post (as someone above provided) so the comments there can be read. Duplicating the comments means I see the same thing twice, or it means the previous replies to that comment are now obscured to me. Which of the two it is depends on whether I find the other post. Not a desirable situation imho.
- remram 5y agoThere you go: https://news.ycombinator.com/item?id=30144920 https://news.ycombinator.com/item?id=30144920
- pvg 5y agohttps://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=author%3Adang%20copy-paste%20comments&sort=byDate&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... Also dupes are pretty common, it'd be weird to the repaste the same discussion into every dupe thread.
- deleted 5y ago[deleted]
- raesene9 5y agoSecure defaults are super important, especially on complex systems as people will not want to mess with the out of the box configuration too much when setting things up. One additional consideration is that the secure defaults should be usable, otherwise the tendency will be to just disable them entirely (think SELinux and how commonly that's turned off as the first action on server setup)