STEPTechnology
Bảo mật

6 Thuật Ngữ Bảo Mật Windows Server Cần Hiểu Trước Khi Vá

Giải thích dễ hiểu 6 thuật ngữ hay gặp khi vá bảo mật Windows Server — LSA, Print Spooler, TLS/SSL cũ, AppLocker, ký số SMB, WinRM — kèm bối cảnh rủi ro thực tế, không phải định nghĩa sách vở.

ST

STEP Technology

Đội kỹ thuật

24/09/2026·17 phút đọc

Vá xong máy chủ, bạn có hiểu được vừa làm gì không?

Bạn vừa mở console máy chủ, gõ đúng lệnh, thấy dòng chữ chạy qua và bảng kết quả in ra — nhưng khựng lại ở những chữ như "bảo vệ LSA", "AppLocker", "ký số SMB"? Nếu đúng vậy, bạn không phải trường hợp cá biệt. Đây là cảm giác của gần như bất kỳ ai không xuất thân IT — kể cả người chủ doanh nghiệp tự tay đi vá máy chủ của chính mình, hay nhân viên vừa được giao thêm việc quản trị hạ tầng mà chưa từng học bài bản.

Vấn đề không nằm ở việc chạy lệnh — kịch bản đã làm phần đó. Vấn đề là không hiểu mình vừa đóng cửa nào, tại sao cửa đó nguy hiểm, và điều gì sẽ xảy ra nếu để nó mở. Không hiểu thì rất khó quyết định đúng khi gặp tình huống thực tế: nhà cung cấp phần mềm hỏi có thể "tắt tạm AppLocker để cài bản cập nhật không", đối tác hỏi "máy chủ có bật ký số SMB không", hoặc đơn giản là muốn biết số tiền và thời gian vừa bỏ ra để vá máy chủ có đáng hay không.

Bài này không hướng dẫn thao tác — hai bài nền tảng Bảo Mật Windows Server Từ Cơ Bản Đến Nâng Cao (Phần 1 & Phần 2) và bài thực hành Vá Bảo Mật Windows Server Trong 20 Phút đã làm việc đó, kèm lệnh PowerShell cụ thể. Bài này đứng trước ba bài đó: giải nghĩa đúng 6 thuật ngữ hay gặp nhất trong quá trình vá, bằng tiếng Việt đơn giản, kèm bối cảnh rủi ro thật — vì sao mỗi thứ lại đáng để bật, không phải chỉ vì "khuyến nghị bảo mật nói vậy".

1. LSA là gì và vì sao hacker thích nhắm vào đây?

LSA (Local Security Authority) là tiến trình trung tâm của Windows chịu trách nhiệm xác thực đăng nhập. Để bạn không phải gõ lại mật khẩu mỗi khi mở một ứng dụng hay truy cập một tài nguyên mạng trong cùng phiên làm việc, LSA tạm giữ thông tin đăng nhập (mật khẩu, mã băm, vé Kerberos) trong bộ nhớ máy tính. Bảo vệ LSA (RunAsPPL) là công tắc khiến vùng nhớ đó không còn đọc trộm được, kể cả bởi chương trình chạy với quyền quản trị.

Nghe thì trừu tượng, nhưng đây là đúng cơ chế "đăng nhập một lần dùng cho cả phiên" (SSO) mà ai cũng quen thuộc — bạn gõ mật khẩu một lần lúc mở máy, sau đó mở ổ đĩa mạng, mở ứng dụng nội bộ, kết nối máy chủ khác đều không phải gõ lại. Cái giá của sự tiện lợi đó: thông tin đăng nhập phải nằm đâu đó trong bộ nhớ để Windows dùng lại, và tiến trình giữ nó tên là lsass.exe.

Đây chính xác là lý do công cụ tấn công như Mimikatz ra đời và nổi tiếng đến vậy trong giới bảo mật: chúng đọc thẳng vùng nhớ của lsass.exe để lấy ra mật khẩu (hoặc mã băm, hoặc vé Kerberos) của mọi tài khoản từng đăng nhập vào máy đó — kể cả tài khoản đã đăng xuất nếu chưa bị dọn khỏi bộ nhớ. Đây là kỹ thuật đứng sau phần lớn các vụ "từ một máy trạm bị lừa mở file đính kèm, lan ra chiếm cả domain": kẻ tấn công chiếm được một máy bất kỳ, đọc trộm bộ nhớ, thấy trong đó có phiên đăng nhập cũ của một tài khoản quản trị (vì quản trị viên từng dùng Remote Desktop vào máy đó để xử lý sự cố), rồi dùng đúng thông tin ấy để leo thang lên máy chủ quan trọng hơn. Bảo vệ LSA không ngăn được việc máy bị chiếm ban đầu, nhưng chặn đúng bước "đọc trộm bộ nhớ" — chặn được domino tiếp theo.

STEP xử lý mục này thế nào ngoài thực tế, cụ thể trên máy Windows Server thật (kể cả lưu ý riêng cho máy bật Secure Boot, và vì sao Microsoft khuyến nghị chạy chế độ kiểm toán một tuần trước khi bật thật): xem mục 3.1 bài Vá Bảo Mật Windows Server Trong 20 Phút.

2. Print Spooler là gì và vì sao PrintNightmare từng gây chấn động?

Print Spooler là dịch vụ Windows quản lý việc in ấn — nhận lệnh in, nạp driver máy in, đẩy dữ liệu ra máy in hoặc máy in ảo (như in ra PDF). PrintNightmare (CVE-2021-34527 cùng một nhóm lỗ hổng liên quan, công bố năm 2021) là lỗ hổng khiến chính chức năng "nạp driver máy in" bị lợi dụng để chạy mã độc với quyền cao nhất trên hệ thống — quyền SYSTEM.

Cơ chế cụ thể: Print Spooler có một hàm tên RpcAddPrinterDriver dùng để cài driver máy in từ xa — tính năng hợp lệ, cần thiết để một máy chủ in dùng chung cho nhiều máy trong công ty. Vấn đề là Windows kiểm tra quyền cho hàm này lỏng hơn mức cần thiết: một tài khoản người dùng bình thường (không cần quyền quản trị) vẫn gọi được hàm đó, và driver được nạp lên sẽ chạy với quyền SYSTEM — quyền cao nhất trên máy, cao hơn cả tài khoản Administrator thông thường — chứ không phải quyền của người vừa gọi hàm. Kẻ tấn công không cần "hack" gì phức tạp: chỉ cần một tài khoản đăng nhập hợp lệ bất kỳ, giả một "driver máy in" chứa mã độc, gọi đúng hàm, và có ngay quyền SYSTEM trên máy đích.

Điều khiến PrintNightmare đặc biệt nguy hiểm là Print Spooler bật sẵn theo mặc định trên hầu hết máy Windows Server — kể cả máy chưa từng cắm một chiếc máy in nào. Và nguy hiểm nhất khi máy đó là Domain Controller: đây là máy giữ toàn bộ cơ sở dữ liệu tài khoản và mật khẩu (dạng mã băm) của cả công ty, nên quyền SYSTEM trên Domain Controller gần như đồng nghĩa với quyền kiểm soát toàn bộ hệ thống đăng nhập của tổ chức.

Kịch bản minh hoạ điển hình (không gán cho khách hàng cụ thể nào của STEP): một máy chủ Domain Controller cài xong vẫn giữ nguyên Print Spooler ở trạng thái bật mặc định, dù không ai trong công ty in ấn qua đó. Một nhân viên vô tình để lộ mật khẩu qua email lừa đảo. Kẻ tấn công dùng đúng tài khoản đó gọi lỗ hổng PrintNightmare thẳng lên Domain Controller, giành quyền SYSTEM, và từ đó có trong tay chìa khoá của toàn bộ hệ thống đăng nhập công ty — không chỉ một máy.

STEP xử lý mục này ra sao: kịch bản Invoke-StepHardening.ps1 có công tắc riêng -TatPrintSpooler, và tự kiểm tra rồi từ chối tắt nếu phát hiện máy đang thật sự chia sẻ máy in — tránh làm gián đoạn in ấn đang dùng thật. Xem mục 3.3 bài Vá Bảo Mật Windows Server Trong 20 Phút; khuyến nghị tắt hẳn trên máy không làm máy chủ in và trên Domain Controller theo CIS Benchmark được nhắc ở Phần 1.

3. Vì sao vẫn phải tắt SSL/TLS đời cũ dù gần như không ai còn dùng?

SSL/TLS là giao thức mã hoá đường truyền mạng — thứ biến "http" không an toàn thành "https" an toàn. SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1 là các phiên bản cũ của giao thức này, đều có lỗ hổng đã biết không thể vá được bằng bản cập nhật, chỉ có thể xử lý bằng cách tắt hẳn — nên dù trình duyệt và phần mềm hiện đại gần như không còn dùng tới, việc chủ động tắt trên máy chủ vẫn cần thiết.

Hai lý do cụ thể. Một, máy chủ vẫn ở trạng thái sẵn sàng phục vụ nếu có ai đó (hoặc một công cụ dò quét tự động) cố tình yêu cầu kết nối bằng giao thức cũ, kể cả khi không có ứng dụng hợp lệ nào thật sự cần nó — giống một ổ khoá chìa cũ vẫn còn lắp trên cửa dù cả nhà đã chuyển sang khoá vân tay, chỉ cần không ai tháo nó ra thì nó vẫn là một cách để mở cửa. Hai, đây là yêu cầu tuân thủ bắt buộc với doanh nghiệp có xử lý thanh toán thẻ: chuẩn bảo mật thẻ thanh toán quốc tế PCI DSS đã yêu cầu tắt SSL 3.0 và TLS 1.0 từ tháng 6/2018.

Rủi ro cụ thể nằm ở kiểu tấn công gọi là "downgrade" (ép hạ cấp giao thức). SSL 3.0 có lỗ hổng tên POODLE (công bố 2014): kẻ tấn công đứng giữa đường truyền có thể ép phiên kết nối "thương lượng xuống" bản giao thức cũ yếu hơn — dù cả máy khách lẫn máy chủ đều có khả năng dùng bản mới hơn — rồi khai thác điểm yếu của bản cũ đó để đọc được nội dung đang tưởng như đã mã hoá. TLS 1.0 có lỗ hổng tương tự tên BEAST. Cả hai đều là ví dụ cho việc "chỉ cần cửa cũ còn mở, dù chẳng ai dùng, kẻ tấn công vẫn có thể ép đi qua cửa đó".

STEP xử lý mục này ra sao: công tắc -TatTlsCu trong kịch bản tắt cả bốn phiên bản cũ, bật TLS 1.2, kèm cờ mã hoá mạnh cho các ứng dụng .NET Framework cũ — xem mục 3.3 bài Vá Bảo Mật Windows Server Trong 20 Phút (lưu ý: cần khởi động lại máy, và phần mềm cũ có thể mất kết nối ngay sau khi tắt). Muốn đi xa hơn — bật hẳn TLS 1.3, phiên bản mới nhất, có sẵn từ Windows Server 2022 — xem bài 6 Lớp Mã Hoá Bảo Vệ Dữ Liệu Windows Server 2022.

4. AppLocker là gì và khác gì phần mềm diệt virus?

AppLocker là tính năng có sẵn trong Windows cho phép bạn định nghĩa danh sách phần mềm được phép chạy trên máy chủ (allowlist). Bất kỳ chương trình nào không nằm trong danh sách đó sẽ bị chặn chạy — kể cả khi nó chưa từng bị bất kỳ hãng diệt virus nào gắn cờ là độc hại.

Đây là điểm khác biệt cốt lõi với phần mềm diệt virus thông thường. Diệt virus hoạt động theo chiều ngược lại: nó cần biết trước (qua mẫu nhận diện, hoặc phân tích hành vi) rằng một chương trình là xấu rồi mới chặn — nghĩa là luôn tồn tại một khoảng thời gian giữa lúc mã độc mới xuất hiện và lúc diệt virus kịp "học" để nhận ra nó (khoảng trống này gọi là lỗ hổng zero-day, hoặc đơn giản là "mã độc chưa có mẫu"). AppLocker lật ngược cách tiếp cận: mặc định không tin bất kỳ thứ gì, chỉ cho chạy đúng những gì đã được duyệt trước. Một mã độc hoàn toàn mới, chưa ai từng thấy trên thế giới, vẫn bị chặn — không phải vì AppLocker "nhận ra" nó xấu, mà đơn giản vì nó không có tên trong danh sách được phép.

Rủi ro cụ thể mà AppLocker chặn: sau khi kẻ tấn công đã có được một chỗ đứng ban đầu trên máy (qua email lừa đảo, lỗ hổng ứng dụng chưa vá, hay mật khẩu bị lộ), bước tiếp theo gần như luôn là tải thêm công cụ giai đoạn hai — công cụ dò mật khẩu, công cụ điều khiển từ xa, hoặc chính payload mã hoá dữ liệu tống tiền. Những công cụ này thường "mới toanh" hoặc được nguỵ trang riêng cho từng cuộc tấn công để né diệt virus. Nếu máy chỉ có diệt virus, công cụ lạ đó có cơ hội chạy lọt trong khoảng thời gian trước khi được cập nhật mẫu nhận diện. Nếu máy có AppLocker ở chế độ chặn thật, công cụ đó đơn giản không chạy được — bất kể diệt virus có nhận ra nó hay không.

Đánh đổi cần biết trước khi bật: AppLocker là công cụ mạnh nhưng khó cấu hình đúng. Danh sách sai hoặc thiếu có thể chặn nhầm chính phần mềm nghiệp vụ đang dùng, thậm chí chặn cả công cụ bạn cần để tự sửa lỗi.

STEP xử lý mục này ra sao — gồm hai con số STEP tự đo được trên máy thật mà tài liệu Microsoft không ghi (ngưỡng số luật bắt đầu khớp sai, và ba tệp hệ thống Windows — trong đó có tệp vận hành nút Start — không khớp luật theo cách thông thường): xem mục 3.2 bài Vá Bảo Mật Windows Server Trong 20 Phút. Quy trình đầy đủ theo đúng khuyến nghị Microsoft (chạy chế độ theo dõi trước, chuyển chặn thật sau, và so sánh với lựa chọn thay thế WDAC) nằm ở mục "Windows Defender Application Control (WDAC) hay AppLocker" trong Phần 2.

5. Ký số gói tin SMB là gì và bảo vệ việc chia sẻ file thế nào?

SMB là giao thức Windows dùng để chia sẻ file và máy in qua mạng nội bộ — ổ đĩa mạng, thư mục dùng chung mà nhân viên công ty vẫn truy cập hằng ngày. Ký số SMB (SMB signing) là cơ chế đóng một "con dấu điện tử" lên từng gói tin SMB trước khi gửi đi, để máy nhận xác minh được gói tin đó đúng là đến từ máy đã gửi và không bị ai chỉnh sửa trên đường truyền.

Cần phân biệt rõ với một khái niệm dễ nhầm: ký số không mã hoá nội dung file đang truyền (đó là một tính năng riêng, SMB Encryption) — ký số chỉ đảm bảo tính toàn vẹn và đúng danh tính: gói tin không bị đổi nội dung và đúng là đến từ máy đã gửi, không phải một máy giả mạo chen vào giữa.

Rủi ro cụ thể mà ký số chặn gọi là tấn công "chen giữa và giả mạo" (man-in-the-middle / relay attack) trong chính mạng nội bộ — không cần kẻ tấn công đến từ internet, chỉ cần họ đã có một chỗ đứng nào đó trong mạng công ty (một máy trạm bị nhiễm mã độc, một thiết bị lạ cắm vào cổng mạng, hoặc một điểm phát Wi-Fi giả). Từ vị trí đó, kẻ tấn công có thể chặn phiên xác thực SMB của người dùng khác rồi "chuyển tiếp" (relay) nó sang một máy chủ khác trong mạng để giả danh chính người dùng đó đăng nhập vào — mà không cần biết mật khẩu thật. Đây là kỹ thuật quen thuộc trong các đợt kiểm tra xâm nhập nội bộ (pentest) lẫn các cuộc tấn công thật, thường xuất hiện ngay sau khi kẻ tấn công vừa có được một chỗ đứng ban đầu trong mạng và đang tìm cách leo thang sang máy quan trọng hơn. Ký số SMB là một trong những lớp phòng thủ chính chặn đúng kỹ thuật này.

STEP xử lý mục này ra sao: mục #2 trong bảng 14 mục an toàn của kịch bản bắt buộc ký số ở phía máy chủ (chiều người khác kết nối vào máy chủ này), và công tắc riêng -KySoSmbPhiaMayKhach bắt buộc ký số ở chiều ngược lại — chính máy chủ này kết nối đi (ví dụ tới máy sao lưu, NAS). Xem mục 2.2 và 3.3 bài Vá Bảo Mật Windows Server Trong 20 Phút — lưu ý máy chủ sẽ từ chối kết nối tới thiết bị NAS/Samba đời cũ chưa hỗ trợ ký số. Phiên bản đầy đủ cả hai chiều, kèm cách rà soát thiết bị cũ trước khi ép buộc toàn máy chủ, nằm ở mục "SMB Signing" trong Phần 1.

6. WinRM là gì và vì sao phải giới hạn chặt ai được dùng?

WinRM (Windows Remote Management) là dịch vụ cho phép điều khiển một máy Windows từ xa bằng dòng lệnh — thay vì ngồi trước màn hình máy chủ, bạn gõ lệnh PowerShell từ máy của mình và nó thực thi ngay trên máy ở xa. Đây là "cổng quản trị chính thức" của Windows: mạnh, tiện — và nếu để mở không kiểm soát, cũng là đường vào lý tưởng cho kẻ tấn công.

WinRM lắng nghe mặc định ở cổng 5985 (chưa mã hoá kênh riêng, dựa vào cơ chế xác thực) hoặc 5986 (đã mã hoá qua HTTPS). Nếu cổng này mở ra internet cho mọi nguồn chứ không giới hạn địa chỉ cụ thể, bất kỳ ai trên mạng cũng có thể thử gõ mật khẩu vào đó — dò mật khẩu hàng loạt (brute-force), hoặc dùng danh sách mật khẩu bị lộ từ một vụ rò rỉ dữ liệu ở nơi khác để thử (credential stuffing, dựa trên thói quen dùng chung một mật khẩu cho nhiều nơi). Nếu trúng, kẻ tấn công có ngay một phiên dòng lệnh đầy đủ quyền trên máy chủ — tương đương ngồi trước màn hình thật.

Điều cần hiểu đúng để tránh hai thái cực sai: cổng mở không tự nó đồng nghĩa dữ liệu bị lộ (nội dung phiên làm việc vẫn được mã hoá qua cơ chế xác thực Kerberos/NTLM ngay cả ở cổng 5985 "chưa mã hoá kênh riêng"), nhưng để mở cho mọi nguồn thì bất kỳ ai có thể đoán hoặc có sẵn mật khẩu đều gõ lệnh được — nên việc phải làm không phải là "đóng hẳn WinRM mãi mãi", mà là giới hạn chặt ai được gọi vào: đúng địa chỉ cần dùng, đúng thời điểm cần dùng, và đóng lại ngay sau khi xong việc.

STEP xử lý mục này ra sao — đây là phần được viết đầy đủ và chi tiết nhất trong cả loạt bài, vì đây là bước làm đầu tiên trước khi chạm vào bất kỳ máy chủ nào từ xa: cách mở đúng hai lớp giới hạn nguồn (tường lửa + bộ lọc riêng trong WinRM), vì sao TrustedHosts = "*" là cái bẫy nguy hiểm nhất của phần này, vì sao chính cặp Basic Auth + AllowUnencrypted mới thật sự làm dữ liệu đi dạng thô (không phải bản thân cổng 5985), và vì sao lệnh Disable-PSRemoting không thật sự đóng cổng — điều STEP đã tự đo trên máy thật chứ không suy đoán theo tên lệnh. Xem trọn mục 1 bài Vá Bảo Mật Windows Server Trong 20 Phút. Với máy chủ cần quản trị từ xa thường trực (không phải một đợt việc rồi đóng lại), cấu hình nên dùng là chuyển hẳn sang HTTPS và giới hạn quyền theo vai trò — xem mục "PowerShell Remoting hardening" trong Phần 1.

Đọc xong rồi thì làm gì tiếp theo?

Hiểu đúng 6 thuật ngữ trên không làm máy chủ của bạn an toàn hơn một chút nào — nó chỉ giúp bạn đọc hiểu và ra quyết định đúng khi cần. Bước làm thật vẫn nằm ở ba bài kia:

  • Muốn làm nhanh, đóng ngay những khe hở phổ biến nhất — đọc Vá Bảo Mật Windows Server Trong 20 Phút, tải kịch bản Invoke-StepHardening.ps1, chạy chế độ kiểm tra trước khi đổi gì.
  • Muốn hiểu toàn cảnh và xây dựng một nền bảo mật đầy đủ hơn — đọc Phần 1 (baseline, danh tính & truy cập, bảo vệ PowerShell, mạng) và Phần 2 (giám sát, kiểm soát ứng dụng, sao lưu chống ransomware).
Chia sẻ:FacebookXZaloTikTok

STEP Có Thể Hỗ Trợ Gì

Hiểu đúng thuật ngữ là bước đầu, không phải đích đến. Bước tiếp theo — biết chính máy chủ của công ty bạn đang thiếu lớp nào trong 6 lớp trên, lớp nào bật lên sẽ làm gãy phần mềm đang chạy, và thứ tự nên làm trước/sau — cần người nhìn vào đúng máy chủ đó, không phải đọc thêm một bài nào nữa. Dịch vụ CIO/quản trị hạ tầng thuê ngoài của STEP nhận rà soát hiện trạng, lên kế hoạch vá đúng thứ tự an toàn, và vận hành liên tục sau đó — không cần công ty bạn tuyển thêm người cho việc này.

Thường phản hồi trong vòng vài phút trong giờ làm việc.