[gelöst]] Am I gehacked?

[clue]

Meine Kiste hängt von Zeit zu Zeit beim Hoch- oder Runterfahren. Damit habe ich mich inzwischen abgefunden. Was mich aber stutzig werden ließ, ist die folgende Meldung beim reboot-Versuch (vorletzte Zeile):



Ich habe kein KVM installiert. Ich hatte einmal spaßeshalber virtualbox ausprobiert und danach wieder gepurged. Davon sollte also nichts mehr übrig sein. Jetzt die Preisfrage: [/Paranoiamodus AN]Ist das normal, dass ich in einer KVM laufe, oder wurde ich von einem Buchstaben-Verbrecher-Verein gehackt und merke gar nicht, dass ich die ganze Zeit in einer VM ausgespäht werde? [/Paranoiamodus AUS]

Also wie kommt da bitte eine VM hin?

[smutbert]

Virtualbox hat doch mit kvm gar nichts am Hut? aber ich würde einfach einmal installierten Paketen suchen, bzw. nach Paketen mit übriggebliebenen Konfigurationsdateien

Code: Alles auswählen

$ dpkg -l '*virtualbox*'
$ dpkg -l '*kvm*'
$ dpkg -l '*libvirtd*'

wäre das was mir einfällt.

[Cae]

Die Meldung stammt aus virt/kvm/kvm_main.c:2786:kvm_reboot(), der sichtbare Kontrollfluss waere dann

Code: Alles auswählen

2777 static int kvm_reboot()
2786         printk(KERN_INFO "kvm: exiting hardware virtualization\n");
...
2792 static struct notifier_block kvm_reboot_notifier = {
2793         .notifier_call = kvm_reboot,
...
3269 void kvm_exit(void)
3276         unregister_reboot_notifier(&kvm_reboot_notifier);
3284 EXPORT_SYMBOL_GPL(kvm_exit);

Die Datei ist kommentiert mit

Code: Alles auswählen

   4  * This module enables machines with Intel VT-x extensions to run virtual
   5  * machines without emulation or binary translation.

-- ich gehe stark davon aus, dass es sich um die Moeglichkeit handelt, VMs zu unterstuetzen. Nicht andersrum, indem der Kernel in einer KVM-beschleunigten Umgebung laeuft. Zumal dieser Kernel nicht direkt wissen kann, dass da KVM fuer Hardwarebeschleunigung sorgt; normalerweise sind da die Qemu-Eintrage (der eigentliche Emulator) im lspci oder den CPU-Flags (weniger aussagekraeftig) verraeterischer.

Gruss Cae

[NAB]

kvm ist ein Kernelmodul, das als "Dienstleistung" Hardwarevirtualisierung anbietet. Und wenn das Modul entladen wird, dann wird diese Hardwarevirtualisierung halt beendet. Das bedeutet nicht, dass sie auch genutzt wird.

Solange es um kvm geht, kann der Kernel aber durchaus erkennen, ob er in einer VM läuft. kvm hat ja keinen Grund, sich zu verstecken, und der Kernel hat Unterstützung für virtualisierte Umgebungen eingebaut. Früh beim Booten müsste bei dir die Meldung "Booting paravirtualized kernel on bare hardware" auftauchen, dann ist dein Kernel der Meinung, dass er direkt auf der Hardware läuft.

[r4pt0r]

Einfache Methode:

Code: Alles auswählen

# lscpu | grep 'Model name'
Model name:            Common KVM processor

Auch lshw gibt überall entsprechende Hinweise auf eine VM-Umgebung, egal ob KVM/Qemu, Virtualbox, Xen, VMware oder was auch immer zum Einsatz kommt.

[towo]

Einfache Methode:

Code: Alles auswählen

# lscpu | grep 'Model name'
Model name:            Common KVM processor

Auch lshw gibt überall entsprechende Hinweise auf eine VM-Umgebung, egal ob KVM/Qemu, Virtualbox, Xen, VMware oder was auch immer zum Einsatz kommt.

Oha, das funktioniert ja so nun nicht wirklich.

[r4pt0r]

Lässt sich in Qemu mittlerweile die Host-CPU an den Gast abbilden? Wäre mir wirklich neu - in sämtlichen KVM-Gästen hab ich bisher immer nur KVM- oder ggf QEMU-"Prozessoren" gesehen...

Allerdings sollten trotzdem in der lshw-Ausgabe diverse Controller hinweise auf die verwendete Virtualisierung geben.

[towo]

Das geht bei kvm doch schon ewig, -cpu host

[catdog2]

Lässt sich in Qemu mittlerweile die Host-CPU an den Gast abbilden? Wäre mir wirklich neu - in sämtlichen KVM-Gästen hab ich bisher immer nur KVM- oder ggf QEMU-"Prozessoren" gesehen...

Klar praktisch schon immer mit -cpu host

Code: Alles auswählen

qemu-system-x86_64 -cpu help
...
x86             host  KVM processor with all supported host features (only available in KVM mode)
...

[rendegast]

Wenn die Virtualisierung bösartig und gut gemacht ist,
sollte das System sie nicht oder schwer feststellen können.
Sowas wie Durchreichen aller Geräte mit Abgreifoption.

[clue]

Virtualbox hat doch mit kvm gar nichts am Hut? aber ich würde einfach einmal installierten Paketen suchen, bzw. nach Paketen mit übriggebliebenen Konfigurationsdateien

Code: Alles auswählen

$ dpkg -l '*virtualbox*'
$ dpkg -l '*kvm*'
$ dpkg -l '*libvirtd*'

wäre das was mir einfällt.

Also ich hab jetzt bei mir nachgeschaut mit folgenden Ergebnissen:

Code: Alles auswählen

dpkg -l '*virtualbox*'
dpkg-query: Kein Paket gefunden, das auf *virtualbox* passt

dpkg -l '*kvm*'
dpkg-query: Kein Paket gefunden, das auf *kvm* passt

dpkg -l '*libvirtd*'
dpkg-query: Kein Paket gefunden, das auf *libvirtd* pass

Die Meldung stammt aus virt/kvm/kvm_main.c:2786:kvm_reboot(), der sichtbare Kontrollfluss waere dann

Code: Alles auswählen

2777 static int kvm_reboot()
2786         printk(KERN_INFO "kvm: exiting hardware virtualization\n");
...
2792 static struct notifier_block kvm_reboot_notifier = {
2793         .notifier_call = kvm_reboot,
...
3269 void kvm_exit(void)
3276         unregister_reboot_notifier(&kvm_reboot_notifier);
3284 EXPORT_SYMBOL_GPL(kvm_exit);

Die Datei ist kommentiert mit

Code: Alles auswählen

   4  * This module enables machines with Intel VT-x extensions to run virtual
   5  * machines without emulation or binary translation.

-- ich gehe stark davon aus, dass es sich um die Moeglichkeit handelt, VMs zu unterstuetzen. Nicht andersrum, indem der Kernel in einer KVM-beschleunigten Umgebung laeuft. Zumal dieser Kernel nicht direkt wissen kann, dass da KVM fuer Hardwarebeschleunigung sorgt; normalerweise sind da die Qemu-Eintrage (der eigentliche Emulator) im lspci oder den CPU-Flags (weniger aussagekraeftig) verraeterischer.

Gruss Cae

Daraus werde ich jetzt nicht schlau. Heißt das, auf jeder Maschine läuft KVM oder ist lediglich KVM support vorhanden?

Einfache Methode:

Code: Alles auswählen

# lscpu | grep 'Model name'
Model name:            Common KVM processor

Auch lshw gibt überall entsprechende Hinweise auf eine VM-Umgebung, egal ob KVM/Qemu, Virtualbox, Xen, VMware oder was auch immer zum Einsatz kommt.

Also meine CPU ist:

Code: Alles auswählen

lscpu | grep 'Model name'
Model name:            AMD A10-5750M APU with Radeon(tm) HD Graphics

Ich habe also einen AMD, der wahrscheinlich aber Virtualisierung beherrscht, nur eben nicht nach Intel-Art.

kvm ist ein Kernelmodul, das als "Dienstleistung" Hardwarevirtualisierung anbietet. Und wenn das Modul entladen wird, dann wird diese Hardwarevirtualisierung halt beendet. Das bedeutet nicht, dass sie auch genutzt wird.

Also läuft KVM dann auch bei Euch? Wo oder wie könnte man das denn nachprüfen?

Solange es um kvm geht, kann der Kernel aber durchaus erkennen, ob er in einer VM läuft. kvm hat ja keinen Grund, sich zu verstecken, und der Kernel hat Unterstützung für virtualisierte Umgebungen eingebaut. Früh beim Booten müsste bei dir die Meldung "Booting paravirtualized kernel on bare hardware" auftauchen, dann ist dein Kernel der Meinung, dass er direkt auf der Hardware läuft.

Diese Meldung erhalte ich nicht. Also kann ich jetzt daraus schließen, dass KVM bei ALLEN Rechnern vorhanden ist, aber nicht zwangsläufig auch läuft? Tut mir Leid, wenn ich jetzt nochmals Frage: Können wir irgendwie überprüfen ob unsere Systeme nicht alle längst in einer VM laufen und munter Daten abgesaugt werden?

[rendegast]

$ /sbin/modinfo kvm_amd kvm_intel
filename: /lib/modules/4.3.0-0.bpo.1-amd64/kernel/arch/x86/kvm/kvm-amd.ko
license: GPL
author: Qumranet
alias: cpu:type:x86,ven*fam*mod*:feature:*00C2*
depends: kvm
intree: Y
vermagic: 4.3.0-0.bpo.1-amd64 SMP mod_unload modversions
parm: npt:int
parm: nested:int

filename: /lib/modules/4.3.0-0.bpo.1-amd64/kernel/arch/x86/kvm/kvm-intel.ko
license: GPL
author: Qumranet
alias: cpu:type:x86,ven*fam*mod*:feature:*0085*
depends: kvm
intree: Y
vermagic: 4.3.0-0.bpo.1-amd64 SMP mod_unload modversions
...

findet udev(?) obige cpu-Feature, so werden die entsprechenden Module geladen.
Damit stehen sie dem System zur Verfügung.
Die Module geben beim Laden/Entladen entsprechende Meldungen.

[clue]

$ /sbin/modinfo kvm_amd kvm_intel
filename: /lib/modules/4.3.0-0.bpo.1-amd64/kernel/arch/x86/kvm/kvm-amd.ko
license: GPL
author: Qumranet
alias: cpu:type:x86,ven*fam*mod*:feature:*00C2*
depends: kvm
intree: Y
vermagic: 4.3.0-0.bpo.1-amd64 SMP mod_unload modversions
parm: npt:int
parm: nested:int

filename: /lib/modules/4.3.0-0.bpo.1-amd64/kernel/arch/x86/kvm/kvm-intel.ko
license: GPL
author: Qumranet
alias: cpu:type:x86,ven*fam*mod*:feature:*0085*
depends: kvm
intree: Y
vermagic: 4.3.0-0.bpo.1-amd64 SMP mod_unload modversions
...

findet udev(?) obige cpu-Feature, so werden die entsprechenden Module geladen.
Damit stehen sie dem System zur Verfügung.
Die Module geben beim Laden/Entladen entsprechende Meldungen.

Also da mein output genau so wie Deiner aussieht, gehe ich davon aus, dass auch bei Dir KVM bereitgestellt wird und eventuell auch geladen wird. Daher schließe ich daraus, dass es sich um einen normalen Vorgang handelt und hoffe, damit werden Angreifern (wie den Geheimverbrechern) Tür und Tor nicht geöffnet.

[rendegast]

Zum Modul gehört die Schnittstelle

Code: Alles auswählen

$ ll /dev/kvm
crw-rw----+ 1 root kvm 10, 232 Mär  7 20:44 /dev/kvm

root und Gruppe kvm dürfen darauf zugreifen.

Das "+" steht für erweiterte Rechte / ACL, in einem xterm:

Code: Alles auswählen

$ whoami
meinuser
$ getfacl /dev/kvm
getfacl: Entferne führende '/' von absoluten Pfadnamen
# file: dev/kvm
# owner: root
# group: kvm
user::rw-
user:meinuser:rw-
group::rw-
mask::rw-
other::---

Es wird meinuser (in Gruppe kvm) angezeigt.
In einer anderen X-Session eines anderen kvm-Benutzers steht dann dieser.
In einer reinen Konsolensitzung wird gar kein Benutzername ausgegeben,
weder unter root noch einem kvm-Benutzer.

Sicherheitsmaßnahme wäre also, daß ein kvm-berechtigter Benutzer zBsp. nicht surft.
Und ein surfender Benutzer nicht in Gruppe kvm aufgenommen wird.



Hier haben solche ACL auch Sound-, Video- und cdrom-Devices:

Code: Alles auswählen

find /dev ! -type d -exec ls -l "{}" \; | awk '$1~/\+$/'

('find -ls' zeigt das "+" nicht an)

Also da mein output genau so wie Deiner aussieht,

Das liegt wohl daran, daß Du den identischen kernel mit identischen Modulen benutzt.
Ich frage da ja nur das Modul ab.

Wenn Du nicht willst, daß die Schnittstelle zur Verfügung steht,
so entlade kvm_amd/kvm_intel und kvm und setze die Module auf die blacklist, zBsp.:
/etc/modprobe.d/00_kein-kvm.conf

Code: Alles auswählen

blacklist kvm
blacklist kvm_amd
blacklist kvm_intel

und noch abschließend die initrd: 'update-initramfs -u -kall'.

Ausblick:
Sollen Modulen Optionen mitgegeben werden 'options modul ... ... ...',
die explizide debian-Vorgaben überschreiben sollen,
so empfehle ich ein Schema
/etc/modprobe.d/00_modul-option.conf
/etc/modprobe.d/zz_modul-option.conf -> 00_modul-option.conf
Dadurch werden debians Optionen beim Laden vorn und hinten eingeschlossen,
denn debians Datein kommen normalerweise mit klein-alphabetschem Namen
und die Dateiliste wird ls-artig abgearbeitet.
Die für das Modul vorgesehenen Optionen gelten dann im first- wie im last-Strike-Prinzip.

[clue]

Puh, das war erstmal Viel auf einmal. Ein dickes Dankeschön an Dich dafür