KVM: Wenig Entropie in Guests | Virtualisierter Hardware RNG

Ich habe bei der Diagnose bezüglich langsamen TLS/SSL Verbindungen festgestellt, dass die verfügbare Entropie meiner KVM Guests sehr gering war. Der Wert Betrug ungefähr 150 – 190.
Nach dem Start eines Guests konnte ich sehen, wie der Pool nur sehr langsam gefüllt wurde. Dabei ist es eigentlich kein Wunder, dass die Werte bei KVM Guests ziemlich gering ist: Die Maschinen haben im Vergleich zu physischen Servern fast keine Last oder Hardware, die gute Zufallszahlen zulassen würden.

Exkurs: Entropie und Linux

Linux hat einen Entropie-Pool, der stets mit „qualitativ hochwertige“ Zufallszahlen gefüllt sein sollte. Diesen Pool kann man via den beiden Device Files

  • /dev/random (blocking) und
  • /dev/urandom (non-blocking)

anzapfen.

Jedes Programm, das Zufallszahlen braucht, benutzt sich im Normalfall aus einem der beiden Files. Stark beansprucht wird der Entropie Pool, wenn zum Beispiel mit Kryptographie gearbeitet wird (TLS-Verbindungen, Schlüsselpaare erzeugen, usw). Read More „KVM: Wenig Entropie in Guests | Virtualisierter Hardware RNG“

pfSense: AES-NI Hardware Crypto Acceleration in KVM

Wie schon des öfteren erwähnt nutze ich in meinem Heimnetzwerk eine pfSense Firewall in einer KVM Maschine. Ich möchte mein Netzwerk in Regensburg mit dem bei meinen Großeltern zusammenschalten via einem Site-To-Site OpenVPN Konstrukt. Dazu habe ich mir die PcEngines APU.1D4 gekauft. Ein Test im lokalem Gigabit Netzwerk war aber wenig erfreulich. Die Geschwindigkeit reichte gerade so für einen HD Stream aus.
Ich hatte zuerst die vergleichsweise schwache CPU in der APU.1D4 in Verdacht, der die „moderne“ Crypto zu schaffen machen. Es stellte sich aber schnell heraus, dass diese sich nahezu langweilt und fast keine CPU Zeit verbraucht wird.

Kein durchreichen von Hardwarefeatures

Der Flaschenhals war tatsächlich auf meinem Hostsystem zu finden: Es war die CPU Einstellung des KVM Hypervisors auf meinem Hostsystem.
Damit möglichst wenig Overhead für das Vortäuschen von Hardware verwendet wird nutze ich Standard Komponenten wie die VirtIO Treiber oder die QEMU CPU. Diese unterstützt aber nicht das Durchreichen von Hardwarefeatures wie AES-NI, obwohl der Intel Core i5-4440 meines Hostsystems AES-NI hat.
Als einzige Ausnahme verwende ich als CPU für meine Firewall den Typ „Sandy Bridge“, was letzendlich einen Intel Xeon E3 Prozessor emuliert. Read More „pfSense: AES-NI Hardware Crypto Acceleration in KVM“

Linux Bridge leitet kein IPv6/ICMPv6 weiter

Zu Hause habe ich auf meinem Homeserver eine virtuelle Maschine auf der Icinga 2 läuft. Diese generiert sich anhand der MAC Adresse der virtuellen Netzwerkkarte eine Link-local-IPv6 Adresse und mit Hilfe der Router Advertisements der pfSense Firewall via SLAAC (Stateless Address Autoconfiguration) eine öffentliche IPv6 Adresse.

Nach dem Booten der Maschine funktioniert alles. Ein paar Checks, die IPv6 benötigen und an meinen Root-Server gehen werden sauber abgearbeitet. Nach einiger Zeit oder einem Prefix-Wechsel werden alle Checks plötzlich rot. Das Problem: Die Kommunikation über IPv6 ist nicht mehr möglich. Nur ein Neustart schein zu helfen.

Einschub: IPv6 tracen mit tcpdump

Meine virtuellen Server zu Hause sind alle ohne graphische Oberfläche. Wiresark ist also nicht installiert, aber tcpdump. Mit tcpdump kann man natürlich genauso arbeiten und reicht für die ersten Schritte aus. Ein Filter für die komplette IPv6 Kommunikation ist ip6. Will man sich nur auf ICMPv6 beschränken ist der Filter icmp6.

Kleines Beispiel, bei der ich ein Bridge Interface belausche:

root@home:~# tcpdump -i br1 -n icmp6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br1, link-type EN10MB (Ethernet), capture size 262144 bytes
12:53:24.174761 IP6 fe80::1:1 > ff02::1: ICMP6, router advertisement, length 88
12:53:30.076520 IP6 fe80::1:1 > fe80::eacc:18ff:fe7e:4f48: ICMP6, neighbor solicitation, who has fe80::eacc:18ff:fe7e:4f48, length 32
12:53:30.076959 IP6 fe80::eacc:18ff:fe7e:4f48 > fe80::1:1: ICMP6, neighbor advertisement, tgt is fe80::eacc:18ff:fe7e:4f48, length 24
12:53:32.090583 IP6 fe80::5054:ff:fe7c:5045 > fe80::1:1: ICMP6, neighbor solicitation, who has fe80::1:1, length 32
12:53:32.090808 IP6 fe80::1:1 > fe80::5054:ff:fe7c:5045: ICMP6, neighbor advertisement, tgt is fe80::1:1, length 24

Ein genauerer Blick ins Paket ist auf dem Terminal unübersichtlich. Man kann aber die Ausgabe von tcpdump zum Beispiel über einen SSH Tunnel in Wireshark pipen. Beispiel:

:~$ ssh root@home tcpdump -i br1 -U -s0 -w - icmp6 | wireshark -k -i -

Happy debugging :-) Read More „Linux Bridge leitet kein IPv6/ICMPv6 weiter“