Maximaler Datenschutz: Windows hinter einem Proxy betreiben

Häufig trifft man auf Fragen wie „Wie bekommt man Windows-Systeme datenschutzfreundlich?“. Empfohlen werden dann meistens diverse Software-„Lösungen“ eines Drittanbieters, Blocklisten für Pi-hole o.ä. oder irgendwelche Konfigurationen, die man wie eine Art Checkliste abarbeiten soll, empfohlen.

Dabei hängen all diese „Lösungen“ aus Prinzip der Realität immer etwas hinterher und mit Bordmitteln lässt sich das sowieso nicht vollständig, zuverlässig und dauerhaft abstellen. Problematisch ist dabei auch, dass die Software eines Drittanbieters an einem System immer mehr „verstellen“ kann als man möchte oder Dinge sogar „kaputt gemacht“ werden können. Die Erfahrung hat gezeigt, dass sich nach einem Systemupdate Dinge anders verhalten können oder neue ggf. privatsphärerelevante Sachen dazu gekommen sind. „Klemmt“ es dann mal irgendwo, dauert die Fehlersuche unter Umständen sogar länger als mit einem „08/15-Standard-System“. Betrachtet man diese „Lösungen“ nüchtern, ist das alles nur ein Katz-und-Maus-Spiel. Hat sich beispielsweise eine URL zum Versenden von z.B. Telemetriedaten geändert und fehlt diese neue URL auf einer Blockliste, könnten möglicherweise alle zuvor gesammelten Daten in einem Rutsch übertragen werden.

Wenn das Windows-System einen begrenzten Einsatzzweck hat, dann lässt sich das Problem viel einfacher und vor allem dauerhaft und zuverlässig lösen. In meinem Fall benötige ich die Windows-VM nur ein paar mal im Jahr für die Steuersoftware und weitere (Offline-)Anwendungen. Die notwendigen externen Endpunkte lassen sich an einer Hand abzählen und der Ansatz mit einem vorgeschalteten Proxy ist einfach perfekt. Alle Endpunkte, die nicht explizit erlaubt sind, werden vom Proxy blockiert. Updates werden von mir praktisch nicht benötigt und falls doch, lässt sich das ggf. mit „WSUS Offline Update“ bewerkstelligen.

Für Docker-User

Diejenigen die bereits Docker verwenden, können sich auch mal dieses Projekt auf GitHub ansehen: Windows inside a Docker container. Zusammen mit einem Squid-Proxy-Container sollte sich das Windows-System ebenfalls gut einschränken/kontrollieren können. Das hab ich bisher noch nicht verwendet, da die „KVM-Variante“ bei mir schon länger läuft und es bisher keinen Grund gab daran etwas zu ändern.

Ich nutze hierfür meinen Heimserver, der sowieso 24/7 läuft und sich aber auch hardwareseitig dafür bestens eignet. Der Zugriff auf die Windows-VM kann über RDP, VNC oder direkt über den Virtual Machine Manager erfolgen. Alternativ gingen natürlich auch Tools wie Guacamole von Apache, um die Windows-VM über den Browser zu bedienen - optional mit 2FA (TOTP).

Das sind die verwendenten Geräte und ihre IP-Adressen:

Router*     192.168.178.1
Linux-VM    192.168.178.70
            10.7.0.10
Windows-VM  10.7.0.2

*) Das nächste Gateway ist in der Regel der Router (z.B. FRITZ!Box), kann aber auch eine Hardware-Firewall sein, falls der Server in einer DMZ betrieben wird.

1. Übersicht

  • Am Server/Host läuft Debian Stable in der Minimal-Konfiguration.
  • Virtualisierung: In den folgenden Abschnitten wird QEMU/KVM genutzt, aber grundsätzlich sollte das Konzept auch mit jeder anderen Virtualisierungssoftware umsetzbar sein. War Virtualisierung bisher noch kein Thema, dann entsprechend einrichten ( → Suchmaschine).
  • Benötigt werden zwei VMs:
    • 1x Linux-VM mit Squid-Proxy
      • Die VM bekommt zwei Netzwerkschnittstellen. Eine davon hängt im gemeinsamen Netz mit der Windows-VM und die andere im „normalen“ Netzwerk.
    • 1x Windows-VM
      • Die VM bekommt nur eine Netzwerkschnittstelle.

2. Aufbau

2.1. Virtuelles Netzwerk erstellen

Über den Virtual Machine Manager lässt sich ein virtuelles internes Netz sehr einfach erstellen. Rechtsklick auf den verbundenen Endpunkt (bspw. das lokales Gerät oder ein entfernter Server) und anschließend „Details“ auswählen. Im nachfolgenden Fenster auf „Virtuelles Netzwerk“ und über das „Plus-Zeichen“ eine neue Verbindung anlegen. In dem neuen Dialog folgende Werte setzen:

Screenshot

  • Modus: Isoliert
  • IPv4: aktivieren
    • Netzwerk: 10.7.0.0/24
    • DHCPv4: deaktiviert
  • IPv6: deaktiviert

2.2. Linux-VM erstellen

Ich verwende für solch minimalistischen Anwendungsfälle gerne Alpine Linux, allerdings lässt sich das Konzept auch mit nahezu allen anderen Linux Distributionen umsetzen. Alpine Linux ist noch ein ticken performanter als andere Distributionen, da es unfassbar schlank ist und für diese Anforderungen bestens geeignet.

  • Meine VM ist zwar mit einem 500 MB Datenträger „ausgestattet“, aber für die Root-Partition werden aktuell bei mir nur etwas mehr als 60 MB benötigt - inkl. Squid-Proxy, SSH-Server und ein paar anderen Tools wie htop.
  • Eine vCPU und 512 MB RAM sind mehr als ausreichend. Im Leerlauf benötigt Alpine Linux ca. 70 MB RAM.
  • Netzwerk
    • Reihenfolge beachten (Erklärung kommt unter „3.1.2. Netzwerkschnittstellen einrichten“)
      1. Externes Netz: Die Netzwerkschnittstelle des Host-Systems (wird vermutlich eine Netzwerkbrücke wie bspw. br0 sein)
      2. Isoliertes Netz: Das virtuelle Netzwerk (z.B. vnet1) aus dem ersten Schritt übernehmen/einsetzen.

2.3. Windows-VM erstellen

  • CPU, RAM, HDD → Hier gilt „Klotzen statt kleckern“!
    • Hier sollte man nicht sparen. Die Windows-VM wird ein vielfaches mehr an Rechenleistung brauchen, damit eine vernünftige Bedienung möglich ist. Lieber nicht einfach nur an den Mindestanforderungen orientieren, sondern am Anfang eher zu viel zur Verfügung stellen als zu wenig - insbesondere für die Installation und Einrichtung. Prozessor und Arbeitsspeicher lassen sich im Nachhinein sehr leicht reduzieren.
  • Netzwerk:
    • Isoliertes Netz: Das virtuelle Netzwerk (z.B. vnet1) aus dem ersten Schritt übernehmen/einsetzen.
  • Optional: Man könnte an dieser Stelle auch einen zusätzlichen Datenträger einrichten, um bspw. Daten auszulagern.

3. Einrichtung

3.1. Linux-VM

3.1.1. Installation

Wer bisher noch keine Erfahrungen mit Alpine Linux gemacht hat, könnte zunächst Schwierigkeiten haben: Vieles ist etwas anders als bei anderen Distributionen. Ein Blick über den Tellerrand lohnt sich jedoch immer.

Für Alpine Linux gibt es die spezielle Variante „Virtual“

Similar to standard. Slimmed down kernel. Optimized for virtual systems.

Hat man den kleinen Installationsdatenträger mit seinen etwas weniger als 50 MB heruntergeladen, erfolgt die Installation immer nach dem selben Schema:

  • ISO-Datei herunterladen, mounten, ggf. Boot-Reihenfolge anpassen und von CD starten.
  • Anweisungen folgen.

Der textbasierte Installer leitet einen durch die Installation. Standardmäßig wird in Alpine Linux (auch während der Installation) der Editor vi genutzt. Wer damit noch keine Erfahrung hat, sollte sich unbedingt in den wichtigsten Kommandos zur Bedienung einlesen, denn andere Editoren (z.B. nano) kann man erst installieren, wenn die Netzwerkverbindung steht :wink:

3.1.2. Netzwerkschnittstellen einrichten

Welche Schnittstelle als eth0 und welche als eth1 erkannt wird, hängt im Grunde von der Reihenfolge ab, in der sie in KVM hinzugefügt wurden bzw. an der dadurch automatischen Nummerierung bei bus="0x08" (XML-Ansicht im virt-manager). Alternativ kann man sich auch an der MAC-Adresse orientieren (ip a).

Screenshot

In der Datei /etc/network/interfaces lassen sich beide Netzwerkschnittstellen definieren:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 192.168.178.70
        netmask 255.255.255.0
        gateway 192.168.178.1
        pre-up sysctl -w net.ipv6.conf.eth0.disable_ipv6=1

# isoliertes netz
auto eth1
iface eth1 inet static
       address 10.7.0.10
       netmask 255.255.255.0
       pre-up sysctl -w net.ipv6.conf.eth1.disable_ipv6=1
       post-up route add default gw 192.168.178.1

Hat man die Netzwerkkonfiguration im Installer übersprungen, fehlt noch ein DNS Server in /etc/resolv.conf

nameserver 192.168.178.1

Nachdem das Netzwerk manuell eingerichtet wurde, müssen die beiden Netzwerkschnittstellen neu gestartet werden:

/etc/init.d/networking restart

3.1.3. squid installieren, konfigurieren und aktivieren

Die Installation des Squid-Proxy erfolgt einfach über den Paketmanager:

apk add squid
# ggf. weiteren Editor wie z.B. nano installieren

In /etc/squid/squid.conf befindet sich anschließend eine Squid Standard-Konfiguration. Dort fügt man direkt nach

# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS

nun die Domains ein, die erlaubt sein sollen (eine vollständige Konfiguration befindet sich am Ende). Die Domains werden zuerst einer ACL (Access Control List) hinzugefügt und anschließenden eine Regel für diese ACL angelegt.

Hier ein Beispiel mit einer kurzen Erklärung:

acl erlaubte_domains dstdomain mycloud.example.com
# Alternativ:
# acl erlaubte_domains dstdomain .example.com
  • acl = Anweisung zur Definition einer Access Control List
  • erlaubte_domains = Name der ACL
  • dstdomain = ACL-Typ (Destination Domain)
  • mycloud.example.com = Domain. Ein vorangestellter Punkt bedeutet, dass sowohl die Domain selbst als auch alle Subdomains erlaubt sind. Der Eintrag .example.com erlaubt also Zugriffe zu
    • example.com
    • www.example.com
    • mail.example.com
http_access allow erlaubte_domains
  • http_access = Anweisung um den Zugriff basierend auf ACLs zu kontrollieren.
  • allow = Zugriff erlauben, wenn nachfolgende Bedingungen erfüllt sind.
  • erlaubte_domains = Name der ACL
Vollständiges Beispiel für eine squid.conf

In dieser Konfiguration sind bereits ein paar Domains hinterlegt:

  • Eigene Nextcloud:
    • mycloud.example.com
  • Steuersoftware/Finanzamt (inkl. aller Subdomains):
    • .buhl.de
    • .buhl-data.com
    • .elster.de
  • Firefox interner Updater (inkl. aller Subdomains)
    • .download-installer.cdn.mozilla.net

Diese Liste lässt sich natürlich beliebig erweitern.

#
# Recommended minimum configuration:
#

# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
acl localnet src 0.0.0.1-0.255.255.255  # RFC 1122 "this" network (LAN)
acl localnet src 10.0.0.0/8     # RFC 1918 local private network (LAN)
acl localnet src 100.64.0.0/10      # RFC 6598 shared address space (CGN)
acl localnet src 169.254.0.0/16     # RFC 3927 link-local (directly plugged) machines
acl localnet src 172.16.0.0/12      # RFC 1918 local private network (LAN)
acl localnet src 192.168.0.0/16     # RFC 1918 local private network (LAN)
acl localnet src fc00::/7           # RFC 4193 local private network range
acl localnet src fe80::/10          # RFC 4291 link-local (directly plugged) machines

acl SSL_ports port 443
acl Safe_ports port 80      # http
acl Safe_ports port 21      # ftp
acl Safe_ports port 443     # https
acl Safe_ports port 70      # gopher
acl Safe_ports port 210     # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280     # http-mgmt
acl Safe_ports port 488     # gss-http
acl Safe_ports port 591     # filemaker
acl Safe_ports port 777     # multiling http

#
# Recommended minimum Access Permission configuration:
#
# Deny requests to certain unsafe ports
http_access deny !Safe_ports

# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports

# Only allow cachemgr access from localhost
http_access allow localhost manager
http_access deny manager

# This default configuration only allows localhost requests because a more
# permissive Squid installation could introduce new attack vectors into the
# network by proxying external TCP connections to unprotected services.
http_access allow localhost

# The two deny rules below are unnecessary in this default configuration
# because they are followed by a "deny all" rule. However, they may become
# critically important when you start allowing external requests below them.

# Protect web applications running on the same server as Squid. They often
# assume that only local users can access them at "localhost" ports.
http_access deny to_localhost

# Protect cloud servers that provide local users with sensitive info about
# their server via certain well-known link-local (a.k.a. APIPA) addresses.
http_access deny to_linklocal

#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#

acl erlaubte_domains dstdomain mycloud.example.com
acl erlaubte_domains dstdomain .buhl.de
acl erlaubte_domains dstdomain .elster.de
acl erlaubte_domains dstdomain .buhl-data.com
acl erlaubte_domains dstdomain .download-installer.cdn.mozilla.net

http_access allow erlaubte_domains

# For example, to allow access from your local networks, you may uncomment the
# following rule (and/or add rules that match your definition of "local"):
# http_access allow localnet

# And finally deny all other access to this proxy
http_access deny all

# Squid normally listens to port 3128
http_port 3128

# Uncomment and adjust the following to add a disk cache directory.
#cache_dir ufs /var/cache/squid 100 16 256

# Leave coredumps in the first cache dir
coredump_dir /var/cache/squid

#
# Add any of your own refresh_pattern entries above these.
#
refresh_pattern ^ftp:       1440    20% 10080
refresh_pattern ^gopher:    1440    0%  1440
refresh_pattern -i (/cgi-bin/|\?) 0 0%  0
refresh_pattern .       0   20% 4320

Damit ist die Squid Konfiguration auch schon abgeschlossen. Wir müssen nun nur noch den Dienst aktivieren, damit dieser mit jedem Systemstart automatisch gestartet wird und ihn einmalig manuell starten:

rc-update add squid default
service squid start

3.1.4. Zusatzsoftware

An der Stelle könnte man noch weitere Dienste installieren. Vorstellbar wäre z.B. ein SMB-Share, welches sich die Linux-VM (oder der Host) und die Windows-VM teilen, damit ein unkomplizierter Datenaustausch möglich ist. In meinem Fall ist das nicht eingerichtet, da ich der Windows-VM einen separaten Zugang zu meiner Nextcloud spendiert habe und den offiziellen Nextcloud-Client für die Synchronisation verwende.

3.2. Windows-VM

3.2.1 Installationsdatenträger

Die Installation erfolgt mit der offiziellen ISO (z.B. Windows 10)

3.2.2. Netzwerk einrichten

Screenshot

  • Einstellungen → Netzwerk und Internet
  • Ethernet → Netzwerkadapter auswählen
  • IP-Einstellungen → Bearbeiten
  • Manuell
    • IPv4: aktiviert
    • IP-Adresse: 10.7.0.2
    • Gateway: 10.7.0.10
    • DNS: 10.7.0.10
    • IPv6: deaktiviert

3.2.3. Proxy im System hinterlegen

Screenshot

  • Einstellungen → Netzwerk und Internet
  • Ethernet → Proxy → Manuelle Proxyeinrichtung
  • Proxyserver verwenden: aktiviert
  • Adresse: 10.7.0.10
  • Port: 3128

3.2.4. ggf. Zusatzsoftware installieren

Normalerweise erkennt eine Zusatzsoftware den im System hinterlegten Proxy automatisch. Falls nicht, lässt sich das recht einfach innerhalb der Anwendung festlegen.

Beispiel Firefox:

  • Einstellungen → Verbindungs-Einstellungen → Einstellungen
  • Proxy-Einstellungen des Systems verwenden: ausgewählt

3.3. Routing

Abhängig davon wie das Netzwerk aufgebaut ist und wie man auf die Windows-VM zugreifen möchte, sind ggf. statische Routen notwendig.

Verwendet man ausschließlich den „Virtual Machine Manager“, um auf die Windows-VM zugreifen zu wollen, dann benötigt man keine statische Route.

Möchte man bspw. auf die Windows-VM über RDP oder VNC zugreifen, müssen die Clients wissen, dass sie das Netz 10.7.0.0/24 über 192.168.178.70 (Linux-VM) erreichen. Dazu muss am nächsten Gateway (Router/Hardware-Firewall) oder am Client selbst eine statische Route angelegt werden. Als Beispiel hier die Schritte an einer FRITZ!Box:

  • Heimnetz → Netzwerk → Netzwerkeinstellungen
  • „Weitere Einstellungen“
  • Punkt „Tabelle für statische Routen“ → Button „IPv4-Routen“

Dort müssen folgende Daten eingetragen werden:

  • IPv4-Netzwerk: 10.7.0.0
  • Subnetzmaske: 255.255.255.0
  • Gateway: 192.168.178.70
  • IPv4-Route aktiv: aktiviert

Wird eine statische Route im Router angelegt, gilt sie für alle daran angeschlossenen Geräte. Alternativ kann man eine statische Route nur für einen einzelnen Client anlegen - dann weiß nur dieser Client, dass das Netz 10.7.0.0/24 über 192.168.178.70 (Linux-VM) erreichbar ist.

4. Abschluss

Geschafft :partying_face: Die Windows-VM befindet sich nun in einem vollständig isolierten und kontrollierten Netz. Die externe Kommunikation ist nur über die im Squid-Proxy hinterlegten Endpunkte möglich. Am System selbst wurde (abgesehen von der Netzwerkkonfiguration) nichts verändert und befindet sich somit im Auslieferungszustand. Beste Voraussetzungen für alle weiteren Anwendungen.

Sollten im Laufe der Zeit weitere Endpunkte notwendig werden, lassen sich diese einfach in der Squid-Proxy-Konfiguration hinzufügen. Nach einem Neustart mit service squid restart ist dann auch der neue Endpunkt erreichbar.

Benötigt eine bestimmte Anwendung weitere Endpunkte, hilft meist ein kurzer Blick in das Logfile. Die Logdateien von Squid befindet sich hier:

/var/log/squid/access.log

Falls dort zu viele Einträge vorhanden sind oder eine zweifelsfreie Zuordnung nicht möglich ist, hilft ggf. die Suchmaschine weiter. Viele Hersteller dokumentieren die notwendigen Endpunkte.

Hinweis: Auch wenn Windows keinen Endpunkt erreichen kann, wird es die Squid-Proxy Logs permanten mit Einträgen füllen. Hilfreich ist in diesem Fall das Tool logrotate.

Fazit

Es ist gar nicht so schwer ein Windows-System bezüglich Privatsphäre sicher einzurichten und zu betreiben. Um maximalen Datenschutz zu erreichen ist man nun unabhängig von Drittanbietersoftware, Blocklisten oder den Systemeinstellungen und kann sich absolut sicher sein, dass nur die Endpunkte kontaktiert werden können, die vorher explizit definiert wurden. Anstatt sich regelmäßig mit diesem Thema zu beschäftigen, betreibt man den Aufwand nur einmalig und muss sich zukünftig keine Sorgen machen. Mit „WSUS Offline Update“ lässt sich das System bei Bedarf aktualisieren. Ob Systemupdates überhaupt notwendig sind, hängt im wesentlichen vom konkreten Anwendungsfall bzw. den genutzten Anwendungen ab. Grundsätzlich lassen sich damit auch alle anderen Systeme (7, Vista, XP, …) isolieren.

Wird die Windows-VM nur selten benutzt, kann man diese nach der Nutzung einfach herunterfahren oder den Zustand sichern, um bspw. Ressourcen für andere Anwendungen freizugeben. Die Linux-VM kann man bei dem geringen Ressourcenverbrauch problemlos permanent laufen lassen.

8 „Gefällt mir“

Der Whitelist-Ansatz gefällt mir. Nach meinen Beobachtungen ist die Proxy-Konfiguration unter Windows benutzerspezifisch, und gilt dann insbesondere nicht für Systemprozesse. Ist das Dein Grund für Offline-Updates?
Wenn Du das Testen willst, kann ich die Registryeinstellungen für Proxy raussuchen die man kopieren müsste.

Bisher hab ich noch nie Updates (offline/online) eingespielt, da sie nicht nötig waren.

Das teste ich gerne. Bisher ist mir in den Logs nichts aufgefallen und ohne Proxy kann die VM keine externen Verbindungen aufbauen.

1 „Gefällt mir“

Du findest in der Registry unter (Pfad wie in Regedit)
Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections
eine Einstellung Reg_Binary DefaultConnectionSettings.
Kopier diese Einstellung bitte nach Computer\HKEY_USERS\S-1-5-18\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections.

Wenn weitere User mit kleinen Nummern da sind, schau mal in
https://learn.microsoft.com/en-us/windows/win32/secauthz/well-known-sids

Wirf danach vielleicht mal Windows Updates an und schau ob die Deinen Proxy benutzen. Falls das grundsätzlich tut, könnte man daraus ein Powershell-Skript machen.

Vielen Dank. Ich hab den Registrykey an der Stelle gesetzt und das Update gestartet. Ja, der Proxy wird an der Stelle benutzt. Das ist der Auszug aus dem Squid Log:

1717558350.246      0 10.7.0.2 TCP_DENIED/403 3844 CONNECT settings-win.data.microsoft.com:443 - HIER_NONE/- text/html
1717558350.368      0 10.7.0.2 TCP_DENIED/403 3844 CONNECT settings-win.data.microsoft.com:443 - HIER_NONE/- text/html
1717558350.398      0 10.7.0.2 TCP_DENIED/403 3844 CONNECT settings-win.data.microsoft.com:443 - HIER_NONE/- text/html
1717558350.430      0 10.7.0.2 TCP_DENIED/403 3844 CONNECT settings-win.data.microsoft.com:443 - HIER_NONE/- text/html
1717558350.465      0 10.7.0.2 TCP_DENIED/403 3844 CONNECT settings-win.data.microsoft.com:443 - HIER_NONE/- text/html
1717558350.524      0 10.7.0.2 TCP_DENIED/403 3844 CONNECT settings-win.data.microsoft.com:443 - HIER_NONE/- text/html
1717558350.756      0 10.7.0.2 TCP_DENIED/403 3844 CONNECT settings-win.data.microsoft.com:443 - HIER_NONE/- text/html
1717558351.809    146 10.7.0.2 TCP_DENIED/403 3829 CONNECT slscr.update.microsoft.com:443 - HIER_NONE/- text/html
1717558363.842      0 10.7.0.2 TCP_DENIED/403 3829 CONNECT slscr.update.microsoft.com:443 - HIER_NONE/- text/html
1717558363.862      0 10.7.0.2 TCP_DENIED/403 3829 CONNECT slscr.update.microsoft.com:443 - HIER_NONE/- text/html
1717558363.876      0 10.7.0.2 TCP_DENIED/403 3829 CONNECT slscr.update.microsoft.com:443 - HIER_NONE/- text/html

Allerdings wird der Proxy auch genutzt, wenn diese Änderungen wieder rückgängig gemacht werden:

1717558712.408      0 10.7.0.2 TCP_DENIED/403 3829 CONNECT slscr.update.microsoft.com:443 - HIER_NONE/- text/html
1717558712.421      0 10.7.0.2 TCP_DENIED/403 3829 CONNECT slscr.update.microsoft.com:443 - HIER_NONE/- text/html
1717558712.434      0 10.7.0.2 TCP_DENIED/403 3829 CONNECT slscr.update.microsoft.com:443 - HIER_NONE/- text/html
1717558712.449      0 10.7.0.2 TCP_DENIED/403 3829 CONNECT slscr.update.microsoft.com:443 - HIER_NONE/- text/html

Falls die Windows-Version wichtig ist:

Edition	Windows 10 Pro
Version	21H2
Installiert am	‎18.‎04.‎2022
Betriebssystembuild	19044.1645

S-1-5-18 war die kleinste Nummer.

1 „Gefällt mir“

Prima. Ich würde ein zwei Jahre altes System nicht verwenden wollen und würde ungern Updates manuell einspielen (insbesondere nicht auf mehreren Systemen). Aber kann ja jeder selbst entscheiden.

Der squid hat kein Zertifikat und wird damit nicht authentifiziert - bei der kontrollierten Netzwerkkonfiguration halte ich das für in Ordnung, sollte aber Verwendern bewusst sein.

Spannend fände ich jetzt, statt squid mitmproxy zu verwenden damit man genau mitlesen kann was wirklich passiert.

Kommt drauf an, was man damit macht. Solange es keine funktionalen Gründe gibt, wüsste ich nicht, warum man bei einem derart isolierten Endgerät Updates einspielen müsste. Betreibt man den Server zusätzlich in einer DMZ und verwendet z.B. Guacamole als „Frontend“, gehen die potentiellen Angriffsvektoren praktisch gegen Null. Der Aufbau eignet sich daher auch gut, um alte Anwendungen auf noch älteren Systemen (z.B. Windows XP) zu betreiben.

Ja, könnte man tun, wenn man z.B. das System oder Anwendungen analysieren möchte. In dem konkreten Anwendungsfall geht es eher um „Ich muss das mal nutzen, um meine damals gekaufte CAD-Anwendung zu benutzen“ oder „Ich muss mal die Steuererklärung machen“.

1 „Gefällt mir“

So wie ich es verstanden habe, verarbeitest du doch persönliche Daten darauf und bist auch in Services, wie deiner Nextcloud, eingeloggt. Ein Szenario wäre Malware (z.b. Ransomware) in deinen Dateien die bisher nur nicht aufgefallen ist, weil sie nicht für Linux konzipiert war und nun auf dem völlig veralteten Windows-System aktiv wird.

Ich kann verstehen, dass es den einen oder anderen in den Fingern juckt :wink: Wie gesagt, das Risiko ist sehr überschaubar. Zum Beispiel hat der Nextcloud-Windows-VM-Nutzer nur Zugriff auf ein einzelnes Verzeichnis und es gibt nur einen „externen“ Benutzer, der von außerhalb darauf zugreifen kann. Dennoch sollte man sich natürlich auch mit dem Thema Backups beschäftigen, falls es dort Daten gibt die man nicht verlieren möchte.

Man könnte noch einen Schritt weitergehen und dem „externen“ Benutzer nur lesenden Zugriff auf dieses Verzeichnis gewähren. Möglicherweise braucht man auch gar keinen Datenaustausch (Nextcloud, SMB, SFTP, …) und kann sich das ganz sparen. So oder so hat man natürlich immer die Möglichkeit, das System auch mit „WSUS Offline Update“ aktuell zu halten, ohne externe Endpunkte zu öffnen.

Wie gesagt, ich sehe da für mich persönlich aktuell (bzw. seit 2022) keine Notwendigkeit und der Fokus in diesem Tutorial liegt auf die Isolierung von Windows.

Danke @nobody für dieses Tuturial.
Ich habe bisher eine Win10 VM in einer Gnome Box am laufen gehabt, genau für den einen Zweck: Die jährliche Steuererklärung.
Ich habe jetzt diese Variante auf meinem Laptop (MX-Linux Xfce) mal „nachgebaut“. Funktioniert einwandfrei.
Ein paar Tipps noch:
Hatte es Anfangs mit der Fluxbox-Version von MX-Linux probiert, hab mich dann aber doch mal an Alpine-Linux „rangetraut“, da man doch nicht viel mehr braucht, als die Netzwerk- und die Proxy-Konfiguration.
Für die Ersteinrichtung von Alpine mit alpine-setup kann man sich an die Anleitung bei linuxnews.de halten. Die dort beschriebene Installation vom ssh-Server, der Zusatzpakete und vom Desktop kann man sich sparen. Brauch man für diesen Zweck nicht wirklich.
Der virt-manager bietet die Möglichkeit vorhandene VM’s von z.B Gnome-Boxes einzubinden. Diese kann man dann klonen und aus diesem Klone eine neue VM, in der mit den beiden Netzwerken erstellten QUEMU/KVM, erstellen. Es bleiben dabei alle Einstellungen erhalten. Erspart einem die Neuinstallation von Win10.
Ich verwende für die Steuer die Steuersparerklärung von der Akademischen Arbeitsgemeinschaft. Damit diese funktioniert (Updates etc.) müssen im Proxy die Domain .akademische.de und .steuertipps.de freigegeben werden.

1 „Gefällt mir“