Vietnamese Professional - CCNP Security Core https://www.forum.vnpro.org/ vi Wed, 22 Jul 2026 12:30:55 GMT vBulletin 60 images/misc/rss.png Vietnamese Professional - CCNP Security Core https://www.forum.vnpro.org/ Network Engineer giỏi thôi chưa đủ – Hãy trở thành Security Engineer! https://www.forum.vnpro.org/forum/ccnp-security/security-core/443125-network-engineer-giỏi-thôi-chưa-đủ-–-hãy-trở-thành-security-engineer Wed, 22 Jul 2026 11:00:46 GMT Network Engineer giỏi thôi chưa đủ – Hãy trở thành Security Engineer!


Bạn có biết?
Hiện nay, hầu hết doanh nghiệp đều đầu tư mạnh vào Firewall, VPN, Zero Trust, IDS/IPS, NAC... để bảo vệ hệ thống trước các cuộc tấn công mạng ngày càng tinh vi.
Điều đó cũng đồng nghĩa với việc Network Security Engineer đang là một trong những vị trí có nhu cầu tuyển dụng rất cao.
Nếu bạn đã có nền tảng CCNA, CCNP ENCOR hoặc đang làm System/Network Engineer, thì CCNP Security Core (350-701 SCOR) là bước đi phù hợp để nâng cấp chuyên môn.
Khóa học giúp bạn làm chủ:
  • Cisco Secure Firewall (NGFW)
  • VPN & Secure Remote Access
  • AAA, ISE, NAC
  • IDS/IPS & các giải pháp bảo mật Cisco
  • Thiết kế và triển khai hệ thống bảo mật doanh nghiệp
Giảng viên: Đào Đức Luân – nhiều năm kinh nghiệm đào tạo và triển khai các giải pháp bảo mật Cisco.
Khai giảng: 05/08/2026
Hình thức: Online
Lịch học: Tối 2 - 4 - 6
Đây không chỉ là khóa học để chinh phục chứng chỉ 350-701 SCOR, mà còn giúp bạn tự tin triển khai các giải pháp bảo mật trong môi trường doanh nghiệp.
Hotline/Zalo: 093 3427 079
Anh Thư: 033 9943 732
Như Ngọc: 0765 944 386

Đầu tư vào kiến thức bảo mật hôm nay chính là đầu tư cho sự nghiệp IT trong tương lai. ​
​]]> CCNP Security Core ThanhQuyen https://www.forum.vnpro.org/forum/ccnp-security/security-core/443125-network-engineer-giỏi-thôi-chưa-đủ-–-hãy-trở-thành-security-engineer Cách hoạt động của Site-to-Site VPN https://www.forum.vnpro.org/forum/ccnp-security/security-core/442956-cách-hoạt-động-của-site-to-site-vpn Mon, 20 Jul 2026 12:41:48 GMT Cách hoạt động của Site-to-Site VPN Trong mô hình Site-to-Site VPN, router hoặc firewall sẽ đóng vai trò VPN Gateway. VPN Gateway chịu trách... Cách hoạt động của Site-to-Site VPN


Trong mô hình Site-to-Site VPN, router hoặc firewall sẽ đóng vai trò VPN Gateway.

VPN Gateway chịu trách nhiệm đóng gói (Encapsulation) các gói tin từ mạng nội bộ vào bên trong một gói IPsec đã được mã hóa, sau đó gửi qua mạng không tin cậy như Internet hoặc MPLS. Ở đầu bên kia, VPN Gateway sẽ giải đóng gói (Decapsulation) và chuyển tiếp gói tin gốc đến đúng máy đích trong mạng nội bộ.

Nhờ cơ chế này, hai mạng LAN ở hai địa điểm khác nhau có thể giao tiếp với nhau như đang nằm trong cùng một hệ thống mạng riêng.
Quy trình hoạt động


Giả sử doanh nghiệp có hai văn phòng:
  • Chi nhánh A: 172.16.4.0/24
  • Trụ sở chính: 10.10.5.0/24 và DMZ 192.168.11.0/24

Hai đầu được kết nối bằng một đường hầm IPsec VPN. Bước 1. Máy tính gửi gói tin


Một máy tính tại mạng 172.16.4.0/24 muốn truy cập máy chủ có địa chỉ 10.10.5.20 ở trụ sở chính.

Máy tính vẫn tạo gói tin IP bình thường:
  • Source IP: 172.16.4.x
  • Destination IP: 10.10.5.20

Máy tính hoàn toàn không biết đang sử dụng VPN.
Bước 2. VPN Gateway mã hóa


Router hoặc firewall tại chi nhánh nhận thấy đây là lưu lượng thuộc mạng cần được bảo vệ.

Gateway sẽ:
  • Mã hóa toàn bộ gói tin.
  • Đóng gói vào một gói IPsec mới.
  • Thay địa chỉ IP bên ngoài bằng Public IP của hai VPN Gateway.

Lúc này, Internet chỉ nhìn thấy lưu lượng giữa hai địa chỉ Public IP, hoàn toàn không thấy các địa chỉ IP nội bộ.
Bước 3. Gateway phía bên kia giải mã


VPN Gateway tại trụ sở nhận được gói IPsec sẽ:
  • Xác thực nguồn gửi.
  • Giải mã.
  • Bóc lớp IPsec.
  • Khôi phục gói tin ban đầu.

Sau đó gói tin được chuyển tiếp đến máy chủ 10.10.5.20.

Chiều ngược lại cũng diễn ra theo đúng quy trình này.
Không cần NAT giữa hai mạng


Một ưu điểm lớn của Site-to-Site VPN là không cần NAT giữa các mạng nội bộ.

Mặc dù cả hai đầu đều sử dụng địa chỉ IP riêng theo chuẩn RFC 1918, các máy tính vẫn có thể giao tiếp trực tiếp với nhau thông qua đường hầm IPsec.

Ví dụ:
  • 172.16.4.15 ↔ 10.10.5.20

Hai máy vẫn nhìn thấy địa chỉ IP thật của nhau thay vì địa chỉ sau NAT.
Protected Traffic là gì?


Không phải toàn bộ lưu lượng đều đi qua VPN.

Quản trị viên phải xác định trước những mạng nào sẽ được mã hóa. Phần lưu lượng này được gọi là Protected Traffic hay Interesting Traffic.

Ví dụ tại chi nhánh:
172.16.4.0/24
↓
10.10.5.0/24
192.168.11.0/24

Điều đó có nghĩa:
  • Lưu lượng từ 172.16.4.0/24 đến 10.10.5.0/24 sẽ được mã hóa.
  • Lưu lượng từ 172.16.4.0/24 đến 192.168.11.0/24 cũng sẽ được mã hóa.
  • Mọi lưu lượng khác, chẳng hạn truy cập Internet, sẽ đi theo đường bình thường và không đi qua VPN.
Protected Traffic phải đối xứng


Một yêu cầu quan trọng khi cấu hình Site-to-Site VPN là hai đầu phải khai báo Protected Traffic theo dạng mirror image (đối xứng).

Ví dụ:

Gateway tại Chi nhánh A
Source : 172.16.4.0/24
Destination : 10.10.5.0/24

Gateway tại Trụ sở chính
Source : 10.10.5.0/24
Destination : 172.16.4.0/24

Có thể thấy Source và Destination chỉ đơn giản là đảo ngược cho nhau.

Nếu hai đầu cấu hình không khớp, đường hầm có thể vẫn thiết lập thành công nhưng lưu lượng sẽ không được mã hóa hoặc chỉ truyền được theo một chiều.
Tổng kết


Có thể hình dung Site-to-Site VPN giống như xây dựng một đường hầm bảo mật xuyên qua Internet. Máy tính ở hai đầu vẫn sử dụng địa chỉ IP riêng và giao tiếp như trong cùng một mạng nội bộ, trong khi VPN Gateway chịu trách nhiệm mã hóa, giải mã và vận chuyển dữ liệu một cách an toàn. Muốn VPN hoạt động ổn định, hai đầu phải thống nhất về Protected Traffic, tức là các cặp mạng nguồn và đích cần được bảo vệ, với cấu hình đối xứng trên cả hai VPN Gateway.
​]]> CCNP Security Core dangquangminh https://www.forum.vnpro.org/forum/ccnp-security/security-core/442956-cách-hoạt-động-của-site-to-site-vpn Vì sao VPN doanh nghiệp luôn cần Digital Certificate? https://www.forum.vnpro.org/forum/ccnp-security/security-core/442905-vì-sao-vpn-doanh-nghiệp-luôn-cần-digital-certificate Sun, 19 Jul 2026 11:17:24 GMT Vì sao VPN doanh nghiệp luôn cần Digital Certificate? Một trong những sai lầm phổ biến khi triển khai VPN là chỉ quan tâm đến username và... Vì sao VPN doanh nghiệp luôn cần Digital Certificate?


Một trong những sai lầm phổ biến khi triển khai VPN là chỉ quan tâm đến username và password. Thực tế, mật khẩu chỉ xác thực người dùng, còn câu hỏi quan trọng hơn là: Làm sao người dùng biết mình đang kết nối đúng VPN Server của công ty, chứ không phải một máy chủ giả mạo?

Đó chính là vai trò của Digital Certificate.

Quy trình này rất giống khi bạn truy cập một website bằng HTTPS. Trước khi nhập tài khoản ngân hàng hoặc thông tin cá nhân, trình duyệt sẽ kiểm tra chứng chỉ SSL/TLS của website để xác minh danh tính máy chủ. Nếu chứng chỉ hợp lệ, kết nối mới được tiếp tục.

Remote Access VPN cũng hoạt động theo nguyên tắc tương tự.

Khi Cisco Secure Client khởi tạo kết nối, VPN Gateway (ví dụ Cisco Secure Firewall FTD) sẽ gửi Identity Certificate của mình. Máy khách sẽ kiểm tra xem chứng chỉ này có được ký bởi một Certificate Authority (CA) đáng tin cậy hay không, có còn hiệu lực hay đã bị thu hồi, đồng thời xác minh tên miền (FQDN) có khớp với địa chỉ VPN mà người dùng đang truy cập hay không. Chỉ khi mọi kiểm tra đều thành công, VPN mới được thiết lập.

Trong nhiều doanh nghiệp, VPN còn sử dụng Mutual Authentication, nghĩa là không chỉ VPN Server chứng minh danh tính với Client mà Client cũng phải xuất trình Computer Certificate hoặc User Certificate để xác thực ngược lại. Điều này giúp giảm đáng kể nguy cơ thiết bị không được cấp phép truy cập vào hệ thống.

Đối với môi trường doanh nghiệp, Microsoft Active Directory Certificate Services (AD CS) là lựa chọn rất phổ biến để triển khai CA nội bộ. Một số tổ chức cũng sử dụng Public CA như DigiCert hoặc GlobalSign, đặc biệt khi người dùng kết nối từ Internet hoặc nhiều thiết bị bên ngoài doanh nghiệp.

Nhiều người mới thường chọn Self-Signed Certificate vì chỉ mất vài phút để tạo. Đây là lựa chọn phù hợp cho phòng Lab hoặc Demo, nhưng không nên sử dụng trong hệ thống thực tế. Lý do là Self-Signed Certificate không được các thiết bị mặc định tin cậy, buộc quản trị viên phải cài đặt chứng chỉ thủ công trên từng máy. Khi số lượng người dùng tăng lên hàng trăm hoặc hàng nghìn, việc quản lý sẽ trở thành một gánh nặng.

Một điểm cũng rất dễ bị bỏ qua là FQDN trong Subject hoặc Subject Alternative Name (SAN) phải chính xác. Nếu người dùng truy cập vpn.company.com nhưng chứng chỉ lại được cấp cho vpn.company.local, VPN Client sẽ hiển thị cảnh báo Name Mismatch. Đây không chỉ là một thông báo phiền phức mà còn là cơ chế quan trọng giúp ngăn chặn các cuộc tấn công giả mạo máy chủ (Man-in-the-Middle).

Có thể nói, trong các giải pháp VPN hiện đại, Digital Certificate chính là "CMND điện tử" của VPN Gateway. Nó giúp người dùng xác minh đúng máy chủ, ngăn chặn giả mạo, hỗ trợ xác thực hai chiều và là nền tảng để xây dựng một hệ thống Remote Access VPN an toàn, đáng tin cậy ở quy mô doanh nghiệp.
​]]> CCNP Security Core dangquangminh https://www.forum.vnpro.org/forum/ccnp-security/security-core/442905-vì-sao-vpn-doanh-nghiệp-luôn-cần-digital-certificate Ví dụ triển khai RAG với Splunk trong doanh nghiệp https://www.forum.vnpro.org/forum/ccnp-security/security-core/442736-ví-dụ-triển-khai-rag-với-splunk-trong-doanh-nghiệp Wed, 15 Jul 2026 04:58:42 GMT Ví dụ triển khai RAG với Splunk trong doanh nghiệp Sau khi hiểu RAG là gì, hãy xem một ví dụ rất thực tế trong môi trường IT và Network... Ví dụ triển khai RAG với Splunk trong doanh nghiệp


Sau khi hiểu RAG là gì, hãy xem một ví dụ rất thực tế trong môi trường IT và Network Operations.

Trong mô hình dưới đây, Splunk không chỉ đóng vai trò là hệ thống phân tích log, mà còn trở thành nguồn tri thức (Knowledge Base) để cung cấp thông tin cho LLM thông qua kiến trúc Retrieval-Augmented Generation (RAG). RAG lấy dữ liệu từ đâu?


Thay vì chỉ dựa vào kiến thức đã được huấn luyện, AI sẽ truy xuất thông tin từ nhiều nguồn dữ liệu khác nhau của doanh nghiệp, chẳng hạn:
  • Splunk: Telemetry, log hệ thống, sự kiện bảo mật.
  • ServiceNow: Ticket hỗ trợ, lịch sử xử lý sự cố.
  • Tài liệu Word, PDF, Excel: Quy trình vận hành (SOP), MOP, Best Practices.
  • Wiki hoặc Website nội bộ.
  • CMDB và Inventory.
  • Hồ sơ khách hàng.
  • Hợp đồng (SOW/Contract).
  • Các lỗi đã biết (Known Errors).
  • Cisco Bug (CDETS), Field Notice (FN), PSIRT.
  • Mẫu cấu hình (Templates), Golden Rules và Code Samples.

Nói cách khác, RAG có thể kết nối gần như mọi kho dữ liệu mà doanh nghiệp đang sử dụng.
AI sẽ làm gì với kho dữ liệu này?


Sau khi truy xuất đúng tài liệu liên quan, LLM sẽ kết hợp khả năng hiểu ngôn ngữ để tạo ra câu trả lời phù hợp với từng khách hàng hoặc từng hệ thống cụ thể.

Nhờ đó doanh nghiệp đạt được nhiều lợi ích:
  • Cá nhân hóa hỗ trợ khách hàng (Customer Personalization).
  • Mở rộng phạm vi ứng dụng của AI sang nhiều phòng ban.
  • Tối ưu quá trình phân tích và phản hồi sự cố.

Đây là điểm khác biệt lớn giữa chatbot AI thông thường và AI dành cho doanh nghiệp.
Một số ứng dụng thực tế


Khi kết hợp LLM + RAG + Splunk, AI có thể hỗ trợ rất nhiều công việc trong vận hành hệ thống:
  • Phân tích sự cố kỹ thuật (Technical Analysis).
  • Tự động tạo báo cáo RCA (Root Cause Analysis).
  • Sinh tài liệu MOP (Method of Procedure).
  • Kiểm tra hệ thống trước và sau khi thay đổi (Pre/Post Change Checks).
  • Phân tích log từ Splunk.
  • Tóm tắt báo cáo MSR hoặc QBR.
  • Phân tích cảm xúc khách hàng từ ticket và email.
  • Hỗ trợ lập trình hoặc giải thích mã nguồn.
  • Tra cứu nhanh các Cisco Bug (CDETS), PSIRT, Field Notice và Known Errors.
  • Phân loại mức độ ưu tiên của ticket.
  • Rà soát quy trình vận hành.
  • Hỗ trợ đào tạo và onboarding kỹ sư mới.
Ví dụ trong môi trường Network Operations


Một kỹ sư NOC nhận được cảnh báo:
"Packet loss tăng đột biến tại chi nhánh Hà Nội."

Thay vì phải tự mình mở hàng loạt công cụ, AI Agent sử dụng RAG sẽ tự động:
  • Truy xuất log từ Splunk.
  • Đọc ticket tương tự trên ServiceNow.
  • Tra cứu tài liệu vận hành và MOP.
  • Kiểm tra Known Errors và Cisco Bug.
  • Đối chiếu với Golden Rules của doanh nghiệp.
  • Tổng hợp toàn bộ thông tin và đề xuất nguyên nhân cũng như hướng xử lý.

Thay vì mất hàng chục phút để thu thập dữ liệu từ nhiều hệ thống, kỹ sư chỉ cần vài giây để nhận được một bản phân tích đầy đủ và có căn cứ.
Kết luận


RAG không chỉ giúp LLM trả lời đúng hơn, mà còn giúp AI hiểu đúng bối cảnh của doanh nghiệp. Khi kết hợp với các nền tảng như Splunk, ServiceNow, CMDB và kho tài liệu nội bộ, AI có thể trở thành một trợ lý kỹ thuật thực thụ, hỗ trợ từ phân tích log, xử lý sự cố đến tạo tài liệu và tư vấn vận hành.

Đó cũng là lý do kiến trúc LLM + RAG đang trở thành nền tảng của các AI Agent hiện đại trong lĩnh vực Network, Security và IT Operations.
​]]> CCNP Security Core dangquangminh https://www.forum.vnpro.org/forum/ccnp-security/security-core/442736-ví-dụ-triển-khai-rag-với-splunk-trong-doanh-nghiệp Các Giao Thức Xác Thực Trong Cisco ISE và IEEE 802.1X https://www.forum.vnpro.org/forum/ccnp-security/security-core/442464-các-giao-thức-xác-thực-trong-cisco-ise-và-ieee-802-1x Thu, 09 Jul 2026 10:52:51 GMT Các Giao Thức Xác Thực Trong Cisco ISE và IEEE 802.1X Authentication Server Quyết Định Giao Thức Xác Thực Trong mô hình IEEE 802.1X,... Các Giao Thức Xác Thực Trong Cisco ISE và IEEE 802.1X

Authentication Server Quyết Định Giao Thức Xác Thực


Trong mô hình IEEE 802.1X, Authentication Server (thường là Cisco Identity Services Engine – Cisco ISE) đóng vai trò quyết định những giao thức xác thực (Authentication Protocols) nào được phép sử dụng trong quá trình xác thực người dùng hoặc thiết bị.

Cisco ISE cung cấp Allowed Protocols List, cho phép quản trị viên xác định chính xác các phương thức xác thực được chấp nhận trong hệ thống.

Điều này đặc biệt quan trọng đối với các tổ chức phải tuân thủ các tiêu chuẩn bảo mật như PCI DSS, HIPAA, ISO 27001, NIST hoặc các yêu cầu nội bộ về an toàn thông tin. Quản trị viên có thể vô hiệu hóa các giao thức yếu và chỉ cho phép các phương thức xác thực mạnh, đáp ứng yêu cầu về bảo mật và tuân thủ (Compliance).
Các Giao Thức Xác Thực Hỗ Trợ Trong Cisco ISE

1. PAP (Password Authentication Protocol / ASCII)


PAP là giao thức xác thực đơn giản nhất.

Đặc điểm:
  • Username và Password được truyền dưới dạng plaintext.
  • Không sử dụng cơ chế mã hóa hay bảo vệ thông tin xác thực.
  • Rất dễ bị đánh cắp thông tin nếu lưu lượng bị nghe lén (Sniffing).

Ngày nay, PAP gần như không còn được khuyến nghị sử dụng trong các môi trường doanh nghiệp do mức độ bảo mật rất thấp.
2. CHAP, MS-CHAPv1 và MS-CHAPv2


Các giao thức này cải thiện bảo mật so với PAP bằng cơ chế Challenge-Response Authentication.

Đặc điểm:
  • Username vẫn được gửi dưới dạng plaintext.
  • Password không được truyền trực tiếp mà được băm (Hash) kết hợp với chuỗi Challenge ngẫu nhiên.
  • Giảm nguy cơ lộ mật khẩu khi truyền trên mạng.

Trong đó:
  • CHAP là chuẩn chung.
  • MS-CHAPv1 là phiên bản của Microsoft, hiện đã lỗi thời.
  • MS-CHAPv2 cải thiện bảo mật đáng kể và vẫn được sử dụng rộng rãi, đặc biệt trong PEAP.
3. EAP (Extensible Authentication Protocol)


EAP không phải là một giao thức xác thực cụ thể mà là một framework cho phép triển khai nhiều phương thức xác thực khác nhau.

EAP hoạt động như một "vỏ bọc" (Framework) để truyền tải các phương thức xác thực như:
  • EAP-TLS
  • PEAP
  • EAP-FAST
  • TEAP
  • EAP-MD5

Bản thân EAP không quy định cách bảo vệ thông tin xác thực; mức độ bảo mật phụ thuộc vào phương thức EAP được sử dụng.
4. EAP-MD5


Đây là một trong những phương thức EAP đơn giản nhất.

Đặc điểm:
  • Username được truyền dưới dạng plaintext.
  • Password được bảo vệ bằng cơ chế Challenge và hàm băm MD5.
  • Hỗ trợ trao đổi bổ sung giữa Supplicant và Authentication Server, ví dụ như thay đổi mật khẩu khi cần.

Tuy nhiên, EAP-MD5 không hỗ trợ xác thực lẫn nhau (Mutual Authentication) và không tạo kênh TLS mã hóa, vì vậy hiện nay hầu như không còn được triển khai trong môi trường doanh nghiệp.
5. EAP-TLS – Tiêu Chuẩn Vàng Cho 802.1X


EAP-TLS (Extensible Authentication Protocol – Transport Layer Security) được xem là phương thức xác thực an toàn nhất trong các triển khai 802.1X.

Quy trình hoạt động:
  1. Thiết bị người dùng (Supplicant) xác minh chứng chỉ số (Certificate) của máy chủ.
  2. Sau khi xác minh thành công, thiết bị gửi chứng chỉ số của mình để xác thực.
  3. Hai bên thực hiện xác thực lẫn nhau (Mutual Authentication).
  4. Thiết lập kênh TLS được mã hóa để bảo vệ toàn bộ quá trình xác thực.

Ưu điểm:
  • Không sử dụng mật khẩu.
  • Chống giả mạo máy chủ.
  • Chống tấn công Man-in-the-Middle (MITM).
  • Mức độ bảo mật rất cao.

Nhược điểm:
  • Yêu cầu hạ tầng PKI (Public Key Infrastructure).
  • Cần triển khai và quản lý chứng chỉ số cho máy chủ và thiết bị đầu cuối.
6. PEAP (Protected Extensible Authentication Protocol)


PEAP là phương thức được triển khai rất phổ biến trong các hệ thống mạng doanh nghiệp.

Cơ chế hoạt động:
  1. Thiết bị xác minh chứng chỉ của máy chủ.
  2. Thiết lập một đường hầm TLS được mã hóa.
  3. Thông tin xác thực của người dùng được truyền bên trong đường hầm TLS.

Sau khi đường hầm được thiết lập, PEAP thường sử dụng một trong hai phương thức xác thực bên trong:
  • EAP-MS-CHAPv2
  • EAP-TLS

Ưu điểm:
  • Không để lộ thông tin xác thực trên mạng.
  • Không bắt buộc triển khai chứng chỉ số cho máy người dùng (khi sử dụng PEAP-MSCHAPv2).
  • Dễ triển khai hơn EAP-TLS.
7. EAP-FAST


EAP-FAST (Extensible Authentication Protocol – Flexible Authentication via Secure Tunneling) được Cisco phát triển nhằm thay thế LEAP và giảm sự phụ thuộc vào hạ tầng PKI.

Thay vì sử dụng chứng chỉ phía máy khách, EAP-FAST sử dụng Protected Access Credential (PAC).

Đặc điểm nổi bật:
  • Hỗ trợ PAC được cấp trước hoặc cấp động.
  • Thiết lập đường hầm TLS an toàn.
  • Bảo vệ thông tin xác thực bằng kênh mã hóa.
  • Hỗ trợ xác thực hai chiều (Mutual Authentication).
  • Hỗ trợ tái xác thực nhanh (Fast Re-authentication).
  • Có thể hoạt động mà không cần chứng chỉ phía máy khách.

EAP-FAST đặc biệt phù hợp với các tổ chức muốn tăng cường bảo mật nhưng chưa triển khai đầy đủ PKI.
8. TEAP (Tunneled Extensible Authentication Protocol)


TEAP là thế hệ mới của các giao thức xác thực dựa trên TLS, được thiết kế để mang lại tính linh hoạt cao hơn so với PEAP.

Các tính năng nổi bật: Chained Authentication


TEAP cho phép xác thực đồng thời cả thiết bị và người dùng trong cùng một phiên làm việc.

Ví dụ:
  • Máy tính phải được xác thực trước.
  • Sau đó người dùng đăng nhập và được xác thực tiếp.
  • Chỉ khi cả hai đều hợp lệ, quyền truy cập mới được cấp.

Điều này đặc biệt hữu ích trong các mô hình Zero Trust. Credential Transition


TEAP hỗ trợ chuyển đổi dần từ xác thực bằng mật khẩu sang xác thực bằng chứng chỉ số mà không cần thay đổi cấu hình hệ thống.

Điều này giúp doanh nghiệp triển khai PKI theo từng giai đoạn, giảm gián đoạn trong quá trình nâng cấp. Enhanced Security


So với PEAP, TEAP mang lại:
  • Linh hoạt hơn trong lựa chọn phương thức xác thực.
  • Bảo vệ thông tin xác thực tốt hơn.
  • Hỗ trợ nhiều cơ chế xác thực trong cùng một đường hầm TLS.
  • Phù hợp với các kiến trúc Zero Trust và môi trường doanh nghiệp hiện đại.
Góc Nhìn Thực Tế


Trong các hệ thống Enterprise hiện nay:
  • EAP-TLS được xem là lựa chọn ưu tiên nhờ mức độ bảo mật cao nhất, đặc biệt khi tổ chức đã triển khai hạ tầng PKI.
  • PEAP (EAP-MS-CHAPv2) vẫn rất phổ biến vì dễ triển khai và không yêu cầu chứng chỉ trên máy người dùng.
  • TEAP đang dần được các tổ chức lớn áp dụng nhờ khả năng xác thực đồng thời thiết bị và người dùng, đáp ứng tốt các yêu cầu của mô hình Zero Trust.
  • EAP-FAST vẫn xuất hiện trong một số môi trường Cisco truyền thống.
  • PAP, CHAP, MS-CHAPv1 và EAP-MD5 chỉ nên duy trì khi cần tương thích với các hệ thống cũ và không còn được khuyến nghị cho các triển khai mới do hạn chế về bảo mật.
​]]> CCNP Security Core dangquangminh https://www.forum.vnpro.org/forum/ccnp-security/security-core/442464-các-giao-thức-xác-thực-trong-cisco-ise-và-ieee-802-1x Mesh Firewall https://www.forum.vnpro.org/forum/ccnp-security/security-core/442347-mesh-firewall Wed, 08 Jul 2026 00:52:50 GMT Đây là một slide rất đáng chú ý vì nó phản ánh xu hướng bảo mật mới của các AI Data Center và môi trường Hybrid Cloud. Thay vì chỉ dựa vào một chiếc... Hybrid Mesh Firewall, nơi khả năng bảo vệ được phân tán khắp hạ tầng, từ switch, máy chủ, workload, Kubernetes cho đến ứng dụng AI.
Hybrid Mesh Firewall – Firewall không còn là một thiết bị


Trong nhiều năm, khi nhắc đến Firewall, chúng ta thường nghĩ đến một thiết bị NGFW đặt ở cổng Internet hoặc giữa các vùng mạng.

Kiến trúc này hoạt động tốt khi phần lớn ứng dụng nằm trong Data Center và lưu lượng chủ yếu đi từ người dùng vào hệ thống (North-South Traffic).

Nhưng AI đã làm thay đổi hoàn toàn cách dữ liệu di chuyển.

Trong AI Data Center hiện đại:
  • AI Agent liên tục gọi API.
  • Kubernetes tạo và hủy container liên tục.
  • GPU trao đổi dữ liệu với GPU.
  • Workload chạy trên nhiều Cloud khác nhau.
  • Lưu lượng East-West chiếm tỷ trọng lớn.

Một firewall đặt ở biên mạng không còn đủ để quan sát và bảo vệ toàn bộ hệ thống.

Đó là lý do Cisco giới thiệu kiến trúc Hybrid Mesh Firewall.
Security Cloud Control – Bộ não điều khiển tập trung


Ở trung tâm sơ đồ là Security Cloud Control.

Đây không phải là firewall, mà là nền tảng quản lý tập trung.

Security Cloud Control giúp:
  • Quản lý policy.
  • Đồng bộ cấu hình.
  • Theo dõi toàn bộ firewall.
  • Thu thập telemetry.
  • Điều phối bảo mật trên Hybrid Cloud.

Nhờ đó, doanh nghiệp có thể áp dụng một chính sách bảo mật thống nhất cho Data Center, Cloud và Edge thay vì cấu hình riêng lẻ trên từng thiết bị.
Secure Firewall – Lớp bảo vệ truyền thống


Đây là dòng Cisco Secure Firewall (Firepower).

Nó vẫn đảm nhiệm những vai trò quen thuộc như:
  • NGFW.
  • IPS.
  • VPN.
  • URL Filtering.
  • Malware Protection.
  • SSL Inspection.

Firewall vật lý vẫn rất quan trọng để kiểm soát lưu lượng North-South giữa Internet và hệ thống nội bộ.
Secure Workload – Bảo vệ từng máy chủ và ứng dụng


AI ngày nay chủ yếu chạy trong:
  • Virtual Machine.
  • Kubernetes.
  • Container.
  • Bare Metal GPU Server.

Secure Workload tập trung bảo vệ từng workload thay vì chỉ bảo vệ mạng.

Các chức năng chính gồm:
  • Microsegmentation.
  • Zero Trust.
  • Quan sát luồng ứng dụng.
  • Phát hiện hành vi bất thường.
  • Kiểm soát giao tiếp giữa các dịch vụ.

Nếu một container bị xâm nhập, chính sách có thể giới hạn ngay phạm vi giao tiếp để ngăn kẻ tấn công lan sang các workload khác.
Cilium – Bảo mật Kubernetes bằng eBPF


Một thành phần nổi bật là Cilium.

Cilium là nền tảng mã nguồn mở sử dụng eBPF trong Linux để kiểm soát lưu lượng mạng ngay trong nhân hệ điều hành.

Trong Kubernetes, Cilium đảm nhận nhiều vai trò:
  • CNI (Container Network Interface).
  • Network Policy.
  • Service Mesh.
  • Observability.
  • Load Balancing.

Nhờ eBPF, Cilium có thể kiểm tra và áp dụng chính sách cho lưu lượng giữa các container mà không cần chuyển qua firewall vật lý, giúp giảm độ trễ và tăng hiệu năng.
Hypershield – Firewall phân tán bằng eBPF và DPU


Hypershield là một trong những công nghệ mới nhất của Cisco.

Thay vì chỉ bảo vệ tại một điểm, Hypershield đưa khả năng bảo mật đến gần từng workload.

Nó tận dụng:
  • eBPF trên Linux.
  • DPU (Data Processing Unit).
  • AI.
  • Distributed Enforcement.

Điều này cho phép chính sách bảo mật được thực thi ngay tại nơi lưu lượng được tạo ra, thay vì đợi đến khi dữ liệu đi qua một firewall tập trung.

Đối với AI Data Center, nơi lưu lượng East-West giữa các GPU và container rất lớn, cách tiếp cận này giúp giảm độ trễ và hạn chế các điểm nghẽn.
Smart Switch – Switch cũng trở thành thiết bị bảo mật


Một điểm mới trong kiến trúc là Smart Switch.

Các switch thế hệ mới không còn chỉ chuyển tiếp gói tin.

Chúng có thể:
  • Thực hiện ACL phần cứng.
  • Phát hiện bất thường.
  • Telemetry thời gian thực.
  • Hỗ trợ eBPF hoặc DPU.
  • Thực thi một phần chính sách bảo mật ngay trong tầng mạng.

Nhờ đó, một phần lưu lượng độc hại có thể bị chặn ngay tại switch mà không cần chuyển lên firewall.
3rd Party Firewall – Không khóa khách hàng vào một hệ sinh thái


Một điểm đáng chú ý là Cisco không chỉ hỗ trợ các sản phẩm của mình.

Kiến trúc Hybrid Mesh Firewall vẫn có thể tích hợp với các firewall của bên thứ ba như:
  • Palo Alto Networks.
  • Fortinet.
  • Check Point.
  • Juniper.
  • Các nền tảng bảo mật khác.

Điều này giúp doanh nghiệp bảo vệ khoản đầu tư hiện có và triển khai dần theo lộ trình phù hợp, thay vì phải thay thế toàn bộ hạ tầng.
Bảo vệ từ hạ tầng đến ứng dụng


Dòng chữ cuối của sơ đồ là:
Protecting from the infrastructure to the application layer

Đây chính là triết lý của Hybrid Mesh Firewall.

Thay vì chỉ bảo vệ tại lớp mạng, hệ thống mở rộng khả năng kiểm soát đến mọi tầng của AI Stack:
  • Infrastructure Layer: Switch, DPU, NIC, GPU Server.
  • Network Layer: Secure Firewall, Smart Switch.
  • Container Layer: Cilium, Kubernetes Network Policy.
  • Workload Layer: Secure Workload, Microsegmentation.
  • Application Layer: AI Agent, API, LLM Service.
  • Cloud Layer: Security Cloud Control và chính sách xuyên suốt Hybrid Cloud.

Mỗi lớp đều có khả năng thực thi chính sách bảo mật, tạo thành một "lưới" (mesh) thay vì phụ thuộc vào một điểm kiểm soát duy nhất.


Kết luận


Hybrid Mesh Firewall đánh dấu sự chuyển dịch từ mô hình "một firewall bảo vệ cả hệ thống" sang "bảo mật được phân tán trên toàn bộ hạ tầng". Trong các AI Data Center hiện đại, nơi hàng nghìn container, AI Agent và GPU liên tục trao đổi dữ liệu, lưu lượng East-West đã vượt xa lưu lượng North-South truyền thống. Vì vậy, việc chỉ đặt firewall ở biên mạng không còn đáp ứng được yêu cầu về hiệu năng và an toàn.

Bằng cách kết hợp Cisco Secure Firewall, Secure Workload, Cilium, Hypershield, Smart Switch và Security Cloud Control, Cisco xây dựng một kiến trúc bảo mật nhiều lớp, nơi chính sách có thể được thực thi ngay tại switch, DPU, máy chủ hoặc workload. Đây cũng là xu hướng chung của ngành an ninh mạng: đưa khả năng bảo vệ đến sát nơi dữ liệu được tạo ra và xử lý, giúp AI Data Center vừa đạt hiệu năng cao vừa đáp ứng các yêu cầu ngày càng khắt khe về bảo mật và Zero Trust.
​]]> CCNP Security Core dangquangminh https://www.forum.vnpro.org/forum/ccnp-security/security-core/442347-mesh-firewall Lựa chọn chế độ hoạt động phù hợp cho IDS/IPS https://www.forum.vnpro.org/forum/ccnp-security/security-core/442281-lựa-chọn-chế-độ-hoạt-động-phù-hợp-cho-ids-ips Mon, 06 Jul 2026 09:58:52 GMT Lựa chọn chế độ hoạt động phù hợp cho IDS/IPS Một trong những quyết định quan trọng nhất khi triển khai IDS/IPS không phải là chọn hãng sản xuất... Lựa chọn chế độ hoạt động phù hợp cho IDS/IPS


Một trong những quyết định quan trọng nhất khi triển khai IDS/IPS không phải là chọn hãng sản xuất hay model thiết bị, mà là lựa chọn đúng chế độ hoạt động (Operating Mode).

Trong các hệ thống doanh nghiệp lớn, rất hiếm khi chỉ có một IDS/IPS duy nhất. Thay vào đó, nhiều cảm biến (sensor) được triển khai ở các vị trí khác nhau và hoạt động ở những chế độ khác nhau để cân bằng giữa khả năng bảo vệ, hiệu năng và tính sẵn sàng của dịch vụ.

Điều quan trọng là hiểu lưu lượng nào đang được phân tích và IDS/IPS có quyền can thiệp vào lưu lượng đó hay không.
1. Inline Mode (IPS Mode) – Chủ động ngăn chặn


Trong Inline Mode, còn gọi là IPS Mode, thiết bị được đặt trực tiếp trên đường đi của lưu lượng (inline).

Điều đó có nghĩa là mọi gói tin thực tế (real traffic) đều phải đi qua IDS/IPS trước khi đến đích.

Nhờ nằm ngay trên đường truyền, IPS có thể thực hiện các hành động theo thời gian thực như:
  • Chặn gói tin độc hại.
  • Hủy phiên TCP (TCP Reset).
  • Loại bỏ phiên kết nối.
  • Ngăn chặn khai thác lỗ hổng.
  • Thực thi chính sách bảo mật ngay lập tức.

Đây là chế độ phù hợp cho:
  • Data Center
  • Hệ thống tài chính
  • Mạng chính phủ
  • Hạ tầng quan trọng (Critical Infrastructure)
  • Các môi trường yêu cầu mức độ bảo mật cao

Tuy nhiên, Inline Mode cũng đặt ra yêu cầu rất cao về việc tinh chỉnh chính sách (Policy Tuning).

Nếu IPS xảy ra False Positive, lưu lượng hợp lệ có thể bị chặn, gây gián đoạn dịch vụ hoặc ảnh hưởng đến các ứng dụng quan trọng.
2. Passive Mode (IDS Mode) – Quan sát nhưng không can thiệp


Trong Passive Mode, còn gọi là IDS Mode, thiết bị không nằm trên đường đi của lưu lượng.

Thay vào đó, IDS chỉ nhận bản sao (copy) của lưu lượng để phân tích.

Điều này mang lại một lợi thế rất lớn:

👉 Không có nguy cơ làm gián đoạn dịch vụ, vì lưu lượng thật vẫn đi trực tiếp đến đích mà không bị IDS can thiệp.

Khi phát hiện dấu hiệu bất thường, IDS sẽ:
  • Ghi log.
  • Sinh cảnh báo.
  • Gửi sự kiện về SOC hoặc SIEM.

Nhưng không chặn lưu lượng.

Passive Mode đặc biệt phù hợp với:
  • Môi trường Production yêu cầu độ ổn định cao.
  • Hệ thống chưa sẵn sàng triển khai IPS.
  • Giai đoạn đánh giá và xây dựng chính sách phát hiện.
3. Hybrid Approach – Cách triển khai được nhiều doanh nghiệp lựa chọn


Trong thực tế, rất ít tổ chức chuyển ngay sang chế độ Protect Mode.

Một phương pháp phổ biến là:

Bước 1: Triển khai IDS ở chế độ Detect (Passive Mode).

↓

Bước 2: Theo dõi các cảnh báo trong một khoảng thời gian.

↓

Bước 3: Điều chỉnh signature và chính sách để giảm false positive.

↓

Bước 4: Chuyển dần sang IPS (Protect Mode) đối với các lưu lượng hoặc vùng mạng đã được kiểm chứng.

Cách tiếp cận này giúp doanh nghiệp:
  • Hiểu rõ hành vi lưu lượng bình thường.
  • Giảm nguy cơ chặn nhầm.
  • Tăng mức độ tin cậy của hệ thống trước khi kích hoạt chức năng ngăn chặn.
SPAN – "Mắt thần" của IDS


Một câu hỏi thường gặp là:
Nếu IDS không nằm trên đường truyền thì nó lấy lưu lượng ở đâu?

Câu trả lời là SPAN (Switch Port Analyzer).

Đây là tính năng trên Cisco Catalyst Switch cho phép sao chép toàn bộ lưu lượng từ:
  • Một cổng (Port)
  • Một VLAN
  • Hoặc nhiều nguồn khác

đến một cổng đích để IDS phân tích.

Điểm quan trọng là:
  • Thiết bị người dùng vẫn giao tiếp bình thường.
  • IDS chỉ nhận bản sao của lưu lượng.
  • Không ảnh hưởng đến hiệu năng hay đường đi của gói tin.

SPAN là phương pháp phổ biến nhất để triển khai IDS trong các mạng doanh nghiệp.
RSPAN và ERSPAN


Trong nhiều hệ thống lớn, IDS không đặt cùng switch với lưu lượng cần giám sát.

Cisco cung cấp hai cơ chế mở rộng:

RSPAN (Remote SPAN)


Cho phép truyền lưu lượng SPAN qua một VLAN chuyên dụng đến switch khác trong cùng mạng Layer 2.

ERSPAN (Encapsulated Remote SPAN)


Đóng gói lưu lượng SPAN trong gói GRE để truyền qua mạng IP.

Nhờ ERSPAN, lưu lượng có thể được gửi đến:
  • Trung tâm SOC.
  • Data Center khác.
  • Máy ảo IDS đặt trên Cloud.
  • Hệ thống phân tích tập trung.

Đây là giải pháp rất phổ biến trong các doanh nghiệp có nhiều chi nhánh hoặc hạ tầng phân tán.
Đừng quên "đường đến" của IDS


Một sai sót thường gặp khi triển khai IDS dưới dạng Virtual Machine hoặc trong môi trường Cloud là chỉ quan tâm đến IDS mà quên mất đường truyền đưa lưu lượng đến cảm biến.

Nếu bản sao lưu lượng không đến được IDS hoặc bị gián đoạn, hệ thống sẽ không thể quan sát đầy đủ các sự kiện an ninh.

Vì vậy, khi triển khai IDS/IPS dưới dạng VM (on-premises hoặc cloud), cần thiết kế:
  • Đường định tuyến dự phòng (Resilient Routing Paths).
  • Kết nối ổn định cho SPAN, RSPAN hoặc ERSPAN.
  • Hạ tầng mạng đủ băng thông để truyền lưu lượng giám sát.

Một cảm biến không nhận được dữ liệu cũng giống như một camera an ninh bị mất tín hiệu: thiết bị vẫn hoạt động, nhưng không còn giá trị giám sát.
Góc nhìn của một Security Architect


Nhiều doanh nghiệp nghĩ rằng IPS luôn tốt hơn IDS vì có khả năng chặn tấn công. Thực tế, không có chế độ nào là "tốt nhất" cho mọi tình huống.
  • IDS (Passive Mode) phù hợp khi ưu tiên tính sẵn sàng, cần quan sát lưu lượng hoặc đang trong giai đoạn tinh chỉnh chính sách.
  • IPS (Inline Mode) phù hợp khi doanh nghiệp đã hiểu rõ hành vi lưu lượng và sẵn sàng chủ động ngăn chặn các mối đe dọa theo thời gian thực.
  • Hybrid Approach là lựa chọn phổ biến nhất hiện nay, cho phép chuyển đổi từng bước từ giám sát sang bảo vệ chủ động sau khi đã tối ưu chính sách.

Một kiến trúc bảo mật trưởng thành thường kết hợp cả ba cách tiếp cận này, tùy theo mức độ quan trọng của từng vùng mạng và yêu cầu vận hành.
Câu hỏi ôn tập


Bốn chiến lược nào sau đây là các vị trí triển khai IDS/IPS hiệu quả để tối đa hóa phạm vi bảo vệ và khả năng phát hiện mối đe dọa? (Chọn bốn)
  • ✅ Place IDS/IPS at aggregation points.
  • ✅ Deploy IDS/IPS at perimeter defense.
  • ❌ Install IDS/IPS on user devices.
  • ✅ Position IDS/IPS in internal segments.
  • ❌ Exclude IDS/IPS from cloud environments.
  • ✅ Utilize cloud & hybrid environments.
  • ❌ Place the IDS/IPS on the outside network after the firewall between the service provider router.

Đáp án đúng:
  • Place IDS/IPS at aggregation points
  • Deploy IDS/IPS at perimeter defense
  • Position IDS/IPS in internal segments
  • Utilize cloud & hybrid environments

Giải thích: Để xây dựng kiến trúc Defense in Depth, IDS/IPS nên được triển khai ở nhiều lớp của hệ thống: tại các điểm hội tụ lưu lượng (Aggregation Points) để thu thập thông tin ngữ cảnh, tại Perimeter để ngăn chặn các mối đe dọa từ Internet, trước các Internal Segments nhằm phát hiện và ngăn chặn Lateral Movement, và trong Cloud & Hybrid Cloud để bảo vệ các workload và lưu lượng East-West. Việc đặt IDS/IPS bên ngoài firewall, phía mạng của nhà cung cấp dịch vụ, thường không được khuyến nghị vì thiết bị sẽ phải xử lý lượng lớn lưu lượng chưa được firewall lọc và không phản ánh đúng mục tiêu bảo vệ của mạng doanh nghiệp.​]]> CCNP Security Core dangquangminh https://www.forum.vnpro.org/forum/ccnp-security/security-core/442281-lựa-chọn-chế-độ-hoạt-động-phù-hợp-cho-ids-ips Redistribute vào OSPF https://www.forum.vnpro.org/forum/ccnp-security/security-core/442223-redistribute-vào-ospf Fri, 03 Jul 2026 10:54:55 GMT Câu chuyện CCIE Lab EI tại Brussels: 20 phút trước giờ nghỉ trưa và bài học nhớ đời về OSPF Redistribution Có một bài học mà tôi vẫn thường chia... Câu chuyện CCIE Lab EI tại Brussels: 20 phút trước giờ nghỉ trưa và bài học nhớ đời về OSPF Redistribution


Có một bài học mà tôi vẫn thường chia sẻ với các học viên CCIE Enterprise Infrastructure sau mỗi kỳ thi Lab.

Không phải là EVPN, không phải Segment Routing hay SDA Fabric.

Mà là... Route Redistribution.

Đó là một tình huống xảy ra trong buổi thi CCIE Lab kéo dài 8 giờ tại Brussels. Khi đồng hồ chỉ còn khoảng 20 phút nữa là đến giờ nghỉ trưa (Lunch Time), tôi gặp một bài yêu cầu khá quen thuộc: redistribute EIGRP vào OSPF. Đọc đề xong, tôi nghĩ: "Phần này chắc chỉ mất vài phút."

Nhưng rồi mọi thứ lại không đơn giản như vậy.
Bước đầu tiên: Đừng nhìn vào lệnh redistribute


Đây là sai lầm mà rất nhiều người mắc phải.

Khi route không xuất hiện trong OSPF, phản xạ đầu tiên thường là kiểm tra:
redistribute eigrp 100 subnets

hoặc:
show ip protocols

Nhưng trong Lab CCIE, nếu đi theo hướng này ngay từ đầu, bạn rất dễ mất hàng chục phút.

Điều đầu tiên tôi luôn tự hỏi là:
"Route cần redistribute đã thực sự tồn tại trong Routing Table chưa?"

Đó là quy luật đầu tiên của Redistribution.

Redistribution không lấy route trực tiếp từ EIGRP Topology Table hay OSPF LSDB.

Nó chỉ lấy route từ:
Routing Protocol
│
▼
IP Routing Table
│
▼
Routing Protocol

Nếu route chưa được cài vào IP Routing Table thì Redistribution hoàn toàn không có gì để làm.
Kiểm tra giao thức nguồn trước


Tôi bắt đầu với giao thức nguồn.

Nếu đang redistribute từ EIGRP sang OSPF thì việc đầu tiên là kiểm tra EIGRP đã học route hay chưa.

Ví dụ:
show ip eigrp topology

Nếu là OSPF thì sẽ là:
show ip ospf database

Nếu là RIP:
show ip rip database

Nếu là BGP:
show ip bgp

May mắn là trong bài thi hôm đó, EIGRP đã học đầy đủ các route.

Vậy vấn đề không nằm ở giao thức nguồn.
Route đã vào Routing Table chưa?


Bước tiếp theo:
show ip route

hoặc
show ip route <prefix>

Đây mới là nơi quyết định Redistribution có diễn ra hay không.

Trong bài thi hôm đó, route đã nằm trong Routing Table.

Điều đó đồng nghĩa:
  • Neighbor OK.
  • EIGRP hoạt động bình thường.
  • Administrative Distance không có vấn đề.
  • Route Selection cũng không có vấn đề.

Đến đây tôi mới bắt đầu kiểm tra phần Redistribution.
OSPF có rất nhiều tùy chọn và cũng rất nhiều "cái bẫy"


So với RIP hay EIGRP, OSPF có nhiều tham số hơn trong lệnh redistribute.

Ví dụ:
router ospf 1
redistribute eigrp 100 ?

Cisco IOS sẽ hiển thị:
metric
metric-type
nssa-only
route-map
subnets
tag

Mỗi tham số đều có thể là nguyên nhân khiến Redistribution hoạt động không đúng như mong muốn.
Seed Metric không phải là thủ phạm


Khác với EIGRP và RIP, OSPF đã có Seed Metric mặc định.

Giá trị mặc định là:
20

Điều đó có nghĩa là nếu bạn quên:
metric

thì OSPF vẫn redistribute bình thường.

Đây là khác biệt rất lớn so với EIGRP.

Trong bài Lab hôm đó, metric hoàn toàn không phải nguyên nhân.
Kiểm tra Metric-Type


OSPF hỗ trợ hai loại External Route. Type 2 (E2)


Đây là mặc định.

Ví dụ trong Routing Table:
O E2 10.1.3.0/24

Với E2, mọi router đều giữ nguyên Seed Metric.

Ví dụ Seed Metric bằng 20.

Dù router cách ASBR một hop hay mười hop thì Metric vẫn là 20.
Type 1 (E1)


Nếu cấu hình:
metric-type 1

thì Metric cuối cùng sẽ bằng:
Seed Metric
+
Toàn bộ Cost OSPF đến ASBR

Các router càng xa ASBR thì Cost càng lớn.

Điều này rất quan trọng trong các mạng có nhiều điểm Redistribution.
Cái bẫy thật sự: Thiếu từ khóa subnets


Sau khoảng vài phút kiểm tra, tôi nhìn lại cấu hình và phát hiện đúng một dòng:
redistribute eigrp 100

Thiếu đúng một từ.
subnets

Đây là một lỗi kinh điển.

Trong OSPFv2:

Nếu không có từ khóa:
subnets

OSPF chỉ redistribute các mạng classful.

Ví dụ:
10.0.0.0/8

hoặc
172.16.0.0/16

hoặc
192.168.1.0/24

Trong khi toàn bộ bài Lab đều sử dụng VLSM.

Ví dụ:
10.1.3.0/24
10.1.23.0/24

Những route này sẽ không bao giờ được redistribute nếu thiếu subnets.

Chỉ cần thêm đúng một từ:
redistribute eigrp 100 subnets

toàn bộ bài bắt đầu hoạt động.

Đó là một bài học mà tôi không bao giờ quên.
Kiểm tra bằng show ip protocols


Sau khi sửa cấu hình, tôi luôn xác nhận bằng:
show ip protocols

Kết quả mong muốn là:
Routing Protocol is "ospf 1"

Redistributing External Routes from

eigrp 100, includes subnets

Nếu không thấy dòng:
includes subnets

thì tôi biết mình vẫn còn thiếu cấu hình.
Kiểm tra LSDB


Bước tiếp theo:
show ip ospf database

Nếu Redistribution thành công thì các route sẽ xuất hiện trong:
Type-5 AS External Link States

Ví dụ:
10.1.3.0
10.1.23.0

Nếu là NSSA thì trước tiên chúng sẽ xuất hiện dưới dạng:
Type-7 LSA

sau đó được ABR chuyển đổi thành Type-5 LSA khi quảng bá sang các Area khác.
Kiểm tra trên ASBR


Một lệnh mà tôi gần như luôn sử dụng trong Lab là:
show ip route 10.1.3.0

Tôi muốn nhìn thấy:
Known via "eigrp 100"

Redistributing via eigrp 100, ospf 1

Advertised by ospf 1 subnets

Ba dòng này xác nhận toàn bộ chuỗi xử lý:
  • Route được học từ EIGRP.
  • Route đang được redistribute vào OSPF.
  • OSPF quảng bá route với tùy chọn subnets.
Kiểm tra trên router khác


Trên các router không phải ASBR:
show ip route

Tôi mong đợi thấy:
O E2 10.1.3.0/24 [110/20]

Nếu dùng:
metric-type 1

thì route sẽ hiển thị:
O E1

Nếu đi qua NSSA:
O N1
O N2

Nhìn vào ký hiệu trong Routing Table là có thể biết ngay loại External Route đang được sử dụng.
Với OSPFv3 thì sao?


Nếu là IPv6, tôi sẽ dùng:
show ipv6 protocols

Để kiểm tra:
  • Giao thức nào đang được redistribute.
  • Seed Metric.
  • Có sử dụng:
include-connected

hay không.

Sau đó kiểm tra:
show ipv6 ospf database

Các route redistribute sẽ xuất hiện trong:
Type-5 AS External Link States

Cuối cùng xác nhận trên router khác bằng:
show ipv6 route

với các ký hiệu:
OE2
OE1
ON1
ON2

giống như OSPFv2 nhưng áp dụng cho IPv6.
Một lưu ý rất dễ mất điểm trong Lab


Nếu redistribute từ BGP vào OSPF, EIGRP hoặc RIP, Cisco chỉ redistribute eBGP routes theo mặc định.

Các route học từ iBGP sẽ không được redistribute.

Muốn đưa iBGP vào Redistribution phải cấu hình:
router bgp <ASN>
bgp redistribute-internal

Đây là chi tiết nhỏ nhưng hoàn toàn có thể khiến bạn mất điểm nếu không để ý.
Kết thúc trước giờ nghỉ trưa


Tôi sửa lại cấu hình, kiểm tra lại toàn bộ các bước một lần cuối:
  • Giao thức nguồn đã học route.
  • Route đã được cài vào IP Routing Table.
  • Redistribution đã có subnets.
  • show ip protocols xác nhận đang redistribute EIGRP và includes subnets.
  • LSDB đã xuất hiện Type-5 LSA.
  • Router khác học được route với ký hiệu O E2.

Tất cả hoàn tất trước khi giám thị thông báo nghỉ trưa.

Sau nhiều năm làm việc và hướng dẫn CCIE, tôi nhận ra rằng những bài Redistribution hiếm khi đánh đố bằng cú pháp. Chúng đánh vào tư duy xử lý sự cố. Người mất nhiều thời gian nhất thường là người bắt đầu từ lệnh redistribute. Còn người giải nhanh thường bắt đầu từ câu hỏi rất đơn giản:
"Route này đã thực sự đi vào IP Routing Table chưa?"

Chỉ cần trả lời đúng câu hỏi đó, bạn đã loại bỏ được hơn một nửa các nguyên nhân gây lỗi trong những bài Redistribution của CCIE Lab.
​]]> CCNP Security Core dangquangminh https://www.forum.vnpro.org/forum/ccnp-security/security-core/442223-redistribute-vào-ospf Ids/ips https://www.forum.vnpro.org/forum/ccnp-security/security-core/442052-ids-ips Sun, 28 Jun 2026 07:57:06 GMT Các tính năng chính của IDS/IPS Những kẻ tấn công mạng ngày càng tinh vi trong việc ngụy trang lưu lượng độc hại để trông giống như lưu lượng... Các tính năng chính của IDS/IPS


Những kẻ tấn công mạng ngày càng tinh vi trong việc ngụy trang lưu lượng độc hại để trông giống như lưu lượng hợp lệ, giúp chúng vượt qua các cơ chế bảo mật cơ bản. Các mối đe dọa này thường được ẩn bên trong những luồng dữ liệu có vẻ bình thường, khiến các firewall truyền thống ở Layer 3 khó có thể phát hiện.

Trong nhiều trường hợp, kẻ tấn công còn giả mạo nguồn gửi (IP Spoofing) để lưu lượng trông như xuất phát từ một thiết bị hoặc hệ thống đáng tin cậy, làm tăng thêm độ khó cho việc phát hiện.

Để đối phó với những kỹ thuật này, doanh nghiệp cần các giải pháp có khả năng kiểm tra sâu hơn tiêu đề (header) của gói tin. Đó chính là vai trò của Intrusion Detection System (IDS) và Intrusion Prevention System (IPS). Hai hệ thống này sử dụng Deep Packet Inspection (DPI) để phân tích phần payload ở tầng ứng dụng, từ đó phát hiện mã độc, hành vi bất thường, vi phạm chính sách và các mẫu tấn công mà firewall truyền thống không thể nhận biết.
Vì sao chỉ dựa vào địa chỉ IP là chưa đủ?


Hãy tưởng tượng bạn là một Security Architect nhận được cảnh báo về hoạt động bất thường trong mạng doanh nghiệp.

Hiện tại, hệ thống chỉ sử dụng:
  • Cơ chế xác thực người dùng.
  • Firewall kiểm soát lưu lượng dựa trên địa chỉ IP.

Đây đều là những lớp bảo vệ quan trọng, nhưng nhóm bảo mật nhận thấy chúng không đủ để phát hiện các cuộc tấn công hiện đại.

Lý do là địa chỉ IP chỉ cho biết nguồn và đích của gói tin, chứ không phản ánh nội dung thực sự bên trong gói tin.

Một firewall Layer 3 có thể cho phép lưu lượng đi qua vì IP nguồn được phép, nhưng hoàn toàn không biết rằng payload chứa:
  • Mã khai thác lỗ hổng (Exploit)
  • Malware
  • Ransomware
  • Shellcode
  • Lệnh Command & Control (C2)

Nói cách khác, Layer 3 chỉ trả lời câu hỏi "gói tin đến từ đâu và đi đến đâu", chứ không trả lời "gói tin đang mang nội dung gì".
Địa chỉ IP không đồng nghĩa với sự tin cậy


Nhiều người cho rằng nếu một thiết bị đã được cấp địa chỉ IP sau khi xác thực thì lưu lượng từ thiết bị đó có thể được tin cậy.

Đây là một giả định không an toàn.

Trong thực tế:
  • Người dùng có thể tự gán địa chỉ IP tĩnh.
  • Kẻ tấn công có thể giả mạo địa chỉ IP (IP Spoofing).
  • Nếu Network Admission Control (NAC) yếu hoặc không được triển khai, thiết bị trái phép vẫn có thể tham gia vào mạng.

Điều đó có nghĩa là một gói tin mang địa chỉ IP "đáng tin cậy" vẫn có thể chứa nội dung độc hại.

Chính vì vậy, doanh nghiệp cần các cơ chế kiểm tra sâu hơn thay vì chỉ dựa vào thông tin địa chỉ IP.
Deep Packet Inspection (DPI)


IDS và IPS sử dụng Deep Packet Inspection (DPI) để phân tích nội dung thực tế của gói tin.

Thay vì chỉ đọc:
  • IP Source
  • IP Destination
  • TCP/UDP Port

DPI tiếp tục kiểm tra:
  • Payload của tầng ứng dụng.
  • Định dạng giao thức.
  • Chuỗi dữ liệu đặc trưng của malware.
  • Dấu hiệu khai thác lỗ hổng.
  • Vi phạm chính sách bảo mật.

Qua đó, hệ thống có thể xác định liệu lưu lượng có thực sự hợp lệ hay đang chứa mã độc được ngụy trang.
IDS và IPS hoạt động như thế nào?


IDS và IPS liên tục phân tích lưu lượng mạng nhằm phát hiện:
  • Hành vi bất thường (Anomalies)
  • Mẫu tấn công đã biết
  • Vi phạm chính sách bảo mật

Để nhận diện các mối đe dọa, hệ thống sử dụng Signature.

Signature là tập hợp các mẫu nhận dạng (pattern) đại diện cho một kiểu tấn công hoặc hành vi cụ thể. Khi lưu lượng khớp với một signature đã biết, IDS/IPS sẽ phát hiện và đưa ra phản ứng phù hợp.

Ngoài việc dựa trên signature, nhiều giải pháp IDS/IPS hiện đại còn kết hợp các kỹ thuật như phân tích hành vi (Behavior Analysis) và phát hiện bất thường (Anomaly Detection) để nhận diện các mối đe dọa mới.
Ba mô hình triển khai IDS/IPS


IDS/IPS có thể được triển khai theo nhiều mô hình khác nhau, tùy thuộc vào yêu cầu giám sát hoặc ngăn chặn của hệ thống. Mặc dù tài liệu đề cập đến ba cách triển khai, điểm quan trọng nhất là sự khác biệt trong cách phản ứng với các mối đe dọa.
Sự khác biệt giữa IDS và IPS

IDS (Intrusion Detection System)


IDS hoạt động ở chế độ giám sát.

Khi phát hiện lưu lượng đáng ngờ, IDS sẽ:
  • Ghi log.
  • Sinh cảnh báo.
  • Thông báo cho quản trị viên.

Tuy nhiên, IDS không can thiệp vào luồng lưu lượng, vì vậy gói tin vẫn tiếp tục được chuyển đến đích.
IPS (Intrusion Prevention System)


IPS hoạt động Inline, nằm trực tiếp trên đường đi của lưu lượng.

Khi phát hiện lưu lượng độc hại, IPS có thể:
  • Chặn gói tin.
  • Hủy phiên kết nối.
  • Reset TCP Session.
  • Ngăn chặn cuộc tấn công theo thời gian thực.

Nhờ đó, mối đe dọa được xử lý ngay trước khi đến máy chủ hoặc người dùng.
Tại sao không phải lúc nào cũng nên chặn?


Đây là câu hỏi rất phổ biến khi triển khai IPS.

Về lý thuyết, chặn lưu lượng độc hại luôn là lựa chọn tốt nhất.

Tuy nhiên, trong thực tế, IPS có thể gặp False Positive — tức là nhận diện nhầm lưu lượng hợp lệ thành lưu lượng tấn công.

Nếu IPS chặn nhầm các gói tin của một ứng dụng quan trọng, hậu quả có thể là:
  • Gián đoạn dịch vụ.
  • Mất kết nối giữa các hệ thống.
  • Ứng dụng ngừng hoạt động.
  • Downtime ảnh hưởng đến hoạt động kinh doanh.

Ngay cả khi TCP thực hiện truyền lại (Retransmission), chính sách IPS vẫn có thể tiếp tục chặn các gói tin đó.

Do đó, việc triển khai IPS luôn cần cân bằng giữa mức độ bảo mật và tính sẵn sàng của dịch vụ.
Kết hợp bảo vệ Endpoint


Trong một số hệ thống quan trọng, doanh nghiệp có thể lựa chọn:
  • Cho phép lưu lượng đi qua sau khi được kiểm tra.
  • Không chặn ngay trên mạng.
  • Tăng cường bảo vệ tại Endpoint.

Giải pháp thường được sử dụng là:
  • Host-Based Intrusion Prevention System (HIPS)
  • Antivirus
  • Antispyware
  • Endpoint Detection and Response (EDR)

Cách tiếp cận nhiều lớp này giúp giảm rủi ro do false positive trên mạng, đồng thời vẫn duy trì khả năng phát hiện và ngăn chặn mối đe dọa tại thiết bị đầu cuối.
Kết luận


IDS và IPS là những thành phần quan trọng trong kiến trúc phòng thủ nhiều lớp (Defense in Depth). Trong khi firewall chủ yếu kiểm soát lưu lượng dựa trên địa chỉ IP và cổng dịch vụ, IDS/IPS sử dụng Deep Packet Inspection (DPI) để phân tích nội dung thực tế của gói tin, phát hiện các mối đe dọa ẩn trong payload. IDS tập trung vào giám sát và cảnh báo, còn IPS có khả năng ngăn chặn tấn công theo thời gian thực. Khi triển khai IPS, doanh nghiệp cần cân nhắc giữa khả năng bảo vệ và nguy cơ gây gián đoạn dịch vụ do các trường hợp false positive, đồng thời kết hợp với các giải pháp bảo vệ endpoint như HIPS, Antivirus và EDR để xây dựng một hệ thống phòng thủ toàn diện.
Câu hỏi ôn tập


Yếu tố nào là cân nhắc quan trọng khi quyết định triển khai IPS để chủ động chặn các mối đe dọa?
  • ❌ The availability of up-to-date threat intelligence feeds for the IPS.
  • ❌ The cost of implementing and maintaining the IPS.
  • ✅ The potential for unintended disruptions to critical applications due to false positives.
  • ❌ The complexity of configuring the IPS to integrate with existing network infrastructure.

Đáp án đúng: The potential for unintended disruptions to critical applications due to false positives.

Giải thích: IPS có khả năng chặn lưu lượng theo thời gian thực, nhưng nếu xảy ra false positive, hệ thống có thể chặn nhầm lưu lượng hợp lệ của các ứng dụng quan trọng, gây gián đoạn dịch vụ hoặc downtime. Vì vậy, trước khi triển khai IPS ở chế độ chặn (prevention mode), cần đánh giá kỹ chính sách phát hiện, hiệu chỉnh chữ ký (signature) và thử nghiệm trong môi trường phù hợp để giảm thiểu tác động đến hoạt động của doanh nghiệp.​]]> CCNP Security Core dangquangminh https://www.forum.vnpro.org/forum/ccnp-security/security-core/442052-ids-ips Bạn đã làm IT nhiều năm… nhưng có một câu hỏi khiến bạn phải suy nghĩ: https://www.forum.vnpro.org/forum/ccnp-security/security-core/441920-bạn-đã-làm-it-nhiều-năm…-nhưng-có-một-câu-hỏi-khiến-bạn-phải-suy-nghĩ Wed, 24 Jun 2026 08:15:47 GMT “Nếu ngày mai doanh nghiệp gặp một cuộc tấn công mạng, mình có đủ khả năng để bảo vệ hệ thống không?” Đây là điều rất nhiều kỹ sư Network, System... Click image for larger version Name: hình ảnh bài viết3.jpg Views: 11 Size: 230.0 KB ID: 441921

“Nếu ngày mai doanh nghiệp gặp một cuộc tấn công mạng, mình có đủ khả năng để bảo vệ hệ thống không?”
Đây là điều rất nhiều kỹ sư Network, System Admin đang bắt đầu quan tâm.
Bởi vì vài năm trước:
👉 Biết cấu hình Router, Switch là một lợi thế.
👉 Quản trị hệ thống ổn định là một kỹ năng quan trọng.
Nhưng hiện tại…
Một kỹ sư IT chuyên nghiệp không chỉ cần biết:
“Làm sao để hệ thống chạy?”
Mà còn phải trả lời được:
“Làm sao để hệ thống được bảo vệ?”

🎯 Sự thay đổi của ngành IT đang diễn ra rất rõ ràng
Doanh nghiệp ngày càng phụ thuộc vào công nghệ.
Dữ liệu ngày càng quan trọng.
Các cuộc tấn công mạng ngày càng tinh vi.
Vì vậy, nhu cầu về những kỹ sư có khả năng:
✅ Hiểu kiến trúc bảo mật
✅ Triển khai giải pháp phòng thủ
✅ Kiểm soát truy cập người dùng
✅ Bảo vệ dữ liệu và hệ thống mạng
đang ngày càng tăng.

Có thể bạn đang ở một trong những tình huống này:
❓ Bạn là Network Engineer nhưng muốn bước sang Security?
❓ Bạn đã học CCNA/CCNP nhưng cảm thấy kiến thức bảo mật còn thiếu?
❓ Công việc hiện tại bắt đầu yêu cầu bạn hiểu Firewall, VPN, Authentication, Threat Protection?
Nếu câu trả lời là "Có"…
Đây có thể là thời điểm phù hợp để bạn nâng cấp bản thân.

🚀 VnPro khai giảng khóa học
CCNP SECURITY – SCOR (350-701)
📅 Khai giảng: 29/06/2026
⏰ Lịch học: Tối 2-4-6
💻 Hình thức: ONLINE
Đây là khóa học dành cho những kỹ sư muốn xây dựng nền tảng chuyên sâu về Cisco Security với các nội dung trọng tâm:
🔹 Network Security
🔹 Secure Access
🔹 Identity Management
🔹 VPN & Encryption
🔹 Threat Protection
🔹 Security Architecture
Không chỉ học câu lệnh cấu hình…
Mục tiêu quan trọng hơn là giúp học viên hiểu:
Vì sao cần bảo mật?
Bảo mật ở đâu?
Triển khai như thế nào trong môi trường thực tế?

💡 Trong ngành CNTT, người phát triển nhanh không phải là người biết nhiều công cụ nhất.
Mà là người liên tục nâng cấp tư duy và năng lực theo sự thay đổi của công nghệ.
Hôm nay bạn đầu tư cho Security…
Ngày mai bạn đang đầu tư cho giá trị nghề nghiệp của chính mình.

📩 Bạn muốn biết CCNP Secutity SCOR có phù hợp với lộ trình nghề nghiệp của mình không?
Hãy inbox để được tư vấn lộ trình học phù hợp và nhận ngay ưu đãi đặc biệt Balo VnPro dành tặng đến bạn!
☎ Hotline/Zalo: 093 3427 079
👩 Anh Thư: 033 9943 732
📧 Email: phongkinhdoanh@vnpro.org
#VnPro #CCNPSecurity scor cybersecurity #NetworkEngineer #CiscoSecurity #ITCareer
​​]]> CCNP Security Core Anh Thư https://www.forum.vnpro.org/forum/ccnp-security/security-core/441920-bạn-đã-làm-it-nhiều-năm…-nhưng-có-một-câu-hỏi-khiến-bạn-phải-suy-nghĩ