loudwhisper
@loudwhisper@infosec.pub
- Comment on Email Security for Every Taste 2 months ago:
Sorry about that :) But you get the credit for spotting the problem! Thanks for that!
- Comment on Email Security for Every Taste 2 months ago:
Thanks, I have taken @sugar_in_your_tea@sh.itjust.works’s suggestion and I have added “create”.
- Comment on Email Security for Every Taste 2 months ago:
With Simplelogin integration Proton does PGP encryption because effectively all emails are forwarded by a simplelogin address. I have just tested to be sure, and I can confirm it is the case. I agree though that this only protects “my side”, which is why I said that it doesn’t provide all the PGP features.
Publishing your PGP public key next to your email doesn’t require “wasting a domain” or anything like that
It does if I don’t have any key that I use for emails. My key(s) is bound to the Proton account with the other domains I use, so for this domain I would need to either add it (back) to Proton (easier option, but “wastes” a domain) or just generate and manage a key myself, that I can then even add manually to Proton, but I didn’t bother doing this just yet. I am not going to use any other public key I have because I wanted specifically to keep this domain separated from my identity.
I just thought it was amusing that you didn’t seem to actually follow your own advice.
FWIW, I do follow the described setup for everything personal, which is what matters to me. As I said, ~1/2 months ago I did have my PGP key because I enrolled the domain into Proton, which if anything is a testament to how annoying it is having to manage keys myself (which I already do for signing commits etc.). Maybe I will spend some time to polish the setup, eventually.
- Comment on Email Security for Every Taste 2 months ago:
I don’t think so, does it sound weird? Not a native speaker, so maybe it does :)
- Comment on Email Security for Every Taste 2 months ago:
Yep, I am aware of the contradiction. I used to, but since then I moved to an alias as it was not worth wasting a domain for a single address. I may spend eventually the time to setup PGP for the alias itself, but I just didn’t. It’s a Proton alias, so I get anyway PGP encryption, though (obviously without all the features, but good enough for the near-zero volume I currently have).
- Comment on Email Security for Every Taste 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.
- Comment on Email Security for Every Taste 2 months ago:
Thanks, I will go and double check, I am sure there are more typos!
I honestly didn’t think at all about the use of checkmarks/crosses and the fact that it can be misinterpreted, I will add a disclaimer.
A bigger issue IMO is how you describe email encryption in transit as a matter of fact, but according to Google transparency report[1] there are still domains that do not support in transit encryption, and, what’s worse, when you send an email you can’t tell if it will be encrypted or not.
you are right. The reason why I took that for granted is because I assumed the scenario in which people use the “mainstream” providers. I was looking at data and I think Outlook and Gmail alone make up more than 50% of the market share. I made an assumption which I considered fair, as 99%+ of the users do not need to worry about this at all. However, this is interesting data and I might add a note about it as well, so thanks!
- Comment on Email Security for Every Taste 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.
- Comment on Email Security for Every Taste 2 months ago:
Thanks a lot! Hopefully at least someone finds it helpful!
- Submitted 2 months ago to technology@lemmy.world | 22 comments
- Comment on Basic Security for your Website | Loudwhisper 3 months ago:
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.
- Comment on Basic Security for your Website | Loudwhisper 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 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!
- Comment on Basic Security for your Website | Loudwhisper 3 months ago:
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.
- Comment on Basic Security for your Website | Loudwhisper 3 months ago:
Nice! I didn’t know this. Thanks!
- Comment on Basic Security for your Website | Loudwhisper 3 months ago:
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.
- Comment on Dynamic IP - Self hosting 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.
- Comment on Basic Security for your Website | Loudwhisper 3 months ago:
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 :)
- Comment on Security and docker 3 months ago:
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.
- Comment on Why do so many people use NGINX? 3 months ago:
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.
- Comment on Dynamic IP - Self hosting 3 months ago:
Since you run already OpenWrt, you can check out openwrt.org/docs/guide-user/services/ddns/client
There is a list on this page of compatible services. If you don’t want to use one more service (DNS), you can use a domain registrar with an API (like porkbun) and find online tools that work with that.
Be aware of the risks of hosting your websites publicly from home, make sure to run them in very isolated environments. Having your VPS compromised is bad, but having your home network compromised is much worse!
- Comment on Basic Security for your Website | Loudwhisper 3 months ago:
Fair question. What I meant is that suggesting that would have made the whole post 10 lines long and not worth doing. So I avoided such suggestions that completely change the threat model.
It’s not useless to avoid a good security posture (although you might have concerns of a monopoly gatekeeping the internet, TLS traffic inspection privacy concerns etc.), on the contrary makes everything I have written about here redundant (+ provide more, like DDoS protection) as you are outsourcing the security controls.
- Comment on Basic Security for your Website | Loudwhisper 3 months ago:
Yep I agree. Especially looking at all the usernames that are tried. I do the same and the only risk come from SSH vulnerabilities. Since nobody would burn a 0-day for SSH (priceless) on my server, unattended upgrades solve this problem too for the most part.
- Comment on Basic Security for your Website | Loudwhisper 3 months ago:
That is basically the essence of this post too! Except crowdsec is used to do what fail2ban does + some light form of WAF (without spinning another machine - which is not strictly needed for a WAF, you can use owasp modsecurity-ready proxies).
- Comment on Basic Security for your Website | Loudwhisper 3 months ago:
Thanks! I did mention this briefly, although I belong to the school that “since I am anyway banning IPs that fail authentication a few times, it’s not worth changing the port”. I think that it’s a valid thing especially if you ingest logs somewhere, but if you do don’t choose 2222! I have added a link to shodan in the post, which shows that almost everybody who changes port, changes to 2222!
- Submitted 3 months ago to selfhosted@lemmy.world | 26 comments
- Comment on PSA: GoDaddy gated their own API. DDNS users warned 3 months ago:
Yes, pretty much that. Plus some configuration might be easier with a DNS hosting. But the main benefit is decoupling domain and DNS for easier change.
- Comment on PSA: GoDaddy gated their own API. DDNS users warned 3 months ago:
Been there…
I thought my API keys were expired, I regenerated them, changed a couple of things, checked all API calls to see if they changed API itself…then I searched the exact error and found out.
For such a breaking change to the API, was it hard to drop an email to every account not meeting the damn “requirements” with an API call performed in the last x months, to alert of the change?
- Comment on PSA: GoDaddy gated their own API. DDNS users warned 3 months ago:
Yep, I like bunny in fact. It didn’t have all the features I needed back then, but it’s a very good product, I heard very good things.
I also agree about the pricing. I ended up not using desec.io, but if I did, I would have probably set a 1-2 Euros recurring donation, as I feel that’s a totally acceptable price.
As for why people use GoDaddy well… I feel personally attacked as that’s exactly how I ended up there, when I didn’t know better.
- Comment on PSA: GoDaddy gated their own API. DDNS users warned 3 months ago:
I also use porkbun, their API is not a masterpiece but it works and allows you to get, set and update records. In fact their API is now supported by some of the common ddns scripts out there.
- Comment on PSA: GoDaddy gated their own API. DDNS users warned 3 months ago:
I think I used it in the past. Is the one where every X months you need to go the the console and confirm the domain is still used, right?
I think nowadays there are better options (incl. Free) with less maintenance and more flexibility