Monthly Archives: October 2018

Ausgehende HTTP-Anfragen von E-Mail Servern, Spamassassin und sa-learn

Posted on by

Es ist grundsätzlich gut, Server abzuschotten. Das gilt natürlich auch für E-Mail-Server unter Linux. Wie meine Leser wissen, ist meine Politik dabei regelmäßig die, nicht nur eingehende sondern auch ausgehende Verbindungen kritischer Systeme so weit wie möglich einzuschränken.

Vor kurzem hatte ich deshalb die Möglichkeiten für Verbindungen von unseren (virtualisierten) Mailservern im LAN ins Internet weiter begrenzt. Das führte dann leider zum Ausfall des Spamassassin-Daemons auf einem Server; da auf dem betroffenen System AmaVis nicht lief, hatte das durchaus spürbare Konsequenzen. Der Grund für den Ausfall ist vielleicht auch für andere Freelancer und Entwickler interessant, die eigene Mailserver im Hausnetz betreiben.

Notwendige ausgehende Verbindungen

Zur Sicherstellung der Kern-Funktionalitäten eines Mailservers im eigenen LAN (mit virtualisierten Segmenten) sind ja eigentlich nur sehr wenige ausgehende Verbindungen erforderlich:

  • Man muss Mails von Servern diverser Provider oder ggf. auch eigenen Servern, die im Internet positioniert sind, abholen. Das ist unter Linux durch Nutzung von Fetchmail und des IMAP- oder POP-Protokolls möglich.
  • Man muss Mails über Relay-Server bei Providern (oder eigene Relay-SMTP-Server im Internet) versenden. Hierzu reicht ein eigener MTA im LAN, der SMTP beherrscht. Unter Linux kommt etwa Postfix in Frage.

Die zu adressierenden Server sind von ihrer Anzahl her in der Regel überschaubar. Die zu nutzenden Ports ergeben sich aus der Absicherung der Verbindung mit STARTTLS/TLS/SSL – je nachdem, was der Provider so anbietet. Also kein Problem mit der Begrenzung der Verbindungsaufnahme durch einen Perimeter-Paketfilter im Segment der Mailserver und/oder an der LAN-Grenze vor dem Router ins Internet. (Natürlich kann auch eine lokale Firewall auf dem Linux-Host die Filterung stützen.)

Natürlich sind das aber nicht alle ausgehenden Verbindungen eines MTA wie Postfix im LAN. Hinzu kommen ggf. auch Verbindungen zu MDAs im LAN – etwa Dovecut oder Cyrus. Oft genug sitzen die aber auf demselben Linux-Host oder im gleichen LAN-Segment. Diese zu Systemen im LAN ausgehenden sowie auch eingehende Verbindungen durch Mail-Clients sind in einem strukturierten, segmentierten LAN leicht durch interne Firewalls an der Grenze von Segmenten zu kontrollieren.

Zusätzliche HTTP- odr HTTPS-Verbindungen ins Internet

Leider reicht eine Begrenzung auf Zieladressen von definierten IMAP- und SMTP-Servern im Internet nicht. Der Hauptgrund ist folgender:

Der Linux-Host, der den Unterbau für die Mail-Server-Komponenten (z.B. Postfix, Dovecot, Cyrus, Amavis, Spamassassin, Virusfilter plus TLS-, SASL-, LDAP-Komponenten) stellt, muss als solcher regelmäßig upgedated werden. Für den Freelancer ist die bequemste Methode sicher die, sich die notwendigen Pakete über einen Paketmanager von Repository-Servern des Linux-Distributors seines Vertrauens oder entsprechenden Mirror-Servern herunter zu laden. Auch die Anzahl solcher Server ist begrenzt. Typischerweise kommt für den Pakettransfer das HTTP- oder das HTTPS-Protokoll zum Einsatz. Aus Sicherheitsperspektive gibt es Vor- und Nachteile beider Varianten (sichere Server-Authentifizierung vs. nicht mehr einsehbarer Datentransfer über die nach außen initiierte Verbindung). In jedem Fall kann man aber auch hier die Zieladressen begrenzen UND den HTTP(S)-Kanal ggf. nur zeitweise öffnen. Konsequenterweise habe ich ausgehende HTTP(S)-Verbindungen der Mail-Server beschnitten.

Erwähnt sei an dieser Stelle der Vollständigkeit halber auch Folgendes:

Je nach Ausbau der Spam- und Virus-Bekämpfung kommen weitere Komponenten ins Spiel (Spamassassin, Razor2, Pyzor, …). Dieser Punkt ist dann schon ein wenig heikler. So schön und hilfreich Razor2 und Pyzor von ihrer Grundidee her auch sein mögen; man überträgt bei der Nutzung
solcher Dienste mindestens mal Hashes, die Inhalte in besonderer Weise differenzieren und vergleichbar machen; im ersten Fall an kommerzielle und abgeschottete Server in den USA. Genutzt werden im Fall von Razor2 die TCP-Ports 2703, ggf. auch Port 7 für ausgehende Verbindungen. Pyzor nutzt UDP-Port 24441; ich möchte mich hier nicht weiter über Sicherheitsprobleme offener UDP-Kanäle auslassen :-). Im Zuge der DSGVO sollte man beim Mailaustausch mit Kunden aber in jedem Fall mal nachfragen, ob der Kunde das Versenden von Hashes zu seinen Mails an Razor/Pyzor-Server erlauben will.

Ich betreibe deswegen eine eigene (virtualisierte) Mail-Server-Instanz für den kritischen Mailaustausch mit Kunden; dabei nutze ich ferner spezielle Mail-Accounts bei Providern. Der zugehörige MTA unterlässt den Einsatz von Razor2/Pyzor; das ist sinnvoll, da von Kunden ja hoffentlich keine SPAM-Mails kommen.

Hinweis: Deaktivieren muss man die Nutzung von Razor/Pyzor im Rahmen von Spamassassin übrigens durch Auskommentieren folgender Zeilen in der Konfigurationsdatei “/etc/mail/spamassassin/v310.pre” (die kennt auch nicht jeder 🙂 ):
“loadplugin Mail::SpamAssassin::Plugin::Razor2”     und     “loadplugin Mail::SpamAssassin::Plugin::Pyzor”.

Von Bedeutung sind bei Einsatz eines Virenscanners auch auch ausgehende HTTP(S)-Verbindungen zu Update-Servern. Im Fall von clamav etwa zu: db.de.clamav.net, database.clamav.net.

Fehler beim Start des Spamassassin-Dämons “spamd” wegen “sa-learn”

Wir nutzen auf unseren Linux-Systemen primär Spamasassin zur Spam-Bekämpfung. Abhängig von der Linux-Distribution, vom Einsatz von AmaVis und eigenen Einstellungen wird auf einem Mailserver dabei der Spamassassin-Daemon gestartet oder nicht.

Amavis nutzt Spamassassin über ein eigenes internes (perl-basiertes) Modul (siehe https://wiki.centos.org/HowTos/Amavisd oder https://help.ubuntu.com/community/PostfixAmavisNew). Obwohl spamd für Amavis nicht gestartet werden muss, greift AmaVis aber auf die vorhandene Spamassassin-Installation und bestimmte zugehörige Einstellungen zu; u.a. Update-Einstellungen (s.u.). Man darf die Spamassassin-Pakete also nicht deinstallieren, wenn man AmaVis in seinen MTA integriert.

Zudem bietet eine zusätzlich laufende Instanz des Spamasassin-Daemons weitere Filtermöglichkeiten, die man etwa im Rahmen von procmail nutzen kann. (Siehe hierzu etwa https://serverfault.com/questions/845712/what-to-do-with-spamassassin-after-installing-amavis und die dortigen Kommentare).

Auf einem meiner Mail-Server wird der Spamassassin-Dämon “spamd” jedenfalls explizit gestartet. Nach dem letzten Hochfahren der betreffenden (virtuellen) Server-Instanz musste ich allerdings ein komisches Verhalten der gesamten Mail-Installation feststellen, was sich nach ein wenig Analyse auf den gescheiterten Start des “spamd“-Dämons zurückführen ließ. Was war da los?

Ich musste eine Weile graben, bis mir klar wurde, dass das Starten des spamd-Services auf einem Suse-Unterbau einige Dinge ablaufen, die man bei der KOnfiguration von Paketfilter-Einstellungen besser nicht vergessen oder ignorieren sollte:

So zeigt die systemd-Service-Konfiguration für “spamd” etwa Folgendes: 

mymails # cat /usr/lib/systemd/system/spamd.service
# This file is part of package amavisd.
#
# Copyright (c) 2011 SuSE LINUX Products GmbH, Germany.
# Author: Werner Fink
# Please send feedback to http://www.suse.de/feedback
#
# Description:
#
#  Used to start the spamd the daemonized version of spamassassin
#       spamassassin adds a header line that shows if the mail has been
#       determined 
spam or not. This way, you can decide what to do with the
#       mail within the scope of your own filtering rules in your MUA (Mail
#       User Agent, your mail program) or your LDA (Local Delivery Agent).
#

[Unit]
Description=Daemonized version of spamassassin
Wants=remote-fs.target network.target
After=remote-fs.target network.target
Before=mail-transfer-agent.target

[Service]
Type=forking
PIDFile=/var/run/spamd.pid
ExecStartPre=/bin/bash -c "sa-update || true"
EnvironmentFile=-/etc/sysconfig/spamd
ExecStart=/usr/sbin/spamd $SPAMD_ARGS -r /var/run/spamd.pid
ExecReload=/usr/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target

Die interessante Zeile ist hier “ExecStartPre=/bin/bash -c “sa-update || true”. Sie legt fest, dass “sa-update” vorab gestartet werden soll.

“sa-update” hat den Zweck, bestimmte Regeln für “spamassassin” automatisch zu erneuern. Dazu wird auf sog. “channels” zugegriffen, hinter denen bestimmte Server im Internet stehen. Siehe hierzu:
https://spamassassin.apache.org/full/3.1.x/doc/sa-update.html. Die Regeln etc. – und damit deren Erneuerung – werden übrigens auch von AmaVis genutzt!. “sa-update” ist somit auch für ein MTA-System mit AmaVis-Dienst relevant; ggf. verlässt sich die Installation dabei aber auf einen durch cron veranlassten Start!

Leider hatte ich “sa-update” in meinem Kopf völlig verdrängt. Da sich die Fehlermeldungen, die ein “systemctl status spamd.service” ausspuckte u.a. auf die nicht erreichbare Adresse “spamassassin.apache.org” und auch “1.4.3.updates.spamassassin.org” bezogen, war klar, dass ich die Begrenzung der ausgehenden Verbindungen wohl etwas übertrieben hatte.

sa-update kann man auch manuell ausführen. Zum Testen eignet sich der Befehl “sa-update –refreshmirrors -vvvvv -D“: 

mymails # sa-update --refreshmirrors -vvvvv -D
Oct 20 13:44:59.164 [4580] dbg: logger: adding facilities: all
Oct 20 13:44:59.164 [4580] dbg: logger: logging level is DBG
Oct 20 13:44:59.164 [4580] dbg: generic: SpamAssassin version 3.4.1
Oct 20 13:44:59.164 [4580] dbg: generic: Perl 5.018002, PREFIX=/usr, DEF_RULES_DIR=/usr/share/spamassassin, LOCAL_RULES_DIR=/etc/mail/spamassassin, LOCAL_STATE_DIR=/var/lib/spamassassin
Oct 20 13:44:59.164 [4580] dbg: config: timing enabled
Oct 20 13:44:59.171 [4580] dbg: config: score set 0 chosen.
Oct 20 13:44:59.181 [4580] dbg: generic: sa-update version svn1652181
Oct 20 13:44:59.181 [4580] dbg: generic: using update directory: /var/lib/spamassassin/3.004001
.....
....
Oct 20 13:44:59.588 [4580] dbg: channel: attempting channel updates.spamassassin.org
Oct 20 13:44:59.588 [4580] dbg: channel: using existing directory /var/lib/spamassassin/3.004001/updates_spamassassin_org
Oct 20 13:44:59.589 [4580] dbg: channel: channel cf file /var/lib/spamassassin/3.004001/updates_spamassassin_org.cf
Oct 20 13:44:59.589 [4580] dbg: channel: channel pre file /var/lib/spamassassin/3.004001/updates_spamassassin_org.pre
Oct 20 13:44:59.590 [4580] dbg: channel: metadata version = 1844313, from file /var/lib/spamassassin/3.004001/updates_spamassassin_org.cf
....
.....

Das oben ist ein Auszug aus einer funktionierenden Konfiguration. Auf dem fehlerhaften System kamen dagegen viele Fehlermeldungen zu diversen durchprobierten channel-Verbindungen. Das betraf dann doch eine ganze Reihe von Servern – wie sich später herausstellte waren das Mirror-Server. Ein Blick in das Protokoll der Firewalls offenbarte dann, dass zu all diesen Servern der Reihe nach wiederholte “http”-Anfragen abgesetzt wurden. Das bestätigte, dass eine zu rigorose Unterbindung von ausgehenden HTTP-Verbindungen für einen Mail-Server mit Spamassassin nicht unbedingt gut ist.

Welche Haupt- und Mirror-
Server für “sa-update” sind in der Firewall zu berücksichtigen?

Nun will man ja nicht unbedingt Fehlerprotokolle und Firewall-Logs studiweren, um herauszufinden, zu welchen sa-channel-Servern man HTTP-Verbindungen zulassen sollte. Dass der Hauptchannel “updates.spamassassin.org” sein soll, geht aus der sa-update Doku zwar hervor, nicht aber der oder die zugehörige Server. Ein “ping updates.spamassassin.org” bringt jedenfalls nichts.

Der aktuelle Server, der im Moment tatsächlich (per DNS!) angefragt wird, ist vielmehr “1.4.3.updates.spamassassin.org”. Darauf sollte man sich aber auf Dauer nicht verlassen. Was ist also bzgl. der Firewall zu tun?

Folgende DNS-Namen sind für Firewall-Regeln wichtig:

  • Ein relevanter Server für HTTP ist in jedem Fall: spamassassin.apache.org
  • Weitere Mirror-Server für ausgehende HTTP-Verbindungen sind z.Z. gelistet unter
    “/var/lib/spamassassin/3.004001/updates_spamassassin_org/MIRRORED.BY”.
    Da kann man ja einige vertrauenswürdige DNS-Namen zulassen. Z.B. “sa-update.spamassassin.org”.

Die zuständige Firewall sollte so konfiguriert werden, dass die IP-Adressen für oben angegebenen DNS-Namen zur Laufzeit aufgelöst werden können. Mit iptables ist das problemlos möglich.

Bzgl. der rules und der Datei MIRRORED.BY noch ein Tip: Man sollte nach Server-Updates oder gar Upgrades immer mal kontrollieren, ob unter “/var/lib/spamassassin/” nicht ein neueres Verzeichnis des Typus 3.00X000Y mit Konfigurations- und Rules-Files aufgetaucht ist. Das relevante Verzeichnis verändert sich im Lauf der Jahre; die alten Verzeichnisse werden oft aber nicht gelöscht.

Bzgl. der Firewall ist in jedem Falle aber auch Folgendes zu beachten:

Der Mailserver muss grundsätzlich DNS-Abfragen stellen können.

Nicht nur, um ggf. die obigen Namen auflösen zu können; sondern auch weil die Überprüfung der Update-Notwendigkeit über DNS-Abfragen erfolgt. Man schaue sich mal mit Wireshark die Kommunikation an! Das Zulassen von DNS in der Firewall erscheint auf den ersten Blick trivial. Aber wer die Kommunikation seines Mail-Server begrenzt, arbeitet ggf. bzgl. SMTP, IMAP, etc. zu externen Servern direkt mit IP-Adressen und lässt DNS außen vor. Im besonderen, wenn diese Server im Internet selbst verwaltete sind.

Dauerhaft laufender Mail-Server und sa-update

Natürlich muss der Update Dienst auch auf einem dauerhaft laufenden System funktionieren. Das wird mittels des “cron”-Dienstes erledigt. Hier ist z.B. auch unter Opensuse ein Eintrag für “sa-update” vorhanden. Vorgaben, die das Update-Verhalten für spamd steuern, findet man bei Opensuse übrigens in der Datei “/etc/sysconfig/spamd”.

Fazit

Bei der Einschränkung ausgehender Verbindungen von E-Mail-Servern sollte man nicht vergessen, dass Spamassassin ebenso wie Virenscanner automatische Updates von grundlegenden Filterregeln vornehmen. In vielen Linux-Distributionen ist ein solcher Update sogar täglich vorgesehen. Für Spamassassin sind in diesem Zusammenhang HTTP-Verbindungen zu “channel”-Servern zu ermöglichen. Daneben sind DNS-Abfragen zuzulassen. Das Scheitern des Startens von “spamd” beim Hochfahren von Mailservern aufgrund von Firewall-Beschränkungen ist möglich.

Links

https://wiki.centos.org/HowTos/Amavisd
https://help.ubuntu.com/community/PostfixAmavisNew
https://serverfault.com/questions/845712/what-to-do-with-spamassassin-after-installing-amavis
https://www.howtoforge.com/community/threads/
spamassassin-automated-update.72393/
https://www.faqforge.com/linux/keep-the-spamassassin-filter-rules-up-to-date-in-ispconfig-3/

VMware Workstation – Virtual Ethernet failed – sometimes for good!

Posted on by

I use VMware Workstation as a hypervisor for hosting a few MS Windows guests, which I need in customer projects. As I do not trust Windows systems I sometimes place such guests in different virtual and isolated host-only networks on my workstation or a dedicated server. On other systems I run virtualized Linux server systems for production and tests with the help of KVM/QEMU, LXC and libvirt. Some time ago I learned the hard way that I have to keep track of the different “local” virtual networks more thoroughly. As the VMware side was affected by a misconfiguration in a rather peculiar way I thought this experience might be interesting for others, too.

Host interface to VMware virtual network sometimes not available?

The whole thing coincided with an upgrade of one of my Opensuse workstations. I am always a bit nervous whether and how such an upgrade may impact the VMware WS installation. Quite often I experienced problems with the automatic compilation in the past. In addition the start of some modules lead to secondary errors. However, at a first test VMware WS 14 compiled without problems on a system with Opensuse Leap 15. No wonder, I thought, as the kernel version 4.12 of Leap15 is relatively old.

Then I had to set up a Windows guest. I gave it an IP address within a virtual VMware host-only network, which covered an IPv4 address range of a class C network. VMware uses a kind of virtual bridge to support such a network; normally one associates a virtual network device on the host with it, to which you can assign a certain IP address in the net’s address ange. For a C-net VMware uses yyy.yyy.yyy.1 as a default on the host’s interface (with yyy.yyy.yyy defining the C-network). In my case the device on the host was named “vmnet6”. In the beginning this virtual interface also worked as expected.

However, during the following days I noticed trouble with “vmnet6”. In a normal host configuration the VMware WS initialization script (“/etc/init.d/vmware”) is started as a LSB service by systemd. The script loads VMware modules and configures the defined virtual networks. Unfortunately, relatively often, my “vmnet6” interface did not become directly available after the start of the Linux host. Some experiments showed however that I could circumvent this problem by some “dubious” action:

I had to enter the “Virtual Network Editor” with root rights and save the already existing virtual network again. Then ifconfig or the ip command enlisted interface “vmnet6” – which also seemed to work normally.

You get a strange feeling when you are forced to remedy something as root …. However, I ignored this problem, which I could not solve directly, for a while. I also noticed that the problem did not occur all the time. This should have rang a bell … but I was too stupid. Until, yesterday, when I needed to set up another special MS WIN guest in the same address range.

Virtual Ethernet failed

In addition I upgraded to VMware WS Version 14.1.3. The (automatic) compilation of the VMware WS modules on Opensuse Leap 15 again worked without major problems. But, when I manually (re-) started the VMware modules via “/etc/init.d/vmware restart” I saw an error message:

“Virtual Ethernet failed”.

Such a message makes you nervous because you assume some real big problem with the VMware modules. However, starting some of my VMware guests (not the ones linked to vmnet6) proved that these guests operated flawlessly and could communicate via their and the hosts network devices. But my “vmnet6” did not appear in the output of “ip a s”.

The problem “Virtual Ethernet failed” is reported in some Internet articles; however without a real solution. See e.g. https://ubuntuforums.org/showthread.php?t=1592977; https://www.linuxquestions.org/questions/slackware-14/vmware-workstation-unable-to-start-services-4175547448/; https://communities.vmware.com/thread/264235.

Now, I seriously began to wonder whether and how this problem was related to the already known problem with my virtual device “vmnet6”. Some tests quickly showed that the error message disappeared when I eliminated the host-only network related to “vmnet6”. Then I tried a new host-only test network with a device “vmnet7” and a different IP range. Also then the “virtual Ethernet” started flawlessly. So, what was wrong with “vmnet6” and/or its IP range? Some residual garbage from old installations? A search for configuration files gave me no better ideas.

vnetlib-log

After a minute I thought: Maybe VMware is right. A look into the log-file “/var/log/vnetlib” revealed: 

Oct 14 14:22:49 VNL_Load - LOG_ERR logged
Oct 14 14:22:49 VNL_Load - LOG_WRN logged
Oct 14 14:22:49 VNL_Load - LOG_OK logged
Oct 14 14:22:49 VNL_Load - Successfully initialized Vnetlib
...
Oct 14 14:22:49 VNL_StartService - Started "Bridge" service for vnet: vmnet0
Oct 14 14:22:49 VNLPingAndCheckSubnet - Return value of vmware-ping: 0
...
Oct 14 14:22:50 VNL_CheckSubnetAvailability - Subnet: xxx.xxx.xxx.xxx on vnet: vmnet2 is available
...
Oct 14 14:22:49 VNL_CheckSubnetAvailability - Subnet: yyy.yyy.yyy.yyy on vnet: vmnet6 is not available
Subnet on vmnet6 is no longer available for usage, please run the network editor to reconfigure different subnet
Oct 14 14:22:50 VNL_CheckSubnetAvailability - Subnet: xxx.xxx.xxx.xxx on vnet: vmnet7 is available
Oct 14 14:22:50 VNL_CheckSubnetAvailability - Subnet: xxx.xxx.xxx.xxx on vnet: vmnet8 is available
.....

(I have replaced real addresses by xxx and yyy.) So, obviously VMware at startup performs a kind of ping check beyond the locally defined virtual devices and networks. Interesting! Why do they ping?

The answer is trivial: When you set up the (virtual) internal bridge for the host-only network you may want to guarantee that the IP-address for the respective host device (“vmnet6”) does not exist anywhere else in the reachable network – especially as the host’s interface of a host-only network may be used for a host controlled routing (and NAT) of the otherwise isolated VMware guests to the outside world.

Address overlap

And this resolved my problem: A manual ping for the address of the planned host’s interface address yyy.yyy.yyy.1 indeed gave me a result. I located the source on another server, where I sometimes perform tests of different virtual network configurations with KVM guests, LXC containers and libvirt. Unfortunately, I had not disabled all of my test networks after my last tests. Due to default DHCP-settings a virtual interface with address yyy.yyy.yyy.1 got established on the test server whenever it was booted. This also explained the finding that the VMware WS problem did not occur always – it only happened when the test server was active in my physical LAN!

Then I actually remembered that I had had a similar problem once in 2016, whilst experimenting with QEMU/VMware-bridge-coupling. (See: Opensuse/Linux – KVM, VMware WS – virtuelle Brücken zwischen den Welten). So, I should have known better and planned my “local” virtual experiments a bit more carefully to avoid address overlaps with other potential virtual networks on different hosts in the LAN.

Stupid me … The VMware WS startup script was absolutely right to not establish a second address
of that kind on my workstation! This lead to the error message “Virtual ethernet failed” – which in my opinion should include a bit more detailed information or a hint to a log-file. But the fault clearly was on my side: One should not think in terms of a local host environment when using VMware WS for virtual networks, but consider the global network configuration.

Still, the whole VMware handling of a possible IP address overlap left me a bit puzzled :

Why can you by saving the questionable virtual network again establish a host interface despite the fact that another interface with the same address is running somewhere in the network? OK, you are root when you do it – but why is no warning given at this point? (VMware could do a ping check there, too …. )

A second question also worried me: Why did the existence of two devices with the same IP-address did not lead to more chaos in the network? One reason probably was that I had allowed pinging but no general TCP-transport to the virtual device on the test server. And explicit routes were otherwise defined properly on the different hosts. However, I could bet on some problems on the ARP-level when the test server was up and running. Anyway – such a basic misconfiguration in a a network may lead to security holes, too, and should, of course, be avoided.

A third question that came up for a second was: How do you avoid overlaps in case one wants to assign KVM/QEMU-guests and VMware guests IP addresses within the same network address space on one and the same virtualization host? Such a scenario is not at all as far fetched as it may seem at first sight. One reason for such a configuration could be the EU GDPR (DSGVO):

If you need to guarantee a customer confidentiality and are nevertheless forced to use a standard MS Windows client, you have a problem as MS may in an uncontrollable way transfer data to their own servers (outside the EU). Just read the license and maintenance agreements you sign with the operation of a standard Win 10 client! Therefore, you may want to isolate such clients drastically and only allow for communication with certain IP-addresses on the Internet (and NOT with MS servers). You may allow communication with some (virtualized) Linux machines in the same sub-network and one of them may serve as a gateway and perimeter firewall with strict filters. You can build up such scenarios by coupling a QEMU-virtual bridge to a VMware virtual bridge. At the same time, however, you need full control over the DHCP-systems on both sides (besides a bit of scripting) to avoid address overlaps. But this is actually easy: the DHCP-control files on the VMware side are found under the directory “/etc/vmware/vmnetX/dhcpd”, with “X” standing for a virtual VMware interface number. On the QEMU side you find the files at “/etc/libvirt/qemu/networks”. There you can control your IP assignments (or even no assignments for some special interfaces). Ok, but this is the beginning of another story.

Conclusion

Never think “local” or host based when working with virtual networks! Always include local virtual test networks in your documentation of your global network landscape! An do not always just accept the standard address assignment for host interfaces to virtual networks without thinking.