Cisco FTD [LAB-8] Cấu hình User Identity trên Cisco FTD

phile

Internship/Fresher
Jan 4, 2021
90
17
8
Mục Lục:
I. Giới thiệu về mô hình bài Lab
II. Cấu hình User Identity trên Cisco FTD thông qua FDM


[LAB-8] Cấu hình User Identity trên Cisco FTD

Lưu ý: tất cả các thiết bị Cisco FTD trong chuổi series này đều được dựng ảo hóa hoàn toàn trên VMware và sử dụng phần mềm FDM để quản lý các thiết bị Cisco FTD. (phiên bản cisco FTD là 7.0.5-72)

I. Giới thiệu về mô hình bài Lab


Mô hình bài Lab bao gồm các thành phần như: Switch, WEB server, DNS server, AD server, Cisco FTD và các PC người dùng được phân chia làm các subnet:
  • Outside network: 10.120.190.0/24
  • User network: 172.31.198.0/24 và 172.31.199.0/24
  • Server network: 172.31.100.0/24 và 172.31.10.0/24
Gateway lần lượt được cấu hình trên cisco FTD: 10.120.190.31/24, 172.31.198.250, 172.31.198.250, 172.31.10.250, 172.31.100.250,...
Yêu cầu của bài Lab:
  • Cấu hình thêm AD Realm trên Cisco FTD được quản lý thông qua FDM để làm nguồn định danh khi thực hiện xác thực user .
  • Cấu hình và kiểm tra User Identity policy sao cho PC thuộc subnet 172.31.198.0/24 nếu muốn vào mạng cần phải xác thực thông qua captive portal. Đồng thời tiến hành cấu hinh Access Control Policy dựa trên user sao cho PC thuộc subnet 172.31.198.0/24 sẽ không ping được tới PC thuộc subnet 172.31.10.0/24.
  • Cấu hình và kiểm tra User Identity policy sao cho các PC thuộc subnet 172.31.199.0/24 (đã join domain) được định danh dựa vào user login domain và không hiển thị portal thông qua NTLM (Transparent Authentication)
1694595082863.png


II. Cấu hình User Identity trên Cisco FTD thông qua FDM

Tất cả các truy cập trên thế giới qua mạng internet được quản lý thông qua IP, đối với người dùng trong mạng LAN cũng như vậy nhưng đôi khi việc quản lý các chính sách dựa vào IP không đảm bảo được độ chính xác. Vì việc cấp IP trong mạng LAN thường dựa vào DHCP nên một lúc nào đó (tùy vào cấu hình DHCP server và cấu hình trên PC) IP có thể bị thay đổi hoặc trong trường hợp người dùng di chuyển giữa các lớp mạng khác nhau thì các chính sách được áp dụng sẽ không còn hiệu lực. Vì thế Cisco FTD cung cấp tính năng User Identity cho phép xác định người dùng được liên kết với một IP đều này giúp việc cấu hình các chính sách đơn giản hơn thay vì dựa vào IP thì lúc này sẽ dựa vào User nên cho dù người dùng có thay đổi IP thì chính sách vẫn hoạt động. Cisco FTD hỗ trợ 2 phương xác thực dùng để mapping User với IP:
  • Passive authentication:cần một công cụ khác để xác thực người dùng và sau đó cung cấp kết quả cho Cisco FTD. Nó thường được thực hiện thông qua xác thực Cisco ISE dot1x và công nghệ pxGrid. Phương pháp này sẽ silence với người dùng.
  • Active authentication: người dùng sẽ được chuyển hướng đến cổng captive portal, nơi họ cần phải điền thông tin xác thực. Khi xác thực người dùng thành công, địa chỉ IP của người dùng sẽ được ánh xạ đến tên người dùng của họ. Phương thức này sẽ yêu cầu người dùng nhập thông tin xác thực. Chi tiết sẽ bao gồm các loại:
    • HTTP Basic: Xác thực người dùng bằng kết nối HTTP Basic Authentication (BA) không được mã hóa. Người dùng đăng nhập vào mạng bằng cửa sổ bật lên xác thực mặc định của trình duyệt.
    • NTLM: Xác thực người dùng bằng kết nối NT LAN Manager (NTLM). Người dùng đăng nhập vào mạng bằng cửa sổ bật lên xác thực mặc định của trình duyệt của họ, ngoài ra còn hỗ trợ cấu hình trên các trình duyệt IE và Firefox để Transparent Authentication bằng cách sử dụng thông tin đăng nhập domain Windows.
    • HTTP Negotiate: Cho phép thiết bị đàm phán phương thức giữa user agent (ứng dụng mà người dùng đang sử dụng để bắt đầu luồng lưu lượng) và Active Directory. Người dùng đăng nhập vào mạng bằng cửa sổ bật lên xác thực mặc định của trình duyệt. Phương thức này cũng hỗ trợ Transparent Authentication nhưng cần được cấu hình phần mềm Cisco User Agent trên AD.
    • HTTP Response Page: Nhắc người dùng xác thực bằng trang web do hệ thống cung cấp. Đây là một hình thức xác thực HTTP Basic.
Lưu ý: Để xác thực người dùng, cần phải định cấu hình nguồn lưu trữ user và lựa chọn phương thức xác thực. Chỉ phương thức Active authentication thông qua HTTP Negotiate mới hỗ trợ địa chỉ URL captive portal dưới dạng DNS khi yêu cầu người dùng điền thông tin còn lại sẽ hiển thị ở dạng IP.

Thông tin nhận dạng người dùng có thể được sử dụng cho nhiều mục đích, chẳng hạn như:
  • Theo dõi và kiểm tra : có thể sử dụng thông tin nhận dạng người dùng để theo dõi ai đã truy cập vào mạng và khi nào. Điều này có thể hữu ích cho việc giải quyết các sự cố bảo mật hoặc báo cáo tuân thủ.
  • Kiểm soát truy cập : có thể sử dụng thông tin nhận dạng người dùng để kiểm soát ai có quyền truy cập vào các tài nguyên cụ thể trên mạng của bạn. Ví dụ, bạn có thể chỉ cho phép một số người dùng nhất định truy cập vào một máy chủ hoặc ứng dụng cụ thể.
  • Phát hiện mối đe dọa : có thể sử dụng thông tin nhận dạng người dùng để xác định hoạt động độc hại trên mạng. Ví dụ, nếu một người dùng không được phép truy cập vào một tài nguyên cụ thể cố gắng thực hiện việc đó, hệ thống có thể được cảnh báo về một mối đe dọa bảo mật tiềm ẩn.
Tất cả phương thức được sử dụng trong bài lab này để định danh user đều là Active authentication, nên việc đầu tiên cần làm là cấu hình thông tin AD làm nguồn chứa thông tin người dùng cần để xác thực. Để cấu hình tiến hành vào phần Objects > Identity Sources > chọn AD Realm.
1694595124306.png

Sau đó tiến hành cấu hình thông tin để kết nối đến AD bao gồm:
  • Name: tên cho AD
  • Directory Username: user dùng để kết nối xác thực với AD cần kết nối
  • Directory Password: password của user dùng để kết nối xác thực với AD cần kết nối
  • Base DN: bộ lọc cho phép query đến các user nằm trong thông tin cấu hình
  • AD Primary Domain: tên domain trên AD cần kết nối
  • Hostname/ IP Address: địa chỉ IP hoặc DNS của AD cần kết nối
  • Port: cổng của AD cần kết nối
Sau khi đã hoàn thành chọn TEST để kiểm tra kết nối với AD đảm bảo nhận được kết quả như hình đối với việc sử dụng AD làm source cho Identity Policy.

Lưu ý: Tùy vào mục đích sử dụng AD cho việc xác thực người dùng mà cần cấu hình cổng kết nối cho phù hợp, cụ thể như sau:
  • Đối với kết nối AD để làm source cho Identity Policy: sẽ sử dụng cổng MGMT để truy vấn.
  • Đối với kết nối AD đề làm source cho Remote Access VPN: sẽ dụng cổng Data để truy vấn.
1694595137746.png



Sau khi đã hoàn thành việc thêm AD, tiến hành vào Polices > Identity > chọn Actice authentication > ENABLE IDENTITY POLICY để tiến hành cấu hình chính sách định danh người dùng sử dụng captive portal.
1694595141801.png

Tiến hành cấu hình certificate và port được sử dụng cho phương thức Active Authentication thông qua captive portal.

Lưu ý: nếu sử dụng SSL Decryption Re-sign thì có thể chọn cùng chứng chỉ đó cho Active Authentication như hình bên dưới. Nếu không có cần tạo certificate mới và cần được cài đặt trên các PC.
1694595145431.png
1694595149907.png
Tiếp theo tiến hành chọn CREATE IDENTITY RULE để cấu hình chính sách định danh.
1694595153574.png

Trong Identity Rule tiến hành cấu hình các thông tin sau để phù hợp với phương thức Active Authentication thông qua captive portal:
  • Order: vị trí của rule, ưu tiên thực hiện từ trên xuống
  • Title: tên của rule
  • AD Identity Source: AD Realm đã được cấu hình để làm source user
  • Action: phương thức định danh
  • Type: kiểu định danh
1694595157900.png

Sau đó trong Tab Source / Destination cần phải cấu hình phạm vi áp dụng chính sách này, tương tự việc cấu hình Access Control Policy.
1694595161608.png

Sau đó tiến hành vào PC thuộc Subnet 172.31.198.0/24 lúc này sẽ thấy portal yêu cầu nhập thông tin user (các user này đã được tạo trên AD), khi đã xác thực thành công thì lúc này PC mới có thể truy cập mạng.
1694595175802.png
1694595178629.png
Kiểm tra trên Cisco FTD vào phần Monitoring > Users sẽ thấy được thông tin user đã được mapping với IP cũng như thông tin traffic.
1694595194874.png

Sau khi chính sách User Identity đã hoạt động lúc này có thể tiến hành cấu hình Access Control Policy dựa vào user tiến hành tạo Policy như hình để cấm ping tới Subnet 172.31.10.0/24
1694595253771.png

TIếp theo tại Tab Users chọn user muốn áp dụng cho chính sách.
1694595258031.png

Lúc này trên PC thuộc Subnet 172.31.198.0/24 không thể ping đến PC thuộc Subnet 172.31.10.0/24 nhưng vẫn có thể truy cập được service web của PC thuộc subnet 172.31.10.0/24. Trong khi đó PC thuộc Subnet 172.31.199.0/24 có thể ping bình thường.
1694595283867.png
1694595286496.png

Đối lúc việc bắt người dùng nhập lại thông tin đăng nhập để có thể vào mạng không phù hợp với các user đã join Domain vì vô tính họ cần phần phải nhập lại thông tin đăng nhập 1 lần nữa (1 lần để đăng nhập máy tính và 1 lần để đăng nhập vào mạng) đều này có thể gây bất tiện nên cầu một phương thức Transparent Authentication. Đối với phương thức định danh người dùng theo Active Authentication Cisco hỗ trợ Transparent Authentication trên 2 kiểu: NTLM và HTTP Negotiate. Bài Lab này sẽ tập trung vào NTLM nhưng để đảm bảo hoạt động cần phải cấu hình một số thông tin trình duyệt web.

Để cấu hình chính sách Identity user thực hiện tương tự ở trên nhưng phần Type chọn NTLM.
1694595199163.png

Tiếp theo tại phần Source / Destination cấu hình phạm vi khi các PC trong Subnet 172.31.199.0/24 truy cập ra bên ngoài ouside zone sẽ áp dụng chính sách.
1694595203199.png

Tiếp theo cần phải truy cập vào PC thuộc subnet 172.31.199.0/24 đã join domain.
1694595207091.png

Tiến hành vào trình duyệt FireFox và chọn nó làm trình duyệt mặc đinh bằng cách chọn Make primary browser.

Lưu ý: Việc Transparent Authentication bằng phương thức Active Authentication trên cisco FTD chỉ hỗ trợ cấu hình trên một số trình duyệt.
1694595210960.png

Tiến hành search about:config trên trình duyệt Firefox đồng thời lọc network.automatic-ntlm-auth.trusted-uris điền thông tin IP và DNS (thường là Gateway của PC nằm trên Cisco FTD) mà cisco FTD dùng để hiển thị captive portal để Firefox tự động xác thực qua NTLM như hình bên dưới.

Lưu ý: network.automatic-ntlm-auth.trusted-uris là một preference trong Firefox cho phép chỉ định các URL mà Firefox sẽ tự động xác thực qua NTLM. NTLM là một giao thức xác thực được sử dụng bởi các hệ thống Windows để xác thực người dùng. Nếu đặt network.automatic-ntlm-auth.trusted-uris thành một giá trị, Firefox sẽ chỉ tự động xác thực qua NTLM cho các URL trong danh sách đó. Nếu không đặt giá trị cho preference này, Firefox sẽ không tự động xác thực qua NTLM cho bất kỳ URL nào.
1694595218132.png

Đảm bảo chứng chỉ cấu hình cho User Identity được cài đặt vào phần Authorities trên trình duyệt Firefox.
1694595224180.png

Sau khi hoàn thành các thông tin trên, lúc này khi PC này kết nối vào mạng sẽ không xuất hiện captive portal nhưng thông tin user được mapping vẫn nằm trên cisco FTD.
1694595228231.png

Kiểm tra trên cisco FTD sẽ thấy được địa chỉ IP mapping với user và các kết nối sẽ có thêm thông tin User.
1694595243141.png
1694595246720.png
 
Last edited:
Mình đang dùng FTD nhưng con này có 1 hạn chế là giới hạn 50000 user Identity sources. Trong khi Domain toàn cầu nên số lượng users đang lớn quá, thành ra add Base DN thì không load nổi user, mà lại không có phần nào để filter. Đã thử giải pháp nhưng chưa có ra.
 

About us

  • Securityzone.vn là một trang web chuyên về an ninh mạng và công nghệ thông tin. Trang web này cung cấp các bài viết, tin tức, video, diễn đàn và các dịch vụ liên quan đến lĩnh vực này. Securityzone.vn là một trong những cộng đồng IT lớn và uy tín tại Việt Nam, thu hút nhiều người quan tâm và tham gia. Securityzone.vn cũng là nơi để các chuyên gia, nhà nghiên cứu, sinh viên và người yêu thích an ninh mạng có thể trao đổi, học hỏi và chia sẻ kiến thức, kinh nghiệm và giải pháp về các vấn đề bảo mật trong thời đại số.

Quick Navigation

User Menu