How do we know if there aren't a bunch of more undetected backdoors?
How do we know if there aren't a bunch of more undetected backdoors?
I have been thinking about self-hosting my personal photos on my linux server. After the recent backdoor was detected I'm more hesitant to do so especially because i'm no security expert and don't have the time and knowledge to audit my server. All I've done so far is disabling password logins and changing the ssh port. I'm wondering if there are more backdoors and if new ones are made I can't respond in time. Appreciate your thoughts on this for an ordinary user.
You're viewing a single thread.
I do IT security for a living. It is quite complicated but not unrealistic for you to DIY.
Do a risk assessment first off - how important is your data to you and a hostile someone else? Outputs from the risk assessment might be fixing up backups first. Think about which data might be attractive to someone else and what you do not want to lose. Your photos are probably irreplaceable and your password spreadsheet should probably be a Keepass database. This is personal stuff, work out what is important.
After you've thought about what is important, then you start to look at technologies.
Decide how you need to access your data, when off site. I'll give you a clue: VPN always until you feel proficient to expose your services directly on the internet. IPSEC or OpenVPN or whatevs.
After sorting all that out, why not look into monitoring?
Fun fact, you can use let's encrypt certs on a internal environment. All you need is a domain.
Just be aware that its an information leakage (all your internal DNS names will be public)
Not if you setup a internal dns
How would that prevent this? To avoid cert errors, you must give the DNS name to let's encrypt. And let's encrypt will add it to their public CT log.
Sorry I though you were referring to IP leakage. Apologizes
...which shouldn't be an issue in any way. For extra obscurity (and convenience) you can use wildcard certs, too.
Are wildcard certs supported by LE yet?
Have been for a long time. You just have to use the DNS validation. But you should do that (and it's easy) if you want to manage "internal" domains anyway.
Oh, yeah, idk. Giving API access to a system to modify DNS is too risky. Or is there some provider you recommend with a granular API that only gives the keys permission to modify TXT and .well-known (eg so it can't change SPF TXT records or, of course, any A records, etc)
What you can (and absolutely should) do is DNS delegation. On your main domain you delegate the
_acme-challenge.subdomains with NS records to your DNS server that will do cert generation (and cert generation only). You probably want to run Bind there (since it has decent and fast remote access for changing records and other existing solutions). You can still split it with separate keys into different zones (I would suggest one key per certificate, and splitting certificates by where/how they will be used).You don't even need to allow remote access beyond the DNS responses if you don't want to, and that server doesn't have anything to do with anything else in your infrastructure.
Ok, so no API at all. Its the internal DNS server itself that runs certbot and makes the changes locally?
Yes, that's one option. Then you only have to distribute the certificates and keys.
Or you allow remote access to that DNS server (Bind has a secure protocol for this), do the challenge requests and cert generation on some other machine. Depends on what is more convenient for you (the latter is better if you have lots of machines/certs).
Worst case if someone compromises that DNS server they can only generate certificates but not change your actual valuable records because these are not delegated there.
I do use it quite a lot. The pfSense package for ACME can run scripts, which might use scp. Modern Windows boxes can run OpenSSH daemons and obviously, all Unix boxes can too. They all have systems like Task Scheduler or cron to pick up the certs and deploy them.