Häufig gestellte Fragen
Vor wie vielen Kernel-Schwachstellen schützt VED heute? Welche Kernel-Versionen werden von VED unterstützt?
Der Linux-Kernel hat jedes Jahr ungefähr 120 öffentliche Schwachstellen (mit CVE-Nummer). Die Verringerung der Speicherbeschädigung kann in 3 separaten Phasen erfolgen: Phase vor der Ausbeutung, Nutzungsphase und Phase nach der Ausbeutung. VED konzentriert sich stark auf die späteren beiden und kann nichts gegen die Pre-Exploitation-Phase tun. Wir haben viele Exploit-Techniken in einer großen Anzahl von Schwachstellen von MITREs CVE + Ubuntu Security Tracker + Public PoC bewertet. Unser Bewertungsverhältnis ist größer als das des öffentlichen PoC / Exploit, aber geringer als das von Ubuntu Security Tracker. Die aktuelle Mainline-Entwicklung und das Testen von VED basieren auf dem Linux-Kernel v4.19 und v5.15. Einige Benutzer führen VED immer noch auf CentOS 7.x (v3.10) aus.
Was ist, wenn eine neue Exploit-Technik/ein neuer Exploit-Vektor entsteht?
Wir entwickeln weiterhin Schutzfunktionen gegen neue Angriffsmethoden.
Kann VED den Container entkommen?
Ja, wenn der Angreifer einen Container als Stützpunkt verwendet und versucht, die Kontrolle über den Host zu übernehmen, indem er den Angriff auf den Linux-Kernel startet, z.B.: CVE-2021-22555.
Wie viel Performance-Hit hat VED?
VED hat weniger als 1% der Auswirkungen auf die Leistung in kleinen PLT-Tests (CPU-intensiv), während die Auswirkungen im E/A-intensiven Szenario mehr als 30% betragen könnten.
VED wird als LKM (Linux Kernel Module) geladen, muss jede Kernel-Version den VED erstellen?
Ja.
Welchen Hakenmechanismus verwendet VED? Hat es ein Kompatibilitätsproblem mit LSM?
VED verwendet kprobe/ftrace, um den Hook-Mechanismus zu implementieren. Debian aktiviert AppArmor standardmäßig und CentOS aktiviert standardmäßig SELinux. VED funktioniert perfekt mit Debian und CentOS. VED bietet eine voll funktionsfähige LKM-Version und eine eBPF-Version für Cloud-native Auditing-Zwecke, von denen letztere nicht über einen Hook implementiert werden muss.
Welche Hardware-Architekturen werden von VED unterstützt?
x86_64 und arm64. Arm64 wird nur auf AWS Gratiton2 (armv8.2) und Raspberry 4 (armv8.0) verwendet.
Was ist ein typisches Szenario, in dem VED eingreifen kann?
Aus Sicht der Risikobewertung 1) Die Container in einer Cloud-nativen Umgebung teilen sich den Linux-Kernel, in dem die Container-Flucht zur Kompromittierung des gesamten Clusters führt. 2) Linux-Kernel, die auf Infotainment und T-Box (AUTOSAR AP) laufen, sind großen Risiken durch den unabhängigen SoC ausgesetzt, z.B.: WiFi und Bluetooth. Es gibt einige Assets, die wichtiger sind als andere, z. B.: 1) SSO-basierte Zero-Trust-Lösung (Single Sign-On). 2) Steuern Sie Knoten in der Cloud-Umgebung wie Kubernetes-Master-Knoten, OpenStack Nova-Scheduler usw. 3) Schlüsselverwaltungsserver, z. B. Knoten, die AKs (Access Keys) generieren und verteilen, Identitätsdienstknoten (Keystone) in OpenStack-Clustern usw.
VED verwendet einen Open-Source-Code eines Drittanbieters, und der Linux-Kernel selbst folgt der GPL-Lizenz, wird das aktuelle Open-Source-Abonnementmodell die GPL-Konformität verletzen?
VED verwendet das gleiche Open-Source-Abonnementmodell wie SuSE, RedHat und PaX / GRsecurity, dh HardenedVault unterzeichnet eine Open-Source-Abonnementvereinbarung mit dem Kunden, von der einige Folgendes umfassen: 1) HardenedVault teilt den VED-Code mit Kunden 2) HardenedVault beendet den Dienst, wenn der Kunde gegen die Vereinbarung verstößt. Aber der Quellcode, den der Kunde erhalten hat, ist immer noch GPL.
Sind alle HardenedVault-Produkte und -Lösungen zu den gleichen Bedingungen wie VED?
Open-Source-Abonnementbedingungen sind ähnlich, aber nicht alle Produkte basieren auf der GPL, wie VaultFuzzer, das auf der Apache-Lizenz 2.0 basiert.