avery/www
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
www/content/2023-09-14-security-infrastructure.md

3.4 KiB
Raw Blame History

+++ title = "Security & Infrastructure" description = "An overview of all the infrastructure and services I host, and the security mindset behind it." date = 2023-09-14 [taxonomies] tags=["selfhosting", "nix", "privacy", "security", "networks"] +++

Security & Infrastructure

Everything on this domain is self-hosted, from DNS to email and all web services. I currently manage four servers:

  • amsterdam and dublin: VMs running on a physical server I own and control the physical security of.
  • berlin: A Vultr VPS.
  • copenhagen: A Linode VPS.

amsterdam acts as the primary nameserver, controlling DNSSEC signing and is thus the root of trust for the domain. It also runs the primary mail server and most web services.

dublin acts as a secondary nameserver and (soon) a backup email queue and backup web server for this static site.

Finally, berlin and copenhagen act as routers for amsterdam and dublin respectively. Each has secondary static IPv4 and IPv6 addresses that are routed over a tunnel to bypass NAT and hosting restrictions on my physical server. Additionally, these VPSs also act as secondary nameservers in case my home network is down.

The goal with all of this is to have some basic redundancy, while keeping sensitive keys and all personal data safely on my physical server.

DNSSEC

amsterdam holds a combined signing key for the zone. Dynamic updates are allowed using TSIG keys on amsterdam and dublin to allow ACME DNS-01 challenges for issuing TLS certificates.

TLS/HTTPS

dublin and amsterdam hold a Let's Encrypt wildcard TLS certificate for the domain, which is used to protect web services. The DNS zone contains a CAA record specifying that only Let's Encrypt may issue certificates for the domain, and only using ACME DNS-01 challenges. All TLS-capable services have TLSA records associated with them for DANE-EE support. Finally, all web services use HTTPS records and HSTS preload headers to advertise support for HTTPS.

Email

amsterdam holds DKIM keys for the domain, which is published in DNS alongside SPF and DMARC records together protect against spoofing the domain. MTA-STS and DANE-EE are used to advertise TLS support for incoming mail. Outgoing mail requires that the receiving server support TLS.

WireGuard

All servers hold WireGuard keys for their end of the tunnels. The tunnel being encrypted and authenticated isn't actually important for my purposes. This could just as easily use another tunneling protocol like GRE, but I find WireGuard trivial to setup even if it adds some keys to manage.