Das ganze Internet im privaten Netzwerk – Teil 1

Alles im LAN: DNS, lokale Domain Namen, Zertifizierungsstelle, TLS/SSL-Zertifikate, Subnet, Routing, IT-Sicherheit, Cyber Security – How To

Docker, Portainer, Nginx Proxy Manager sowie Domain Routing, Webserver, Firewall, Intrusion Detection, Debian, Ubuntu, Linux, Proxmox, XCP-ng, SOHO, Home Lab, Cloud

Das ist eher eine Fallstudie, als ein Tutorial, wie man bestimmte Dienste aus dem öffentlichen Internet auch im internen LAN anwenden kann. Ein internes LAN kann zu Hause sein, im Homeoffice, in kleinen Büros oder in Unternehmen, im SOHO oder im Home Lab. Zum Einsatz kommt ausschließlich Open Source Software. Dabei werden wichtige Sicherheitseinstellungen auch lokal umgesetzt. Das ist möglicherweise etwas übertrieben für ein privates Netzwerk. Macht es aber leicht, diese Konzepte und Konfigurationen in das öffentliche Internet auf Server und Instanzen in der Cloud zu übertragen. Außerdem fördert es das technische Verständnis dafür, wie das Internet und seine Dienste im Kern funktionieren.

Vorüberlegungen

Sind diese alle belegt und ist kein Switch angeschlossen, können weitere Geräte sich nur per WLAN mit dem Router verbinden. Abgesehen davon sind die angeschlossenen Geräte oder Anwendungen nur über eine IP-Adresse zu erreichen. Es fehlt ein flexibel konfigurierbares DNS, wodurch Server oder Anwendungen über einen eigenen Domain Namen aufgerufen werden können.

Im LAN kann man ganz einfach Dienste einrichten und über die IP-Adresse und einen Port aufrufen. Andererseits wäre es schön, statt dessen einen Domain-Namen zu benutzen. Ein eigener DNS-Server ist natürlich eine anspruchsvolle Angelegenheit. Jedoch längst nicht so komplex, wie vergleichsweise ein eigener Mailserver, z. B. mit Postfix und Dovecot. Zum Beispiel ist es nicht erforderlich, den lokalen DNS-Server mit dem globalen DNS zu synchronisieren. Sein Aufgabenbereich ist begrenzt auf das lokale Netzwerk.

Mit der Entscheidung für ein DNS im eigenen LAN, stellen sich die folgenden Fragen.

Welche IP-Adressen sind für lokale Netzwerke reserviert?

Die IANA hat eine Reihe von IP-Adressen aus dem öffentlichen Adressraum ausgespart. Infolge dieser Trennung können private IP-Adressen in lokalen Netzwerken beliebig oft bzw. in beliebigen Netzwerken genutzt werden.

Netzadressbereiche mit privaten Adressen:

• 10.0.0.0 bis 10.255.255.255
• 172.16.0.0 bis 172.31.255.255
• 192.168.0.0 bis 192.168.255.255

Übrigens, es handelt sich dabei um IPv4-Adressen. Moderne Netzwerkkomponenten verwenden auch IPv6-Adressen. Daher könnte man ein Netzwerk mit dieser Art von IP-Adressen konstruieren.

Welche Top-Level Domain Namen kann man in einem internen, privaten Netz nutzten?

Es ist sinnvoll, die von der Internet Engineering Task Force (IETF) reservierten Top-Level Domain (TLD) zu nutzen (siehe RFC6762, Appendix G).

• intranet
• internal
• private
• corp
• home
• lan

Die wichtigsten Vorteile sind: diese Domain Namen sind absolut kostenlos, sie erfordern wenig Verwaltung, und es entstehen keine Konflikte mit dem öffentlichen DNS.

Wie kommt man an gültige SSL-Zertifikate für lokale Domänen?

Sichere Verbindungen mit Domain-Zertifikaten im privaten Netz? Ist im LAN nicht alles sicher? Naja, für Entwickler bestehen diese Anforderungen. Weniger wegen der Sicherheit, aber für die Entwicklung von Anwendungen und Lösungen. Inzwischen gibt es aber auch Programme, wie z.B. Nextcloud, die Warnmeldungen (in Logdateien) generieren, wenn Zugriffe über unsichere Verbindungen erfolgen. Manche Anwendungen, wie z. B. vaultwarden, das Selbst-Hosting Paket des Passwort Managers Bitwarden, verweigern die Installation auf einem Host ohne ein gültiges Domain-Zertifikat.

Ungeachtet dessen besteht innerhalb eines privaten Netzwerkes eine besondere Problematik. Denn öffentliche Zertifizierungsstellen beglaubigen die Echtheit eines Dienstes mit einem Zertifikat nur dann, wenn dieser für die Öffentlichkeit zugänglich ist. Im Gegensatz dazu ist ein Dienst im LAN naturgemäß nicht öffentlich.

Also, woher sollen die Zertifikate kommen?

OpenSSL bietet die Möglichkeit, eine eigene Zertifikats-Autorität (CA) zu erstellen. Allerdings akzeptieren die neuesten Browser von dieser (eigenen) Autorität ausgestellte Zertifikate nicht (mehr). Zumindest werden sie als selbst-signiert eingestuft. Lästige Warnhinweise erscheinen. Das Symbol für eine sichere Verbindung neben der Adresszeile des Browsers wird niemals grün dargestellt.

Eine attraktive Methode sind die kostenlosen Zertifikate von Let’s Encrypt. Etwas verkürzt ausgedrückt, benötigen die Zertifikate von Let’s Encrypt einen öffentlichen Domain-Namen, dem eine öffentliche IP-Adresse zugewiesen ist. Folglich funktioniert es mit IP-Adressen und Domains im privaten LAN nicht. Alternativ könnte man die öffentliche IP-Adresse des Routers zum Internet verwenden. Allerdings ändert sich diese IP-Adresse bei den meisten Internet Service Providern in regelmäßigen Abständen. Weiterer Nachteil ist, dass am Router bestimmte Ports geöffnet sein müssen, um Anfragen von außen an interne Maschinen weiterzuleiten. Ab diesem Moment sind weitere, sicherheitsrelevante Aspekte zu berücksichtigen.
Auch dafür gibt es Lösungen. Aber in dem Fall wird der Datenverkehr aus dem lokalen Netz heraus und dann über die externe Domain wieder hinein geroutet. Allerdings soll das in dem folgenden Beispiel vermieden werden.

Wie alles zusammenhängt

Im folgenden Beispiel eines physischen Netzwerks basiert die Konstruktion auf den dargestellten Vorüberlegungen. Das LAN besteht aus drei Subnetzen. Es wird ein eigenes lokales DNS eingesetzt. Mit einer lokalen Zertifizierungsstelle ist es möglich, gültige und akzeptierte Zertifikate für unterschiedliche lokale Dienste zu erstellen. Es ist nicht notwendig, Ports am Router zu öffnen. Und im Ergebnis kann der Nginx Proxy Manager lokale Subdomains managen und Zertifikate verwalten.

• 

Kurze Details zu LAN-1

Router-1 ist das Gateway zum Internet. Er spannt das erste Netzwerk, LAN-1, auf. Alle Geräte, die mit diesem Router verbunden werden, erhalten eine IP-Adresse vom eingebauten DHCP-Server. Bei diesem Beispiel sind es die Adressen aus dem Bereich von 192.168.1.0 bis 192.168.1.254. Der Router selbst hat in LAN-1 per Konfiguration die Adresse 192.168.1.1. Außerdem hat er auch eine externe, öffentliche IP-Adresse vom ISP erhalten. Je nach Internetanbieter kann das eine feste Adresse sein. Doch häufig wird die Verbindung in der Nacht kurzzeitig unterbrochen. Dadurch wechselt die externe IP des Routers regelmäßig.

In LAN-1, bzw. an Router-1, wird Router-2 angeschlossen. Auf dem zweiten Router müssen die Standardeinstellungen deaktiviert sein, auch der DHCP-Server. In einem Netzwerk sollte es nur einen DHCP-Server geben. In der System-Konfiguration von Router-2 wird 192.168.1.250 als feste WAN-Adresse eingetragen. Durch zusätzliche Einstellungen in Router-1 erhält Router-2 immer exakt diese Adresse vom DHCP-Server in LAN-1.

Router-2 bekommt in LAN-2 die IP-Adresse 192.168.24.1. Um das zweite Netzwerk aufzuspannen, wird in der LAN-Konfiguration von Router-2 ein neuer Adressbereich angegeben.

Kurzinfo zu LAN-2

LAN-2 soll die Netzwerk-Adresse 192.168.24.0 mit einer Subnetzmaske 255.255.248.0 erhalten. In CIDR-Schreibweise 192.168.24.0/21. Diese Festlegung ist sehr großzügig gewählt. Die Anzahl der IP-Adressen reicht für 2.046 Geräte.

Das ist kurios, nicht wahr? Je nach Blickrichtung, von der inneren oder von der äußeren Seite betrachtet, ist der Router über zwei unterschiedliche IP-Adressen zu erreichen. Auf der einen Seite ist der Router ein weiteres Gerät eines Netzes, und zur anderen Seite spannt er ein neues Netzwerk auf. Dort allerdings mit anderen Netzwerkadressen. Folgerichtig ist ein Router das Verbindungsstück, um mindestens zwei Netzwerke zu verbinden.

Im Grunde genommen ist Router-2 das Gateway von LAN-2 zu LAN-1. Wegen seiner besonderen Konfiguration aber ist Router-2 nicht in der Lage, die theoretisch 2046 verfügbaren Adressen des Netzwerkes an unterschiedliche Geräte zu vergeben. Zum Beispiel ist der integrierte DHCP-Server des Routers deaktiviert. Vor allem stellt sich die Frage, wer verwaltet dieses zweite und anschließend das dritte Teilnetz?

Diese Aufgabe übernimmt in dem Beispiel ein Server mit einem Debian-Betriebssytem. In dem Server sind zwei Netzwerkkarten eingebaut. Die erste Karte ist das Interface zu LAN-2. Es ist direkt verbunden mit Router-2.

Kurzinfo zu LAN-3

Der zweite Netzwerkadapter bildet das Interface für das dritte Subnetz. Durch die Konfiguration des zweiten Interfaces erhält LAN-3 die Netzwerk-Adresse 192.168.32.0 mit einer Subnetzmaske 255.255.255.0. In CIDR-Schreibweise 192.168.32.0/24. Von dieser Netzwerkkarte besteht eine Kabelverbindung zu einem Switch. Und daran sind alle weiteren Geräte angeschlossen.

Zusammenfassung der vorhandenen Netzwerkstruktur

Für alle drei Netzabschnitte ist Router-1 der Durchgang ins Internet. Alle Geräte in LAN-1 erhalten von Router-1 per DHCP eine IP-Adresse. Die Geräte können nur über ihre jeweilige IP-Adresse miteinander kommunizieren. Alle Anfragen, für die es innerhalb dieses LANs kein Zielgerät gibt, werden hinaus ins Internet geleitet oder verpuffen.

Alle Geräte innerhalb des LAN-1 Netzwerkes können Geräte in LAN-2 nicht erkennen. Alles, was die Geräte zu sehen bekommen, ist die IP-Adresse von Router-2, aber nichts von dem, was dahinter passiert. Ohne zusätzliche Einstellungen auf Router-2 kommen IP-Pakete aus LAN-1 dort nicht hindurch. Für Geräte in LAN-2 in Bezug auf das Netzwerk LAN-3 ist es genau das gleiche.

Es gilt aber nicht in umgekehrter Richtung. Geräte aus LAN-2 erreichen Geräte in LAN-1 oder können hinaus ins Internet. Und Geräte aus LAN-3 können sowohl auf Geräte in LAN-2, oder LAN-1 zugreifen, oder durch das Gateway ins Internet gelangen.

Hier nicht eingesetzt, aber zu erwähnen ist das folgende. Zusätzlich zur physischen Trennung von Teilnetzen lassen sich logische Netzsegmente in einem virtuellen LAN (VLAN) konstruieren. Das besondere daran ist, dass sich ein VLAN über mehrere physisch getrennte Teilnetze erstrecken kann.

Die Rolle vom Debian-Server

Von außen sind Geräte im Netzwerk nicht zu erreichen. Eine einfache Firewall auf dem Router-1 blockt alle Anfragen. Alle Ports sind geschlossen. Allerdings werden von den Geräten innerhalb des LANs viele Dienste im Internet aufgerufen. So gelangen Daten von außen in das Netzwerk.
In dem Beispielnetzwerk treffen die Daten ab LAN-2 auf den Debian-Server. Dort filtert die Firewall nftables den ein- und ausgehenden Datenverkehr. Das Intrusion Detection System suricata übernimmt die Analyse der IP-Pakete.

Besonders wichtig ist eine fehlerfreie Netzwerkkonfiguration von allen Komponenten. Zum Beispiel für einen möglichst schnellen Transport von IP-Paketen. Das betrifft auch die beiden Netzwerkkarten im Server. Die Einstellungen der ersten Karte muss mit den Angaben in Router-2 übereinstimmen. Gateway für das LAN-2 ist die interne IP-Adresse von Router-2.

Bei der Konfiguration der zweiten Netzwerkkarte wurde ein einfaches privates Netzwerk mit einer /24 Subnetzmaske eingestellt. Gateway für LAN-3 ist das gleiche wie für LAN-2. Damit IP-Pakete zwischen den Netzwerkkarten weitergeleitet werden können, ist IP-Forwarding im Kernel aktiviert. Das heißt, der Debian-Server agiert auch als Router.

Wie bereits erwähnt, sind die Subnetze physisch voneinander getrennt. Von LAN-3 sollen Zugriffe möglich sein auf Geräte in LAN-2 und LAN-1. Deshalb trägt man statische Routen manuell in den Netzwerkeinstellungen ein. Aufschluss gibt die Routingtabelle des Servers.

DHCP-Server

In LAN-2 und LAN-3 erhalten die meisten Geräte eine statische IP-Adresse. Jede dieser Adressen ist mit einem dedizierten Namen im DNS verknüpft. Im Gegensatz dazu sind mobile Geräte und ein Teil der virtuellen Maschinen nur kurzfristig aktiv. In beiden Fällen ist kein dedizierter Name erforderlich, aber eine dynamische IP-Adresse. Deshalb wird auf dem Debian-System ein DHCP-Server eingerichtet. Mobile Geräte erhalten die Möglichkeit, sich über Wifi-Access-Points mit dem Netzwerk zu verbinden. In der Konfiguration vom ISC DHCP-Server kann ein Netzwerkadmininistrator jene IP-Adressbereiche reservieren, die bei Bedarf dynamisch zugewiesen werden dürfen. Geräte erhalten auf diese Weise nicht nur temporär eine IP-Adresse. Im DNS erscheint automatisch ein vorübergehender Hostname. Daher müssen DHCP und DNS gut aufeinander abgestimmt sein, was durch entsprechende Konfiguration gelingt.

• 

DNS-Server – das eigentliche Herzstück des Netzwerks

In dem Beispiel läuft ISC bind9 auf dem Debian-Server. Ein dediziertes DNS in einem (lokalen) Netzwerk ist nicht unbedingt erforderlich. Aber (auch dort) sehr komfortabel. Die Administration erfordert nicht einmal zu viel Aufwand. Der DNS-Server muss nur einen einzigen Domain Namen verwalten. Eventuell auch ein paar weitere. Nur selten kommen neue Geräte hinzu. Eine Synchronisation mit öffentlichen DNS-Servern ist nicht nötig – und schon gar nicht gewollt! Der lokale DNS-Server leitet Anfragen, die er nicht beantworten kann, über das Gateway weiter, zum öffentlichen DNS.

In der DNS-Konfiguration kann man einen frei erfundenen Namen als privaten Domain Namen einsetzen. Folglich ist ein Gerät oder ein Service dann anstatt mit seiner IP-Adresse auch über diese Domäne zu erreichen. Jedem Gerätenamen ist eine IP-Adresse zugeordnet – und umgekehrt (Reverse DNS). In dem Beispiel verwaltet der Debian-Server die DNS-Zonen für LAN-2 und LAN-3.

Noch schöner wäre es, SSL-Zertifikate mit der eigenen, lokalen Domäne nutzen zu können. Bisher war es möglich, mit OpenSSL selbst-signierte Zertifikate auszustellen, die der Webbrowser akzeptiert. Aber damit funktioniert es leider nicht mehr. Aktuelle Webbrowser akzeptieren diese Art der selbst-signierten Zertifikate offensichtlich nicht. Auch die Zertifizierungsstelle ist nicht mehr vertrauenswürdig eingestuft. Eine Lösung bietet sich mit Easy-RSA.

Easy-RSA, die eigene Zertifizierungsstelle

Easy-RSA ist ein kryptologisches System. Damit lässt sich eine Public-Key-Infrastruktur aufbauen. Die Zertifizierungsstelle wird als eine gültige anerkannt. Browser vertrauen den Zertifikaten, obwohl sie selbst signiert sind.

Es empfiehlt sich, Easy-RSA auf einer virtuellen Maschine zu installieren und dieses System nur zu starten, um neue Zertifikate auszustellen.

Auf einem Computer innerhalb von LAN-3 läuft bereits VirtualBox. Der Hypervisor (Typ-2) in diesem Beispiel ist der geeignete Speicherplatz für die neue virtuelle Maschine. Easy-RSA ist in den Debian-Repositorien als Paket vorhanden. Daher ist Debian als Betriebssystem in der virtuellen Maschine gut geeignet. Nach einer kurzen Einrichtung des Systems steht Easy-RSA bereit.

Verwendung von Easy-RSA

Der erste Schritt besteht darin, die Zertifizierungsstelle Certificate Authority (CA) einzurichten. Mit OpenSSL lassen sich anschließend Zertifikatsanfragen (CR) generieren. Im dritten Schritt werden die Anfragen von der CA beglaubigt und signiert. Am Ende kommen gültige Zertifikate heraus, die man in die SSL-Konfiguration von einem Webserver integrieren kann. Der Prozess lässt sich beschleunigen, wenn man anstatt eines separaten Zertifikats für jeden Server nur ein einzelnes Wildcard Zertifikat generiert. Innerhalb des LANs reicht ein solches Zertifikat vollkommen aus. Ein letztes Hindernis besteht allerdings noch. Dem Webbrowser ist die Zertifizierungsstelle bislang völlig unbekannt. Standardmäßig akzeptiert der Browser die Zertifikate von dieser Zertifizierungsstelle nicht. Die Lösung besteht darin, die Zertifikatsverwaltung des Browsers zu öffnen und die Zertifizierungsstelle zu importieren. Dafür importiert man den öffentlichen Schlüssel der CA.

Zwischenstand

Nun können Anwendungen und Dienste im eigenen lokalen Netzwerk über eine sichere Verbindung aufgerufen werden. Im Vergleich zu Let’s Encrypt ist diese Methode mit Easy-RSA natürlich deutlich aufwendiger. Es gibt aber auch eine Reihe von Vorteilen. Die CA ist im im eigenen Hause. Es ist nicht erforderlich, Ports am Gateway Router zu öffnen. Der diesbezügliche Traffic verbleibt im lokalen Netz. Nichts muss nach draußen gehen. Nichts muss von draußen wieder rein.

• 

Ein Beispiel für eine konkrete Anwendung

Auf einer Workstation mit einem Ubuntu Server Betriebssystem wurde ein Interface mit mehreren IP-Adressen eingerichtet. Das bedeutet, die Maschine ist über mehrere dedizierte IP-Adressen erreichbar. Für jede Adresse verwaltet ein Apache Webserver diverse virtuelle Server. MariaDB wird als MySQL-Server eingesetzt. Dieses Set-Up entspricht einer typischen Test- und Entwicklungsumgebung für viele unterschiedliche Web Projekte. Im Grunde ist die Workstation in diesem lokalen Netzwerk gleichzeitig auch ein Produktivsystem.

Anpassung von DNS und Konfigurationen

In den Zone Files auf dem DNS-Server werden für alle IP-Adressen auf der Workstation die gewünschten Subdomains eingetragen und als A-Record oder CNAME registriert. Auf der Workstation sind weitere Konfigurationen vorhanden, wo zu der IP-Adresse auch der DNS-Name des Dienstes ergänzt werden sollte, zum Beispiel /etc/hosts. Auch in der Apache Konfiguration muss der ServerName für den namensbasierten virtuellen Host eingesetzt werden. Danach lässt sich das Webprojekt nicht nur über die IP-Adresse erreichen. Es ist auch unter der vollständigen Subdomain erreichbar, zum Beispiel

http://testserver24.its-my.lan

Das entspricht einem voll qualifizierten Domain-Namen (FQDN).
Abschließend ist noch eine Anpassung der Apache SSL-Konfiguration erforderlich. Dabei kommen die von Easy-RSA erzeugten Sicherheitszertifikate zum Einsatz. Nach einem Neustart des Apache Webservers lassen sich Webprojekte über eine sichere Verbindung erreichen. Die URL bzw. die Adresse beginnt anstatt mit http nun mit https, zum Beispiel:

https://testserver24.its-my.lan

---

Mit einer steigenden Anzahl von Geräten, Maschinen, Diensten, Anwendungen und Servern nimmt auch die Zahl der Einträge im lokalen DNS-Server zu. In diesem Netzwerk laufen beispielsweise Server mit TrueNAS, Freenas, Nextcloud, Owncloud, Ubuntu, Docker und Kubernetes. Dazu kommen dedizierte Maschinen mit Proxmox oder XCP-ng. Und darauf laufen noch viel mehr virtualisierte Instanzen.

Alle Clients in diesem Netzwerk können auf diese Weise gemeinsam genutzte Programme verwenden, ERP, CMS, Kalender, File-Sharing-Dienste, Back-Up Systeme usw.
Auch Monitoring spielt eine Rolle. Dies erfolgt unter anderem mit Prometheus sowie mit Netdata.

Zusammenfassung

Auch in einem privaten Netzwerk geht mehr. Nicht alle Geräte müssen zwangsläufig in nur einem Netzsegment betrieben werden. Mit dem Einsatz von Internettechnologien sowie Open Source Software, lassen sich leicht komplexe Vernetzungen realisieren. Dabei kann es gelingen, die Kontrolle über Vorgänge und Strukturen zu behalten und zu verbessern. Durch den Zuwachs an Erfahrungen erweitert sich das technische Verständnis grundlegend. Das führt zu ansteigendem Wissen über sicherheitsrelevante Aspekte. Einmal gelernt und dann genauso bei öffentlichen Projekten angewendet, wird es das Internet sicherer machen.

Abschließende Hinweise

Das alles muss, soll oder kann nicht nur auf diese Weise nachgebaut werden. Es kann so oder mit völlig anderen Programmen realisiert werden. Für alle genannten Programmen und Methoden gibt es viele Alternativen.

---

Das war bislang eine grobe Übersicht mit vielen sehr allgemeinen Hinweisen. Im zweiten Teil folgt ein detailliertes Tutorial zur Nutzung von Docker, Portainer und Nginx Proxy Manager. Themenschwerpunkt ist die Absicherung mit Zertifikaten und das Schließen von offenen Ports.

---

Quellenangaben

Titelfoto (barbeitet) stammt von Solen Feyissa auf Unsplash