[-] loudwhisper@infosec.pub 3 points 2 months ago

Not that I know, which is the reason why I essentially didn't consider those threats relevant for my personal threat model. However, it's also possible it happened and it was never discovered. The point is that there are risks associated with having the same provider having access to both the emails (and the operations around them) and the keys/crypto operations.

The cost of stealthily compromising a secure email company is simply disproportionate compared to the gain from accessing my emails. Likewise, it's unrealistic to think some sophisticated attacker would target me specifically to the point that they will discover and then compromise the specific tooling I am using to access/encrypt/decrypt emails. Also, a $5 wrench could probably achieve the same goal in a quicker and cheaper way.

If I were a Snowden-level person, I would probably consider that though, as it's possible that the US government would try to coerce -say- Proton in serving bad JS code to user X. For most people I argue these are theoretical attacks that do not pose concrete risk.

[-] loudwhisper@infosec.pub 3 points 2 months ago

Thanks!

Can you make the images clickable? They’re impossible to read at that size.

I will look into it, there might be a zola option for it. If there is, sure!

This paragraph should probably mention that this won’t work if the provider uses E2EE

That paragraph is in the context of what I call "transparent encryption", which means E2EE works until the provider is not compromised and the E2EE is effectively broken by delivering malicious software or disclosing the key. E2EE is as resilient as the security of the provider, which is why picking a trusted one is important. Of course, compromising the provider and breaking the E2EE is quite complex.

[-] loudwhisper@infosec.pub 3 points 3 months ago

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!

[-] loudwhisper@infosec.pub 3 points 3 months ago

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.

[-] loudwhisper@infosec.pub 4 points 4 months ago

Yeah, indeed. To me is still completely absurd. At this point is not just a bad registrar, for most of us (hobbyists), I think it's a completely non-functional option. Basically every competitor offers an API.

I stuck with them out of lazyness for far too long.

[-] loudwhisper@infosec.pub 4 points 4 months ago

With a lot of stuff on top!

[-] loudwhisper@infosec.pub 3 points 4 months ago

But then I would ask, what's the point of paying 10-20x per computing unit at that point? If you just use ec2 instance, all AWS offers you is an API to manage them, is it worth the premium? Besides, you will still need to mess with a lot of other services (VPCs, SGs, etc.) anyways.

What's the selling point in your opinion?

[-] loudwhisper@infosec.pub 3 points 4 months ago

Is that what you get with Cloud? Because there are still a million ways to shoot yourself in the foot. The main difference is that the single genius doesn't need to implement things him/herself, but decisions still need to be taken and fragile setups can still be built.

Imagine an ec2 instance in a satellite account performing some business critical function with an instance role, whose custom IAM policy allows to do it in another account. Clouds are not giving you good engineering, they are giving you premade building blocks, you can absolutely still make a mess with those. Even more, the complexity and the immense portfolio of features can allow very creative ways to build very low-quality systems.

I think you can have good, boring, simple systems built by engineers. With or without Cloud services.

[-] loudwhisper@infosec.pub 3 points 4 months ago

What do you mean by "promotion"? A discount? Credits to get started?

[-] loudwhisper@infosec.pub 3 points 8 months ago

Yeah, and it also requires quite many options, some with harder-to-predict outcomes. For example RootDirectory can be used to effectively chroot the process, but that carries implications such as the application not having access to CA certificates anymore, which in general in containers is a solved problem.

[-] loudwhisper@infosec.pub 4 points 8 months ago

I would also add security, or at least accessible security. Containers provide a number of isolation features out-of-the-box or extremely easy to configure which other systems require way more effort to achieve, or can't achieve.

Ironically, after some conversation on the topic here on Lemmy I compiled a blog post about it.

[-] loudwhisper@infosec.pub 3 points 9 months ago

Not to the level I can get with rofi and i3. The only way to get somewhat similar is to use yabai, which needs SIP disabled to have somewhat similar features.

view more: ‹ prev next ›

loudwhisper

joined 1 year ago