73 lines
3.4 KiB
Markdown
73 lines
3.4 KiB
Markdown
|
+++
|
||
|
|
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][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
|
||
|
|
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][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.
|
||
|
|
|
||
|
|
## 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.
|
||
|
|
|
||
|
|
## Email
|
||
|
|
`amsterdam` holds [DKIM][8] keys for the domain, which is published in DNS
|
||
|
|
alongside [SPF][9] and [DMARC][10] records together protect against spoofing
|
||
|
|
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
|
||
|
|
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.
|
||
|
|
|
||
|
|
[0]: https://git.averywinters.org/avery/home
|
||
|
|
[1]: https://en.wikipedia.org/wiki/TSIG
|
||
|
|
[2]: https://letsencrypt.org/docs/challenge-types/#dns-01-challenge
|
||
|
|
[3]: https://letsencrypt.org
|
||
|
|
[4]: https://letsencrypt.org/docs/caa
|
||
|
|
[5]: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities
|
||
|
|
[6]: https://developer.mozilla.org/en-US/docs/Glossary/https_rr
|
||
|
|
[7]: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
|
||
|
|
[8]: https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail
|
||
|
|
[9]: https://en.wikipedia.org/wiki/Sender_Policy_Framework
|
||
|
|
[10]: https://en.wikipedia.org/wiki/DMARC
|
||
|
|
[11]: https://datatracker.ietf.org/doc/html/rfc8461
|
||
|
|
[12]: https://en.wikipedia.org/wiki/Generic_Routing_Encapsulation
|
||
|
|
[13]: https://datatracker.ietf.org/doc/html/rfc6781
|
||
|
|
[14]: https://www.wireguard.com
|