Sven Slootweg (soft-deprecated) @joepie91@pixie.town

@m04 FWIW, it seems that 3M calls these 'braided straps', maybe that term will help find the right ones?

@scanlime Exactly. It's the same kind of scam as in much of the corporate consulting world: if you just charge a high enough fee, nobody in the company will dare to question whether they are actually getting value for money because your head is going to be on the chopping block for pointing out the error of the higher-up, so why bother checking

@scanlime Don't have to actually be right if you can make your customers *believe* that you are right!

*taps forehead*

@scanlime Trying to look confident so that they can sell bigger data plans to companies trying to do 'competitor research', basically

@baldur I mean, with how normalized it has become for companies to be shitty with no recourse (ie. "free market politics"), that's not that surprising to me, even though that absolutely shouldn't be how it is

@katnjiapus The recommendations I usually give people are basically:

1. Disable password authentication for SSH, and use keypair authentication only (these are two separate steps!). Changing ports is not needed, fail2ban also isn't really.

2. Either set up automatic system updates ("unattended upgrades", or whatever your distro of choice calls them) or have a scheduled event every week to update manually and keep track of security notices. The former is easiest.

Make sure to do full distro upgrades when a new release comes out; those are usually not automatic, even with automatic updates enabled.

3. When running public-facing services, if you *can* sandbox them, do so. On NixOS this is automatic for a lot of services, using Docker it's *sort of* sandboxed (but not very well, usually), on other systems you may have to do this manually but it can usually be done directly in the systemd service file.

That's... more or less it, as the basic steps? Like, there's a lot more that can be done, that's specific to the services you run (and often explained in their documentation), but if you get these few things right, you're already doing better than a lot of public-facing production servers.

Of course, if you intend to do something especially sensitive (eg. services for activists), you should be getting someone involved who has experience in this sort of thing. This list is just for your run-of-the-mill personal/community/small-company/etc. server.

--

To elaborate on the port changing and fail2ban thing a bit: these are really common recommendations but I don't find them useful in practice, and they bring their own issues.

The port-changing is a form of security-through-obscurity that dates back to when internet-wide scanners only scanned for SSH servers on port 22 for capacity reasons. This hasn't been relevant since zmap, and so doesn't do anything anymore besides "making you manually specify the port for any SSH-based tool like rsync".

The fail2ban recommendation comes from the password login days; it's a way to throttle login attempts so that someone can't bruteforce a password over the network. But with keypair authentication this is not relevant, as long as password auth is entirely *disabled*; the search space is so big that even without throttling you will never bruteforce a key.

*At best* it reduces log entries and slightly reduces CPU use, at the cost of making it very easy to accidentally lock yourself out if eg. you try to connect from a spotty mobile connection that has to reconnect a couple of times in a short time.