9.3.1 Virtual Machine Security

Virtual Machine (VM) Security mencakup praktik, tools, dan kebijakan untuk melindungi instance komputasi cloud dari ancaman siber. VM adalah salah satu attack surface terbesar di lingkungan cloud karena langsung terekspos ke internet, menjalankan aplikasi produksi, dan sering menjadi target utama penyerang.

Hardening VM (OS Baseline & CIS Benchmarks)

Hardening adalah proses mengamankan OS dengan mengurangi permukaan serangan. Standar industri yang paling banyak digunakan adalah CIS (Center for Internet Security) Benchmarks.

OS Baseline

Setiap VM harus dimulai dari OS baseline yang sudah di-hardening:

# Contoh: Mematikan layanan yang tidak perlu di Linux
systemctl disable --now avahi-daemon
systemctl disable --now cups
systemctl disable --now rpcbind
systemctl disable --now bluetooth

CIS Benchmark Linux menyediakan ~200+ rekomendasi yang mencakup:

• Filesystem configuration: mount /tmp dengan nodev,noexec,nosuid
• Kernel hardening: konfigurasi sysctl untuk mencegah IP spoofing, smurf attack
• SSH hardening: disable root login, gunakan key-based auth, set MaxAuthTries=3
• Audit logging: aktifkan auditd untuk log semua aktivitas sistem
• PAM (Pluggable Authentication Modules): konfigurasi password complexity dan lockout policy

Contoh mount /tmp yang aman di /etc/fstab:

/dev/xvdf1  /tmp  ext4  defaults,noexec,nosuid,nodev  0  0

Tools Hardening Otomatis

Lynis - security audit tool open-source:

# Install dan jalankan audit
sudo apt install lynis -y
sudo lynis audit system --logfile /var/log/lynis-audit.log

CIS-CAT - alat resmi dari CIS untuk menilai kepatuhan:

# Assess terhadap CIS Benchmark
./CIS-CAT.sh -a -b benchmarks/CIS_Ubuntu_Linux_22.04_LTS_Benchmark_v2.0.0.xml

IMDS Protection (Instance Metadata Service)

Instance Metadata Service (IMDS) adalah endpoint HTTP internal di cloud provider yang menyediakan informasi tentang instance VM - termasuk kredensial sementara (IAM role credentials), user-data, dan konfigurasi network.

Kerentanan: SSRF → IMDS

Server-Side Request Forgery (SSRF) adalah vektor serangan paling umum untuk mengeksploitasi IMDS. Ketika aplikasi web memproses URL dari user tanpa validasi, penyerang bisa mengarahkan request ke http://169.254.169.254/ dan mencuri kredensial IAM.

Eksploitasi SSRF ke IMDS:

# Jika aplikasi rentan SSRF, penyerang bisa request:
http://target-app.com/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Mendapatkan AWS credentials sementara
http://target-app.com/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/MyRole

Mitigasi: IMDSv2 di AWS

IMDSv2 menggunakan session-oriented requests yang jauh lebih aman:

# Wajibkan IMDSv2 pada EC2 instance
aws ec2 modify-instance-metadata-options \
    --instance-id i-1234567890abcdef0 \
    --http-tokens required \
    --http-endpoint enabled \
    --http-put-response-hop-limit 1

Di AWS, Anda juga bisa memblokir akses IMDS dari container atau aplikasi non-privileged dengan hop limit dan network policy.

Patch Management

Patch management di cloud harus otomatis dan terjadwal untuk mencegah kerentanan yang sudah diketahui (known exploited vulnerabilities).

AWS Systems Manager (SSM) Patch Manager

# Membuat patch baseline
aws ssm create-patch-baseline \
    --name "Ubuntu22-Production-Baseline" \
    --operating-system UBUNTU \
    --approval-rules "PatchFilterGroup=[{PatchFilters=[{Key=CLASSIFICATION,Values=[Security,Updates]},{Key=SEVERITY,Values=[Critical,Important]}]}]" \
    --approved-patches-enable-non-security

# Menggunakan Maintenance Window untuk menjadwalkan patch
aws ssm create-maintenance-window \
    --name "Monthly-Patching-Windows" \
    --schedule "cron(0 2 ? * SUN#1 *)" \
    --duration 3 \
    --cutoff 1

Azure Update Management

# Azure Policy untuk auto-patching VM
{
  "if": {
    "field": "type",
    "equals": "Microsoft.Compute/virtualMachines"
  },
  "then": {
    "effect": "deployIfNotExists",
    "details": {
      "type": "Microsoft.Automation/automationAccounts/softwareUpdateConfigurations",
      "roleDefinitionIds": ["/providers/microsoft.authorization/roleDefinitions/..."]
    }
  }
}

Best Practice - Gold AMI (Golden Image): Buat AMI baseline yang sudah di-patch dan di-hardening, deploy instance baru dari AMI tersebut, lalu terminate instance lama:

# Pipeline otomatis dengan Packer
packer build -var 'source_ami=ami-0c55b159cbfafe1f0' \
             -var 'region=ap-southeast-1' \
             -var 'ssh_username=ubuntu' \
             ubuntu-hardened.pkr.hcl

SSH Key Management vs Password Authentication

Menggunakan password untuk SSH adalah praktik berbahaya di cloud karena rawan brute force.

SSH Key Pair

# Generate key pair dengan ED25519 (lebih aman dari RSA 2048)
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/cloud-key -C "[email protected]"

# Copy public key ke VM
ssh-copy-id -i ~/.ssh/cloud-key.pub [email protected]

Konfigurasi SSH yang aman di /etc/ssh/sshd_config:

Port 2222                          # Ubah port default
PermitRootLogin no                 # Nonaktifkan root login
PasswordAuthentication no          # Hanya key-based auth
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
MaxAuthTries 3                     # Batasi percobaan
ClientAliveInterval 300            # Timeout idle 5 menit
ClientAliveCountMax 2
AllowUsers deploy admin            # Whitelist user
LogLevel VERBOSE                   # Log semua aktivitas

Session Manager (AWS SSM) - Tanpa SSH Sama Sekali

SSM Session Manager memungkinkan akses shell tanpa membuka port 22, tanpa bastion host, dan tanpa SSH key:

# Akses instance tanpa SSH
aws ssm start-session --target i-1234567890abcdef0

Semua sesi dicatat di AWS CloudTrail dan dapat di-audit.

Security Groups (Stateful Firewall)

Security Groups adalah stateful firewall di level instance. Aturan ingress dan egress diterapkan langsung ke VM.

# Security Group ketat untuk web server
aws ec2 authorize-security-group-ingress \
    --group-id sg-12345678 \
    --protocol tcp \
    --port 443 \
    --cidr 0.0.0.0/0

aws ec2 authorize-security-group-ingress \
    --group-id sg-12345678 \
    --protocol tcp \
    --port 80 \
    --cidr 0.0.0.0/0

# SSH hanya dari office IP
aws ec2 authorize-security-group-ingress \
    --group-id sg-12345678 \
    --protocol tcp \
    --port 22 \
    --cidr 203.0.113.0/24

Perbedaan Security Group vs NACL:

Dedicated Hosts & Nitro Enclaves

Dedicated Hosts

Dedicated Host memberikan VM fisik khusus untuk satu customer - memenuhi persyaratan regulasi lisensi dan compliance tertentu (misalnya, Bring Your Own License untuk Windows/ SQL Server).

# Membuat dedicated host di AWS
aws ec2 allocate-hosts \
    --instance-type m5.large \
    --availability-zone ap-southeast-1a \
    --quantity 2 \
    --auto-placement on

AWS Nitro Enclaves

Nitro Enclaves adalah lingkungan eksekusi terisolasi (trusted execution environment / TEE) yang melindungi data sensitif bahkan dari administrator instance.

# Konfigurasi Nitro Enclave CLI
enclave:
  name: "payment-processing"
  cpu_count: 2
  memory_mib: 2048
  eif_path: "/home/ec2-user/payment.eif"

Kelebihan Nitro Enclaves:

• Tidak memiliki akses persistent storage
• Tidak ada akses network langsung
• Hanya bisa berkomunikasi dengan parent instance via vsock
• Dilindungi oleh Nitro Hypervisor (hardware-level isolation)

Attack Vectors

SSRF → IMDS (Sudah dibahas di atas)

Cryptomining (Cryptojacking)

Penyerang menyusupkan script penambangan cryptocurrency ke VM yang tidak aman. Tanda-tandanya:

• CPU usage tinggi terus-menerus
• Network traffic mencurigakan ke pool mining
• File aneh seperti xmrig, minerd, atau script Python mining

Pencegahan:

• Batasi outbound traffic dengan security group (hanya ke layanan yang diperlukan)
• Gunakan GuardDuty (AWS) atau Microsoft Defender for Cloud untuk deteksi
• Monitor anomali CPU dengan CloudWatch

VM Escape

VM Escape adalah serangan di mana penyerang menembus hypervisor dan mengakses host fisik atau VM lain. Sangat jarang terjadi, namun dampaknya sangat serius.

Mitigasi utama dilakukan oleh cloud provider:

• Nitro Hypervisor (AWS) - menggunakan hardware-assisted virtualization (KVM-based)
• Hyper-V isolated (Azure)
• gVisor dan Kata Containers untuk container isolation

Catatan: VM escape membutuhkan zero-day di hypervisor. Sebagai customer, fokus Anda adalah mengamankan OS dan aplikasi - karena hampir semua insiden berasal dari misconfig, bukan hypervisor bug.

Verifikasi

# Cek konfigurasi IMDSv2
aws ec2 describe-instances --instance-id i-12345 --query 'Reservations[0].Instances[0].MetadataOptions'

# Audit CIS Benchmark dengan Lynis
sudo lynis audit system

# Cek SSH config
sudo sshd -T | grep -E "permitrootlogin|passwordauthentication|port"

Referensi

• CIS Benchmarks
• AWS IMDSv2 Documentation
• Nitro Enclaves
• Lynis Security Audit