Vor einiger Zeit kam ich mit der - doch recht zeitintensiven - Pflege meines Mailserver-Setups nicht mehr nach und
so entschloss ich mich diese Bürde in professionelle Hände abzugeben.
Natürlich vertraue ich mein - mittlerweile - recht umfangreiches E-Mail Archiv nicht jedem dahergelaufenen Provider an.
Nein! Selbstverständlich muss dieser höchsten Ansprüchen genügen.
Was lag also näher, als diese Aufgabe an
Posteo abzutreten - einem
deutschen E-Mailanbieter mit Sitz in Berlin und zudem Arbeitgeber eines Freundes. Hauptaugenmerk dort liegt auf
Sicherheit, Datenschutz und Nachhaltigkeit. Der Dienst ist zwar nicht kostenlos, aber günstig und zudem werbefrei.
Selbst das Mailserver-Setup, natürlich bestehend aus Open Source Software, entspricht in etwa dem vormals von mir verwendeten.
Wunderbar, also nichts wie rüber migriert!
Leider gibt es einen kleinen Haken, Posteo bietet - aus
gutem - Grund
keine Unterstützung für kundenspezifischen Domains an. Wie das allerdings doch möglich ist, erkläre ich nachfolgend..
Backups sind wichtig. Diese Tatsache ist sicher niemandem neu, aber die Anforderungen sind vielfältig: Sie sollten regelmäßig - am besten automatisiert - erzeugt und verifiziert werden, auf unterschiedliche Speichermedien, mit besonderen Hardware-Anforderungen. Backup-Systeme sollten nicht permanent mit dem gesicherten Computer verbunden sein - dies schließt natürlich auch via Netzwerk zugängliche NAS/SAN-Systeme ein - und im Falle von “Offlinemedien”, nach der Sicherung, an unterschiedlichen Orten gelagert werden. Dort dann unter idealen klimatischen Bedingungen, um einer vorzeitigen Alterung und bit rot vorzubeugen, am besten bei regelmäßiger Stromzufuhr.
MinIO ist ein offenes,
AWS/S3 API kompatibles
Object-Storage System, welches hervorragend dazu geeignet ist, in Kubernetes betrieben zu werden.
Die Installation einer produktionsreifen Konfiguration gestaltet sich äußerst einfach.
Die einzigen beiden Voraussetzungen sind der Zugriff auf einen Kubernetes Cluster und
HELM (in Version 3).
Sollte der Cluster noch nicht bereit stehen, kannst du natürlich Minikube verwenden oder dir einmal
k3s ansehen, damit kann
man in wenigen Sekunden einen schlüsselfertigen Single-Node Kubernetes Cluster aufsetzen. Den Kubernetes Paketmanager HELM werden wir für die Installation von MinIO verwenden.
Egal mit welcher Cryptowährung man hantiert, es empfiehlt sich immer eine eigene Kopie der
Blockchain
zu besitzen, nicht nur um - im Falle transparenter Transaktionen - Einsicht zu erhalten, sondern primär um sich vor potentiellen Angriffen zu schützen, sich unabhängig von
remote nodes zu machen und natürlich um das Netzwerk zu unterstützen. Nur so kann man den großen Vorteil einer Blockchain - die Dezentralität - überhaupt erst sinnvoll nutzen.
Insbesondere bei privacy coins, wie Monero - aber natürlich auch bei allen anderen Cryptowährungen - lohnt es sich, seinen Node via TOR (oder einem anderen Anonymisierungsnetzwerks
wie
I2P) als HiddenService bereitzustellen und sich auf diese Weise von seinem lokalen PC aus zu verbinden.
Diesen Artikel beginne ich direkt einmal mit einer Warnung:
Selbstverständlich bietet port-knocking keinen echten Schutz vor einem Angriff. Hiermit verschleierte Dienste sollten immer noch durch übliche weitere Faktoren wie z.B. Authentifikation und rate-limiting geschützt werden!
Aber nachdem ich mich ja unter anderem hier bereits als großen Freund der port-knocking Methode bekannt habe, folgt nun eine kleine Anleitung, wie man mit Hilfe von sticky-sessions unter HA-Proxy, Zugang zu versteckten backends freigeben kann.
Nachdem ich vor einer ganzen Weile erstmalig, auf einem von mir administrierten Server, mit dem Monero Projekt und der dazu gehörigen digitalen Währung XMR in Berührung kam, war ich hellauf begeistert von der Funktionsweise und den Prinzipien dieses gemeinnützigen Projekts.
Im Gegensatz zu vielen anderen digitalen Währungen liegt hier die Priorität auf starker Anonymität und Privatsphäre. Transaktionen sind, nur wenn ausdrücklich erwünscht, rückverfolgbar. Ein weiteres interessantes Detail ist die Verwendung des zugrundeliegenden Proof of Work Algorithmus RandomX.
In einem recht restriktivem Netzwerk benötigte ich eine Möglichkeit, um auf diverse interne Dienste über das Internet zugreifen zu können.
Diesen Anlass nahm ich als Gelegenheit um etwas mit
TOR und
Onioncat herumzuspielen. Mein primäres Ziel war es, sicheren Zugriff auf den internen
Mailserver zu gewähren, sodass man E-Mails abrufen kann ohne direkt mit dem LAN verbunden zu sein.
TOR dient hier lediglich als Transportebene, so ist keine Portweiterleitung im Router notwendig. Onioncat wird als
hidden-service bereitgestellt und erzeugt ein
Overlay-Netzwerk, welches IPv6 als Protokoll auf Layer 3 verwendet. Die Dienste sind dann später über eine statische IPv6 Adresse via
TOR/Onioncat erreichbar.
