[mdmglr]

I don’t understand the tech independence claim? The script is replacing a unified service like Google or Apple iCloud with a lot of other services. Vultr and mailgun for example.

There is something to be said about the larger centralized services. I’d be hesitant to put any sensitive files on my own server. The larger firms have security departments ready to respond to CVE’s and 0days.

[partdavid]

I work at one of these "larger firms".

You might be surprised at how much even basic things like security response or considerations are valued at "larger firms", or inconsistently applied (in part because of their size), or don't accord with the users' interests.

It's typical for "larger firms" for example to have a vulnerability evaluation process that pretty much boils down to "can we avoid responding to this vulnerability at all?" and if there's any way to avoid it, they do--because even patching will cost money. Across a big service with a variety of components? Potentially even "real" money. And the mistakes these companies make, when they make them, are often huge (like Sony storing plaintext passwords), even when they're elementary mistakes.

Put something on encrypted storage and served by a reasonably-configured OpenBSD server? That's probably quite a bit safer from compromise, when considering all threats, than Flickr or Google Drive or whatever. What it's not safer from, probably, are corruptions and loss (like from bad hardware, mistaken deletion, key loss, and so forth).

So I use both services and self-hosted things--but it's certainly the case for my "sensitive files" that they don't go within sniffing distance of a "larger firm" cloud service but are stored and backed up with my own encryption, using tools like OpenBSD and the utilities stemming from it.

As for whether it's "tech independence", perhaps it's more about being able to make the choice for yourself about where that line is drawn, rather than being forced to accept serfdom because you don't know any better. If someone takes this as a first step, moving cloud providers could be their second, or DNS registrars; or maybe revision 2 of the script (or someone else taking inspiration from it) can describe how to host your own nameservers and MTA. But there has to be some place to start, and an opinionated cookbook is not a bad one.

[quesera]

> There is something to be said about the larger centralized services. I’d be hesitant to put any sensitive files on my own server. The larger firms have security departments ready to respond to CVE’s and 0days.

Some people change their own oil, mow their own lawns, fix their own dripping faucets, etc.

Running a secure server on the internet requires different, but not more knowledge and effort, and is less expensive, than changing your own oil.

There's no need to be in thrall to the "larger firms". They have different problems, which you might not be able to solve for them -- but you can often solve your own.

[mdmglr]

I think this is disingenuous. Example: configuring a linux firewall properly is not on the same competency level of changing your oil.

This script doesn’t harden sshd to the level I’d call safe. Disabling root login is minimum. I’d have port change, timeouts, fail2ban, otp via Pam all configured. Only allow specific IP ranges and users to ssh. I’d use ansible to properly configure instead of this script.

In the case of httpd. Id run it in docker or chroot. Again fail2ban, otp, I’d probably put it on a different port have it proxied via Cloudflare and have httpd only allow Cloudflare ips.

All this that are difficult to learn.

Source: I run my families infrastructure. Which spans multiple servers, routers, switches across 7 houses in 3 countries. I also change my own oil.

[sivers]

Great metaphor. Thank you.

[moralestapia]

>The larger firms have security departments ready to respond to CVE’s and 0days.

Nah, they do have large security departments, though.

I've met many CSOs that had never wrote a line of code in their lives. That kind of works ... until it doesn't and it fails embarrasingly bad.