Remember when everyone told you to check your Google Account for location history and activity tracking and so on?

You should do the same with your Microsoft account (if you have one). They also have such a page about personalized advertisement, activity history, location history, buy history, …

You might want to change some of those settings :)

@xoxys Yes, but after more reading it could be the case, that it wasn't a service account installed within the OS, but on the server hardware:

The classic remote management interface of the server itself. Which usually shouldn't even be available from the internet, but it seems like the hoster they selected didn't care about that.

Link TED talk on language 

@Katsudon The basics are: Use HTTPS, if set an DoH provider of your trust in your browser and don't click through error messages.

Along with don't install additional certificates if you don't know what you are doing and so on.

All in all in boils down to: Don't pretend to be smarter than the piece in front of you. Especially when it comes to security warnings.

For public WiFis use HTTPS everywhere and enable the "Encrypt All Sites Eligible" setting. That's pretty much it.

Realy great article about Hardware security tokens:

It contains a ton of information for people who want to learn a bit about modern security tools :)

Cache-Poisoned Denial-of-Service (CPDoS) is a new class of web cache poisoning attacks aimed at disabling web resources and websites.

@xoxys Yes. Or use one of their ISO images to install the machine using the interactive console. This should make sure no weird service users from your providers are left in there.

As I just saw some people talking about "With self-hosting this wouldn't have happened", I have to say, looking at the self-hosting scene and their usage of vendor images for server installs, this would have happened the same way with most self-hosted setups.

Most people, don't use their own OS images when setting up new servers. You should do this to mitigate vendor accounts.

Just donated $100 to @gnome to fight a patent troll

Any software entity choosing to spend time to squash the fuckers instead of silently paying up has my utmost respect.

Please consider donating too, it's a good cause!

@waweic I don't say there is no reason to use them, but the reasons most of them advertise are simply wrong. They don't make your network connections more secure and you don't become anonymous. You get some pseudonymity and "secure" transfer to your VSP, but that's it.

Depending on what you are doing that can be enough, but most people simply don't need that, especially when you want to make use of your civil rights you might end up fighting a shadow company.

@blacklight447 To be honest, is easier to justify. I mean they are a development company and they didn't higher lots of Ops people, therefore things went up and down.

But this company? A VPN company? Handing certificates is their bread and butter. And operating the VPN network securely the main purpose of their company.

@Katsudon To make it easy, I assume your VPN ISP is trustable as well and you don't act stupid.

With VPN enabled, the attacker will only be able to see, that you are connected to the this particular VPN service. With proper configuration, no DNS lookups and no SNI information will be possible.

When you use DoH and HTTPS without VPN, the eavesdropper can see that you are connecting your bank due to SNI headers or IP, and that's it.

@Katsudon Only from your workstation to the place the VPN connection is terminated.

On the internet, that still means that there can be a bunch of boxes in between. Just not the same boxes as you would have between you and your target.

Also we should use TLS on pretty much everything nowadays and therefore the VPN only hides minor metadata like IP addresses, which makes their security benefit minimal. (All this, talking about public VPN services, company VPNs are a little bit different)

@Katsudon That's a rather easy one: They are used to restrict or grant access to networks and services, when they grant access based on network zones.

Of course, those connections are encrypted, but that's to prevent information leaking to eavesdroppers along the way between you and the network you are connecting.

With public VPN services like NordVPN, this not exactly the case. With such a VPN service you connect to the (same) internet, just at another point of the world.

Those "lessons learned" are more like lessons you should already know. But not everyone is an expert, and not everyone thinks of everything in first place. Therefore I hope there are maybe some people who at least get something new out of it.

By the way, most likely you don't need a public VPN service at all. They neither provide anonymity, nor much additional security, when you get some basics right.

If you really wonder about those basics, feel free to reach out :)

Some "lessons learned" from the whole disaster:

1. Revoke keys when you notice the private key was compromised
2. Use HSMs to prevent private keys from getting compromised
3. Inform your customers about breaches
4. Do proper audit logging of your systems' user accounts
5. Use your own OS images, when installing machines
6. Run an IDS to get informed when your production systems act unusual
7. Spend more money on infrastructure security, less on marketing it

Currently checking my shared documents on Nextcloud and came across an interesting PDF that seems to be around for quite a while:

Just if someone never saw it before. It's a little privacy guide that has quite some nice illustrations for kids. Why not teach team blue vs. team red as a super hero comic?


Agreed, happens over here as well. But I guess non of us is in a situation where it happens permanently and maybe even with people around who do this intentionally.

So I guess it's less because it happens, but more because it constantly happens? (Imagine being constantly called by a name you really dislike)


Show more

Sheogorath 🦊's choices:

Sheogorath's Microblog

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!