From f8651c959fd61035be5a15a3b11bb40bd4441699 Mon Sep 17 00:00:00 2001 From: Avery Winters Date: Wed, 4 Oct 2023 12:23:29 -0500 Subject: [PATCH] Update infrastructure post --- content/2023-09-14-security-infrastructure.md | 49 ++++++++++--------- 1 file changed, 26 insertions(+), 23 deletions(-) diff --git a/content/2023-09-14-security-infrastructure.md b/content/2023-09-14-security-infrastructure.md index c16ccf5..be00f2e 100644 --- a/content/2023-09-14-security-infrastructure.md +++ b/content/2023-09-14-security-infrastructure.md @@ -1,47 +1,50 @@ +++ title = "Security & Infrastructure" -description = "An overview of all the infrastructure and services I host, and the security mindset behind it." +description = """\ +An overview of all the infrastructure and services I host, and the security \ +mindset behind it. \ +""" date = 2023-09-14 +updated = 2023-10-04 [taxonomies] -tags=["selfhosting", "nix", "privacy", "security", "networks"] +tags = [ "selfhosting", "nix", "privacy", "security", "networks" ] +++ # Security & Infrastructure +**Note**: This post was updated to reflect a change in the number of servers +I use to host everything. + Everything on this domain is [self-hosted][0], 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 +services. I currently manage two servers: +- `amsterdam`: A VM running on a physical server I own and control the physical security of. -- `berlin`: A Vultr VPS. -- `copenhagen`: A Linode VPS. +- `edinburgh`: A Contabo 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. +Finally, `edinburgh` acts as a router for `amsterdam`. It has secondary static +IPv4 and IPv6 addresses that are routed over a tunnel to bypass NAT and hosting +restrictions on my physical server. Additionally, this VPS also acts as secondary +nameserver 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][13] for the zone. Dynamic updates -are allowed using [TSIG][1] keys on `amsterdam` and `dublin` to allow [ACME DNS-01 challenges][2] for issuing TLS certificates. +`amsterdam` holds a [combined signing key][13] for the zone. Dynamic updates +are allowed using a [TSIG][1] key to allow [ACME DNS-01 challenges][2] for +issuing TLS certificates. ## TLS/HTTPS -`dublin` and `amsterdam` hold a [Let's Encrypt][3] wildcard TLS certificate -for the domain, which is used to protect web services. The DNS zone contains a -[CAA][4] 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][5] support. -Finally, all web services use [HTTPS][6] records and [HSTS preload][7] headers -to advertise support for HTTPS. +`amsterdam` holds a [Let's Encrypt][3] wildcard TLS certificate for the domain, +which is used to protect web services. The DNS zone contains a [CAA][4] 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][5] support. Finally, all web services use +[HTTPS][6] records and [HSTS preload][7] headers to advertise support for HTTPS. ## Email `amsterdam` holds [DKIM][8] keys for the domain, which is published in DNS @@ -50,7 +53,7 @@ the domain. [MTA-STS][11] 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][14] keys for their end of the tunnels. The tunnel +Both servers hold [WireGuard][14] 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][12], but I find WireGuard trivial to setup even if it adds some keys to manage.