Truong Nhat Hoang

nftables trong thực chiến

Sun, 28 Jun 2026 09:00:00 +0000

Về lý thuyết, một firewall là một bộ lọc gói tin đặt giữa hai vùng mạng, quyết định gói nào được đi qua và gói nào bị chặn. Nghe thì đơn giản, nhưng khi chúng ta ngồi xuống viết ruleset thật cho một máy chủ đang chạy thì mới thấy khoảng cách giữa “chặn port 22” trong đầu và một tập luật đúng, không tự khoá mình ra ngoài, không rò rỉ, và vẫn đo đếm được. Bài này mình muốn đi hết quãng đường đó với nftables, framework lọc gói mặc định của nhân Linux hiện đại.

Mình sẽ viết như một buổi dựng máy chủ tại nhà: một con VPS hoặc một máy Linux trong LAN, chạy vài dịch vụ, và chúng ta muốn nó có một hàng rào tử tế.

nftables là gì?

nftables là hệ thống lọc gói trong nhân Linux, ra mắt chính thức từ nhân 3.13 (năm 2014) để thay thế bộ công cụ cũ iptables (cùng họ với ip6tables, arptables, ebtables). Điểm mấu chốt: thay vì bốn công cụ riêng với bốn cú pháp, nftables gom tất cả vào một framework duy nhất, một ngôn ngữ luật duy nhất, và một tiện ích dòng lệnh duy nhất là nft. Bên dưới, nó dùng lại hạ tầng Netfilter (các hook trong đường đi của gói tin) mà iptables vẫn dùng, nên đây không phải là một cỗ máy hoàn toàn mới, mà là một lớp giao diện được thiết kế lại cho gọn.

Vì sao đáng chuyển sang

Có vài lý do rất thực tế, không phải chạy theo mốt:

Một bảng, nhiều họ địa chỉ. Một luật có thể áp cho cả IPv4 lẫn IPv6 qua họ inet, thay vì phải viết đôi.
Cú pháp khai báo, gần với cách chúng ta suy nghĩ. Bạn khai báo table, trong đó có chain, trong chain có rule.
sets và maps là công dân hạng nhất. Muốn chặn một danh sách IP? Bỏ vào một set, thay vì hàng trăm dòng luật rời rạc.
Nạp luật theo kiểu nguyên tử (atomic). Cả file luật được nạp trong một giao dịch: hoặc thành công toàn bộ, hoặc không đổi gì. Không có cảnh nửa nạp xong thì đứt.

Điểm 4 nghe nhỏ nhưng nó cứu chúng ta khỏi trạng thái firewall “dở dang” giữa chừng, một trong những cách tự khoá mình ra khỏi máy chủ kinh điển.

Ba khái niệm phải nắm trước khi gõ

Trước khi viết dòng luật đầu tiên, ba khái niệm này quyết định mọi thứ.

Hook. Netfilter đặt các điểm móc trên đường đi của gói tin. Với họ inet/ip, những hook chúng ta hay dùng là prerouting, input, forward, output, postrouting. Gói gửi tới chính máy này đi qua input. Gói máy này định tuyến giúp máy khác đi qua forward. NAT thường móc vào prerouting và postrouting.

Stateful, tức là có theo dõi trạng thái kết nối. Đây là trái tim của một firewall dùng được. Netfilter có module conntrack ghi nhớ mọi kết nối đang diễn ra. Nhờ đó, thay vì phải mở port cho cả chiều đi lẫn chiều về, chúng ta chỉ cần một luật: “cho qua mọi gói thuộc kết nối đã được thiết lập hoặc liên quan”. Trạng thái conntrack gồm new (gói mở kết nối mới), established (thuộc kết nối đã có), related (liên quan, ví dụ gói lỗi ICMP của một kết nối), và invalid (không khớp trạng thái nào, thường nên vứt).

Policy mặc định. Mỗi base chain có một chính sách: accept hoặc drop. Nguyên tắc an toàn là default deny: đặt policy drop, rồi chỉ mở đúng những gì cần. Đây là khác biệt tư duy giữa “chặn cái xấu tôi biết” và “chỉ cho cái tốt tôi cần”, và cái sau luôn bền hơn.

Ruleset đầu tiên: bảo vệ chính máy chủ

Giả sử máy chủ chạy SSH (port 22), một web server (80/443), và không làm router. Ta chỉ cần lọc lưu lượng đi vào chính nó, tức chain input. File luật đặt tại /etc/nftables.conf:

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;

        # Gói của kết nối đã thiết lập hoặc liên quan: cho qua
        ct state established,related accept

        # Vứt gói invalid trước khi làm gì thêm
        ct state invalid drop

        # Loopback luôn tin cậy
        iif "lo" accept

        # ICMP/ICMPv6 cần thiết (ping, path MTU discovery, neighbor discovery)
        ip protocol icmp icmp type { echo-request, echo-reply, destination-unreachable, time-exceeded } accept
        ip6 nexthdr icmpv6 icmpv6 type { echo-request, echo-reply, nd-neighbor-solicit, nd-neighbor-advert, nd-router-advert } accept

        # Dịch vụ mở ra ngoài
        tcp dport 22 accept
        tcp dport { 80, 443 } accept

        # Mọi thứ còn lại rơi vào policy drop
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

Vài điểm đáng dừng lại. Dòng ct state established,related accept đặt lên đầu là cố ý: phần lớn gói tin qua một chain thuộc về kết nối đang chạy, cho chúng qua sớm giúp tránh phải duyệt hết các luật phía dưới. Việc mở ICMPv6 không phải tuỳ chọn với IPv6: neighbor discovery (nd-neighbor-solicit, nd-neighbor-advert) là tương đương của ARP trong IPv6, chặn nó là tự cắt kết nối IPv6 của mình. Đây là một cái bẫy rất hay gặp khi người ta bê tư duy “chặn hết ICMP cho chắc” từ IPv4 sang.

Chain output mình để policy accept cho gọn. Ở một máy chủ cứng hơn, bạn có thể siết cả chiều ra, nhưng hãy làm sau khi đã hiểu rõ máy đang cần nói chuyện với ai.

Đừng tự khoá mình ra ngoài

Đây là phần thực chiến quan trọng nhất mà lý thuyết ít nhắc. Nếu bạn đang SSH vào con VPS ở xa và nạp một ruleset default-drop bị sai, phiên của bạn đứt và bạn mất luôn đường vào. Có hai thói quen cứu mạng.

Thứ nhất, kiểm thử bằng cách nạp có thời hạn. Trên systemd, dùng một hẹn giờ tự khôi phục: mở một phiên riêng chạy lệnh sẽ flush ruleset sau, chẳng hạn, 2 phút, rồi mới nạp luật mới ở phiên chính. Nếu luật mới khoá bạn, chỉ cần chờ 2 phút là firewall bị xoá và bạn vào lại được.

# Phiên A (cửa thoát hiểm): sau 120 giây sẽ mở toang lại
sleep 120 && nft flush ruleset &

# Phiên B: nạp luật mới và thử kết nối
sudo nft -f /etc/nftables.conf

Nếu sau khi thử thấy mọi thứ ổn, quay lại phiên A huỷ tiến trình sleep, rồi lưu luật cho khởi động sau. Thứ hai, luôn dùng nft -c -f file để kiểm tra cú pháp trước khi nạp thật; cờ -c chỉ kiểm mà không áp dụng.

Thêm NAT: khi máy chủ làm router

Nếu máy này định tuyến cho một mạng con phía sau (ví dụ một mạng lab, hoặc một đám container), chúng ta cần NAT. Trường hợp phổ biến nhất là source NAT kiểu masquerade: giấu toàn bộ mạng nội bộ sau một địa chỉ công cộng duy nhất trên giao diện ra ngoài.

NAT trong nftables sống ở một table riêng, với các chain móc vào hook postrouting (đổi địa chỉ nguồn, sau khi định tuyến xong) và prerouting (đổi địa chỉ đích, trước khi định tuyến, dùng cho port forwarding).

table inet nat {
    chain postrouting {
        type nat hook postrouting priority srcnat; policy accept;

        # Giấu subnet nội bộ sau IP của card mạng ra internet
        ip saddr 10.0.0.0/24 oif "eth0" masquerade
    }

    chain prerouting {
        type nat hook prerouting priority dstnat; policy accept;

        # Chuyển tiếp cổng: 8080 bên ngoài về một máy nội bộ
        iif "eth0" tcp dport 8080 dnat to 10.0.0.5:80
    }
}

Hai điều bắt buộc kèm theo. Một, phải bật chuyển tiếp gói tin trong nhân, nếu không mọi luật forward đều vô nghĩa:

sudo sysctl -w net.ipv4.ip_forward=1
# và cho IPv6 nếu cần: net.ipv6.conf.all.forwarding=1

Hai, chain forward trong table filter phải thực sự cho phép lưu lượng đi qua, vì nó vẫn đang là policy drop. Một cặp luật tối thiểu:

# Bổ sung vào chain forward của table inet filter
ct state established,related accept
ip saddr 10.0.0.0/24 oif "eth0" accept

Ở đây mình cố tình tách bạch: filter quyết định gói có được đi qua không, nat quyết định gói bị viết lại địa chỉ ra sao. Trộn hai việc này trong đầu là nguồn gốc của rất nhiều giờ debug. Một điểm nữa thường gây bối rối: DNAT viết lại địa chỉ đích ở prerouting, nhưng luật filter ở forward lại nhìn thấy địa chỉ đích đã bị viết lại (10.0.0.5), không phải địa chỉ ban đầu. Vì thứ tự hook là prerouting rồi mới tới forward.

Logging: nhìn thấy cái mình đang chặn

Một firewall câm là một firewall khó tin. Chúng ta muốn thấy cái gì đang bị vứt, ít nhất trong lúc dựng. nftables ghi log qua nhật ký nhân, và bạn có thể gắn tiền tố để lọc về sau:

# Đặt ngay trước khi gói rơi vào policy drop của chain input
log prefix "nft-input-drop: " level info

Log rồi drop có thể tách làm hai bước như trên (gói không khớp luật nào sẽ được log rồi mới bị policy drop nuốt). Xem kết quả bằng:

sudo journalctl -k -f | grep "nft-input-drop"

Một lưu ý thực tế: đừng log mọi gói bị drop trên một máy chủ công cộng thật. Internet quét port liên tục, log của bạn sẽ phình ra rất nhanh và tự nó thành một vấn đề. Cách lành mạnh là dùng rate limit cho chính dòng log, để bạn thấy được mẫu tấn công mà không chết chìm:

limit rate 5/minute log prefix "nft-input-drop: " level info

Kiểm thử: chứng minh luật làm đúng việc

Viết luật xong chưa phải là xong. Chúng ta cần quan sát cả trạng thái lẫn hành vi.

Xem toàn bộ ruleset đang chạy, kèm bộ đếm nếu đã bật:

sudo nft list ruleset

Bật bộ đếm trên một luật bằng từ khoá counter để đo lưu lượng thật:

tcp dport 22 counter accept

Sau đó nft list ruleset sẽ hiện số gói và số byte đã khớp luật đó, cách nhanh nhất để trả lời câu hỏi “luật này có thực sự được dùng không”. Từ một máy khác trong LAN, thử quét vài port để xác nhận cái đóng thì đóng, cái mở thì mở:

# Từ máy khác trỏ vào IP máy chủ
nmap -Pn -p 22,80,443,3306 192.168.1.10

Bạn muốn thấy 22/80/443 ở trạng thái open, còn 3306 (giả sử MySQL chỉ nghe nội bộ) ở filtered. Nếu 3306 hiện closed thay vì filtered, đó là dấu hiệu gói bị nhân từ chối (RST) chứ không phải bị firewall lặng lẽ nuốt, một khác biệt tinh tế nhưng nói lên luật của bạn chưa bao trùm port đó. Cuối cùng, để luật sống sót qua khởi động lại, bật service:

sudo systemctl enable --now nftables

Lưu lại vài suy nghĩ chưa gọn

Đến đây chúng ta đã có một firewall stateful đúng nghĩa: default-deny, cho phép kết nối đã thiết lập, mở đúng dịch vụ, làm NAT khi cần, và có mắt để nhìn. Nhưng mình không muốn kết bài kiểu “và thế là bạn đã an toàn”, vì thật ra ranh giới ở đây khá mờ.

Một firewall gói tin lọc theo địa chỉ và cổng; nó gần như mù trước những gì xảy ra bên trong một kết nối đã mở. Web server của bạn nghe trên 443 và firewall vui vẻ cho qua, còn lỗ hổng trong ứng dụng phía sau thì nó không thấy. Với conntrack, có những đánh đổi về bộ nhớ và về cách xử lý gói invalid mà mình đã lược đi để bài không dài quá. Và câu hỏi “nên siết chiều output tới mức nào” thì không có đáp án chung, nó phụ thuộc bạn tin máy chủ của mình tới đâu.

Điều mình thấy đáng giá nhất khi tự tay viết ruleset, thay vì bật một GUI hay copy một script, là nó buộc mình phát biểu rõ ràng máy chủ được phép nói chuyện với ai. Phần lớn thời gian, chính việc phải viết ra điều đó đã dạy nhiều hơn bản thân tập luật.

Tài liệu tham khảo

nftables project wiki, “What is nftables?” và “Quick reference-nftables in 10 minutes” (wiki.nftables.org)
nft(8) manual page, Netfilter project
Netfilter/iptables project (netfilter.org), tài liệu về conntrack và các hook
Arch Linux Wiki, mục “nftables”
Wikipedia, “nftables” và “Netfilter”

Fail2Ban cho tổng đài VoIP

Fri, 19 Jun 2026 09:00:00 +0000

Nếu chúng ta từng mở một tổng đài VoIP ra Internet công cộng, dù chỉ vài giờ, gần như chắc chắn trong log đã có người gõ cửa. Không phải một người, mà là hàng loạt con bot quét cả dải IPv4 để tìm cổng SIP 5060 đang mở. Bài này mình muốn đi qua cách dùng Fail2Ban để chặn kiểu tấn công brute-force đó, và quan trọng hơn là ngồi đọc lại log tấn công thật để hiểu chúng ta đang chống lại cái gì.

SIP và bề mặt tấn công là gì?

Về lý thuyết, SIP (Session Initiation Protocol, mô tả trong RFC 3261) là giao thức báo hiệu: nó không mang giọng nói, nó chỉ lo việc thiết lập, sửa đổi và kết thúc một cuộc gọi. Âm thanh thật đi qua RTP trên các cổng khác. SIP là giao thức dạng text, các bản tin trông rất giống HTTP, với những phương thức như REGISTER, INVITE, OPTIONS, SUBSCRIBE.

Điểm yếu nằm ở chỗ này. Để một máy điện thoại đăng ký vào tổng đài, nó gửi một bản tin REGISTER kèm thông tin xác thực. Tổng đài trả về 401 Unauthorized cùng một nonce, máy điện thoại băm mật khẩu theo cơ chế digest authentication rồi gửi lại. Nếu sai, tổng đài lại trả 401 hoặc 403 Forbidden. Cả một vòng lặp hỏi-đáp, và mỗi lần sai đều để lại một dòng trong log. Kẻ tấn công chỉ việc thử REGISTER liên tục với hàng nghìn số máy nhánh (extension) và mật khẩu phổ biến. Đây chính là brute-force SIP.

Một biến thể tinh vi hơn dùng OPTIONS hoặc INVITE để dò xem extension nào tồn tại trước, dựa vào việc tổng đài trả về mã lỗi khác nhau cho số có thật và số không có thật. Đó là extension enumeration, bước do thám trước khi dồn sức đoán mật khẩu.

Fail2Ban hoạt động thế nào?

Fail2Ban là một daemon viết bằng Python. Ý tưởng của nó đơn giản đến mức đẹp: đọc log của một dịch vụ, so từng dòng với một tập biểu thức chính quy (regex), và khi một địa chỉ IP vi phạm quá nhiều lần trong một khoảng thời gian, nó gọi firewall của hệ điều hành để chặn IP đó lại trong một khoảng thời gian nhất định.

Ba khái niệm cốt lõi:

Filter: tập regex mô tả một dòng log “xấu”. Fail2Ban cần trích ra được địa chỉ IP thủ phạm qua một nhóm bắt tên là <HOST>.
Jail: bản cấu hình gắn một filter vào một file log cụ thể, kèm ngưỡng maxretry, cửa sổ thời gian findtime, và thời gian chặn bantime.
Action: việc cần làm khi ban, thường là thêm một luật vào iptables, nftables hoặc firewalld.

Công thức tinh thần rất gọn: nếu một IP tạo ra nhiều hơn maxretry dòng log khớp filter trong vòng findtime giây, chặn nó trong bantime giây.

Đọc log tấn công thật

Đây là phần mình thấy thú vị nhất. Dưới đây là một đoạn log Asterisk đã được rút gọn và thay IP, nhưng cấu trúc thì đúng như những gì chúng ta gặp ngoài đời:

[2026-06-15 02:11:07] NOTICE[2043] chan_sip.c: Registration from '"100" <sip:100@vd.example.net>' failed for '203.0.113.44:5081' - Wrong password
[2026-06-15 02:11:07] NOTICE[2043] chan_sip.c: Registration from '"101" <sip:101@vd.example.net>' failed for '203.0.113.44:5081' - Wrong password
[2026-06-15 02:11:08] NOTICE[2043] chan_sip.c: Registration from '"102" <sip:102@vd.example.net>' failed for '203.0.113.44:5081' - No matching peer found
[2026-06-15 02:11:08] NOTICE[2043] chan_sip.c: Registration from '"admin" <sip:admin@vd.example.net>' failed for '203.0.113.44:5081' - Username/auth name mismatch

Vài điều đáng chú ý. Thứ nhất, tần suất: bốn lần thử trong đúng hai giây, và số extension chạy tuần tự 100, 101, 102. Đây rõ ràng là script, không phải người. Thứ hai, phần lý do phía cuối mỗi dòng khác nhau: Wrong password nghĩa là extension có thật nhưng mật khẩu sai (nguy hiểm, vì kẻ tấn công biết mình đã tìm đúng một số máy), còn No matching peer found nghĩa là số đó không tồn tại. Kẻ tấn công đọc đúng những khác biệt này để lọc ra danh sách extension thật. Thứ ba, cổng nguồn 5081 cứ giữ nguyên trong một loạt, cho thấy chúng đang tái sử dụng một socket.

Với tổng đài dùng chan_sip cũ, có một chi tiết lịch sử đáng nhớ: mặc định Asterisk trả lời khác nhau cho extension tồn tại và không tồn tại, khiến việc enumeration dễ dàng. Về sau người ta thêm tùy chọn alwaysauthreject=yes để tổng đài luôn trả cùng một kiểu từ chối, bịt bớt kênh rò rỉ thông tin này. Nếu đang chạy pjsip hiện đại, hành vi mặc định đã an toàn hơn, nhưng nguyên tắc vẫn thế.

Một dạng log khác, từ máy trả về mã SIP thô, trông như sau:

SIP/2.0 401 Unauthorized
SIP/2.0 403 Forbidden

401 là “hãy xác thực lại”, còn 403 là “tôi từ chối”. Khi thấy một IP nhận về hàng trăm mã 403 trong một phút, không cần nghĩ nhiều nữa.

Viết một filter và một jail

Fail2Ban đã đóng gói sẵn filter asterisk, nhưng mình muốn dựng lại một phiên bản tối giản để chúng ta thấy cơ chế. File filter đặt tại /etc/fail2ban/filter.d/asterisk-custom.conf:

[Definition]
failregex = ^.*Registration from '.*' failed for '<HOST>:\d+' - Wrong password$
            ^.*Registration from '.*' failed for '<HOST>:\d+' - No matching peer found$
            ^.*Registration from '.*' failed for '<HOST>:\d+' - Username/auth name mismatch$
ignoreregex =

Điểm mấu chốt là token <HOST>. Fail2Ban thay nó bằng một pattern nhận cả IPv4 lẫn IPv6, và bắt lấy kết quả để biết ban ai. Nếu regex của chúng ta không chứa <HOST>, jail sẽ không bao giờ ban được ai cả, đây là lỗi phổ biến nhất khi tự viết filter.

Trước khi tin tưởng, luôn kiểm thử filter trên log thật bằng công cụ fail2ban-regex:

fail2ban-regex /var/log/asterisk/messages \
  /etc/fail2ban/filter.d/asterisk-custom.conf

Lệnh này in ra số dòng khớp và số IP trích được. Nếu nó báo 0 matched, filter sai chứ không phải log sạch.

Tiếp theo là jail, đặt trong /etc/fail2ban/jail.d/asterisk.local (luôn dùng file .local thay vì sửa .conf gốc để khỏi mất khi cập nhật gói):

[asterisk-custom]
enabled  = true
port     = 5060,5061,5081
protocol = udp
filter   = asterisk-custom
logpath  = /var/log/asterisk/messages
maxretry = 5
findtime = 600
bantime  = 86400
action   = %(action_)s

Diễn giải: năm lần đăng ký hỏng trong vòng 600 giây (mười phút) từ cùng một IP sẽ dẫn tới một lệnh ban kéo dài 86400 giây (một ngày). Với môi trường bị quét dày, nhiều người đặt bantime = -1 để ban vĩnh viễn, hoặc bật chế độ recidive để những IP tái phạm nhiều lần bị chặn hàng tuần.

Sau khi nạp lại cấu hình, kiểm tra trạng thái jail:

fail2ban-client reload
fail2ban-client status asterisk-custom

Kết quả sẽ liệt kê số lần khớp tổng cộng, số IP đang bị chặn, và danh sách địa chỉ trong “banned IP list”. Lần đầu nhìn con số này nhảy lên vài trăm chỉ sau một đêm, cảm giác vừa nhẹ nhõm vừa hơi rợn.

Vài lưu ý để không tự bắn vào chân

Fail2Ban rất mạnh, và chính vì mạnh nên nó dễ chặn nhầm. Vài điều mình rút ra:

Whitelist dải IP tin cậy. Đặt ignoreip cho subnet văn phòng và địa chỉ của chính các máy nhánh hợp lệ, nếu không một nhân viên gõ sai mật khẩu vài lần có thể tự khóa mình khỏi tổng đài.
UDP không có khái niệm “kết nối”. Phần lớn SIP chạy trên UDP, nên đừng trông chờ những dấu hiệu bắt tay TCP. Chúng ta đang lọc thuần túy dựa trên nội dung log ứng dụng, đó là lý do filter phải khớp thật chính xác.
Fail2Ban là lớp phòng thủ, không phải lớp duy nhất. Nó giảm nhiễu và cản brute-force ngây thơ, nhưng một kẻ tấn công phân tán qua hàng nghìn IP (kiểu botnet) sẽ không chạm ngưỡng maxretry trên từng IP. Vì thế nó nên đi cùng: đặt tổng đài sau VPN hoặc SBC (Session Border Controller) khi có thể, đổi cổng SIP mặc định, đặt mật khẩu extension đủ dài và ngẫu nhiên, và bật alwaysauthreject hoặc dùng pjsip hiện đại để cắt kênh enumeration.
Đọc log định kỳ. Fail2Ban chặn theo luật chúng ta viết, nhưng chính chúng ta mới nhìn ra một dạng tấn công mới trước khi viết được luật cho nó. Cái vòng “đọc log, chỉnh filter, kiểm thử bằng fail2ban-regex” là công việc không bao giờ thật sự kết thúc.

Thành thật mà nói, không có cấu hình nào chặn được tất cả. Một tổng đài mở ra Internet luôn là mục tiêu, và điều tốt nhất chúng ta làm được là nâng chi phí tấn công lên đủ cao để kẻ lười bỏ đi, đồng thời giữ cho bản thân đủ tỉnh táo để nhận ra khi kẻ kiên nhẫn xuất hiện. Fail2Ban làm rất tốt phần đầu tiên. Phần thứ hai vẫn nằm ở đôi mắt của chúng ta khi ngồi đọc từng dòng log lúc hai giờ sáng.

Tài liệu tham khảo

RFC 3261, SIP: Session Initiation Protocol, IETF.
Fail2Ban, tài liệu và wiki chính thức trên GitHub (fail2ban/fail2ban).
Asterisk documentation, Security và cấu hình chan_sip / pjsip (docs.asterisk.org).
Manual page: fail2ban-regex(1) và jail.conf(5).

Giải phẫu tấn công cước lậu qua SIP

Wed, 10 Jun 2026 09:00:00 +0000

Có một loại tấn công mà nạn nhân thường không biết mình đã bị đánh cho tới khi nhận hoá đơn. Không có ransomware nhấp nháy trên màn hình, không có dữ liệu bị mã hoá, chỉ có một dòng cước điện thoại quốc tế dài bất thường về các đầu số ở những nơi chúng ta chưa từng gọi tới. Đó là toll fraud, hay cước lậu, và trong thế giới VoIP nó gần như luôn đi qua cùng một cánh cửa: một tổng đài Asterisk cấu hình lỏng, phơi thẳng port SIP ra Internet.

Bài này mình muốn mổ xẻ chuỗi tấn công đó theo đúng trình tự kẻ tấn công đi, rồi giải thích vì sao hai biện pháp cũ kỹ đến mức nhàm chán, đặt tổng đài vào DMZ và bắt buộc xác thực mạnh, lại là thứ chặn được phần lớn các vụ này.

SIP là gì, và vì sao nó dễ bị nhắm

Về lý thuyết, SIP (Session Initiation Protocol) là một giao thức báo hiệu ở tầng ứng dụng, được mô tả trong RFC 3261. Nó không truyền tiếng nói. Việc nó làm là thiết lập, sửa đổi và kết thúc các phiên: gọi đi đâu, ai gọi ai, dùng codec gì, luồng thoại thật (mang bởi RTP) sẽ đi qua địa chỉ và cổng nào. Nói cách khác, SIP là phần lễ tân, còn RTP là phần hội thoại.

Vài đặc điểm khiến SIP thành mục tiêu ngọt:

Nó là text-based, cú pháp giống HTTP, rất dễ đọc và dễ chế tác request bằng script.
Mặc định nó thường chạy trên UDP cổng 5060, một cổng UDP mở là món quà cho việc quét hàng loạt vì không cần bắt tay ba bước như TCP.
Cơ chế xác thực mặc định là Digest authentication (kế thừa từ HTTP), dựa trên username và password. Nếu ai đó đoán được cặp này, họ hợp lệ trong mắt tổng đài.
Một tổng đài PBX theo định nghĩa là thứ được nối vào mạng thoại có tính cước. Đằng sau nó là tiền thật, tính theo phút, chảy về các nhà mạng.

Điểm cuối cùng là mấu chốt. Đánh sập một web server chỉ khiến trang die. Chiếm được một extension SIP có quyền gọi ra ngoài nghĩa là kẻ tấn công có một máy in tiền, và người trả hoá đơn là chúng ta.

Lịch sử và động cơ: cước lậu để làm gì

Trò này không mới. Từ thời tổng đài analog, dân phreaking đã tìm cách gọi chùa. Nhưng VoIP biến nó thành một ngành công nghiệp có động cơ tài chính rõ ràng, thông qua thứ gọi là IRSF (International Revenue Share Fraud).

Cơ chế đại khái thế này. Có những đầu số quốc tế thuộc dạng premium rate, cước gọi tới rất cao. Một bên trung gian ký hợp đồng ăn chia doanh thu với nhà mạng sở hữu dải số đó: cứ có cuộc gọi đến, họ được chia phần. Kẻ tấn công chỉ cần bơm thật nhiều phút gọi vào các số này, từ tổng đài của nạn nhân, rồi thu tiền chia sẻ doanh thu. Nạn nhân trả cước, nhà mạng trung gian và kẻ tấn công chia nhau khoản lời. Đây là lý do các cuộc tấn công thường nhắm vào những đầu số lạ ở các quốc gia xa xôi, và thường bùng nổ vào cuối tuần hay ngày lễ, khi không ai ngồi nhìn dashboard.

Vì có tiền thật ở cuối đường, việc quét SIP diễn ra liên tục và tự động hoá. Nếu chúng ta bật một tổng đài mới với IP public, thường chỉ trong vòng vài giờ tới vài ngày log đã đầy các lượt thăm dò từ khắp nơi.

Giải phẫu một cuộc tấn công

Chuỗi tấn công điển hình đi qua bốn bước, mỗi bước đều để lại dấu vết đặc trưng trong log.

Bước 1: Quét và điểm danh máy chủ

Kẻ tấn công quét dải IP để tìm cổng SIP mở. Công cụ kinh điển là SIPVicious với script svmap, hoặc đơn giản là nmap với option quét UDP. Cách nhận diện một máy chủ SIP là gửi một request và xem nó có trả lời theo đúng ngữ pháp SIP không.

Một request thăm dò kiểu OPTIONS trông như sau:

OPTIONS sip:100@target.example SIP/2.0
Via: SIP/2.0/UDP scanner:5061;branch=z9hG4bK-1
From: "sipvicious" <sip:100@target.example>;tag=abc
To: <sip:100@target.example>
Call-ID: 1@scanner
CSeq: 1 OPTIONS
User-Agent: friendly-scanner
Max-Forwards: 70

Chi tiết đắt giá ở đây là header User-Agent: friendly-scanner. Đó là chữ ký mặc định của SIPVicious. Trong nhiều năm nó là dấu hiệu số một để chặn: thấy friendly-scanner gõ cửa thì gần như chắc chắn không phải bạn bè. Dĩ nhiên kẻ tấn công có kinh nghiệm sẽ đổi header này, nên nó chỉ lọc được lớp ồn ào nhất.

Bước 2: Điểm danh extension

Khi biết có tổng đài, việc tiếp theo là tìm xem những extension nào tồn tại. Kẻ tấn công dò lần lượt các số máy nhánh (100, 101, 200, 1000…) bằng cách gửi REGISTER hoặc INVITE và đọc mã trả về.

Điểm yếu kinh điển của cấu hình sơ sài là tổng đài phản hồi khác nhau cho extension tồn tại và extension không tồn tại. Ví dụ, với một số máy có thật nhưng sai mật khẩu, Asterisk trả 401 Unauthorized (kèm thử thách xác thực). Với một số không tồn tại, nó trả 404 Not Found. Chỉ cần so sánh mã trả về, kẻ tấn công lập được danh sách extension hợp lệ mà chưa cần đoán một mật khẩu nào. Đây là một dạng rò rỉ thông tin qua kênh phụ (user enumeration).

Bước 3: Dò mật khẩu

Có danh sách extension rồi, bước còn lại là brute-force mật khẩu. SIP Digest hoạt động theo kiểu thử thách và phản hồi (challenge-response): server gửi một nonce, client băm mật khẩu cùng nonce đó rồi gửi lại. Công cụ như svcrack của SIPVicious tự động thử hàng nghìn mật khẩu.

Đây là nơi các thói quen tệ trả giá. Rất nhiều triển khai đặt mật khẩu extension trùng số extension (1001/1001), hoặc dùng những chuỗi như 1234, secret, tên công ty. Với mật khẩu yếu, brute-force thành công chỉ trong ít phút.

Bước 4: Bơm cuộc gọi

Khi đã có một extension hợp lệ với mật khẩu đúng, kẻ tấn công đăng ký như một máy nhánh thật và bắt đầu gửi INVITE tới các đầu số premium quốc tế. Nếu dialplan cho phép extension đó gọi ra ngoài không giới hạn, cuộc gọi đi qua trung kế (trunk) và đồng hồ cước bắt đầu chạy. Họ thường mở nhiều kênh song song để nhồi càng nhiều phút càng tốt trước khi bị phát hiện.

Toàn bộ chuỗi này, từ quét tới cuộc gọi đầu tiên, hoàn toàn tự động hoá và có thể hoàn tất trong vài chục phút nếu tổng đài mở và mật khẩu yếu.

Vì sao DMZ cộng auth chặn được

Bây giờ tới phần thú vị: hai biện pháp cơ bản, và lý do chúng hiệu quả không phải vì thần kỳ mà vì chúng cắt đúng vào các giả định của kẻ tấn công.

DMZ: giới hạn ai được phép gõ cửa

DMZ (demilitarized zone) là một phân đoạn mạng nằm giữa Internet và mạng nội bộ, tách bởi firewall. Ý tưởng gốc của DMZ không phải giấu tổng đài đi, mà là kiểm soát chặt luồng vào ra của nó và cô lập nó khỏi phần còn lại của hệ thống nếu nó bị chiếm.

Với một tổng đài, tư duy DMZ thực dụng là: SIP không nên là dịch vụ mở cho cả hành tinh. Trong đa số môi trường doanh nghiệp, ta biết trước ai cần kết nối tới nó:

Trung kế SIP chỉ đến từ dải IP của nhà cung cấp dịch vụ thoại (ITSP). Dải này cố định và ít.
Điện thoại nội bộ nằm trong LAN, không cần đi qua IP public.
Nhân viên làm việc từ xa nên vào qua VPN, chứ không phải phơi SIP thẳng ra ngoài.

Firewall của DMZ vì thế chỉ cần cho phép cổng SIP và dải RTP từ đúng các nguồn đã biết, chặn phần còn lại theo mặc định (default deny). Điều này vô hiệu hoá gần như toàn bộ Bước 1 và Bước 2. Máy quét ở một IP ngẫu nhiên trên Internet không còn gửi được gói tin nào tới tổng đài, nên không thể điểm danh máy chủ, không thể điểm danh extension, không có gì để brute-force. Kẻ tấn công không phá được một cánh cửa mà nó không chạm tới được.

Một hệ quả kiến trúc quan trọng: nếu bắt buộc phải mở SIP ra ngoài (ví dụ có softphone di động), đặt trước nó một SBC (Session Border Controller) hoặc một SIP proxy làm lớp chắn, thay vì để Asterisk trực tiếp đối mặt Internet. SBC được thiết kế đúng cho việc chịu đòn ở biên: rate limiting, lọc theo địa lý, phát hiện quét.

Auth: biến việc đoán thành bất khả thi kinh tế

Firewall cắt được kẻ lạ, nhưng không cắt được kẻ tấn công đến từ một nguồn hợp lệ, hay trường hợp buộc phải mở dịch vụ. Đây là lúc xác thực gánh phần còn lại. Ba nguyên tắc:

Mật khẩu mạnh và ngẫu nhiên cho mọi extension. Một chuỗi ngẫu nhiên đủ dài biến không gian brute-force thành thiên văn. Khi mỗi lần thử tốn thời gian mạng, đoán một mật khẩu 16 ký tự ngẫu nhiên là bất khả thi về mặt thực tế. Điều này giết Bước 3.
Chống điểm danh extension. Trong Asterisk, tham số alwaysauthreject=yes (với chan_sip) hoặc hành vi tương đương trong res_pjsip bắt tổng đài phản hồi giống hệt nhau cho extension sai và mật khẩu sai. Kẻ tấn công không còn phân biệt được 401 với 404, nên không dựng được danh sách extension. Điều này bịt lỗ rò ở Bước 2.
Khoá theo tần suất thất bại. Kết hợp Asterisk với fail2ban: đọc log, thấy một IP liên tục xác thực hỏng thì tự thêm luật firewall chặn IP đó. Đây là lưới an toàn cho cả những nỗ lực brute-force lọt qua.

Ngoài xác thực, còn một lớp phòng thủ mà mình xem là bắt buộc chứ không phải tuỳ chọn: giới hạn dialplan. Ngay cả khi một extension bị chiếm, nếu dialplan của nó không được phép gọi quốc tế thì cuộc gọi cước lậu không đi ra được. Nguyên tắc đặc quyền tối thiểu áp vào thoại: một máy nhánh lễ tân chỉ cần gọi nội bộ và nội hạt thì đừng cho nó gọi tới đầu số vệ tinh ở nửa kia địa cầu. Thêm trần chi tiêu hoặc cảnh báo khi lưu lượng quốc tế vọt bất thường, và ngay cả khi mọi lớp trên thủng, thiệt hại vẫn bị chặn trần.

Một cấu hình phòng thủ tối thiểu

Gộp lại, một tổng đài Asterisk chịu được các đợt quét thường trực có những đặc điểm sau:

; res_pjsip / chan_sip: không tiết lộ extension nào tồn tại
alwaysauthreject = yes

; bắt buộc xác thực cho mọi cuộc gọi vào
allowguest = no

; mật khẩu extension: chuỗi ngẫu nhiên dài, không trùng số máy
; ví dụ secret = 9fK2$pQ7wL!x4Rt8

; dialplan: chỉ mở quốc tế cho những extension thật sự cần

Kèm theo đó là firewall default-deny chỉ mở SIP/RTP cho dải ITSP và VPN, fail2ban đọc log Asterisk, và giám sát cước để bắt bất thường sớm. Không có món nào trong đây là công nghệ mới. Tất cả đều đã có từ hơn một thập kỷ. Điều đáng nói là phần lớn các vụ cước lậu vẫn xảy ra vì thiếu đúng những thứ nhàm chán này: một tổng đài dựng nhanh cho kịp việc, IP public, mật khẩu mặc định, và không ai nhìn lại.

Kết

Điều mình thấy đáng suy nghĩ nhất về toll fraud là nó gần như không dùng lỗ hổng phần mềm nào. Không có CVE nào cần vá, không có exploit tinh vi. Nó chỉ khai thác một chuỗi các mặc định hợp lý cho môi trường tin cậy nhưng nguy hiểm khi phơi ra môi trường thù địch: SIP mở, phản hồi khác nhau cho extension tồn tại, mật khẩu dễ đoán, dialplan rộng rãi. Firewall và xác thực chặn được nó không phải vì chúng thông minh, mà vì chúng lập lại đúng các ranh giới tin cậy mà kiến trúc mặc định đã xoá đi.

Có lẽ đó là bài học chung của nhiều thứ trong bảo mật: phần lớn phòng thủ hiệu quả không nằm ở công cụ mới, mà ở việc thành thật trả lời câu hỏi ai thật sự cần chạm vào cái này, rồi mạnh dạn chặn tất cả những gì còn lại. Với thoại, câu hỏi đó có một sức nặng cụ thể: mỗi phút bỏ lửng là tiền thật.

Tài liệu tham khảo

RFC 3261, SIP: Session Initiation Protocol, IETF.
RFC 3550, RTP: A Transport Protocol for Real-Time Applications, IETF.
Asterisk Documentation, Security và PJSIP Configuration, Sangoma (docs.asterisk.org).
SIPVicious, bộ công cụ kiểm thử SIP của Sandro Gauci (github.com/EnableSecurity/sipvicious).
Communications Fraud Control Association (CFCA), báo cáo thường niên về International Revenue Share Fraud.
fail2ban, tài liệu chính thức (www.fail2ban.org).

SPF, DKIM, DMARC cho một tên miền cá nhân

Mon, 01 Jun 2026 09:00:00 +0000

Ba bản ghi DNS nhỏ, ba lớp niềm tin chồng lên nhau, đủ để một tên miền cá nhân thôi bị mạo danh.

Vì sao email lại dễ bị giả mạo?

Về lý thuyết, SMTP (Simple Mail Transfer Protocol), giao thức mà cả thế giới dùng để gửi email, được thiết kế từ năm 1982 trong một thế giới mạng nhỏ và tin nhau. Nó không có bất kỳ cơ chế nào để kiểm tra xem người gửi có thực sự là người mà họ tự xưng hay không. Cụ thể, trường From: mà chúng ta nhìn thấy trong hộp thư chỉ là một dòng text do bên gửi tự điền vào. Không có gì ngăn tôi mở một kết nối SMTP và khai báo mình là ceo@ngan-hang-cua-ban.com.

Đây chính là gốc rễ của email spoofing và phần lớn các chiến dịch phishing. Ba giao thức chúng ta sẽ bàn hôm nay, SPF, DKIM và DMARC, được sinh ra để vá lỗ hổng niềm tin đó mà không cần thay đổi bản thân SMTP. Chúng hoạt động như những lớp chứng thực chồng lên nhau, đặt trong DNS, để bên nhận có thể tự hỏi: “email này có đúng là đến từ hạ tầng được phép gửi thay cho domain này không?”.

Một chi tiết quan trọng cần nắm ngay từ đầu: có tới hai địa chỉ người gửi trong một email. Một là envelope sender (còn gọi là MAIL FROM hay Return-Path), dùng trong quá trình vận chuyển. Hai là header From:, cái mà người dùng thực sự nhìn thấy. SPF kiểm tra cái thứ nhất, còn DMARC quan tâm cái thứ hai. Nhầm lẫn giữa hai địa chỉ này là nguồn gốc của rất nhiều cấu hình sai.

SPF: ai được phép gửi thay cho tôi?

SPF (Sender Policy Framework, RFC 7208) trả lời một câu hỏi đơn giản: những địa chỉ IP nào được phép gửi email cho domain của tôi? Chủ domain công bố một danh sách trong một bản ghi TXT trên DNS. Khi một mail server nhận email, nó lấy domain trong envelope sender, tra bản ghi SPF, rồi so IP thực tế của bên gửi với danh sách đó.

Với một domain cá nhân dùng, ví dụ, một nhà cung cấp email nào đó, bản ghi có thể trông như thế này:

example.com.  IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

Đọc từ trái sang phải:

v=spf1 là phiên bản, bắt buộc.
include:... nói rằng “hãy tin cả danh sách IP mà domain kia công bố”. Ta dùng cái này thay vì liệt kê IP thủ công, vì nhà cung cấp có thể đổi IP bất cứ lúc nào.
-all ở cuối là phần quan trọng nhất. Nó nghĩa là “mọi nguồn khác không nằm trong danh sách trên đều FAIL”. Dấu - là hard fail. Nếu dùng ~all (dấu ngã) thì là soft fail, tức “đáng ngờ nhưng vẫn nhận”.

Có vài cạm bẫy thực tế cần nhớ. SPF có giới hạn cứng 10 lần tra cứu DNS (mỗi include, a, mx, redirect đều tính). Vượt quá là kết quả trả về permerror và coi như SPF hỏng. Vì vậy đừng nhồi năm sáu include vào một domain cá nhân. Điểm yếu lớn thứ hai: SPF kiểm tra envelope sender, không phải header From: mà người dùng thấy. Cho nên chỉ riêng SPF không hề chống được kẻ giả mạo trường From: hiển thị. Và điểm yếu thứ ba: SPF vỡ khi email được forward, vì máy chủ trung gian gửi lại bằng IP của chính nó, một IP không nằm trong danh sách.

DKIM: chữ ký số cho từng lá thư

DKIM (DomainKeys Identified Mail, RFC 6376) tiếp cận vấn đề theo hướng mật mã học. Thay vì hỏi “IP này có được phép không”, DKIM gắn một chữ ký số vào phần header của mỗi email. Máy chủ gửi giữ private key, còn public key được công bố trên DNS. Bên nhận lấy public key, xác minh chữ ký, và nếu khớp thì chắc chắn hai điều: email thực sự do domain đó ký, và nội dung (các header và body được ký) không bị sửa trên đường đi.

Chữ ký nằm trong một header tên DKIM-Signature, đại khái:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2026;
  h=from:to:subject:date; bh=<hash cua body>;
  b=<chu ky so>...

Trong đó d= là domain ký, s= là selector. Selector cho phép một domain có nhiều cặp khóa song song (ví dụ cho nhiều dịch vụ gửi khác nhau, hoặc để xoay vòng khóa). Public key tương ứng nằm ở:

mail2026._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=<public key base64>"

Ưu điểm lớn của DKIM so với SPF là nó sống sót qua forward, vì chữ ký đi kèm nội dung chứ không phụ thuộc IP. Nhược điểm: nếu một máy chủ trung gian sửa nội dung (thêm dòng quảng cáo footer, sửa charset, gắn thẻ mailing list), chữ ký sẽ vỡ. Với domain cá nhân, lời khuyên thực tế là dùng khóa RSA 2048-bit (1024-bit đã bị coi là yếu), và nếu tự vận hành thì nên đặt lịch xoay selector định kỳ, ví dụ mỗi năm một lần.

DMARC: dán hai mảnh lại và ra chính sách

Đây là mảnh ghép làm cho hai cái trên trở nên có ý nghĩa. DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) làm ba việc.

Thứ nhất, nó buộc kết quả SPF hoặc DKIM phải alignment với header From: mà người dùng nhìn thấy. Nhớ lại rằng SPF kiểm tra envelope sender, DKIM kiểm tra d=. Kẻ tấn công hoàn toàn có thể có một email pass SPF cho domain rác của hắn, nhưng lại đặt From: là domain của bạn. DMARC chặn đúng trò này: nó yêu cầu domain đã pass (qua SPF hoặc DKIM) phải trùng với domain trong From:. Chỉ cần một trong hai align là email đạt DMARC.

Thứ hai, nó cho chủ domain công bố một chính sách về việc phải làm gì khi một email không đạt: none (không làm gì, chỉ theo dõi), quarantine (đẩy vào spam), hoặc reject (từ chối thẳng).

Thứ ba, và đây là phần hay bị bỏ quên, DMARC cung cấp báo cáo. Bên nhận sẽ gửi lại cho bạn các báo cáo tổng hợp (aggregate report, thường gọi là rua) hằng ngày, liệt kê IP nào đã gửi thay cho domain bạn và kết quả xác thực ra sao.

Một bản ghi DMARC cho domain cá nhân đặt tại _dmarc.example.com:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100"

adkim=s và aspf=s bật chế độ strict alignment (domain phải khớp chính xác, không chỉ khớp phần domain gốc). pct là phần trăm email áp dụng chính sách, hữu ích khi triển khai từ từ.

Trình tự triển khai cho một domain cá nhân

Cái sai lớn nhất người ta hay mắc là nhảy thẳng vào p=reject, rồi phát hiện một dịch vụ hợp pháp (bản tin, form liên hệ, hóa đơn) bị chặn mất. Cách an toàn là leo thang dần dần.

Bật SPF với -all, liệt kê đúng những dịch vụ bạn thực sự dùng để gửi.
Bật DKIM trên nhà cung cấp email chính, kiểm tra một email tự gửi cho mình xem chữ ký có pass không.
Công bố DMARC ở mức p=none kèm rua=. Ở giai đoạn này bạn không chặn gì cả, chỉ quan sát báo cáo trong vài tuần.
Khi báo cáo cho thấy mọi luồng gửi hợp pháp đều align sạch, nâng lên p=quarantine, rồi cuối cùng p=reject. Có thể dùng pct=25 rồi pct=50 để tăng dần.

Đọc báo cáo rua bằng mắt thường khá cực vì nó là XML nén. Có những dịch vụ miễn phí giúp trực quan hóa, nhưng nếu thích tự làm thì một script Python nhỏ parse XML cũng đủ dùng cho một domain cá nhân lưu lượng thấp.

Vài suy nghĩ cuối

Điều thú vị là cả ba giao thức này đều không sửa gì trong SMTP. Chúng chỉ chồng thêm các tuyên bố có kiểm chứng lên trên một giao thức vốn cả tin, và giao phần thực thi cho bên nhận. Nghĩa là hiệu quả của chúng phụ thuộc vào việc bên nhận có chịu kiểm tra hay không. Một domain cá nhân đặt p=reject hoàn hảo vẫn có thể bị giả mạo tới một máy chủ nào đó không thèm đọc DMARC.

Và cũng nên thành thật: bộ ba này chống được kẻ giả mạo chính xác domain của bạn, nhưng không cản được lookalike domain (kiểu examp1e.com với số một), cũng không cản được display name giả. Chúng là một lớp phòng thủ rất đáng làm, gần như miễn phí, nhưng không phải viên đạn bạc. Với tôi, giá trị lớn nhất của việc triển khai đầy đủ trên một domain cá nhân không hẳn là chặn được kẻ xấu, mà là cái báo cáo rua: lần đầu tiên bạn thực sự nhìn thấy ai đang gửi email nhân danh mình.

Tài liệu tham khảo

RFC 7208, Sender Policy Framework (SPF), IETF.
RFC 6376, DomainKeys Identified Mail (DKIM) Signatures, IETF.
RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC), IETF.
RFC 5321, Simple Mail Transfer Protocol, IETF.
M3AAWG, Email Authentication Best Common Practices.
Wikipedia: Email authentication, DMARC, DomainKeys Identified Mail.

WireGuard hay bastion host cổ điển

Sat, 23 May 2026 09:00:00 +0000

Mỗi khi cần cho một người từ Internet chạm được vào một máy nằm sâu trong mạng nội bộ, chúng ta đứng trước cùng một câu hỏi cũ: mở một cửa, hay dựng một đường hầm. Bastion host là cái cửa. WireGuard là cái đường hầm. Bài này mình muốn đặt hai thứ đó cạnh nhau, không phải để tuyên bố cái nào thắng, mà để nhìn cho rõ mỗi lựa chọn đang gánh giúp chúng ta phần rủi ro nào và đẩy phần rủi ro nào sang chỗ khác.

Bài toán: truy cập từ xa vào thứ không nên phơi ra Internet

Về lý thuyết, một máy chủ database hay một bảng điều khiển quản trị không bao giờ nên có một public IP lắng nghe trực tiếp trên Internet. Lý do rất đơn giản: bất cứ port nào mở ra công cộng đều là một bề mặt tấn công (attack surface) bị quét liên tục, mỗi ngày, bởi các bot tự động. Chỉ cần một lỗ hổng chưa vá trong dịch vụ đó, hoặc một mật khẩu yếu, là xong.

Nhưng người vận hành thì vẫn phải vào được. Kỹ sư cần SSH vào máy, DBA cần nối tới cổng 5432 của Postgres, người trực đêm cần mở dashboard nội bộ. Vấn đề trở thành: làm sao cho đúng người vào được mà không biến cả khu vực nội bộ thành thứ ai cũng gõ cửa được.

Có hai trường phái trả lời câu hỏi này, và chúng đại diện cho hai triết lý mạng khác nhau.

Bastion host: mô hình cái cổng thành

Bastion host (đôi khi gọi là jump host hoặc jump box) là một máy chủ được làm cứng (hardened) đặt ở vùng đệm giữa Internet và mạng nội bộ, thường là trong một DMZ (demilitarized zone). Nó là điểm duy nhất được phép nhận kết nối từ bên ngoài. Muốn vào máy nội bộ, bạn phải SSH vào bastion trước, rồi từ bastion mới nhảy tiếp vào bên trong.

Ý tưởng cốt lõi là thu hẹp điểm vào. Thay vì mười máy nội bộ mỗi máy mở một port ra Internet, chúng ta chỉ mở đúng một máy, và dồn toàn bộ công sức phòng thủ, giám sát, ghi log vào đúng máy đó.

Lịch sử

Cái tên bastion mượn từ kiến trúc quân sự: pháo đài có những mấu lồi (bastion) nhô ra để tập trung hỏa lực phòng thủ. Trong ngành mạng, thuật ngữ này được phổ biến hóa qua bài viết kinh điển của Marcus Ranum đầu thập niên 1990 và sau đó được đóng đinh trong cuốn Building Internet Firewalls của Chapman và Zwicky (O’Reilly). Ở thời kỳ mà firewall dạng packet filter còn thô sơ, ý tưởng “một máy hy sinh, được làm cứng tối đa, đặt ngoài cùng” là một bước tiến lớn về tư duy phòng thủ theo lớp.

Bastion trong thực tế trông thế nào

Một cấu hình SSH điển hình dùng bastion nhìn như sau ở phía client:

Host bastion
    HostName bastion.example.com
    User ops
    IdentityFile ~/.ssh/id_ed25519

Host db-internal
    HostName 10.0.4.12
    User dba
    ProxyJump bastion

Khi gõ ssh db-internal, SSH tự động nối tới bastion trước rồi mở một đường xuyên qua nó tới 10.0.4.12. Máy nội bộ không hề có route ra Internet, nó chỉ tin tưởng các kết nối đến từ bastion.

Điểm mạnh của mô hình này:

Một điểm để canh gác. Toàn bộ log truy cập, session recording, xác thực đa yếu tố đều gom về một chỗ. Muốn biết ai đã vào hệ thống đêm qua, chúng ta chỉ cần đọc log của bastion.
Không cần phần mềm lạ trên máy đích. Máy nội bộ chỉ chạy SSH server bình thường. Đây là ưu điểm với những hệ thống cũ, thiết bị mạng, hoặc chỗ mà chính sách không cho cài thêm gì.
Chuẩn công nghệ đã chín. SSH, firewall, DMZ là những thứ mọi sysadmin đều hiểu.

Điểm yếu cũng nằm ngay trong thiết kế:

Bastion là mục tiêu tập trung. Chiếm được bastion nghĩa là có bàn đạp vào toàn bộ nội bộ. Nó vừa là điểm phòng thủ, vừa là điểm thất bại đơn (single point of failure) nếu bị hạ.
Bản thân nó vẫn lắng nghe công khai. Port 22 của bastion vẫn phơi ra Internet, vẫn bị quét, vẫn ăn brute-force. Chúng ta chỉ thu nó về một máy chứ không làm nó biến mất.
Vận hành thủ công dễ trôi. Quản lý authorized_keys, xoay vòng khóa, gỡ quyền khi người nghỉ việc: tất cả đều là quy trình con người, và quy trình con người thì mục ruỗng theo thời gian.

WireGuard: mô hình đường hầm mã hóa

WireGuard là một VPN hiện đại, gọn tới mức đáng ngạc nhiên: nhân của nó chỉ khoảng vài nghìn dòng code, so với hàng trăm nghìn dòng của IPsec hay OpenVPN. Nó được Jason A. Donenfeld viết, và từ phiên bản 5.6 đã được hợp nhất thẳng vào nhân Linux mainline, một dấu hiệu rất mạnh về chất lượng.

Thay vì mở một cửa để người ta gõ, WireGuard dựng một giao diện mạng ảo mã hóa giữa hai máy. Khi tunnel đã lên, máy từ xa hành xử như thể nó đang nằm ngay trong mạng nội bộ, với một địa chỉ IP nội bộ riêng.

Vì sao nó khác về bản chất

Điểm khiến WireGuard thú vị dưới góc nhìn bảo mật không phải tốc độ, mà là cách nó xử lý gói tin lạ. WireGuard xác thực bằng cặp khóa công khai kiểu Curve25519, và có một tính chất gọi là im lặng mật mã (cryptographic silence): nếu một gói UDP đến mà không được ký bởi một khóa mà nó đã biết, WireGuard vứt gói đó đi mà không trả lời gì cả.

Hệ quả rất lớn. Với con mắt của một máy quét Internet, cái port UDP của WireGuard trông như một port đóng, thậm chí như một máy không tồn tại. Không có banner, không có handshake để dò, không có gì để brute-force. Bạn không thể tấn công một dịch vụ mà bạn không chứng minh được là nó đang lắng nghe. Đây chính là tinh thần zero-trust ở tầng mạng: không chứng minh được danh tính bằng khóa thì thậm chí không tồn tại một cuộc hội thoại.

Một cấu hình tối thiểu

Phía server, file /etc/wireguard/wg0.conf có thể gọn như sau:

[Interface]
Address = 10.100.0.1/24
ListenPort = 51820
PrivateKey = <khóa-riêng-của-server>

[Peer]
PublicKey = <khóa-công-khai-của-laptop-kỹ-sư>
AllowedIPs = 10.100.0.2/32

Phía client:

[Interface]
Address = 10.100.0.2/24
PrivateKey = <khóa-riêng-của-laptop>

[Peer]
PublicKey = <khóa-công-khai-của-server>
Endpoint = vpn.example.com:51820
AllowedIPs = 10.0.0.0/16
PersistentKeepalive = 25

Bật lên bằng wg-quick up wg0. Trường AllowedIPs ở đây làm hai việc cùng lúc: nó vừa là bảng định tuyến, vừa là danh sách kiểm soát truy cập mật mã. Peer này chỉ được phép gửi và nhận gói cho đúng dải IP ghi trong đó, không hơn.

Đánh đổi của WireGuard

WireGuard không miễn phí về mặt chi phí vận hành, nó chỉ dời chi phí sang chỗ khác.

Nó bảo vệ đường ống, không bảo vệ danh tính con người. WireGuard trả lời câu hỏi “gói tin này có được ký bởi khóa hợp lệ không”, chứ không trả lời “con người sau khóa này còn được phép vào không”. Bản thân giao thức không có khái niệm hết hạn phiên, không có tích hợp danh bạ người dùng, không có xác thực đa yếu tố. Một khi laptop có khóa riêng, nó vào được cho tới khi bạn tự tay gỡ khóa công khai đó khỏi server.
Quản lý khóa quy mô lớn là việc thật. Mười người thì sửa file tay được. Năm trăm người, xoay vòng khóa, cấp và thu quyền theo nhóm thì bạn cần một lớp điều phối bên trên. Đây chính là chỗ các sản phẩm như Tailscale hay Netbird ra đời: chúng bọc WireGuard bằng một control plane lo phần danh tính và phân phối khóa.
Tunnel phẳng dễ cấp quyền quá tay. Vì máy từ xa hành xử như đang ở trong nội bộ, nếu AllowedIPs ghi rộng, một laptop bị chiếm sẽ có đường đi thẳng vào rất nhiều thứ. Nguyên tắc đặc quyền tối thiểu phải được thực thi cẩn thận qua từng peer và qua firewall nội bộ, chứ không tự động có.

Vậy chọn cái nào

Mình nghĩ cách đặt câu hỏi “cái nào tốt hơn” là sai ngay từ đầu, vì hai thứ này bảo vệ hai tầng khác nhau và thực tế bổ sung cho nhau rất tốt.

Bastion mạnh ở tầng kiểm toán danh tính con người: ai vào, lúc nào, gõ lệnh gì, ghi lại được hết ở một điểm. WireGuard mạnh ở tầng giấu bề mặt mạng: biến port ra thành vô hình với kẻ quét, cắt đứt gần như toàn bộ tầng lớp tấn công brute-force và dò dịch vụ.

Một kiến trúc tỉnh táo thường xếp chồng cả hai. Đặt bastion host phía sau một endpoint WireGuard: kẻ tấn công ngoài Internet không nhìn thấy cả port 22 lẫn dịch vụ VPN theo cách thông thường, còn khi đã qua tunnel thì mọi truy cập vẫn bị dồn qua bastion để ghi log và soi. Lúc này WireGuard lo phần “chỉ những cỗ máy hợp lệ mới được phép nói chuyện”, còn bastion lo phần “và đây chính xác là con người nào đã làm gì”.

Nếu buộc phải chọn một, mình để lại vài câu hỏi thay cho kết luận. Bạn cần chứng minh ai đã truy cập, hay chỉ cần chặn kẻ lạ ngay từ cổng? Đội của bạn đủ kỷ luật để duy trì quy trình khóa và log thủ công không? Máy đích có cho cài thêm phần mềm không, hay là thiết bị cũ chỉ nói được SSH? Câu trả lời cho những câu này quyết định nhiều hơn là bản thân công nghệ. Zero-trust không phải một sản phẩm bạn mua, nó là một tư thế bạn phải liên tục giữ, và cả bastion lẫn WireGuard chỉ là công cụ để giữ tư thế đó.

Tài liệu tham khảo

WireGuard: Next Generation Kernel Network Tunnel, Jason A. Donenfeld (whitepaper chính thức tại wireguard.com)
Tài liệu chính thức WireGuard: https://www.wireguard.com/
Building Internet Firewalls, Elizabeth D. Zwicky, Simon Cooper, D. Brendan Chapman, O’Reilly
Wikipedia: Bastion host
Wikipedia: WireGuard
NIST SP 800-207, Zero Trust Architecture

Đọc một bản packet capture

Thu, 14 May 2026 09:00:00 +0000

Có một kỹ năng mà mình nghĩ ai làm hạ tầng hay bảo mật cũng nên có: mở một file .pcap ra và đọc được nó đang kể chuyện gì. Không phải để làm màu, mà vì rất nhiều lúc log của ứng dụng nói dối, log của firewall thì mơ hồ, còn gói tin thì không biết nói dối. Nó là thứ thật nhất mà chúng ta có: đúng những byte đã chạy qua dây.

Bài này mình đi qua một luồng TCP từ lúc bắt, tới lúc đọc từng lớp, rồi cuối cùng nối lại với access policy trên firewall theo giá trị IP và protocol. Mình cố giữ nó thực tế, dùng đúng công cụ mà chúng ta hay có sẵn: tcpdump để bắt, Wireshark (hoặc tshark) để mổ xẻ.

Packet capture là gì?

Về lý thuyết, packet capture là việc sao chép lại các khung dữ liệu đi qua một giao diện mạng, rồi lưu chúng ra đĩa theo một định dạng đọc được sau này. Định dạng phổ biến là pcap và bản mới hơn là pcapng. Mỗi bản ghi trong file gồm một timestamp, độ dài gói, và toàn bộ các byte đã bắt được, thường bắt đầu từ lớp liên kết (Ethernet) trở lên.

Điểm quan trọng: capture không diễn giải gì cả. Nó chỉ chép byte. Việc diễn giải “đây là một cái SYN của TCP” là do phần mềm đọc (Wireshark) làm sau, dựa trên chồng giao thức. Cho nên khi đọc, chúng ta luôn đọc theo từng lớp: Ethernet -> IP -> TCP/UDP -> payload. Mô hình quen thuộc ở đây là chồng TCP/IP, và mỗi lớp bọc lớp trên nó lại (encapsulation).

Bắt gói bằng tcpdump

tcpdump là công cụ dòng lệnh gọn nhất để bắt. Trên một máy Linux, để bắt lưu lượng tới một web server và ghi ra file, mình hay dùng:

sudo tcpdump -i eth0 -n -s 0 -w capture.pcap 'tcp port 443 and host 203.0.113.10'

Giải thích nhanh vài cờ, vì mỗi cái đều có lý do:

-i eth0: chọn giao diện cần bắt. Dùng -i any nếu muốn bắt hết mọi interface (nhưng khung sẽ ở dạng linux “cooked”, hơi khác Ethernet chuẩn).
-n: đừng phân giải DNS ngược. Nếu không, tcpdump sẽ tự đi hỏi DNS và làm bẩn chính bản capture của bạn.
-s 0: bắt toàn bộ độ dài gói (snap length không giới hạn). Ngày xưa mặc định hay cắt ngắn payload, làm mất dữ liệu tầng ứng dụng.
-w capture.pcap: ghi nhị phân ra file thay vì in ra màn hình.
Phần trong nháy đơn là BPF filter (Berkeley Packet Filter): chỉ bắt những gì khớp. Ở đây là TCP cổng 443 và có liên quan tới host 203.0.113.10.

Cái BPF filter này là filter lúc bắt (capture filter). Nó khác với display filter của Wireshark, chỗ này rất dễ nhầm. Capture filter quyết định gói nào được ghi xuống đĩa, nên nếu lọc sai lúc bắt thì mất luôn, không lấy lại được. Vì vậy khi chưa chắc, mình thường bắt rộng rồi lọc hẹp lúc đọc.

Muốn xem nhanh tại chỗ mà không mở Wireshark, thêm -A (in payload dạng ASCII) hoặc -X (hex kèm ASCII):

sudo tcpdump -i eth0 -n -A 'tcp port 80 and host 203.0.113.10'

Bắt tay ba bước của TCP

Trước khi mở Wireshark, cần nhắc lại luồng mà chúng ta sẽ đi tìm. Một kết nối TCP luôn mở đầu bằng three-way handshake:

Client gửi một gói có cờ SYN, kèm một số thứ tự khởi đầu (sequence number).
Server trả lại SYN, ACK: vừa xác nhận SYN của client, vừa gửi sequence number của chính nó.
Client gửi ACK để chốt. Từ đây kết nối ở trạng thái ESTABLISHED và dữ liệu bắt đầu chảy.

Khi đóng, chúng ta sẽ thấy FIN, ACK ở cả hai chiều, hoặc một cú RST nếu ai đó cắt phũ. Cái đẹp của việc đọc capture là ba bước này hiện ra rõ mồn một, và nếu nó không hiện ra đủ, đó chính là manh mối.

Mở bằng Wireshark và lọc lại

Mở capture.pcap trong Wireshark, việc đầu tiên là thu hẹp tầm nhìn bằng display filter. Display filter khác BPF ở chỗ nó chỉ ẩn/hiện chứ không xoá gì, nên cứ thoải mái gõ. Vài filter mình dùng gần như mỗi ngày:

ip.addr == 203.0.113.10
tcp.port == 443
tcp.flags.syn == 1 and tcp.flags.ack == 0
tcp.analysis.retransmission
tcp.stream eq 0

Dòng tcp.flags.syn == 1 and tcp.flags.ack == 0 lọc ra đúng các gói SYN thuần (client mở kết nối), rất tiện để đếm xem có bao nhiêu lần thử bắt tay. Dòng tcp.analysis.retransmission cho thấy gói bị truyền lại, tức là có mất mát hoặc nghẽn đâu đó. Còn tcp.stream eq 0 gom đúng một cuộc hội thoại TCP lại thành một luồng, để chúng ta không bị lẫn giữa nhiều kết nối song song.

Một mẹo rất thực dụng: chuột phải vào một gói bất kỳ trong luồng và chọn Follow -> TCP Stream. Wireshark sẽ ráp lại toàn bộ payload theo đúng thứ tự sequence number, hiển thị hai chiều bằng hai màu. Với HTTP thô, bạn đọc thẳng ra request và response. Với TLS thì chỉ thấy dữ liệu mã hoá, nhưng phần bắt tay (ClientHello, ServerHello) vẫn ở dạng rõ và nói cho bạn biết SNI, phiên bản, bộ mã.

Đọc từng lớp của một gói

Chọn một gói SYN đầu luồng, khung chi tiết của Wireshark bung ra theo đúng chồng giao thức. Mình đọc từ dưới lên:

Frame: siêu dữ liệu do capture thêm vào, gồm timestamp và độ dài. Không phải dữ liệu trên dây, chỉ là ghi chú của công cụ.
Ethernet II: địa chỉ MAC nguồn và đích, cùng trường EtherType (0x0800 nghĩa là bên trong là IPv4). Lớp này chỉ có ý nghĩa trong phạm vi một chặng L2.
Internet Protocol: đây là chỗ có IP nguồn và đích, TTL, và trường Protocol. Với TCP, trường Protocol mang giá trị 6. Con số này quan trọng, mình sẽ quay lại nó ở phần policy.
Transmission Control Protocol: cổng nguồn, cổng đích (443), sequence và acknowledgment number, và quan trọng nhất là các cờ. Ở gói đầu chúng ta muốn thấy đúng cờ SYN bật, các cờ khác tắt.

Nếu bạn thích dòng lệnh, tshark in ra đúng những trường này mà không cần giao diện:

tshark -r capture.pcap -Y 'tcp.flags.syn==1' \
  -T fields -e ip.src -e ip.dst -e ip.proto -e tcp.dstport -e tcp.flags

Lệnh này cho ra một bảng gọn gàng: IP nguồn, IP đích, số hiệu protocol, cổng đích, và cờ. Đây gần như chính là ngôn ngữ mà một access policy nói.

Nối capture với access policy

Đây là phần mình thấy hay nhất, vì nó biến việc đọc gói từ một trò tò mò thành một công cụ chẩn đoán thật.

Một access policy trên firewall, về bản chất, là một danh sách luật có thứ tự, mỗi luật khớp gói theo vài trường rồi quyết định allow hay deny. Những trường mà luật hay dùng chính là những trường chúng ta vừa đọc trong capture:

IP nguồn và đích (từ lớp IP).
Protocol (trường Protocol của IP: 6 cho TCP, 17 cho UDP, 1 cho ICMP).
Cổng nguồn và đích (từ lớp TCP hoặc UDP).

Hãy tưởng tượng một luật rất đời thường, viết theo kiểu iptables:

iptables -A INPUT -p tcp -s 203.0.113.10 --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j DROP

Luật đầu cho phép TCP tới cổng 443 nếu nguồn là 203.0.113.10. Luật sau chặn mọi TCP tới 443 còn lại. Bây giờ ghép nó với những gì đọc được trong capture:

Nếu chúng ta thấy đủ SYN -> SYN,ACK -> ACK, nghĩa là gói khớp luật ACCEPT và chính sách đang cho qua. Đường đi thông.
Nếu chỉ thấy SYN lặp lại nhiều lần, cách nhau đều đặn (thường theo cấp số nhân do TCP tự thử lại), mà không có SYN,ACK đáp, thì gói nhiều khả năng bị một luật DROP nuốt im lặng. Firewall vứt gói và không nói gì, nên client cứ kiên nhẫn gửi lại.
Nếu thấy một RST trả về gần như tức thì sau SYN, đó thường là kiểu từ chối chủ động: có thể là luật REJECT (khác DROP), hoặc đúng là không có dịch vụ nào nghe ở cổng đó.

Chính sự khác nhau giữa “im lặng” và “bị đá về” đã là một thông tin chẩn đoán. DROP làm client treo tới khi timeout, còn REJECT hoặc cổng đóng làm client thất bại nhanh. Chỉ cần nhìn có RST hay không, chúng ta đã đoán được kiểu luật đang tác động, mà không cần đăng nhập vào firewall.

Cách nối này rất máy móc, và đó là điểm mạnh của nó. Lấy ip.src, ip.dst, ip.proto, tcp.dstport từ capture, đặt cạnh bảng luật, dò xem gói khớp luật nào đầu tiên (vì luật xử lý theo thứ tự trên xuống). Kết quả khớp đó phải giải thích được hành vi bạn thấy trên dây. Nếu không khớp, hoặc là bạn đọc sai luật, hoặc có một thiết bị khác (NAT, một firewall khác, một security group) đang chen vào giữa.

Nhân tiện nói tới NAT: nếu giữa client và server có NAT, thì IP nguồn bạn thấy ở hai đầu capture sẽ khác nhau. Bắt ở phía client thấy IP nội bộ, bắt ở phía server thấy IP đã dịch. Khi đối chiếu với policy, phải biết luật đang viết theo IP trước hay sau khi dịch. Đây là chỗ người ta hay chẩn đoán nhầm nhất, và cũng là lý do vì sao đôi khi cần bắt ở cả hai đầu rồi so timestamp và cổng để ghép cặp lại đúng luồng.

Một quy trình đọc gọn

Gộp lại, khi cầm một capture để điều tra một kết nối nghi bị chặn, mình thường đi thế này:

Lọc về đúng luồng: ip.addr == <đích> and tcp.port == <cổng>, hoặc khoá theo tcp.stream.
Tìm gói SYN đầu tiên. Có SYN,ACK đáp lại không?
Nếu có: handshake xong, vấn đề nằm ở tầng cao hơn (ứng dụng, TLS, HTTP), không phải ở access policy L3/L4.
Nếu chỉ có SYN lặp lại: nghi DROP. Đối chiếu ip.proto và cổng với các luật deny.
Nếu có RST nhanh: nghi REJECT hoặc cổng đóng. Kiểm tra dịch vụ và luật reject.
Kiểm tra retransmission để loại trừ nguyên nhân mất gói thuần tuý (mạng tậm tịt) trước khi đổ lỗi cho policy.

Mình để ý là bước 3 hay bị bỏ qua. Rất nhiều lần “firewall chặn” thật ra là handshake TCP hoàn tất bình thường, còn lỗi nằm ở TLS bắt tay thất bại hay ứng dụng trả về mã lỗi. Capture giúp chúng ta phân định rạch ròi ranh giới đó: tới đâu là mạng, từ đâu là ứng dụng.

Kết

Đọc packet capture, nói cho cùng, là tập nhìn cùng một sự việc ở nhiều lớp: MAC ở L2, IP ở L3, cờ TCP ở L4, và payload ở trên. Access policy cũng chỉ đang đọc vài trong số những trường đó rồi ra phán quyết. Khi bạn quen với việc lấy ip.src, ip.dst, ip.proto, cổng từ một gói và soi ngược vào bảng luật, thì phần lớn các ca “không kết nối được” sẽ tự phân loại thành vài nhóm rất rõ.

Mình không nghĩ có một kết luận gọn ghẽ kiểu “cứ làm X là xong”, vì mỗi hạ tầng có cách chen NAT, proxy, và stateful inspection riêng. Nhưng cái khung ở trên, đọc theo lớp rồi ghép với luật theo IP và protocol, thì gần như luôn là điểm khởi đầu đúng. Phần còn lại là kiên nhẫn cuộn qua từng gói.

Tài liệu tham khảo

tcpdump và libpcap, tài liệu chính thức: tcpdump.org
Wireshark User’s Guide và tham chiếu display filter: wireshark.org
RFC 9293, Transmission Control Protocol (TCP)
RFC 791, Internet Protocol (định nghĩa trường Protocol và IPv4 header)
IANA Protocol Numbers (bảng số hiệu cho trường Protocol của IP)
Trang man của iptables và netfilter, netfilter.org

Milvus năm 2025

Tue, 05 May 2026 09:00:00 +0000

Mấy năm trước mình có viết một bài về Milvus, nhưng API hồi đó đã lỗi thời gần hết. Bài này mình viết lại từ đầu theo cách dùng hiện tại, kèm một demo tìm ảnh tương tự trên một triệu vector chạy trong Docker. Mình sẽ cố gắng giải thích tại sao lại chọn index này thay vì index kia, chứ không chỉ dán lệnh cho xong.

Milvus là gì?

Về lý thuyết, Milvus là một vector database: một cơ sở dữ liệu chuyên để lưu và truy vấn vector embedding. Khác với database quan hệ truyền thống nơi ta hỏi “tìm dòng có id = 42”, với vector database ta hỏi “tìm 10 vector gần nhất với vector truy vấn này”. Phép “gần nhất” ở đây là approximate nearest neighbor (ANN), gần đúng chứ không tuyệt đối, và chính chữ “approximate” đó là toàn bộ lý do vector database tồn tại.

Tại sao lại cần gần đúng? Vì tìm chính xác k vector gần nhất trong hàng triệu vector chiều cao (ví dụ 768 hoặc 1536 chiều) bằng cách so từng cặp là brute force, độ phức tạp O(N * d) cho mỗi truy vấn. Với một triệu vector 768 chiều, mỗi câu query phải làm gần một tỉ phép nhân. Chấp nhận sai số vài phần trăm để đổi lấy tốc độ nhanh hơn hàng trăm lần: đó là giao kèo cốt lõi của ANN.

Milvus đóng gói phần ANN đó lại, thêm vào lớp lưu trữ, phân mảnh (sharding), sao lưu, lọc theo metadata, và một giao diện để ta không phải tự cài HNSW hay IVF bằng tay. Đổi lại, nó là một hệ phân tán khá nặng: bản đầy đủ chạy trên nhiều thành phần (etcd, MinIO, message queue). May là có bản Milvus Lite và bản standalone bằng Docker cho việc học và làm demo.

Một chút lịch sử

Milvus ra đời khoảng năm 2019 từ Zilliz, và sau đó được trao cho LF AI & Data Foundation (một nhánh của Linux Foundation). Giai đoạn 1.x nó còn khá đơn giản. Bước ngoặt là bản 2.x, viết lại theo kiến trúc tách rời tính toán và lưu trữ (compute và storage), nhắm tới quy mô lớn và khả năng scale ngang.

Điểm khiến API cũ trong bài trước của mình hết dùng được là gói PyMilvus. Bản cũ dùng lối Collection, connections.connect() khá dài dòng. Từ khoảng cuối chu kỳ 2.4 trở đi, PyMilvus giới thiệu lớp MilvusClient, gom hầu hết thao tác vào một đối tượng duy nhất. Bài này mình dùng lối MilvusClient vì nó là cách được khuyến nghị hiện tại và ngắn hơn nhiều.

HNSW so với IVF

Đây là quyết định quan trọng nhất khi dùng Milvus, quan trọng hơn cả việc chọn Milvus hay đối thủ. Có hai họ index phổ biến, và chúng đại diện cho hai triết lý khác nhau.

IVF: chia không gian thành ô

IVF (Inverted File) hoạt động theo kiểu phân cụm. Lúc build index, Milvus chạy k-means để chia toàn bộ vector thành nlist cụm, mỗi cụm có một tâm (centroid). Khi truy vấn, thay vì so với tất cả, ta chỉ so với vector nằm trong nprobe cụm gần vector truy vấn nhất.

nlist: số cụm khi build. Nhiều cụm thì mỗi cụm nhỏ, quét nhanh, nhưng dễ bỏ sót vector nằm sát ranh giới cụm.
nprobe: số cụm sẽ quét khi tìm. Tăng nprobe thì recall tăng, tốc độ giảm. Đây là núm vặn recall/tốc độ lúc chạy.

IVF thường đi kèm nén để tiết kiệm RAM. IVF_FLAT giữ nguyên vector gốc (chính xác nhất, tốn RAM nhất). IVF_SQ8 nén mỗi chiều xuống 1 byte. IVF_PQ dùng product quantization, nén rất mạnh nhưng đánh đổi độ chính xác. Điểm mạnh của họ IVF là thời gian build nhanh và tốn ít bộ nhớ hơn.

HNSW: đồ thị nhiều tầng

HNSW (Hierarchical Navigable Small World) là một dạng đồ thị. Mỗi vector là một đỉnh, được nối với các vector lân cận thành một đồ thị “thế giới nhỏ” có nhiều tầng, tầng trên thưa để nhảy xa, tầng dưới dày để tinh chỉnh. Truy vấn là đi bộ trên đồ thị: bắt đầu ở tầng cao, tham lam đi về phía vector truy vấn, rồi tụt dần xuống tầng thấp.

M: số cạnh tối đa mỗi đỉnh. M lớn thì đồ thị dày, recall cao, nhưng tốn RAM và build lâu.
efConstruction: độ rộng tìm kiếm lúc build. Lớn thì đồ thị chất lượng hơn, build chậm hơn.
ef (hoặc efSearch): độ rộng tìm kiếm lúc query. Đây là núm recall/tốc độ lúc chạy, tương tự nprobe của IVF.

HNSW thường cho recall cao và độ trễ thấp nhất ở cùng mức recall, nên nó là lựa chọn mặc định hợp lý cho phần lớn ứng dụng. Cái giá là tốn RAM (phải giữ cả đồ thị lẫn vector trong bộ nhớ) và build lâu hơn IVF.

Vậy chọn cái nào?

Một cách nghĩ đơn giản:

Dữ liệu vừa phải, cần độ trễ thấp và recall cao, có đủ RAM: chọn HNSW.
Dữ liệu rất lớn, RAM là ràng buộc, chấp nhận recall thấp hơn chút: chọn IVF_PQ hoặc IVF_SQ8.
Chỉ vài chục nghìn vector: đôi khi FLAT (brute force, chính xác 100%) là đủ và đơn giản nhất. Đừng tối ưu sớm.

Với demo một triệu vector bên dưới, mình chọn HNSW vì một triệu vector vẫn nằm gọn trong RAM của một máy để bàn bình thường, và mình muốn recall cao để kết quả tìm ảnh nhìn cho ra hồn.

Chạy Milvus standalone trong Docker

Milvus có sẵn script biên dịch cấu hình Docker Compose. Cách nhanh nhất để có một node standalone:

# Tải script cài đặt chính thức
curl -sfL https://raw.githubusercontent.com/milvus-io/milvus/master/scripts/standalone_embed.sh -o standalone_embed.sh

# Khởi động Milvus standalone
bash standalone_embed.sh start

Lệnh này dựng một container Milvus lắng nghe ở cổng 19530 (gRPC) và 9091 (health/metrics). Kiểm tra sống chưa:

curl http://localhost:9091/healthz

Nếu bạn chỉ muốn thử cực nhanh mà không cần Docker, có thể dùng Milvus Lite (nhúng thẳng vào tiến trình Python, dữ liệu lưu trong một file cục bộ). Nhưng Milvus Lite hợp cho tập nhỏ; với một triệu vector mình khuyên chạy bản standalone trong Docker.

Demo: tìm ảnh trên một triệu vector

Ý tưởng: biến mỗi ảnh thành một vector bằng một mô hình embedding, nạp vào Milvus, rồi cho một ảnh truy vấn để tìm những ảnh giống nhất. Ở đây mình tách phần trích xuất đặc trưng ra khỏi phần Milvus, vì phần embedding tùy thuộc mô hình bạn dùng (CLIP, ResNet, hay bất kỳ mô hình vision nào). Điều Milvus quan tâm chỉ là: một vector float32 có số chiều cố định.

Giả sử ta đã có embedding dạng CLIP ViT-B/32, tức 512 chiều, chuẩn hóa L2. Cài client:

pip install pymilvus numpy

Tạo collection và index

import numpy as np
from pymilvus import MilvusClient, DataType

client = MilvusClient(uri="http://localhost:19530")

DIM = 512
COLLECTION = "image_search"

# Xóa nếu đã tồn tại, để chạy lại cho sạch
if client.has_collection(COLLECTION):
    client.drop_collection(COLLECTION)

# Định nghĩa schema: id + vector + đường dẫn ảnh làm metadata
schema = client.create_schema(auto_id=False, enable_dynamic_field=False)
schema.add_field("id", DataType.INT64, is_primary=True)
schema.add_field("embedding", DataType.FLOAT_VECTOR, dim=DIM)
schema.add_field("path", DataType.VARCHAR, max_length=512)

# Tham số index HNSW + metric COSINE (hợp với embedding đã chuẩn hóa)
index_params = client.prepare_index_params()
index_params.add_index(
    field_name="embedding",
    index_type="HNSW",
    metric_type="COSINE",
    params={"M": 16, "efConstruction": 200},
)

client.create_collection(
    collection_name=COLLECTION,
    schema=schema,
    index_params=index_params,
)

Một điểm dễ sai: metric_type. Nếu embedding đã chuẩn hóa L2 thì COSINE và tích vô hướng (IP) cho thứ hạng như nhau, nhưng nếu chưa chuẩn hóa mà lại dùng IP thì kết quả sẽ lệch. Chọn metric đúng với cách bạn tạo vector, đừng để mặc định quyết định thay.

Nạp một triệu vector

Ở đây mình sinh vector ngẫu nhiên để minh họa hình dạng dữ liệu và cách chèn theo lô (batch). Trong thực tế bạn thay np.random.random bằng embedding thật của ảnh.

TOTAL = 1_000_000
BATCH = 10_000

for start in range(0, TOTAL, BATCH):
    n = min(BATCH, TOTAL - start)
    vecs = np.random.random((n, DIM)).astype(np.float32)
    # Chuẩn hóa L2 cho khớp với metric COSINE
    vecs /= np.linalg.norm(vecs, axis=1, keepdims=True)

    rows = [
        {
            "id": start + i,
            "embedding": vecs[i].tolist(),
            "path": f"/data/img/{start + i}.jpg",
        }
        for i in range(n)
    ]
    client.insert(collection_name=COLLECTION, data=rows)
    print(f"đã chèn {start + n}/{TOTAL}")

# Đẩy dữ liệu từ buffer xuống lớp lưu trữ bền
client.flush(COLLECTION)

Chèn theo lô cỡ vài nghìn tới vài chục nghìn dòng là hợp lý: lô quá nhỏ thì tốn round-trip mạng, lô quá lớn thì tốn RAM và dễ chạm giới hạn kích thước message. Sau khi chèn xong nhớ flush để dữ liệu được ghi bền, rồi load collection vào bộ nhớ trước khi tìm:

client.load_collection(COLLECTION)

Truy vấn ảnh giống nhất

# Vector truy vấn: trong thực tế là embedding của ảnh người dùng đưa vào
query = np.random.random((1, DIM)).astype(np.float32)
query /= np.linalg.norm(query, axis=1, keepdims=True)

results = client.search(
    collection_name=COLLECTION,
    data=query.tolist(),
    limit=10,
    search_params={"metric_type": "COSINE", "params": {"ef": 64}},
    output_fields=["path"],
)

for hit in results[0]:
    print(hit["id"], round(hit["distance"], 4), hit["entity"]["path"])

Núm cần vặn ở đây là ef. Với ef=64 bạn được tốc độ tốt; nếu recall chưa đủ, tăng dần lên 128, 256 và đo lại. Nguyên tắc: ef phải lớn hơn hoặc bằng limit, và tăng ef luôn đánh đổi độ trễ.

Lọc theo metadata

Điểm mà một vector database ăn đứt việc tự cài HNSW ở nhà là lọc kết hợp. Ví dụ chỉ tìm trong ảnh thuộc một thư mục:

results = client.search(
    collection_name=COLLECTION,
    data=query.tolist(),
    limit=10,
    filter='path like "/data/img/1%"',
    search_params={"metric_type": "COSINE", "params": {"ef": 64}},
    output_fields=["path"],
)

Cần lưu ý: lọc quá gắt (chỉ còn vài phần trăm dữ liệu thỏa điều kiện) có thể làm recall của ANN tụt, vì đồ thị HNSW được xây trên toàn bộ dữ liệu chứ không riêng phần đã lọc. Đây là một góc khuất hay bị bỏ qua khi ghép filter với vector search, và cũng là chỗ các vector database khác nhau ở chất lượng cài đặt.

Vài điều đọng lại

Nếu phải rút gọn: Milvus không phải thứ để cài cho mọi dự án. Với vài chục nghìn vector, một thư viện như FAISS nhúng thẳng trong tiến trình, hoặc thậm chí một numpy brute force, có khi đơn giản và đủ nhanh hơn. Milvus bắt đầu đáng giá khi bạn cần: dữ liệu vượt quá RAM một máy, cập nhật liên tục, lọc metadata phức tạp, hoặc nhiều dịch vụ cùng truy vấn một kho vector.

Còn về HNSW so với IVF, thú thật mình không nghĩ có câu trả lời “đúng” cho mọi trường hợp. Cách trung thực nhất vẫn là dựng cả hai trên đúng dữ liệu của bạn, đo recall và độ trễ ở vài mức tham số, rồi chọn theo con số chứ không theo lời khuyên trên mạng (kể cả bài này). Vector search là một lĩnh vực mà trực giác hay đánh lừa ta, và cái giá của việc đo đạc thường rẻ hơn cái giá của việc chọn sai index rồi phải build lại một triệu vector lúc nửa đêm.

Tài liệu tham khảo

Milvus documentation, https://milvus.io/docs
PyMilvus documentation, https://milvus.io/docs/quickstart.md
Malkov & Yashunin, “Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs” (bài báo gốc về HNSW)
FAISS wiki, “The index factory” (giải thích IVF, PQ, Flat), https://github.com/facebookresearch/faiss/wiki
LF AI & Data Foundation, trang dự án Milvus

Gán nhãn từ loại bằng HMM và Viterbi

Sun, 26 Apr 2026 09:00:00 +0000

Trong bài về Hidden Markov Model (HMM) trước đây, chúng ta đã dừng lại ở phần lý thuyết: mô hình có gì, các xác suất được định nghĩa ra sao, và ba bài toán kinh điển mà một HMM phải trả lời. Bài này mình muốn khép lại phần còn dang dở đó bằng một thứ cụ thể sờ được: một bộ gán nhãn từ loại (Part-of-Speech tagging) cho tiếng Việt, chạy được, có code, và giải thích từng bước tại sao nó ra kết quả như vậy.

Ý tưởng cốt lõi: gán nhãn từ loại là bài toán tìm chuỗi trạng thái ẩn hợp lý nhất cho một chuỗi quan sát, và thuật toán Viterbi chính là công cụ giải nó.

Gán nhãn từ loại là gì?

Part-of-Speech tagging, hay gọi tắt là POS tagging, là việc gán cho mỗi từ trong câu một nhãn từ loại: danh từ, động từ, tính từ, giới từ, và vân vân. Ví dụ với câu “học sinh học bài”, ta muốn máy đọc ra:

học sinh/N  học/V  bài/N

Nghe qua thì tưởng đơn giản, tra từ điển là xong. Nhưng vấn đề nằm ở chỗ nhập nhằng (ambiguity). Từ “học” trong ví dụ trên vừa có thể là danh từ (trong “học sinh”) vừa có thể là động từ (trong “học bài”). Con người phân biệt được nhờ ngữ cảnh, còn máy thì cần một mô hình để lượng hóa cái ngữ cảnh đó. Tiếng Việt còn khó thêm một bậc vì ranh giới từ không trùng ranh giới âm tiết: “học sinh” là một từ gồm hai âm tiết, nên trước khi gán nhãn chúng ta ngầm giả định câu đã được tách từ (word segmentation) xong xuôi. Trong bài này mình giả định đầu vào đã là chuỗi token đã tách từ, để tập trung vào phần gán nhãn.

Vì sao dùng HMM cho việc này?

Ta mô hình hóa câu như sau. Chuỗi các nhãn từ loại t_1, t_2, ..., t_n là chuỗi trạng thái ẩn: ta không quan sát trực tiếp được chúng, đó chính là thứ cần suy ra. Chuỗi các từ w_1, w_2, ..., w_n là chuỗi quan sát: đây là dữ liệu ta nhìn thấy. Mục tiêu là tìm chuỗi nhãn có xác suất hậu nghiệm lớn nhất:

t* = argmax P(t_1..t_n | w_1..w_n)

Dùng quy tắc Bayes và bỏ mẫu số (vì nó không phụ thuộc vào t), ta được:

t* = argmax P(w_1..w_n | t_1..t_n) · P(t_1..t_n)

HMM đơn giản hóa vế phải bằng hai giả định quen thuộc. Thứ nhất, giả định Markov: một nhãn chỉ phụ thuộc vào nhãn ngay trước nó, chứ không phải cả lịch sử. Thứ hai, giả định độc lập của quan sát: một từ chỉ phụ thuộc vào nhãn của chính nó. Với hai giả định này, biểu thức gọn lại thành tích của hai loại xác suất:

t* = argmax ∏ P(w_i | t_i) · P(t_i | t_{i-1})

Trong đó có hai bảng số cần học từ dữ liệu:

Xác suất phát xạ (emission) P(w_i | t_i): khi trạng thái là nhãn t_i, khả năng sinh ra từ w_i là bao nhiêu. Ví dụ P(học | V).
Xác suất chuyển (transition) P(t_i | t_{i-1}): khả năng nhãn t_i đứng ngay sau nhãn t_{i-1}. Ví dụ P(V | N), khả năng một động từ đi ngay sau một danh từ.

Đây chính là mô hình HMM bậc một, còn gọi là bigram tagger vì transition chỉ nhìn một nhãn lùi về trước.

Huấn luyện: chỉ là đếm

Điểm dễ chịu của HMM có giám sát là “huấn luyện” thực ra chỉ là đếm tần suất trên một kho ngữ liệu (corpus) đã được gán nhãn tay. Không có gradient descent, không có epoch. Ta ước lượng theo hợp lý cực đại (maximum likelihood estimation):

P(w | t) = count(t, w) / count(t)

P(t_2 | t_1) = count(t_1, t_2) / count(t_1)

Ví dụ, nếu trong corpus nhãn N xuất hiện 1000 lần và trong đó từ “bài” đi kèm nhãn N là 12 lần, thì P(bài | N) = 12 / 1000 = 0.012.

Có một cái bẫy kinh điển ở đây: nếu một từ chưa từng xuất hiện với nhãn nào đó, xác suất phát xạ sẽ bằng 0, và vì cả chuỗi là một tích, chỉ một số 0 duy nhất sẽ giết chết toàn bộ đường đi. Đây là vấn đề từ chưa gặp (out-of-vocabulary) và thưa dữ liệu (data sparsity). Cách xử lý phổ biến là làm mượt (smoothing), đơn giản nhất là add-one smoothing (Laplace): cộng một lượng nhỏ vào mọi tần suất để không xác suất nào tuyệt đối bằng 0. Trong code phía dưới mình dùng một hằng số nhỏ cho từ chưa gặp.

Vì sao cần Viterbi, không thể brute force?

Giả sử có T nhãn khác nhau và câu dài n từ. Số chuỗi nhãn khả dĩ là T^n. Với T = 15 nhãn và câu 20 từ, con số đó đã là 15^20, lớn hơn số nguyên tử ta muốn đếm trong một buổi chiều. Không thể duyệt hết.

Thuật toán Viterbi giải bài toán này bằng quy hoạch động (dynamic programming). Nhận xét mấu chốt: đường đi tốt nhất kết thúc ở nhãn t tại vị trí i nhất định phải chứa đường đi tốt nhất kết thúc ở một nhãn nào đó tại vị trí i-1. Nói cách khác, ta không cần nhớ mọi đường, chỉ cần nhớ với mỗi (vị trí, nhãn) thì xác suất của đường tốt nhất dẫn tới đó là bao nhiêu, và nó tới từ nhãn nào.

Ta định nghĩa V[i][t] là xác suất của chuỗi tốt nhất kết thúc bằng nhãn t tại từ thứ i. Công thức truy hồi:

V[i][t] = max over t' của ( V[i-1][t'] · P(t | t') ) · P(w_i | t)

Song song với V, ta lưu một bảng backpointer để nhớ nhãn t' nào đã cho giá trị max, phục vụ việc lần ngược (backtracking) ra chuỗi cuối. Độ phức tạp giảm từ T^n xuống còn O(n · T^2): tuyến tính theo độ dài câu, bình phương theo số nhãn. Đó là toàn bộ phép màu.

Một chi tiết kỹ thuật đáng nói: nhân nhiều xác suất nhỏ với nhau sẽ dẫn tới tràn số dưới (underflow), số bé tới mức máy tính làm tròn thành 0. Cách chuẩn là làm việc trong không gian log: thay tích bằng tổng các log, thay max của tích bằng max của tổng. Kết quả argmax không đổi vì log là hàm đơn điệu tăng. Code dưới đây dùng log để an toàn.

Cài đặt cho tiếng Việt

Dưới đây là một bộ gán nhãn HMM bigram hoàn chỉnh bằng Python thuần, không phụ thuộc thư viện ngoài. Mình để corpus huấn luyện nhỏ ngay trong code để bài tự chạy được, còn trong thực tế bạn sẽ nạp một corpus lớn như VLSP hoặc Vietnamese Treebank.

import math
from collections import defaultdict, Counter

# Corpus mẫu: mỗi câu là danh sách (từ_đã_tách, nhãn).
# N: danh từ, V: động từ, A: tính từ, P: đại từ, E: giới từ.
train = [
    [("học_sinh", "N"), ("học", "V"), ("bài", "N")],
    [("tôi", "P"), ("học", "V"), ("tiếng_Việt", "N")],
    [("bài", "N"), ("này", "P"), ("khó", "A")],
    [("cô_giáo", "N"), ("giảng", "V"), ("bài", "N")],
    [("tôi", "P"), ("đọc", "V"), ("sách", "N"), ("hay", "A")],
    [("học_sinh", "N"), ("đọc", "V"), ("sách", "N"), ("ở", "E"), ("trường", "N")],
]

START = "<s>"

def train_hmm(data):
    trans = defaultdict(Counter)   # trans[t_prev][t] = đếm chuyển
    emit = defaultdict(Counter)    # emit[t][w]      = đếm phát xạ
    tag_count = Counter()
    for sent in data:
        prev = START
        for word, tag in sent:
            trans[prev][tag] += 1
            emit[tag][word] += 1
            tag_count[tag] += 1
            prev = tag
    return trans, emit, tag_count

trans, emit, tag_count = train_hmm(train)
TAGS = list(tag_count.keys())

Phần quan trọng là hai hàm xác suất, có làm mượt. Ta cho từ chưa gặp một xác suất phát xạ nhỏ nhưng khác 0, để nó không tự động bị loại.

UNK_EMIT = 1e-6  # xác suất phát xạ cho từ ngoài từ vựng

def log_emit(tag, word):
    total = tag_count[tag]
    c = emit[tag][word]
    if c == 0:
        return math.log(UNK_EMIT)
    return math.log(c / total)

def log_trans(prev, tag):
    total = sum(trans[prev].values())
    c = trans[prev][tag]
    # add-one smoothing cho xác suất chuyển
    return math.log((c + 1) / (total + len(TAGS)))

Và đây là trái tim của bài, thuật toán Viterbi trong không gian log:

def viterbi(sentence):
    n = len(sentence)
    V = [{} for _ in range(n)]
    back = [{} for _ in range(n)]

    # Bước khởi tạo: từ đầu tiên, nhãn chuyển từ START.
    for t in TAGS:
        V[0][t] = log_trans(START, t) + log_emit(t, sentence[0])
        back[0][t] = START

    # Bước truy hồi.
    for i in range(1, n):
        for t in TAGS:
            best_prev, best_score = None, float("-inf")
            for t_prev in TAGS:
                score = V[i - 1][t_prev] + log_trans(t_prev, t)
                if score > best_score:
                    best_score, best_prev = score, t_prev
            V[i][t] = best_score + log_emit(t, sentence[i])
            back[i][t] = best_prev

    # Lần ngược: tìm nhãn cuối tốt nhất rồi đi lùi.
    last_tag = max(V[n - 1], key=V[n - 1].get)
    tags = [last_tag]
    for i in range(n - 1, 0, -1):
        last_tag = back[i][last_tag]
        tags.append(last_tag)
    tags.reverse()
    return list(zip(sentence, tags))

print(viterbi(["học_sinh", "học", "bài"]))
print(viterbi(["tôi", "đọc", "sách"]))

Kết quả in ra sẽ là:

[('học_sinh', 'N'), ('học', 'V'), ('bài', 'N')]
[('tôi', 'P'), ('đọc', 'V'), ('sách', 'N')]

Chú ý câu đầu: từ “học” được gán đúng là động từ V chứ không phải danh từ, mặc dù nó nằm giữa hai danh từ. Lý do là xác suất chuyển P(V | N) và P(N | V) trong corpus mẫu ủng hộ mẫu hình danh từ, động từ, danh từ hơn là ba danh từ liên tiếp. Đó chính là ngữ cảnh mà mô hình đã học được, chỉ từ việc đếm.

Những chỗ mô hình này còn yếu

Mình muốn thành thật về giới hạn, vì HMM bigram tuy đẹp về mặt sư phạm nhưng còn cách khá xa các bộ gán nhãn hiện đại.

Thứ nhất, cửa sổ ngữ cảnh quá hẹp. Bigram chỉ nhìn một nhãn lùi. Nâng lên trigram (nhìn hai nhãn) thường cải thiện độ chính xác nhưng làm dữ liệu thưa hơn, đòi hỏi smoothing tinh vi hơn như back-off hay nội suy tuyến tính.

Thứ hai, HMM không nhìn được đặc trưng bên trong từ. Một mô hình phân biệt (discriminative) như Conditional Random Field (CRF) có thể dùng đặc trưng như từ có viết hoa không, hậu tố là gì, từ đứng sau là gì, thứ mà HMM sinh tính (generative) không nắm bắt tự nhiên. Với tiếng Việt, thông tin như “từ láy”, “từ Hán Việt”, hay từ lân cận thường rất có giá trị.

Thứ ba, và đây là điều thực tế nhất: các bộ gán nhãn tốt nhất hiện nay dựa trên biểu diễn ngữ cảnh sâu, kiểu BiLSTM-CRF hay các mô hình nền Transformer như PhoBERT cho tiếng Việt. Chúng học được biểu diễn từ theo ngữ cảnh hai chiều, vượt xa giả định Markov một bậc.

Vậy học HMM để làm gì khi đã có Transformer? Mình nghĩ giá trị của nó không nằm ở việc đem đi triển khai, mà ở chỗ nó là mô hình chuỗi tối giản mà bạn có thể hiểu trọn vẹn từ đầu tới cuối. Viterbi không biến mất khi ta lên BiLSTM-CRF: tầng giải mã của CRF vẫn dùng đúng thuật toán quy hoạch động đó để tìm chuỗi nhãn tối ưu. Nắm chắc HMM và Viterbi là nắm chắc cái xương sống mà rất nhiều mô hình chuỗi phức tạp hơn vẫn đang dựa vào. Còn chuyện nó có phải công cụ mình chọn cho một dự án thật hay không, thành thật mà nói, còn tùy dữ liệu và ràng buộc, và mình không nghĩ có một câu trả lời gọn gàng cho mọi trường hợp.

Tài liệu tham khảo

Daniel Jurafsky, James H. Martin, Speech and Language Processing, chương về HMM và POS tagging (bản nháp chương 3 phiên bản 3 có công khai trên trang của tác giả tại Stanford).
L. R. Rabiner, “A Tutorial on Hidden Markov Models and Selected Applications in Speech Recognition”, Proceedings of the IEEE, 1989.
A. J. Viterbi, “Error bounds for convolutional codes and an asymptotically optimum decoding algorithm”, IEEE Transactions on Information Theory, 1967.
Christopher Manning, Hinrich Schütze, Foundations of Statistical Natural Language Processing, MIT Press.
Dat Quoc Nguyen và cộng sự, “PhoBERT: Pre-trained language models for Vietnamese”, Findings of EMNLP 2020.
Trang dự án VLSP (Vietnamese Language and Speech Processing) về các bộ ngữ liệu và nhãn từ loại tiếng Việt.

Cấu trúc một pipeline OCR

Fri, 17 Apr 2026 09:00:00 +0000

OCR là gì?

Về lý thuyết, OCR (Optical Character Recognition, nhận dạng ký tự quang học) là bài toán biến một tấm ảnh chứa chữ thành chuỗi văn bản mà máy tính đọc được. Nghe thì đơn giản, kiểu “nhìn vào ảnh rồi đọc ra chữ”, nhưng nếu chúng ta ngồi bóc tách quá trình đó ra thì sẽ thấy nó không phải là một phép biến đổi duy nhất, mà là một chuỗi các bước nối tiếp nhau. Đó chính là lý do người ta hay gọi nó là một pipeline chứ không phải một mô hình đơn lẻ.

Mình muốn viết bài này như một bản mô tả kiến trúc: một hệ OCR thực dụng được ghép từ những mảnh nào, mỗi mảnh giải quyết chuyện gì, và vì sao tách chúng ra lại tiện hơn là gộp tất cả vào một cục.

Một điểm cần phân biệt ngay từ đầu. Có hai bối cảnh rất khác nhau. Thứ nhất là document OCR: ảnh scan tài liệu, hóa đơn, sách, form. Ảnh loại này thường phẳng, chữ nằm ngay ngắn, nền sạch. Thứ hai là scene text, tức là chữ nằm trong ảnh chụp đời thường: biển hiệu, biển số xe, chữ trên bao bì. Loại thứ hai khó hơn nhiều vì chữ bị nghiêng, cong, phối cảnh, ánh sáng loạn xạ. Kiến trúc pipeline mình mô tả dưới đây áp dụng cho cả hai, nhưng độ nặng của từng bước sẽ khác nhau tùy bối cảnh.

Lịch sử ngắn

OCR không phải chuyện mới. Từ những năm 1970, Ray Kurzweil đã làm ra máy đọc chữ cho người khiếm thị, và các hệ thương mại đọc tài liệu in đã tồn tại rất lâu trước khi deep learning phổ biến. Thời đó cách làm chủ đạo là template matching và trích đặc trưng thủ công: nhị phân hóa ảnh, cắt từng ký tự ra, rồi so khớp hình dạng với bộ mẫu. Cách này chạy tốt với font in chuẩn, nền trắng, nhưng gần như bó tay với chữ viết tay hay ảnh chụp ngoài đời.

Bước ngoặt đến khi mạng nơ-ron tiếp quản cả khâu nhận dạng lẫn khâu phát hiện. Hai ý tưởng đáng nhớ: CTC (Connectionist Temporal Classification, Graves và cộng sự, 2006) cho phép huấn luyện nhận dạng cả dòng chữ mà không cần cắt sẵn từng ký tự, và các mô hình phát hiện vùng chữ dựa trên mạng tích chập giúp tìm chữ trong ảnh phức tạp. Từ đó pipeline OCR hiện đại định hình thành ba khối mà chúng ta sẽ đi qua lần lượt.

Ba khối chính

Một hệ OCR thực dụng, bất kể dùng thư viện nào, gần như luôn có thể chia thành ba khối:

Tiền xử lý (preprocessing): làm sạch và nắn thẳng ảnh đầu vào.
Phát hiện vùng chữ (text detection): tìm ra chữ nằm ở đâu trong ảnh.
Nhận dạng (text recognition): đọc nội dung của từng vùng chữ đã tìm được.

Nhiều khi người ta thêm một khối thứ tư ở cuối là hậu xử lý (post-processing), nhưng ba khối trên là xương sống. Điểm hay của cách chia này là mỗi khối có thể thay thế độc lập. Chúng ta có thể đổi mô hình nhận dạng mà không đụng gì đến khâu phát hiện, hoặc thêm một bước nắn ảnh mới mà phần còn lại vẫn nguyên.

Tiền xử lý

Đây là khối ít hào nhoáng nhất nhưng lại quyết định phần lớn chất lượng cuối cùng. Ý tưởng đơn giản: đưa ảnh về trạng thái mà các khối sau dễ làm việc nhất. Với document OCR, các thao tác kinh điển gồm:

Chuyển xám (grayscale): bỏ màu, giữ độ sáng, giảm chiều dữ liệu.
Nhị phân hóa (binarization): tách chữ (đen) khỏi nền (trắng). Phương pháp Otsu chọn ngưỡng toàn cục tự động, còn adaptive thresholding chọn ngưỡng cục bộ theo từng vùng, hữu ích khi ánh sáng không đều.
Khử nghiêng (deskew): ảnh scan hay bị lệch vài độ. Ước lượng góc nghiêng rồi xoay lại giúp dòng chữ nằm ngang, khâu phát hiện dòng sau đó nhẹ đi nhiều.
Khử nhiễu (denoise) và loại bỏ đường kẻ: với form và bảng biểu, các đường kẻ ô hay dính vào chữ.

Một lưu ý thực dụng: đừng nhị phân hóa quá tay. Với chữ mờ hoặc nền phức tạp, việc ép ảnh về đen trắng có thể xóa mất nét chữ. Nhiều mô hình nhận dạng hiện đại thích ăn ảnh xám hoặc ảnh màu hơn là ảnh nhị phân, vì chúng tự học được cách bỏ nhiễu. Nói cách khác, mức độ tiền xử lý cần cân theo mô hình phía sau, chứ không có công thức chung.

Phát hiện vùng chữ

Khối này trả lời câu hỏi “chữ nằm ở đâu”. Đầu ra thường là một tập các hộp bao (bounding box) hoặc đa giác bao quanh từng từ hoặc từng dòng. Có hai họ tiếp cận chính.

Họ thứ nhất dựa trên hộp (box-based), kế thừa từ các mô hình phát hiện vật thể như SSD hay Faster R-CNN, coi mỗi chữ như một “vật thể” cần khoanh vùng. EAST (Efficient and Accurate Scene Text detector) là một đại diện quen thuộc: nó dự đoán trực tiếp các hộp xoay được, chạy nhanh, hợp với chữ nằm tương đối thẳng.

Họ thứ hai dựa trên phân đoạn (segmentation-based). Thay vì dự đoán hộp, mô hình dự đoán ở mức pixel xem điểm nào thuộc vùng chữ, rồi gộp các pixel lại thành vùng. CRAFT (Character Region Awareness for Text detection) đi theo hướng này, dự đoán vùng ký tự và mức độ liên kết giữa các ký tự, nhờ vậy xử lý tốt chữ cong và chữ có khoảng cách bất thường. DBNet thì học luôn một ngưỡng nhị phân khả vi để tách vùng chữ, cân bằng khá tốt giữa tốc độ và độ chính xác, và là mặc định trong nhiều bộ OCR mã nguồn mở.

Vì sao tách riêng khâu phát hiện? Vì trong đa số ảnh thực tế, chữ chỉ chiếm một phần nhỏ diện tích. Bắt mô hình nhận dạng đọc cả tấm ảnh vừa tốn kém vừa dễ sai. Khoanh vùng trước rồi mới đọc là một cách chia để trị rất tự nhiên.

Nhận dạng

Sau khi có các vùng chữ, mỗi vùng được cắt ra, nắn về dạng chữ nhật (một số hệ có thêm bước rectification để duỗi chữ cong về thẳng), rồi đưa vào khối nhận dạng để đọc nội dung. Đây là nơi có nhiều lựa chọn kiến trúc thú vị nhất.

Kiến trúc kinh điển là CRNN (Convolutional Recurrent Neural Network): một khối tích chập trích đặc trưng từ ảnh dòng chữ, một khối hồi tiếp (thường là BiLSTM) mô hình hóa thứ tự trái sang phải, và một tầng CTC để giải mã ra chuỗi ký tự. Cái đẹp của CTC là nó cho phép huấn luyện với nhãn chỉ là chuỗi văn bản, không cần biết mỗi ký tự nằm ở cột pixel nào. Đại khái, CTC căn chỉnh mềm giữa các cột đặc trưng và các ký tự, cho phép ký tự lặp và ký tự trống rồi thu gọn lại.

Họ thứ hai là attention-based và gần đây là Transformer. Ở đây quá trình đọc được mô hình như một bài toán dịch: từ chuỗi đặc trưng ảnh sinh ra chuỗi ký tự, mỗi bước “chú ý” vào phần ảnh liên quan. TrOCR của Microsoft là một ví dụ, dùng encoder thị giác kiểu ViT và decoder ngôn ngữ kiểu Transformer. Cách này thường mạnh hơn với chữ viết tay và ngữ cảnh phức tạp, vì decoder mang sẵn một chút hiểu biết ngôn ngữ, nhưng đổi lại nặng hơn và cần nhiều dữ liệu hơn.

Chọn cái nào là một trade-off khá rõ. CTC nhẹ, nhanh, dễ triển khai trên thiết bị yếu, rất hợp document OCR font in. Attention/Transformer chính xác hơn ở ca khó nhưng tốn tài nguyên. Trong thực tế nhiều hệ thống chạy CTC làm mặc định và chỉ dồn ảnh khó sang mô hình nặng hơn.

Hậu xử lý, mảnh ghép hay bị quên

Đầu ra thô của khối nhận dạng hiếm khi hoàn hảo. Đây là lúc hậu xử lý kiếm điểm. Một vài thao tác thường gặp: sửa lỗi bằng từ điển hoặc mô hình ngôn ngữ (ví dụ “rn” bị đọc nhầm thành “m”, hay “0” và “O” lẫn lộn), ràng buộc định dạng khi biết trước kiểu dữ liệu (ngày tháng, mã số thuế, biển số), và ghép lại bố cục từ các hộp rời rạc thành đoạn văn, bảng, cột theo đúng thứ tự đọc.

Với hóa đơn và form, khâu này thường quan trọng ngang khâu nhận dạng. Đọc đúng từng ký tự mà xếp sai thứ tự cột thì kết quả vẫn vô dụng. Nhiều hệ hiện nay gọi phần này là layout analysis và đầu tư khá nặng vào nó.

Ghép lại thành một dòng chảy

Nếu tóm cả pipeline vào một câu, nó chạy thế này: ảnh vào, được làm sạch và nắn thẳng ở khâu tiền xử lý, đưa qua khâu phát hiện để tìm các vùng chữ, mỗi vùng được cắt và đọc ở khâu nhận dạng, rồi các mẩu văn bản được ráp lại và sửa ở khâu hậu xử lý. Một số bộ hiện đại gộp phát hiện và nhận dạng vào một mô hình huấn luyện đầu-cuối (end-to-end) để hai khâu tối ưu cùng nhau, nhưng ngay cả khi đó, về mặt khái niệm ba vai trò vẫn còn nguyên đó.

Điểm mình muốn nhấn mạnh là tính module. Khi một hệ OCR đọc sai, việc đầu tiên nên làm không phải là đổi cả mô hình, mà là hỏi lỗi nằm ở khối nào. Nếu vùng chữ bị bỏ sót, đó là chuyện của khâu phát hiện. Nếu vùng đúng mà chữ đọc bậy, đó là khâu nhận dạng hoặc tiền xử lý quá tay. Nếu từng chữ đúng mà bố cục loạn, đó là hậu xử lý. Chia pipeline ra không chỉ để dễ xây, mà còn để dễ chẩn đoán.

Mình để ngỏ một chút ở đây, vì ranh giới giữa các khối đang mờ dần. Các mô hình thị giác-ngôn ngữ lớn giờ có thể “đọc” cả tấm ảnh tài liệu trong một lần suy luận, làm người ta tự hỏi liệu pipeline ba khối có còn là cách đúng để nghĩ nữa không. Cá nhân mình vẫn thấy cách chia này hữu ích, ít nhất là như một khung tư duy, kể cả khi cài đặt thực tế đã gộp nhiều thứ lại. Có thể vài năm nữa mình sẽ nghĩ khác, và như vậy cũng chẳng sao.

Tài liệu tham khảo

Graves et al., “Connectionist Temporal Classification: Labelling Unsegmented Sequence Data with Recurrent Neural Networks”, ICML 2006.
Shi, Bai, Yao, “An End-to-End Trainable Neural Network for Image-based Sequence Recognition (CRNN)”, 2015.
Zhou et al., “EAST: An Efficient and Accurate Scene Text Detector”, CVPR 2017.
Baek et al., “Character Region Awareness for Text Detection (CRAFT)”, CVPR 2019.
Liao et al., “Real-time Scene Text Detection with Differentiable Binarization (DBNet)”, AAAI 2020.
Li et al., “TrOCR: Transformer-based Optical Character Recognition with Pre-trained Models”, 2021.
Tesseract OCR, tài liệu chính thức trên GitHub (tesseract-ocr/tesseract).
Wikipedia, “Optical character recognition”.

Liveness: chống giả mạo trong nhận diện khuôn mặt

Wed, 08 Apr 2026 09:00:00 +0000

Khi nói về nhận diện khuôn mặt, đa số chúng ta hình dung ra bài toán “đây là ai”. Nhưng có một bài toán đứng trước nó, âm thầm hơn, và thường là chỗ hệ thống bị đánh sập đầu tiên: “khuôn mặt trước camera có phải là một người thật đang sống hay không”. Đó chính là liveness detection, hay còn gọi là presentation attack detection (PAD). Bài viết này mình muốn đi qua ba mảnh ghép có liên quan chặt với nhau: embedding, cách chọn ngưỡng (threshold), và cách phòng thủ trước replay attack.

Nhận đúng người là một chuyện, chắc chắn rằng người đó đang thật sự ở đó lại là một chuyện khác.

Về lý thuyết, nhận diện khuôn mặt là gì

Một hệ thống nhận diện khuôn mặt hiện đại gần như luôn xoay quanh khái niệm embedding. Ý tưởng: đưa một ảnh khuôn mặt qua một mạng neural (thường là CNN hoặc gần đây là các kiến trúc transformer), rồi thu về một vector số thực có chiều cố định, ví dụ 128 hoặc 512 chiều. Vector này là face embedding, một điểm trong không gian nhiều chiều.

Điều làm cho embedding hữu ích là cách nó được huấn luyện. Với các hàm mất mát như triplet loss (nổi tiếng qua FaceNet của Google, 2015) hoặc họ margin-based softmax như ArcFace (2019), mạng học sao cho hai ảnh của cùng một người nằm gần nhau, còn hai người khác nhau nằm xa nhau. “Gần” và “xa” ở đây thường đo bằng khoảng cách Euclid hoặc cosine similarity.

Nói cách khác, việc so khớp khuôn mặt quy về so sánh hai vector. Với cosine similarity, ta tính:

cos(a, b) = (a · b) / (‖a‖ · ‖b‖)

Giá trị càng gần 1 thì hai khuôn mặt càng giống. Toàn bộ “trí thông minh” nằm ở mạng tạo embedding, còn khâu so khớp cuối cùng lại đơn giản đến bất ngờ. Đây là điểm đẹp và cũng là điểm nguy hiểm: nếu ai đó đưa vào một ảnh in hoặc một video phát lại mà mạng vẫn tạo ra embedding “đúng người”, thì phần so khớp sẽ vui vẻ gật đầu.

Chọn ngưỡng: nơi lý thuyết gặp thực tế

Giả sử ta đã có embedding của khuôn mặt đang đứng trước camera và embedding tham chiếu lưu trong cơ sở dữ liệu. Ta tính độ tương đồng, rồi phải quyết định: chấp nhận hay từ chối. Ranh giới đó là ngưỡng.

Chọn ngưỡng là một bài toán đánh đổi, không có con số đúng tuyệt đối. Có hai loại lỗi ngược nhau:

False Acceptance Rate (FAR): tỉ lệ hệ thống chấp nhận nhầm người lạ thành người đúng. Đây là lỗi về an ninh.
False Rejection Rate (FRR): tỉ lệ hệ thống từ chối nhầm chính chủ. Đây là lỗi về trải nghiệm.

Kéo ngưỡng khắt khe hơn (đòi similarity cao hơn) thì FAR giảm nhưng FRR tăng, người dùng thật bị làm phiền nhiều hơn. Nới lỏng ngưỡng thì ngược lại. Điểm mà FAR bằng FRR gọi là Equal Error Rate (EER), một con số hay dùng để so sánh chất lượng giữa các mô hình, nhưng nó không nhất thiết là ngưỡng vận hành ta nên chọn.

Chọn ngưỡng thực tế phụ thuộc vào ngữ cảnh sử dụng. Mình hay nghĩ theo kiểu:

Mở khóa điện thoại cá nhân: ưu tiên trải nghiệm, FRR thấp, người ta bực nếu máy không nhận mặt mình.
Xác thực giao dịch ngân hàng hoặc kiểm soát ra vào khu vực nhạy cảm: ưu tiên an ninh, FAR phải cực thấp, chấp nhận đôi khi làm phiền chính chủ.

Một điểm dễ bị bỏ qua: ngưỡng học từ tập kiểm thử trong phòng lab thường lạc quan hơn thực tế. Ánh sáng, góc mặt, camera rẻ tiền, người đeo kính hay đội mũ, tất cả kéo phân bố similarity dịch đi. Vì thế ngưỡng nên được hiệu chỉnh (calibrate) trên dữ liệu gần giống môi trường triển khai, và nên được theo dõi lại theo thời gian. Đây là chỗ mà một con số nghe rất khoa học lại cần khá nhiều phán đoán kỹ thuật.

Và đây là điều quan trọng nhất của phần này: dù ngưỡng có được chỉnh tinh tế đến đâu, nó chỉ trả lời câu hỏi “có giống người đúng không”. Nó không trả lời câu hỏi “đây có phải người thật không”. Một tấm ảnh in sắc nét của bạn có thể tạo ra embedding gần như trùng khớp với chính bạn. Ngưỡng, tự thân nó, hoàn toàn mù trước giả mạo.

Các kiểu tấn công trình diễn

Trước khi nói phòng thủ, cần điểm qua kẻ tấn công định làm gì. Trong thuật ngữ chuẩn (tham chiếu chuẩn ISO/IEC 30107), những cách này gọi chung là presentation attack:

Print attack: in ảnh khuôn mặt nạn nhân ra giấy rồi giơ trước camera. Rẻ và đơn giản đến bất ngờ.
Replay attack: phát lại một video hoặc ảnh khuôn mặt nạn nhân trên màn hình điện thoại, máy tính bảng. Vì là video nên có cả chuyển động, khó phân biệt hơn ảnh in.
3D mask attack: dùng mặt nạ silicone hoặc in 3D. Tốn kém nhưng vượt được nhiều hệ thống chỉ dựa vào hình 2D.
Deepfake / injection attack: tinh vi hơn, không giơ gì trước camera cả mà chèn thẳng luồng video giả vào đường truyền, bỏ qua camera vật lý. Đây là hướng tấn công đang lên và khó chịu nhất.

Trong nhóm này, replay attack đáng bàn nhất vì nó vừa rẻ, vừa mang chuyển động nên đánh lừa được các phòng thủ ngây thơ.

Phòng thủ replay attack

Ý tưởng cốt lõi của mọi liveness detection là tìm bằng chứng cho thấy trước camera là một khuôn mặt sống ba chiều, chứ không phải một bề mặt phẳng phát lại. Có hai nhánh lớn.

Liveness thụ động (passive)

Passive liveness cố phân biệt thật/giả chỉ từ hình ảnh, không yêu cầu người dùng làm gì. Nó bắt các dấu vết mà một màn hình hay tờ giấy để lại:

Moiré pattern: khi chụp lại một màn hình, sự chồng lưới pixel của màn hình và cảm biến camera tạo ra hoa văn gợn sóng đặc trưng. Mắt người khó thấy nhưng mô hình học được.
Phản xạ và độ bóng: màn hình phát ánh sáng và có vùng chói phẳng, da người phản xạ khác hẳn. Giấy in thì hay thấy nếp gấp, bóng đổ không tự nhiên.
Kết cấu da (texture): lỗ chân lông, vi mạch máu, độ nhám của da thật khác với bề mặt in hoặc màn hình. Nhiều mô hình PAD học chính đặc trưng tần số cao này.
Chiều sâu (depth): nếu có cảm biến depth (ví dụ camera hồng ngoại chấm như Face ID của Apple dùng structured light), một bề mặt phẳng lộ ra ngay vì không có hình học 3D của mặt thật.

Passive được ưa chuộng vì mượt, người dùng không phải làm gì thêm, nhưng nó chạy đua vũ trang với chất lượng màn hình và máy in ngày càng tốt.

Liveness chủ động (active / challenge-response)

Active liveness yêu cầu người dùng phản ứng theo một thử thách ngẫu nhiên: chớp mắt, quay đầu sang trái, mỉm cười, đọc một dãy số. Cơ chế phòng thủ nằm ở tính ngẫu nhiên và tức thời của thử thách. Một video quay sẵn không thể biết trước hệ thống sẽ yêu cầu quay trái hay chớp mắt, nên không đáp ứng đúng và kịp lúc.

Đây cũng chính là điểm mấu chốt để chống replay: gắn mỗi phiên xác thực với một thử thách chỉ dùng một lần (nonce), phát sinh phía máy chủ, có thời hạn ngắn. Cách nghĩ này rất giống chống replay trong bảo mật mạng nói chung, nơi ta đính nonce hoặc timestamp vào mỗi request để một gói tin cũ bị bắt lại không thể dùng lần hai.

Nói thêm về deepfake injection: khi kẻ tấn công chèn thẳng luồng video giả, ngay cả active liveness cũng có thể bị qua mặt nếu deepfake đủ nhanh để phản ứng với thử thách theo thời gian thực. Vì vậy các hệ thống nghiêm túc còn xác thực cả tính toàn vẹn của đường dẫn thu ảnh: chứng thực rằng khung hình thật sự đến từ camera phần cứng của thiết bị chứ không phải một luồng ảo được inject, thường qua các cơ chế attestation ở tầng hệ điều hành.

Một khung phòng thủ nhiều lớp

Trong thực tế không ai chọn một biện pháp duy nhất. Một pipeline hợp lý thường chồng nhiều lớp:

Detect và align khuôn mặt trong khung hình.
Passive liveness chấm điểm nhanh dấu vết giả mạo (moiré, texture, depth).
Active challenge khi rủi ro cao hoặc điểm passive không đủ chắc.
Sinh embedding rồi so khớp với tham chiếu theo ngưỡng đã hiệu chỉnh.
Ràng buộc phiên: nonce, timestamp, và attestation nguồn ảnh để chống replay và injection.

Chỉ khi cả chuỗi này cùng gật đầu thì mới coi là xác thực thành công. Điểm hay của cách chồng lớp: kẻ tấn công phải vượt đồng thời nhiều rào có bản chất khác nhau, chi phí tấn công tăng phi tuyến.

Vài đánh đổi thành thật

Không có hệ thống liveness nào hoàn hảo, và mình nghĩ điều lành mạnh là thừa nhận thẳng như vậy. Mỗi lớp phòng thủ đều kèm cái giá:

Passive liveness mượt nhưng dễ tụt hiệu quả khi màn hình hoặc máy in đời mới hơn dữ liệu huấn luyện. Nó cần được cập nhật liên tục, giống một sản phẩm sống chứ không phải một mô hình đóng băng.
Active liveness chắc hơn nhưng thêm ma sát, và người dùng lớn tuổi hoặc trong môi trường ồn ào có thể thao tác sai, đẩy FRR lên.
Cảm biến depth chống 2D rất tốt nhưng cần phần cứng chuyên dụng, không phải camera web nào cũng có.
Ngưỡng đặt càng chặt để giảm FAR thì càng làm phiền chính chủ, và ranh giới “đúng” thay đổi theo môi trường triển khai.

Cuối cùng, liveness không phải bài toán giải một lần rồi thôi. Nó là một cuộc rượt đuổi: kẻ tấn công tìm cách mới, người phòng thủ vá lại, rồi lặp. Điều thực tế nhất mà một kỹ sư có thể làm là đừng tin vào một lớp duy nhất, đo lường FAR và FRR trên dữ liệu gần với thực tế, và chấp nhận rằng con số “an toàn” hôm nay chỉ đúng cho tới lần tấn công thông minh kế tiếp. Mình thấy đó không phải một kết luận bi quan, chỉ là cách nhìn trung thực về một bài toán vẫn đang mở.

Tài liệu tham khảo

ISO/IEC 30107-1 và 30107-3, Information technology, Biometric presentation attack detection.
Schroff, Kalenichenko, Philbin, FaceNet: A Unified Embedding for Face Recognition and Clustering, CVPR 2015.
Deng, Guo, Xue, Zafeiriou, ArcFace: Additive Angular Margin Loss for Deep Face Recognition, CVPR 2019.
NIST FRVT (Face Recognition Vendor Test), các báo cáo về FAR/FRR và presentation attack, trang chính thức của NIST.
Apple Platform Security Guide, phần Face ID và TrueDepth camera.
Wikipedia, các mục Liveness detection, Spoofing attack, Cosine similarity.