User Tools

Site Tools


linux:apps:kvm:kvm-hardening

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
linux:apps:kvm:kvm-hardening [2026/09/13 13:24] – [Network containing] oscarlinux:apps:kvm:kvm-hardening [2026/09/16 16:31] (current) – [Network containing] oscar
Line 56: Line 56:
 ``` ```
 #### Step 2: Create a Libvirt hook script #### Step 2: Create a Libvirt hook script
-Libvirt can execute scripts when VMs start. We will use a qemu hook to isolate the traffic. +Libvirt can execute scripts when VMs start. We will use a qemu hook to isolate the traffic. Open a terminal on your host and create the hook directory if it does not exist.
- +
-Open a terminal on your host and create the hook directory if it does not exist.+
  
 ``` ```
-# mkdir -p /etc/libvirt/hooks+# mkdir -p /etc/libvirt/hooks/qemu.d
 ``` ```
 Create and edit the hook file and paste the following script (replace vnet0 and 192.168.122.1 with your actual interface and allowed gateway): Create and edit the hook file and paste the following script (replace vnet0 and 192.168.122.1 with your actual interface and allowed gateway):
  
 ```    ```   
-# nano /etc/libvirt/hooks/qemu +# nano /etc/libvirt/hooks/qemu.d/vm-gateway-only-access 
-------------------------------+-------------------------------------------------------
  
 #!/bin/bash #!/bin/bash
  
-VM_NAME="Your-VM-Name" +set -euo pipefail 
-INTERFACE="vnet0" + 
-ALLOWED_GATEWAY="192.168.122.1"+NFT="/usr/sbin/nft" 
 +VM_NAME="$1" 
 +VM_MAC=$(/usr/bin/virsh domiflist "$1" | awk '/:[0-9a-fA-F]/ {print $5}') 
 +LIBVIRT_BRIDGE="virbr0" 
 +HOST_INTERFACE="enp2s0" 
 +BLOCKED_IPV4_RANGES="{ 192.168.0.0/16 }" 
 +BLOCKED_IPV6_RANGES="{ 2001:1c00:2e07:fa0a::/64, fdaa:66:67::/48 }" 
 +TABLE="vm_filter" 
 +CHAIN="vm_${VM_NAME//[^a-zA-Z0-9_]/_}" 
 + 
 +install_rules() 
 +{ 
 +    "$NFT" delete table inet "$TABLE" 2>/dev/null || true 
 +    "$NFT" add table inet "$TABLE" 
 +    "$NFT" add chain inet "$TABLE" "$CHAIN" '{ type filter hook forward priority -300; policy accept; }' 
 + 
 +    # Allow established and related return traffic 
 +    "$NFT" add rule inet "$TABLE" "$CHAIN" ct state established,related accept 
 + 
 +    # Allow only VM -> 192.168.178.1 
 +     "$NFT" add rule inet "$TABLE" "$CHAIN" ether saddr "$VM_MAC" ip daddr "$BLOCKED_IPV4_RANGES" drop 
 +     "$NFT" add rule inet "$TABLE" "$CHAIN" ether saddr "$VM_MAC" ip6 daddr "$BLOCKED_IPV6_RANGES" drop 
 + 
 +    # ALLOW remaining traffic from the VM out to the internet via enp2s0 
 +    "$NFT" add rule inet "$TABLE" "$CHAIN" ether saddr "$VM_MAC" oifname "$HOST_INTERFACE" accept 
 +} 
 + 
 +remove_rules() 
 +{ 
 +    "$NFT" delete table inet "$TABLE" 2>/dev/null || true 
 +} 
 + 
 +case "${2:-}" in 
 +    start) 
 +        [[ "$1" == "$VM_NAME" ]] && install_rules 
 +        ;; 
 + 
 +    stopped) 
 +        [[ "$1" == "$VM_NAME" ]] && remove_rules 
 +        ;; 
 +esac 
 + 
 +exit 0
  
-OBJECT=$1 
-OPERATION=$2 
-if [ "$OBJECT" = "$VM_NAME" ]; then 
-    if [ "$OPERATION" = "started" ] || [ "$OPERATION" = "start" ]; then 
-        # 1. Allow traffic to the specific gateway IP 
-        iptables -I FORWARD -m physdev --physdev-in $INTERFACE -d $ALLOWED_GATEWAY -j ACCEPT 
-        iptables -I FORWARD -m physdev --physdev-out $INTERFACE -s $ALLOWED_GATEWAY -j ACCEPT 
-         
-        # 2. Drop all other traffic from this interface 
-        iptables -A FORWARD -m physdev --physdev-in $INTERFACE -j DROP 
-        iptables -A FORWARD -m physdev --physdev-out $INTERFACE -j DROP 
-    fifi 
 ``` ```
  
Line 101: Line 129:
 Now, every time you start this specific VM, the host firewall will block all network traffic unless it is explicitly sent to or from your chosen gateway IP. Now, every time you start this specific VM, the host firewall will block all network traffic unless it is explicitly sent to or from your chosen gateway IP.
 If you are using nftables instead of iptables, or if you need help finding the exact subnet/gateway IP of your virt-manager network, let me know! If you are using nftables instead of iptables, or if you need help finding the exact subnet/gateway IP of your virt-manager network, let me know!
 +
 +Check if the firewall settings are created and removed with:
 +  # nft list ruleset
 +The firewall settings will look something like:
 +```
 +table inet vm_filter {
 + chain vm_Debian13_ESP {
 + type filter hook forward priority raw; policy accept;
 + ct state established,related accept
 + ether saddr 51:44:60:7e:d3:fe ip daddr 192.168.0.0/16 drop
 + ether saddr 51:44:60:7e:d3:fe ip6 daddr { 2001:1c00:2e07:fa0a::/64, fdaa:66:67::/48 } drop
 + ether saddr 51:44:60:7e:d3:fe oifname "enp2s0" accept
 + }
 +}
 +```
 +
 +## Kernel Samepage Merging (KSM)
 +In Linux, KSM (Kernel Samepage Merging) is a feature that scans your system's RAM looking for identical memory pages. When it finds matching pages, it merges them into a single, shared page using a mechanism called Copy-on-Write (CoW)
 +
 +  * The ksm service controls the actual raw kernel thread (ksmd) that does the heavy lifting.
 +  * The ksmtuned service is a user-space daemon. It actively watches your system and dynamically adjusts the tuning parameters of the kernel thread (like how fast it scans memory) based on how many QEMU/KVM instances are currently running.
 +
 +#### The Security Risk: Side-Channel Attacks
 +While KSM is great for saving RAM on high-density servers, it introduces a major security flaw called a Memory Side-Channel / Cache-Leak Attack. [1, 2] 
 +Because memory pages are shared between the host and the guest, a malicious process inside your Debian guest can perform precise timing measurements on memory access. By deliberately modifying a page and measuring how long it takes to process, the guest can figure out if that same data exists elsewhere in the host system's RAM. This can allow an attacker to bypass virtualization barriers and leak sensitive host data (like cryptographic keys or passwords). [2, 5] 
 +
 +Even if you only run a single Debian guest, KSM can still merge identical pages between your one guest and the Debian host operating system. If ksmtuned kicks in and starts aggressive page merging, the side-channel attack vector remains open between your isolated guest and your underlying hypervisor.
 +
 +#### Check if KSM is running
 +To check if ksmtuned and the underlying Kernel Samepage Merging (KSM) engine are active on your Debian Trixie host, run these diagnostic commands:
 +  systemctl status ksmtuned ksm
 +
 +What to look for: If it says Active: active (running), it is active. If it says Active: inactive (dead) or loaded (...; masked), it is successfully disabled.
 +
 +#### How to completely disable KSM
 +To ensure no memory deduplication happens at all, you should permanently stop and disable both the tuning daemon and the kernel driver: [5] 
 +
 +   1. Stop and mask the services so they can never be started by other system triggers:
 +   
 +   sudo systemctl disable --now ksm ksmtuned
 +   sudo systemctl mask ksm ksmtuned
 +   
 +   2. Force the kernel to instantly unshare any pages it has already merged:
 +   
 +   echo 2 | sudo tee /sys/kernel/mm/ksm/run
 +   
 +(Setting this to 2 completely disables the engine and forces the kernel to unmerge everything immediately. Setting it to 0 only stops it from scanning new pages). [2, 5] 
  
  
linux/apps/kvm/kvm-hardening.1789305845.txt.gz · Last modified: by oscar