Übungen für die Selbstlernwoche

Zusatz:

Versucht die SD-Karte vom PC aus via chroot zu bedienen.

→ Ein PC mit x86er Instruktionssatz kann die ARM-Applikationen auf der SD-Karte nicht ausführen

Das Debian-Paket qemu-user-static enthält eine reihe von Emulatoren mit denen Architekturfremde Binaries ausgeführt werden können. Der Ausführungsmechanismus ähnelt dem eines Python-Scriptes: Die Programmdatei wird normal aufgerufen und das System wählt automatisch den passenden Interpreter.

Kopiert den ARM-Emulator aus der quemu-Suite auf die SD-Karte. Ein chroot sollte nun normal möglich sein.

Voraussetzungen:

Es braucht drei Virtuelle Rechner in zwei Netzwerken

• Erstellt zwei private Switches in Hyper-V: SW-Eins und SW-Zwei

  • Private Switches sind nicht mit dem Host-System verbunden und ermöglichen nur die Kommunikation zwischen den angebundenen VMs

• Erstellt eine VM "Router" mit zwei Netzwerkkarten

  • "Router" ist damit sowohl an "SW-Eins" als auch "SW-Zwei" angebunden
• Erstellt eine VM "Client-Eins" die nur an "SW-Eins" angebunden ist
• Erstellt eine VM "CLient-Zwei" die nur an "SW-Zwei" angebunden ist

→ Beide Client-Rechner haben einen Layer-2-Link zum Router, aber nicht zueinander.

Hinweis: Da die Netzwerke nicht ans Internet angebunden sind, muss die Systeminstallation auf anderem Wege erfolgen. Die Live-DVD eignet sich als System für die Client-Rechner.

IP-Konfiguration

Setzt IP-Adressen auf allen drei Rechnern.

• Nutzt ntürlich zwei verschiedene Netze
• Nutzt das ip-Kommando zum setzen der Adresse

→ Die Clients können den Router pingen. Der Router kann Pings an beide Clients absetzen.

Routing

Der Router soll Pakete zwischen beiden Rechnern vermitteln.

Der Router kennt bereits beide Netze. Hier ist kaum Konfguration erforderlich. Es muss lediglich die Routing-Funktion des Linux-Kernels aktiviert werden.

Auf den Clients braucht keine Routing-Funktion aktiviert werden, sie sollen ja nicht vermitteln. In der Rounting-Tabelle der CLients müssen aber Netze und Gateway eingetragen werden.

Benutzt traceroute oder mtr um zu sehen, wie sich die Route verhält, wenn die IP-Vermittlung auf dem Router aus- und eingeschaltet wird.

DHCP

Richtet dnsmasq auf dem Router ein um DHCP-Adressen an die beiden Netze zu vergeben.

• Achtet darauf, dass die Client-Rechner keine statische Konfiguration benutzen. Die Live-DVD eignet sich als System für die Clients.
• Die Interfaces am Router müssen statisch konfiguriert sein.
• alle Command-Line-Optionen, die in der man-Page von dnsmasq beschrieben sind, sind auch Optionen in /etc/dnsmasq.conf
• Achtet darauf, dass das Routing nach dem Reboot aller Rechner sofort funktioniert.

Hinweis zu Online-Tutorials

SSH unterstützt neben vollwertigen VPNs auch das Weiterleiten einzelner TCP-Ports und das Einrichten eines Socks-Proxys. Beides hat mit dieser Übung nicht zu tun. Viele "VPN"-Tutorials im Internet beziehen sich jedoch fälschlicherweise auf diese Techniken.

VPN-Server ("Client-Zwei")

• SSH installieren
• In /etc/ssh/sshd_config muss die Option "PermitTunnel" aktiviert sein
• In /root/.ssh/authorized_keys muss ein Zugangskey für den Client hinterlegt sein.

VPN-Client ("Client-Eins")

1. Der SSH-Client wird als Root-User gestartet.

   • Der Private-Key für den SSH-Login liegt deshalb entweder unterhalb von /root/.ssh/ oder muss beim Aufruf von ssh mit der Option -i angegeben werden.

2. Testet den SSH-Zugang (von root zu root)

   root@client~# ssh -i private_key root@server

3. Stellt sicher das der SSH-Zugang getestet ist

4. Seriously! Wenn die SSH-Verbindung schon nicht funktioniert, kann der Rest auch nicht funktionieren

5. root@client~# ssh -i private_key -o Tunnel=ethernet -w any root@server

Zwischenergebnis

Auf Server und Client entsteht jeweils ein unkonfiguriertes Netzwerkinterface "tap0". Dieses kann manuell mit einer IP-Adresse versehen werden. Server und client sollen sich dann gegenseitig anpingen können.

Der VPN-Client hat damit noch keinen Zugriff auf das Netzwerk des Servers. Stattdessen ist das TAP-Interface des Servers vollständig von dem Netz auf eth0 entkoppelt.

SSH-Rechte

Die VPN-Clients sollen natürlich keine Root-Shell auf dem Server bekommen. Lest den Absatz "AUTHORIZED_KEYS FILE FORMAT" in der man-Page zu sshd. Konfiguriert den die Key-Einträge am Server so, dass VPN-Clients das TAP-Device einrichten können, aber keine Shell kriegen.

Bridging

Das VPN-Interface tap0 soll auf das Netzwerk von eth0 "gebridged" werden. D.H. beide Interfaces sollen sich so verhalten, als wären sie an einen gemeinsamen Switch angeschlossen. Dies ermöglicht es dem VPN-Client, DHCP-Adressen aus dem Host-Netz des Servers zu beziehen und alle Rechner dort zu erreichen.

1. Installiert bridge-utils auf dem Server
2. Legt mittels brctl ein neues Bridge-Interface br0 an
3. Fügt eth0 der Bridge hinzu
4. Entfernt alle IP-Adressen von eth0 (tut dies nicht via SSH, denn der Rechner ist dann offline)

5. Bezieht DHCP auf br0

   • Baut dann den SSH-Tunnel auf (alle bestehenden Tunnel wurden im Vorherigen schritt unterbrochen)
   • Fügt das tap-Interface der Bridge hinzu
6. → Auf der Client-Maschine: Bezieht DHCP auf tap0

→ Das Bridging von VPN-Interfaces und Netzwerkkarte erlaubt dem Server die VPN-Clients direkt ins Hostnetzwerk einzubringen. Die Reale Netzwerkkarte wird dabei der Bridge unterstellt. Alle IP-Kommunikation des Hosts läuft dann über br0 während eth0 nur noch die zugeordnete Hardware-Schnittstelle ist.

Erinnert euch in diesem Zusammenhang auch an das Verhalten von Hyper-V unter Windows: Beim Anlegen eines "Externen" Hyper-V-Switches geht das Windows-Netzwerk-Interface verloren (wird Hyper-V unterstellt) und der Windows-Host muss selbst mit einem virtuellen Interface weiterarbeiten. Dies entspricht exakt dem Bridging-Verhalten, das wir auch hier beobachten.

UID/GID Mappings

Die Dateien /etc/subuid und /etc/subgid enthalten zusätzliche UIDs/GIDs, die ein unprivilegierter Benutzer annehmen darf. Die IDs liegen idR. im Sechs- bis Siebenstelligen Zahlenbereich, so dass sie sich mit den 2^16 UIDs klassischer Unix-Systeme nicht überschneiden.

Diese Übung muss z.T. wieder mit (echten) Root-Rechten vorbereitet werden. Der Unshare-Kontext selbst soll am Ende aber unprivilegiert laufen.

• Stellt sicher, dass euer Benutzer über eine ausreichende Menge an SubUIDs und -GIDs verfügt.

  • üblich sind 2^16 pro Benutzerkonto. Man kann aber auch mit mehr oder weniger arbeiten.
  • es gibt eine man-Page zu subuid und subgid
  • ggf. muss in Debian das Paket "uidmap" installiert sein

• Erzeugt einen Unshare-Kontext mit ID-Mappings

  • UID 0 aus dem Namespace soll eurer realen User-ID entsprechen (z.B. 1000)
  • die UIDs 1 bis 65535 sollen aus euren persönlichen subuid-Range kommen
  • Gruppen-IDs analog

• chrooted in das vorbereitete Alpine Linux

  • versucht wieder via su zu einem der vormals angelegten Alpine-User zu wechseln

    • legt die Konten und Heimverzeichnisse ggf. neu an (Berechtigungen und so)
  • legt Dateien und Verzeichnisse als unprivilegierte Nutzer an
  • Entfernt Zugriffsberechtigungen für andere User
  • → Der Unshare-User kann außerhalb des Namespace nicht auf Dateien seiner eigenen SubUIDs zugreifen, es handelt sich normal um andere UIDs