avery/www
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Update infrastructure post

Browse source
This commit is contained in:
Avery Winters 2023-10-04 12:23:29 -05:00
parent 1441b50cb3
commit f8651c959f
Signed by: avery
SSH key fingerprint: SHA256:eesvLB5MMqHLZrAMFt6kEhqJWnASMLcET6Sgmw0FqZI
1 changed files with 26 additions and 23 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

49
content/2023-09-14-security-infrastructure.md
View file

@ -1,47 +1,50 @@
+++ +++
title = "Security & Infrastructure" 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 date = 2023-09-14
updated = 2023-10-04
[taxonomies] [taxonomies]
tags=["selfhosting", "nix", "privacy", "security", "networks"] tags = [ "selfhosting", "nix", "privacy", "security", "networks" ]
+++ +++
# Security & Infrastructure # 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 Everything on this domain is [self-hosted][0], from DNS to email and all web
services. I currently manage four servers: services. I currently manage two servers:
- `amsterdam` and `dublin`: VMs running on a physical server I own and control - `amsterdam`: A VM running on a physical server I own and control
the physical security of. the physical security of.
- `berlin`: A Vultr VPS. - `edinburgh`: A Contabo VPS.
- `copenhagen`: A Linode VPS.
`amsterdam` acts as the primary nameserver, controlling DNSSEC signing and is `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 thus the root of trust for the domain. It also runs the primary mail server and
most web services. most web services.
`dublin` acts as a secondary nameserver and (soon) a backup email queue and Finally, `edinburgh` acts as a router for `amsterdam`. It has secondary static
backup web server for this static site. 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
Finally, `berlin` and `copenhagen` act as routers for `amsterdam` and `dublin` nameserver in case my home network is down.
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 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. sensitive keys and all personal data safely on my physical server.
## DNSSEC ## DNSSEC
`amsterdam` holds a [combined signing key][13] for the zone. Dynamic updates `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. are allowed using a [TSIG][1] key to allow [ACME DNS-01 challenges][2] for
issuing TLS certificates.
## TLS/HTTPS ## TLS/HTTPS
`dublin` and `amsterdam` hold a [Let's Encrypt][3] wildcard TLS certificate `amsterdam` holds a [Let's Encrypt][3] wildcard TLS certificate for the domain,
for the domain, which is used to protect web services. The DNS zone contains a which is used to protect web services. The DNS zone contains a [CAA][4] record
[CAA][4] record specifying that only Let's Encrypt may issue certificates for specifying that only Let's Encrypt may issue certificates for the domain, and
the domain, and only using ACME DNS-01 challenges. All TLS-capable services have TLSA records associated with them for [DANE-EE][5] support. only using ACME DNS-01 challenges. All TLS-capable services have TLSA records
Finally, all web services use [HTTPS][6] records and [HSTS preload][7] headers associated with them for [DANE-EE][5] support. Finally, all web services use
to advertise support for HTTPS. [HTTPS][6] records and [HSTS preload][7] headers to advertise support for HTTPS.
## Email ## Email
`amsterdam` holds [DKIM][8] keys for the domain, which is published in DNS `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. incoming mail. Outgoing mail requires that the receiving server support TLS.
## WireGuard ## 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 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 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. WireGuard trivial to setup even if it adds some keys to manage.