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

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

@ -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.
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.