Cloud IDS — Intrusion Detection Qua Packet Mirroring

Tại sao quan trọng trong production

Firewall rules, Cloud Armor, Cloud NGFW — tất cả đều là preventive controls: chúng block traffic trước khi đến đích. Nhưng không có preventive control nào là hoàn hảo. Zero-day exploits chưa có signature. Lateral movement dùng legitimate protocols (port 443, gRPC). Insider threat access data qua đúng permissions.

Cloud IDS fill một gap khác: detective control. Thay vì block, nó observe traffic và alert khi phát hiện anomalous patterns. Nếu malware đã vào trong VPC và đang contact C2 server, IDS sẽ detect traffic pattern đó và alert — ngay cả khi firewall rules không explicitly block destination IP.

Điều quan trọng cần hiểu ngay từ đầu: Cloud IDS là detect và alert only. Nó không block traffic. Đây là điểm phân biệt cơ bản với IPS (Intrusion Prevention System). Nếu cần prevention, phải integrate Cloud IDS với Cloud NGFW Enterprise để tạo IPS.

Internal Model — Kiến Trúc Packet Mirroring

Cơ chế fundamental: out-of-band inspection

Cloud IDS không đứng trong data path. Traffic không đi qua IDS. Thay vào đó, Cloud IDS sử dụng Google Cloud Packet Mirroring — một cơ chế trong Andromeda copy một bản của traffic và gửi đến IDS endpoint để phân tích.

VM A ─────────────────────────────────────────► VM B
       (traffic thực sự, không bị interrupt)
         │
         ▼ (mirror copy, không affect main flow)
   [Packet Mirroring Policy]
         │
         ▼
   IDS Endpoint (managed VM)
         │
         ▼
   Palo Alto Networks Analysis
         │
         ▼
   Threat Alerts → Cloud Logging

Hậu quả quan trọng: vì IDS inspect copy của traffic, không phải original:

Nếu IDS detection chậm hoặc bỏ sót, traffic thực sự đã đến đích — không có "delay" hay "retry" opportunity
IDS không thể block — nó chỉ có thể record và alert sau khi traffic đã pass
Packet Mirroring thêm overhead ở Andromeda (copy packets), nhưng không thêm latency cho main traffic path

Palo Alto Networks Technology

Cloud IDS tích hợp Palo Alto Networks threat detection engine. Google không tự build signature database mà leverage Palo Alto's technology với các capabilities:

App-ID: Palo Alto's application identification technology. App-ID identify ứng dụng bất kể port, protocol, hay evasion technique. Ví dụ:

BitTorrent traffic chạy trên port 443 → App-ID nhận diện là BitTorrent, không phải HTTPS
Custom protocol dùng port 80 → App-ID phân tích behavior pattern để identify protocol thực sự

Theo GCP documentation: App-ID detect applications "irrespective of port, protocol, evasive tactic, or encryption" với new applications being added weekly.

Vulnerability Detection: signatures identify exploitation attempts. Database cover:

Buffer overflow attempts
Format string vulnerabilities
Remote code execution attempts
Unauthorized access patterns
Known CVE exploits

Anti-Spyware: phát hiện malware-to-C2 communication:

Known C2 infrastructure domains
Behavioral patterns của C2 communication (beaconing, command execution, data exfiltration patterns)
Malware families known signatures

IDS Endpoint — Deployment Architecture

Một IDS Endpoint là zonal GCP resource trong một Google-managed VPC:

bash

gcloud ids endpoints create my-ids-endpoint \
  --network=projects/PROJECT/global/networks/my-vpc \
  --zone=us-central1-a \
  --severity=MEDIUM \
  --project=PROJECT

Quan trọng: --network là VPC network để protect, không phải network mà endpoint nằm trên. IDS Endpoint sử dụng Private Services Access (PSA) — tương tự Cloud SQL — để kết nối với Google-managed VPC của Palo Alto engine.

Khi tạo endpoint:

GCP allocate /30 IP range từ PSA subnet cho endpoint
Peering connection được tạo giữa customer VPC và Google-managed VPC
Packet Mirroring policies có thể được configure để gửi traffic đến endpoint address

Capacity: mỗi IDS Endpoint có maximum throughput 5 Gbps. Nếu traffic cần monitor vượt 5 Gbps, phải deploy nhiều endpoints.

Packet Mirroring Policy — Chọn Traffic để Inspect

IDS Endpoint nhận traffic từ Packet Mirroring policies. Mỗi policy define:

Mirrored resources: VMs, subnets, network tags để mirror
Filter: chọn lọc traffic nào cần mirror (all, ingress only, egress only)
Collector: IDS Endpoint address

bash

gcloud compute packet-mirrorings create my-pm-policy \
  --network=my-vpc \
  --region=us-central1 \
  --collector-ilb=IDS_ENDPOINT_FORWARDING_RULE \
  --mirrored-subnets=projects/PROJECT/regions/us-central1/subnetworks/my-subnet \
  --filter-dir=BOTH

Trade-off trong mirror selection: mirror toàn bộ traffic → cost cao hơn, overhead cao hơn, nhưng visibility đầy đủ. Mirror chỉ east-west traffic (VM-to-VM) → bỏ sót north-south threats nhưng giảm cost.

Alert System — Severity và Response

Severity Levels

Khi Cloud IDS phát hiện threat, nó tạo alert với severity:

CRITICAL: Immediate action required. Exploits đang xảy ra, data breach có thể đang xảy ra.
HIGH: Serious threat, investigation needed soon.
MEDIUM: Potential threat, review recommended.
LOW: Suspicious activity but low confidence.
INFORMATIONAL: Normal behavior flagged for visibility (ví dụ: common scanners)

Khi tạo IDS Endpoint, --severity flag set minimum severity mà endpoint sẽ alert. Ví dụ --severity=MEDIUM nghĩa là chỉ alert cho MEDIUM, HIGH, CRITICAL — bỏ qua LOW và INFORMATIONAL.

Trong production: bắt đầu với MEDIUM hoặc HIGH để avoid alert fatigue, sau đó điều chỉnh dựa trên false positive rate.

Alert destination

Cloud IDS alerts đi vào Cloud Logging dưới log name: projects/PROJECT/logs/ids.googleapis.com%2Fthreat

Mỗi alert log entry chứa:

json

{
  "threatName": "Eicar Test File",
  "severity": "MEDIUM",
  "category": "MALWARE",
  "sourceIpAddress": "10.0.0.5",
  "destinationIpAddress": "203.0.113.1",
  "sourcePort": 45123,
  "destinationPort": 80,
  "networkName": "projects/.../global/networks/my-vpc",
  "direction": "EGRESS"
}

Từ Cloud Logging, có thể:

Export sang Pub/Sub để trigger automated remediation
Export sang SIEM (Chronicle, Splunk) cho security investigation
Create log-based alerts trong Cloud Monitoring để page on-call

Automated Response Pattern

Cloud IDS chỉ detect, nhưng với Pub/Sub integration, có thể build automated response:

Cloud IDS Alert → Cloud Logging → Pub/Sub Topic → Cloud Run Function
                                                        │
                                                        ▼
                                                  [If CRITICAL]
                                                  Add VPC firewall deny rule
                                                  for threat source IP

Đây là một pattern phổ biến: dùng Cloud IDS cho detection và trigger automation để apply block rule trong VPC firewall khi confidence cao (CRITICAL severity).

Cloud IDS + Cloud NGFW Enterprise = IPS

Cloud IDS là detection only. Cloud NGFW Enterprise là prevention only (block based on signatures). Kết hợp hai sản phẩm này tạo ra Intrusion Prevention System:

IDS flow:

Traffic → Packet Mirroring → IDS Endpoint → Alert → Human/Automation review

IPS flow với Cloud NGFW Enterprise:

Traffic → [Cloud NGFW Enterprise Firewall Endpoint]
               │
               ├─ IPS signature check → DROP if match
               └─ Forward if clean

Khi Cloud NGFW Enterprise enable IPS (bật trong Security Profile), nó dùng threat signatures built-in (không phải Palo Alto — đây là Google/Mandiant signatures). Traffic matching signature bị block trong data path, không chỉ log.

Khi nào dùng Cloud IDS vs Cloud NGFW IPS:

	Cloud IDS	Cloud NGFW IPS
Position	Out-of-band (copy traffic)	In-band (inline inspection)
Action	Detect và alert	Detect và block
Latency impact	Zero (copy, không affect main)	Thêm latency (inline)
Signature database	Palo Alto Networks	Google/Mandiant
TLS inspection	Không	Có (với Enterprise tier)
Coverage	North-south + East-west	North-south + East-west
Cost model	Per-endpoint per-hour + mirrored bytes	Per-endpoint per-hour

Một số tổ chức dùng cả hai: Cloud IDS cho visibility với Palo Alto signatures, Cloud NGFW IPS để block trong data path.

Constraints & Giới Hạn

5 Gbps per endpoint

Đây là hard limit hiện tại. Nếu aggregate traffic của subnets được mirror vượt 5 Gbps, cần deploy thêm endpoints và distribute traffic bằng nhiều Packet Mirroring policies.

Không có auto-scaling cho IDS Endpoints hiện tại — phải manual provision.

Không inspect encrypted traffic (theo mặc định)

Cloud IDS inspect traffic ở L4-L7 nhưng không decrypt TLS. Điều này có nghĩa:

Unencrypted protocols (HTTP, SMTP, FTP): full inspection
TLS traffic: chỉ có thể inspect metadata (SNI, certificate), không phải payload

Đây là limitation đáng kể vì phần lớn modern threat traffic là TLS encrypted. Cloud NGFW Enterprise với TLS inspection khắc phục vấn đề này, nhưng Cloud IDS không có TLS decryption.

Detection delay

Vì là out-of-band, alert generation có delay (vài giây sau khi traffic pass). Không phù hợp cho real-time prevention — chỉ phù hợp cho detection và post-facto investigation.

Cloud IDS — Intrusion Detection Qua Packet Mirroring ​

Tại sao quan trọng trong production ​

Internal Model — Kiến Trúc Packet Mirroring ​

Cơ chế fundamental: out-of-band inspection ​

Palo Alto Networks Technology ​

IDS Endpoint — Deployment Architecture ​

Packet Mirroring Policy — Chọn Traffic để Inspect ​

Alert System — Severity và Response ​

Severity Levels ​

Alert destination ​

Automated Response Pattern ​

Cloud IDS + Cloud NGFW Enterprise = IPS ​

Constraints & Giới Hạn ​

5 Gbps per endpoint ​

Không inspect encrypted traffic (theo mặc định) ​

Detection delay ​

Tham khảo ​