+++
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" ]
[extra]
show_only_description = true
+++

**Note: This post is out of date, but I am leaving it here for its
historical value.**

Everything on this domain is [self-hosted][0], from DNS to email and all web
services. I currently manage two servers:
- `amsterdam`: A VM running on a physical server I own and control
the physical security of.
- `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.

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 a [TSIG][1] key to allow [ACME DNS-01 challenges][2] for
issuing TLS certificates.

# TLS/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
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
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.

[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