I agree with you on the principle. In this case I disagree with the premise. Years of actions I think easily out weight that tweet. If that’s the only reason to be suspicious, then I don’t think it’s warranted.

Thanks, I appreciate it.

Sure, it does. Which depending on what their goal is, may be perfectly fine.

They have always been actively almost exclusively on reddit (where they engage) anyway, they will keep doing so I assume.

The problem is that those arguments are not falsifiable. If not one, but two completely reasonable explanation cannot convince you of someone motivations, nothing can. However, I don’t care if Musk did or did not a Nazi salute. His actions speak much louder (in a bad sense) than the aesthetic that he decides to adopt. Proton donation pattern for example would be a strong indicator to measure intentions.

but it was a wildly tone deaf one if so

Maybe. But also maybe people are allowed to have different cultural references, and in a global context (i.e., the internet) we should expect diversity. I - for example - had never heard of this 88 thing, and I would definitely not think about it at all the next time I create a username, and I didn’t think it when I went to a barber shop that has that number in the name. Likewise, I wouldn’t call anybody writing “Merry Xmas” tone deaf for missing the reference to the X MAS of infamous history (and just recently in the news). For some people it’s apparently impossible to see their culture as non-universal (at the cost of sounding stereotypical, folks from US have particularly this problem after decades of cultural hegemony).

for a party that’s steeped in all of the same memetic game playing, you cant ignore the dog whistles

This all happened before Musk/Bannon salute. Just to specify it.

It’s not a problem of complexity, it’s a deliberate choice of not wanting to do that, because it is synthetic content disconnected from the community.

This comment is a perfect example of why I have written https://loudwhisper.me/blog/proton-fediverse-burnout/

The 88 thing is the complete tip of the iceberg for me. I can’t honestly imagine the thought process needed to reach a conclusion that a Taiwanese guy (8 is a lucky number) born in '88 would put that number as a dog-whistle (which is not really part of his own cultural landscape) for Nazis, while dealing with a PR issue.

It’s like looking at a crashed car, tire marks on the ground and suggesting it must have been a sharknado and not a car accident.

(Re)Posting and not engaging with the community is not free publicity, is bad publicity. They don’t have the resources (according to them) do to the latter, and therefore they choose not to do the former.

In case of proton free means “subsidized by paying users”. No big mystery on how they make money.

They specifically said they don’t want to do automated posting, to avoid writing and not interacting with the community. I see no value in them doing this, considering we can get the same content via RSS, blog page or email newsletter. Presence makes sense if it means presence. If it means a bot reposting content, anybody can do it, but the value is very low.

The biggest items on the graph are all out of bounds accesses, use-after-free and overflows. It is undeniable that memory safe languages help reducing vulnerabilities, we know for decades that memory corruption vulnerabilities are both the most common and the most severe in programs written in memory-unsafe languages.

Unsafe rust is also not turning off every safety feature, and it’s much better to have clear highlighted and isolated parts of code that are unsafe, which can be more easily reviewed and tested, compared to everything suffering from those problems.

I don’t think there is debate here, rewriting is a huge effort, but the fact that using C is prone to memory corruption vulnerabilities and memory-safe languages are better from that regard is a fact.

Oh, it looks like! Something went wrong with Zola build and I must have not noticed. Thanks a lot for pinging me about that, I will fix it today!

EDIT: Fixed! That’s what you get when you forget to bump the Docker image version after you upgrade zola version locally with a breaking change in the config! :) Thanks for letting me know, it would have taken me a long time to see it was broken!

Comfort is the main reason, I suppose. If I mess up Wireguard config, even to debug the tunnel I need to go to the KVM console. It also means that if I go to a different place and I have to SSH into the box I can’t plug my Yubikey and SSH from there. It’s a rare occurrence, but still…

Ultimately I do understand both point of view. The thing is, SSH bots pose no threats after the bare minimum hardening for SSH has been done. The resource consumption is negligible, so it has no real impact.

To me the tradeoff is slight inconvenience vs slightly bigger attack surface (in case of CVEs). Ultimately everyone can decide which compromise is acceptable for them, but I would say that the choice is not really a big one.

Hey, the short answer is yes, you can.

I would elaborate a little more:

• First, you have the problem of sourcing the data. In essence, Crowdsec won’t be able to go and fetch those logs for you dynamically, but can go and take those logs from a file (you can do a dirty solution like a sidecar deployment) or from a stream. You can deploy crowdsec in multiple modes, and you can have many instances that talk to each other. You can also simply have some process tailing the pod logs and sending them to a file crowdsec has access to or serving them as a stream (see https://doc.crowdsec.net/docs/data_sources/intro).
• The above means that it doesn’t really matter whether you run Crowdsec inside your cluster (it does have a Helm chart) or on the host. Ultimately all it matters is that crowdsec has access to your pods logs (for example, the logs of your ingress controller).
• The next piece is the remediation component. What do you want crowdsec to do, once it is able to detect bad IPs? If you want to just add IPs to the firewall, then it might make more sense running it on the host(s) you use in ingress, if you want to add the IPs to network policies you can do it, but you need to develop your own remediation components. I am planning to write a remediation component that will add the IPs to Hetzner firewall, some other systems are already supported, but this would be a way to basically block the IPs outside your cluster. For nginx ingress controller there is already a pre-made remediation component .

In practice I personally would choose a simple setup where the interesting logs are just forwarded (in Syslog format for example) to a single crowdsec instance. If you have ingress from a single node, I’d go for running it on the host and banning via firewall, if you have multiple ingress nodes, then I would run it inside the cluster and ban via a loadBalancer/cloud firewall/whatever you have in front.

In essence, I would spend some time to think about your preferences, and it might take a little bit to make the setup clean, but I think you have plenty of flexibility to do what you prefer. Let me know if you want to bounce some more ideas!

Yeah I know (I mentioned it myself in the post), but realistically there is no much you can do besides upgrading. Unattended upgrades kick in once a day and you will install the security patches ASAP. There are also virtual patches (crowdsec has a virtual patch for that CVE), but they might not be very effective.

I argue that VPN software is a smaller attack surface, but the problem still exists (CVEs) for everything you expose.

Nice! I didn’t know this. Thanks!

AFAIK I know that SSH has MaxAuthTries and LoginGraceTime, but all it does is terminating the SSH session (I.e. slow down at most), it won’t block the IP via firewall or configuration.

Not sure if there is a recent feature that does the same.

Yes, I have used it in the past and it was annoying…

You can get SSL certs with letsencrypt, but you need to use the http verification method.

Yeah, what I mean is that it’s useless using ports like 2222, that’s like the unofficial SSH port! Bots are generally harmless (once you move to key auth), and you get functional the same result with the automatic IP ban on failed auth, minus the bother to change client configurations to your custom port. Anyway, if someone does want cleaner logs, changing port works :)

Also hypervisors get escape vulnerabilities every now and then. I would say that in a realistic scale of difficulty of escape, a good container (doesn’t matter if using Docker or something else) is a good security boundary.

If this is not the case, I wonder what your scale extremes are.

A good container has very little attack surface, since it can have almost no code or tools available, a read-only fs, no user privileges or capabilities whatsoever and possibly even a syscall filter. Sure, the kernel is the same but then the only alternative is to split that per application VMs-like) and you move the problem to hypervisors.

In the context of this asked question, I think the gains from reducing the attack surface are completely outweighed from the loss in functionality and waste of resources.

Completely agree, which is why I do the same.

Additional bonus: proxies that interact with the docker API directly (I think also caddy can do it) save you from exposing the services on any port at all (only in the docker network). So it’s way less likely to expose a port with a service by mistake and no need for arbitrary and unique localhost ports.