ISC2 CC · Domain 4 · 24%

An ninh mạng

Network Security

Domain chiếm 24% bài thi — bao gồm các mối đe dọa mạng phổ biến, kiến trúc phòng thủ nhiều lớp (firewall, IDS/IPS, DMZ), VPN, an ninh không dây và các giao thức bảo mật cốt lõi.

Mục tiêu chương / Learning objectives

1. Lý thuyết cốt lõi / Core theory

1.1. Các mối đe dọa mạng phổ biến (Network Threats)

1.2. Firewall — Bốn thế hệ (Packet Filter / Stateful / NGFW / WAF)

LoạiKiểm traVí dụHạn chế
Packet FilterIP, port, protocol từng packet độc lậpiptables cơ bản, ACL routerKhông biết trạng thái kết nối
StatefulTheo dõi trạng thái connection (SYN/ACK/FIN)Windows Firewall, pfSenseKhông hiểu application layer
NGFWDeep Packet Inspection, app ID, user ID, IPS tích hợpPalo Alto, Fortinet, Cisco FTDĐắt hơn, cần license
WAFHTTP/HTTPS layer — SQLi, XSS, OWASP Top 10AWS WAF, Cloudflare WAF, ModSecurityChỉ bảo vệ web app

1.3. IDS vs IPS (Intrusion Detection / Prevention System)

IDS (Intrusion Detection System): Phát hiện và cảnh báo — đặt out-of-band (nhận bản sao traffic qua SPAN port). Không block traffic. Ví dụ: Snort ở chế độ IDS, Zeek (Bro).
IPS (Intrusion Prevention System): Phát hiện và block inline — đặt in-line giữa nguồn và đích. Có thể drop packet, reset connection. Ví dụ: Snort ở chế độ IPS, Suricata, NGFW tích hợp IPS.
Signature-based: So sánh traffic với database signature đã biết — chính xác với known threats, bỏ sót zero-day.
Anomaly-based: Học baseline bình thường, alert khi có deviation — phát hiện được unknown attacks, nhưng false positive cao hơn.

1.4. VPN — Hai loại và hai giao thức (Site-to-site / Remote Access · IPSec / SSL-TLS)

1.5. Kiến trúc DMZ & Network Segmentation (Demilitarized Zone / VLAN / Microsegmentation)

DMZ (Demilitarized Zone) là vùng mạng nằm giữa internet và internal network, chứa các server cần truy cập từ bên ngoài (web server, email server, DNS public). Kiến trúc: Internet → Firewall ngoài → DMZ → Firewall trong → Internal Network. Firewall ngoài cho phép traffic vào DMZ; firewall trong chỉ cho phép traffic cụ thể từ DMZ vào internal.

VLAN (Virtual LAN): Phân tách mạng logic trên cùng infrastructure vật lý — HR VLAN, Finance VLAN, Guest VLAN. Traffic giữa VLAN phải qua router/firewall → áp dụng access control. Giảm broadcast domain, hạn chế lateral movement của attacker.
Microsegmentation: Phân tách chi tiết đến cấp workload/container — dùng trong cloud và datacenter hiện đại. Ví dụ: mỗi microservice chỉ được nói chuyện với service cụ thể, không phải toàn bộ mạng.

1.6. An ninh không dây & Giao thức bảo mật (Wireless Security / Secure Protocols)

WPA2 (Wi-Fi Protected Access 2): Dùng AES-CCMP cho mã hóa — mạnh hơn WEP/WPA/TKIP. Vẫn dễ bị tấn công offline dictionary attack nếu PSK yếu (dùng WPA2-Enterprise/802.1X để khắc phục). WPA3: Dùng SAE (Simultaneous Authentication of Equals) thay PSK — chống offline dictionary attack, forward secrecy. Bắt buộc từ 2020 cho thiết bị Wi-Fi mới.

Giao thức bảo mật — luôn dùng phiên bản encrypted:
SSH thay vì Telnet (port 22 vs 23 — Telnet cleartext).
HTTPS thay vì HTTP (TLS encryption — bảo vệ cả Confidentiality và Integrity).
SFTP/FTPS thay vì FTP (FTP cleartext kể cả credentials).
SNMPv3 thay vì SNMPv1/v2 (SNMPv3 có auth và encryption).
TLS 1.2+ thay vì SSL/TLS cũ hơn (SSLv3, TLS 1.0/1.1 đã bị deprecate).

1.7. Bảo mật Email — SPF, DKIM, DMARC, BIMI (Email Security Protocols)

Email là vector tấn công phổ biến nhất — 90%+ các cuộc tấn công bắt đầu bằng email. Bốn giao thức xác thực email tạo thành lớp phòng thủ quan trọng chống giả mạo domain:

SPF (Sender Policy Framework): DNS TXT record liệt kê danh sách IP/host được phép gửi email thay mặt cho domain. Email server nhận kiểm tra IP người gửi có nằm trong SPF record hay không.
Ví dụ record: v=spf1 include:_spf.google.com ip4:203.0.113.10 -all
-all = reject tất cả nguồn không được liệt kê (strict). ~all = softfail (mark as spam nhưng không reject).

DKIM (DomainKeys Identified Mail): Chèn chữ ký mã hóa (cryptographic signature) vào header email. Server gửi ký bằng private key, server nhận verify bằng public key lưu trong DNS TXT record. Bảo vệ tính toàn vẹn của email — nội dung không bị chỉnh sửa trong quá trình truyền.
DNS record: selector._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0..."

DMARC (Domain-based Message Authentication, Reporting & Conformance): Policy điều phối SPF và DKIM — quy định hành động khi email không vượt qua SPF hoặc DKIM. Ba policy mode:
p=none — chỉ monitor, không block (dùng khi mới triển khai)
p=quarantine — đưa vào spam/quarantine
p=reject — từ chối email hoàn toàn (strict enforcement)
DMARC cũng yêu cầu gửi report về địa chỉ chỉ định — phân tích ai đang gửi email giả danh domain của bạn.

BIMI (Brand Indicators for Message Identification): Hiển thị logo thương hiệu bên cạnh email trong hộp thư người dùng (Gmail, Apple Mail). Yêu cầu: domain phải có DMARC policy p=quarantine hoặc p=reject. BIMI tăng nhận diện thương hiệu và giúp người dùng phân biệt email thật/giả.

🖥️ Nền tảng: Ubuntu 22.04 LTS
🛠️ Công cụ: dig, nmap, mxtoolbox (web)

Lab (Inline) — Kiểm tra SPF/DKIM/DMARC của domain thực tế

OS: Ubuntu 22.04 · Tool: dig (DNS lookup). Lưu ý: chỉ query DNS — không gửi email, không scan, hoàn toàn an toàn và hợp pháp.

# Cài dig nếu chưa có
sudo apt install dnsutils -y

# --- Bước 1: Kiểm tra SPF record của google.com ---
dig TXT google.com | grep spf

# --- Bước 2: Kiểm tra DKIM record của Google ---
# Selector phổ biến là "google" hoặc "default" — thay bằng selector thực tế
dig TXT google._domainkey.google.com

# --- Bước 3: Kiểm tra DMARC record ---
dig TXT _dmarc.google.com

# --- Bước 4: Phân tích một domain không có DMARC enforcement ---
# Thử với một domain nhỏ hơn để thấy sự khác biệt
dig TXT _dmarc.example.com

# --- Bước 5: Kiểm tra nhanh MX record (mail server của domain) ---
dig MX google.com

✅ Kết quả mong đợi / Expected output:
SPF của google.com: "v=spf1 include:_spf.google.com ~all" — thấy include: chỉ ra Google dùng nhiều IP range con.
DKIM của google.com: "v=DKIM1; k=rsa; p=MIIBIjANBgkq..." — thấy public key RSA dài.
DMARC của google.com: "v=DMARC1; p=reject; rua=mailto:..." — policy reject là enforcement cao nhất, có địa chỉ nhận report.
Domain không có DMARC: NXDOMAIN hoặc không có TXT record — domain này dễ bị giả mạo, email giả danh không bị block tự động.
Để phân tích chi tiết hơn, dùng MXToolbox (mxtoolbox.com/SuperTool): nhập domain → chọn SPF Lookup, DKIM Lookup, DMARC Lookup — hiển thị kết quả phân tích trực quan.

2. Bài thực hành / Hands-on lab

🖥️ Nền tảng: Windows 11
🛠️ Công cụ: PowerShell 7

Lab 1 — Windows Firewall Audit (PowerShell)

OS: Windows 11 · Tool: PowerShell 7 (Administrator).

Mục tiêu: kiểm tra cấu hình Windows Firewall — phát hiện rule quá rộng hoặc profile bị tắt.

# Xem trạng thái tất cả firewall profiles (Domain/Private/Public)
netsh advfirewall show allprofiles

# Liệt kê các rule đang enabled, sắp xếp theo Direction
Get-NetFirewallRule |
    Where-Object { $_.Enabled -eq 'True' } |
    Select-Object DisplayName, Direction, Action, Profile |
    Sort-Object Direction |
    Format-Table -AutoSize

# Tìm rule Allow Inbound có thể rủi ro (any remote address)
Write-Host "`n=== Potentially Risky Inbound Allow Rules ===" -ForegroundColor Red
Get-NetFirewallRule |
    Where-Object { $_.Direction -eq 'Inbound' -and $_.Action -eq 'Allow' -and $_.Enabled -eq 'True' } |
    ForEach-Object {
        $filter = $_ | Get-NetFirewallAddressFilter
        $portFilter = $_ | Get-NetFirewallPortFilter
        [PSCustomObject]@{
            Name          = $_.DisplayName
            LocalPort     = $portFilter.LocalPort
            RemoteAddress = $filter.RemoteAddress
            Protocol      = $portFilter.Protocol
        }
    } |
    Where-Object { $_.RemoteAddress -eq 'Any' } |
    Format-Table -AutoSize

# Kiểm tra kết nối mạng đang active (established connections)
Write-Host "`n=== Active Network Connections ===" -ForegroundColor Cyan
Get-NetTCPConnection |
    Where-Object { $_.State -eq 'Established' } |
    Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, State |
    Sort-Object RemoteAddress |
    Format-Table -AutoSize

✅ Kết quả mong đợi / Expected output: netsh advfirewall hiển thị State ON/OFF cho Domain/Private/Public profile — tất cả phải ON. Danh sách rule Inbound Allow với RemoteAddress=Any cần được review — các rule này cho phép kết nối từ bất kỳ đâu. Connections established đến các IP lạ (không phải server nội bộ hoặc cloud provider đã biết) cần điều tra.

🖥️ Nền tảng: Ubuntu 22.04 LTS
🛠️ Công cụ: Bash + ufw + tshark/Wireshark

Lab 2 — Linux Firewall Audit & Network Analysis (Bash)

OS: Ubuntu 22.04 · Tool: Bash + ufw + iptables + tshark. Lưu ý: Chỉ chạy nmap và tshark trên lab network do bạn sở hữu hoặc có quyền kiểm tra.

# Kiểm tra trạng thái ufw (Uncomplicated Firewall)
sudo ufw status verbose

# Xem iptables rules chi tiết với line numbers
sudo iptables -L -n -v --line-numbers

# Xem FORWARD chain (quan trọng nếu server làm gateway/router)
sudo iptables -L FORWARD -n -v

# Kiểm tra port đang lắng nghe (listening services)
# Mỗi port open = attack surface tiềm năng
ss -tlnp
# Hoặc: netstat -tlnp (nếu net-tools đã cài)

# Nmap scan localhost để thấy attacker nhìn thấy gì từ bên ngoài (lab only)
# Cài: sudo apt install nmap -y
nmap -sV --script=banner 127.0.0.1

# Capture 20 packet đầu tiên trên interface eth0 với tshark (phân tích giao thức)
# Cài: sudo apt install tshark -y
sudo tshark -i eth0 -c 20

# Capture và lọc chỉ HTTP traffic (cleartext) để minh họa sniffing risk
sudo tshark -i eth0 -c 50 -Y "http" -T fields \
    -e ip.src -e ip.dst -e http.request.method -e http.request.uri 2>/dev/null

# Kiểm tra kết nối established và LISTEN
ss -tunap | grep -E "ESTABLISHED|LISTEN"

✅ Kết quả mong đợi / Expected output: ufw status cho thấy các rule Allow/Deny với port và source. iptables -L cho thấy chains và policy (DROP là tốt hơn ACCEPT cho default policy). ss -tlnp cho thấy các port đang mở — port 22 (SSH), 80 (HTTP), 443 (HTTPS) là bình thường; các port lạ cần điều tra. tshark capture hiển thị real-time packets với protocol, IP nguồn/đích. Nếu thấy HTTP cleartext với credentials trong URI — minh họa nguy cơ sniffing rõ ràng.

3. Tình huống doanh nghiệp / Real-world scenario

Bối cảnh — Evil Twin AP tại khách sạn hội nghị:

Một giám đốc kinh doanh kết nối laptop vào WiFi "Hotel_Conference_Free" tại hội trường hội nghị. AP này thực ra là Evil Twin do attacker dựng lên với SSID trùng với AP thật của khách sạn. Attacker đặt laptop chạy hostapd-wpe để capture 802.1X credentials và thực hiện SSL stripping trên traffic HTTP.

Phân tích tình huống:

  1. Tại sao HTTPS vẫn bị ảnh hưởng trong một số trường hợp: Nếu user bấm "Accept certificate error" khi bị MITM, hoặc app dùng HTTP redirect trước khi HTTPS — attacker có window để capture. Tuy nhiên: HTTPS đúng cách với HSTS và certificate pinning sẽ không thể bị đọc nội dung.
  2. Tại sao giám đốc không phát hiện: SSID giống hệt, signal strength attacker có thể mạnh hơn AP thật (khoảng cách gần hơn), không có certificate warning nếu chỉ dùng HTTP app.
  3. Phòng thủ — VPN enforcement policy: Công ty ban hành policy bắt buộc: mọi kết nối từ mạng không phải corporate phải qua VPN. VPN client tự động kết nối khi phát hiện không ở corporate network. Traffic mã hóa trong VPN tunnel → attacker chỉ thấy encrypted data.
  4. Phòng thủ — Certificate pinning: App mobile và desktop pin certificate của server — nếu certificate thay đổi (MITM proxy), app từ chối kết nối.
  5. Phòng thủ — WIPS (Wireless IPS): Trong văn phòng công ty: WIPS scan liên tục phát hiện AP lạ có SSID trùng với corporate SSID → alert ngay và có thể deauth các client kết nối vào rogue AP.
  6. Phòng thủ — Security Awareness: Train nhân viên nhận biết dấu hiệu Evil Twin (certificate warning, login page lạ, website không load đúng) — khi nghi ngờ, ngắt kết nối và dùng data 4G/5G thay.

Key takeaway: "Never trust public WiFi without VPN." Mạng WiFi công cộng là môi trường hostile mặc định — nguyên lý Zero Trust áp dụng hoàn toàn ở đây.

4. Tự kiểm tra / Knowledge check

  1. Giải thích tại sao stateful firewall an toàn hơn packet filter firewall. Cho ví dụ một loại tấn công mà packet filter bỏ sót nhưng stateful chặn được.
  2. Phân biệt IDS và IPS về vị trí triển khai trong mạng và hành động khi phát hiện tấn công. Loại nào phù hợp hơn cho môi trường production quan trọng?
  3. Tại sao WPA3 an toàn hơn WPA2 khi dùng Personal mode (PSK)? Tính năng nào của WPA3 ngăn offline dictionary attack?
  4. Công ty có web server cần truy cập từ internet và database server chỉ dùng nội bộ. Thiết kế kiến trúc mạng nào phù hợp? Vẽ sơ đồ đơn giản.
  5. Vì sao HTTPS không đủ để bảo vệ hoàn toàn khỏi Evil Twin? Cần thêm biện pháp nào?
C03: Kiểm soát truy cập C05: Vận hành bảo mật
Thực hành trên công cụPowerShell 7 · Bash · ufw · tshark
Nền tảngWindows 11 · Ubuntu 22.04
Thời điểm phát hànhQ2/2026
Ngày biên soạn24/05/2026
Người biên soạnTrần Văn Hòa (MCT)
Phiên bảnv1.0
Zalo