Tuesday, July 30, 2013

Bảo mật cho DHCP Server (phần 1)

Ở phần 1 của bài về bảo mật cho DHCP server này, tôi sẽ nói về các loại mối đe dọa khác nhau nhằm vào DHCP server và đi cùng với đó là những rủi ro mà các mối đe dọa đó có thể gây ra cho hạ tầng DHCP cũng như hệ thống thông tin của bạn.

Hẳn chúng ta đều biết, DHCP là một trong nhiều dịch vụ mạng thiết yếu trong các hệ thống mạng ngày nay. Đã có rất nhiều bài viết đề cập tới phương thức hoạt động của giao thức DHCP cũng như là các bước triển khai và quản lý một hạ tầng DHCP. Vì thế, ở đây tôi chỉ xin tóm tắt lại một số ưu điểm mà dịch vụ DHCP mang lại để từ đó giúp bạn thấy rõ tầm quan trọng của việc duy trì sự hoạt động ổn định cho DHCP server:

- Quản lý tập trung việc cấp phát địa chỉ IP (và các thiết lập cần thiết khác như các địa chỉ của DNS server, WINS server, default gateway…) cho các máy tính trong mạng được thực hiện tại DHCP server giúp giảm thiểu thời gian cần thiết để để cấu hình (hoặc cấu hình lại) cho các thông số IP cho chúng.

- Ngoài ra, việc tự động gán các địa chỉ IP cũng giúp bạn tránh được những lỗi phát sinh từ việc nhập bằng tay các thông tin về IP tại mỗi máy. Ví dụ, DHCP giúp ngăn chặn các xung đột về địa chỉ xảy ra khi hai (hay nhiều) máy được gán cùng một IP.

Ở phần 1 của bài về bảo mật cho DHCP server này, tôi sẽ nói về các loại mối đe dọa khác nhau nhằm vào DHCP server và đi cùng với đó là những rủi ro mà các mối đe dọa đó có thể gây ra cho hạ tầng DHCP cũng như hệ thống thông tin của bạn.

Nhưng trước hết chúng ta cùng ôn lại một chút về cách thức làm việc của giao thức DHCP để thấy được lỗ hổng nào tồn tại trong DHCP mà kẻ xấu có thể khai thác. Quá trình truyền thông giữa một máy được cấu hình sử dụng IP động (DHCP client) với một máy được cấu hình đảm nhận chức năng cấp phát IP động (DHCP server) cơ bản diễn ra như sau:

- Đầu tiên, một DHCP client muốn nhận mới một địa chỉ IP (chứ không phải muốn phục hồi lại thời gian “thuê” của một địa chỉ IP mà nó đang sử dụng) sẽ gửi lên toàn mạng (broadcast) một thông điệp DHCP Discover có chứa địa chỉ MAC của nó để tìm kiếm sự hiện diện của DHCP server.

- Nếu tồn tại sự hoạt động của (các) DHCP server thuộc cùng subnet với DHCP client trên thì (các) server này sẽ phản hồi lại cho client bằng một thông điệp DHCP Offer có chứa một địa chỉ IP (và các thiết lập TCP/IP khác) như là một lời đề nghị cho “thuê” địa chỉ.

- Ngay khi nhận được gói DHCP Offer đến đầu tiên, client sẽ trả lời lại cho server (dĩ nhiên là gửi cho server nào mà nó nhận được gói DHCP Offer đến đầu tiên trong trường hợp có nhiều DHCP server nằm cùng subnet với nó) một thông điệp DHCP Request như là sự chấp thuận lời đề nghị cho “thuê” trên.

- Cuối cùng, server gửi lại cho client thông điệp DHCP Acknowledgment để xác nhận lần cuối “hợp đồng cho thuê địa chỉ” với client. Và từ đây client có thể sử dụng địa chỉ IP vừa “thuê” được để truyền thông với các máy khác trên mạng.


[IMG]

Ta thấy rằng, nhìn chung DHCP làm việc khá đơn giản nhưng điểm mấu chốt ở đây là xuyên suốt quá trình trao đổi thông điệp giữa server và client không hề có sự xác thực hay kiểm soát truy cập nào. Vì vậy, server không có cách nào biết được rằng nó có đang liên lạc với một legitimate client (tạm dịch là máy hợp pháp, tức là một máy không bị điều khiển để thực hiện các mục đích xấu) hay không, và ngược lại client cũng không thể biết được là nó có đang liên lạc với một legitimate server hay không. Khả năng trong mạng xuất hiện các rogue clientrogue server (tạm dịch là máy “đều giả”, tức là một máy bị điều khiển để thực hiện các hành vi xấu) tạo ra nhiều vấn đề đáng quan tâm như:

- Một rogue DHCP server có thể cung cấp cho các legitimate client các thông số cấu hình TCP/IP giả tạo và trái phép như: địa chỉ IP không hợp lệ, sai subnet mask, hoặc sai địa chỉ của default gateway, DNS server nhằm ngăn chặn client truy cập tài nguyên và sử dụng dịch vụ trong mạng nội bộ hoặc Internet (đây là một dạng của tấn công DoS). Việc thiết lập một rogue DHCP server có thể thực hiện được bằng cách sử dụng các chiêu “social engineering” để có được quyền tiếp cận vật lý vào mạng của bạn và attacker sẽ cắm dây mạng vào máy tính đã được cấu hình làm rogue DHCP server.
[IMG]

- Thêm tình huống xấu khác có thể nảy sinh là attacker xâm nhập thành công vào một legitimate client nào đó trong mạng và thực hiện cài đặt và thực thi trên client này một chương trình có chức năng liên tục gửi tới DHCP server các gói tin yêu cầu xin cấp IP với các địa chỉ MAC nguồn không có thực cho tới khi toàn bộ dải IP trong scope của DHCP server này bị nó “thuê” hết. Dẫn tới server không còn IP nào để có thể cấp phát cho các legitimate client khác. Hậu quả là các client này không thể truy cập vào mạng và làm các công việc của họ.

- Còn một hiểm họa nữa có thể xảy ra nếu như attacker phá vỡ được các hàng rào bảo vệ mạng vàđoạt được quyền kiểm soát legitimate DHCP server của bạn. Lúc này, attacker có thể sẽ tạo ra những sự thay đổi trong cấu hình của DHCP server theo hướng có lợi cho hắn như:
+ thiết lập lại dải IP, subnet mask của scope để tạo ra tình trạng DoS trong mạng.
+ hoặc đổi thiết lập DNS để chuyển hướng yêu cầu phân giải tên miền của client tới rogue DNS (do attacker dựng lên), kết quả là client có thể sẽ bị dẫn dụ tới các website giả mạo được xây dựng nhằm mục đích đánh cắp thông tin tài khoản của client hoặc website có chứa mã độc mà sẽ được tải về máy client.

[IMG]
+ hoặc cũng có thể thay đổi default gateway trỏ về máy của attacker để toàn bộ thông tin mà client gửi ra ngoài mạng sẽ được chuyển tới máy của hắn (thay vì đi tới default gateway thực sự), sau đó attacker sẽ chụp lại các thông tin này trước khi chuyển tiếp chúng tới gateway thực sự của mạng và client vẫn truyền thông bình thường với các máy ngoài mạng nhưng người dùng lại không hề nhận biết được rằng họ đã để lộ thông tin cho attacker (đây là một dạng của tấn công Man-in-the-Middle).
[IMG]

Chưa hết, nếu bạn đang chạy dịch vụ DHCP server đã bị tấn công trên cùng một máy với Domain Controller thì hậu quả sẽ còn nghiêm trọng hơn nữa khi attacker sẽ có khả năng nắm được cơ sở dữ liệu Active Directory và gây thêm nhiều rắc rối khác cho hệ thống của bạn.

Như vậy, có khá nhiều nguy cơ đe dọa tới tính bí mật, toàn vẹn và độ sẵn sàng của hạ tầng DHCP và từ đó tạo ra những rủi ro chung cho toàn bộ hệ thống mạng của chúng ta. Trong phần 2 của bài viết này, chúng ta sẽ cùng thảo luận về những giải pháp cụ thể và những công cụ hữu ích để đảm bảo an toàn cho DHCP server trên cả hai nền tảng là Linux và Windows.
Phần 2

Tìm hiểu về DHCP Server Security (phần 2)

Trong phần 1, chúng ta đã điểm qua 1 vài tình huống điển hình thường gặp của DHCP server cùng vài phương pháp cơ bản để phòng tránh. Trong phần 2 này, chúng ta sẽ tiếp tục với những phương pháp hiệu quả và công cụ sử dụng để tăng cường tính bảo mật của DHCP server trong nền tảng Windows 2000 và Windows Server 2003.

Tìm hiểu về DHCP Server Auditing

Việc kiểm soát cơ sở dữ liệu DHCP trên DHCP server sẽ giúp bạn xác định các DHCP client đang nhận được địa chỉ trực tiếp từ server tốt hơn. Bên cạnh đó, quá trình này cũng giúp bạn nhận biết các thành phầnBAD_ADDRESS trong cơ sở dữ liệu, và nơi xuất xứ của chúng … những thông tin này thực sự hữu ích, khi chúng có thể gây ra những địa chỉ xung đột khi hệ thống DHCP server giả mạo tiến hành gán địa chỉ trong khi chúng vẫn đang được sử dụng.
Để kích hoạt tính năng kiểm soát trên toàn bộ hệ thống DHCP server, mở bảng điều khiển DHCP console để kết nối tới DHCP server trên hệ thống mạng. Kích chuột phải lên server node và chọn Properties, trên thẻ General, đánh dấu vào ô Enable DHCP audit logging:

Các bản ghi kiểm soát DHCP được lưu trữ mặc định trong thư mục %windir%\system32\dhcp, nhưng người dùng có thể thay đổi qua thẻ Advance. Các bản ghi này được tạo ra hoặc gắn liền với các danh mục công việc hàng ngày có tên là DhcpSrvLog-Mon.log, DhcpSrvLog-Tue.log … Mỗi bản ghi này sẽ bắt đầu với ID của sự kiện tương ứng, và phần đầu bản ghi lưu trữ danh sách các ID với giải thích chi tiết. Ngoài ra, các thao tác tùy chỉnh cũng có thể được làm thông qua khóaHKLM\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters trong Registry:
- DhcpLogFilesMaxSize chỉ định dung lượng tối đa đối với tất cả file bản ghi lưu trữ DHCP (mặc định là 7 MB)
- DhcpLogDiskSpaceCheckInterval quy định cụ thể việc kiểm tra dung lượng đ��a sử dụng của DHCP (chế độ mặc định là 50 phút)
- DhcpLogMinSpaceOnDisk xác định mức không gian trống tối thiểu để khóa tạm thời chức năng đăng nhập (mức mặc định là 20 MB)

DHCP Administrators Group

Trước kia, với 1 số hệ thống thì các thành viên trong nhóm Domain Admins có toàn quyền thiết lập DHCP trên server, và bạn cũng có thể ủy quyền cho những tài khoản người dùng với những công việc phù hợp để quản lý DHCP của hệ thống. Để làm việc này, mở Active Directory Users and Computers và thêm tên tài khoản người dùng vào nhóm DHCP Administrators:

Cơ chế này tạo cho người dùng khả năng quản lý trực tiếp DHCP server trên hệ thống mà không cần phải cấp quyền, phân quyền hay xác thực cho tài khoản quản trị đó để thực hiện các tác vụ khác. Tuy nhiên, 1 vấn đề nảy sinh ở đây là làm thế nào để quản lý tất cả thành viên trong nhóm DHCP Administrators để chắc chắn rằng không có tài khoản trái phép hoặc giả mạo nào đã được thêm vào nhóm này?
Bên cạnh đó, bạn có thể theo dõi các thành viên của các nhóm quan trọng như DHCP Administrators bằng chức năng Restricted Groups của Group Policy. Để làm việc này, sử dụng Active Directory Users and Computersđể mở Default Domain Policy và chuyển tới Computer Configuration\Windows Settings\Security Settings\Restricted Groups:

Kích chuột phải lên Restricted Groups và chọn Add Group, ở đây chúng ta chỉ định DHCP Administrators là nhóm người dùng cần theo dõi:

Bấm OK, chọn tiếp nút Add trong bảng thuộc tính tiếp theo để chỉ định riêng biệt những tài khoản nào được phép trở thành thành viên của nhóm.
Lưu ý rằng, cho dù nhóm đã có thành viên trong đó, nhưng bạn vẫn phải thực hiện bước này và nhận dạng từng thành viên trong nhóm đó 1 lần nữa:

Nhấn OK và thành viên trong nhóm DHCP Administrators đã được giới hạn như mong muốn (ở ví dụ này là tài khoản Bob Smith):

Những gì sẽ xảy ra khi chúng ta thực hiện bước làm phía trên, mỗi khi Group Policy tiến hành refresh toàn bộ thành viên của domain controller (thông thường là 5 phút 1 lần) trong nhóm DHCP Administrators được kiểm tra, hoặc do sự cố (phần mềm độc hại) mà 1 số tài khoản (ở đây là Mary Smith) khi được thêm vào nhóm, sau đó lại tự động bị xóa bỏ, sự kiện ID 637 sẽ được ghi lại Security log nếu bạn đã kích hoạt tính năng quản lý, kiểm soát các tài khoản. Và, các thành viên thuộc nhóm DHCP Administrators sẽ được theo dõi, quản lý chặt chẽ như mong muốn.
Lưu ý rằng Windows 2000 có đi kèm với 1 nhóm tài khoản khác gọi là DHCP Users, có thể được sử dụng để gán quyền cho các tài khoản người dùng với thuộc tính read-only bằng DHCP console, và các thành viên trong nhóm này cũng được điều khiển theo cách tương tự sử dụng Restricted Groups.

DNSUpdateProxy Group

Trên hệ thống mạng của Windows, DHCP và DNS có thể làm việc cùng nhau để đơn giản hóa quá trình thiết lập, tùy chỉnh các hoạt động của hệ thống mạng. Thông thường, những vấn đề thường xuyên xảy ra là việc DHCP client đăng ký một bản ghi (host) trực tiếp với DNS server, trong khi bản ghi PTR (pointer) được đăng ký thay vì client bởi DHCP server. Điều này có nghĩa là các cuộc tấn công nhắm vào DHCP server có thể kiểm soát thông qua các bản ghi đã đăng ký với hệ thống DNS server và tiếp tục được sử dụng để chuyển hướng traffic tới các trang web xấu, hoặc gây ra hiện tượng Denial Of Service – DoS. Nếu bạn “biến” DHCP server thành 1 thành viên của nhóm DNSUpdateProxy, hệ thống DHCP server của bạn sẽ không bị mất quyền sở hữu hoặc các bản ghi dữ liệu của client. Các làm này chủ yếu được sử dụng khi cập nhật, nâng cấp từ Windows NT để đảm bảo rằng các client cấp dưới không hỗ trợ DNS có thể bị mất quyển sở hữu khi đang nâng cấp tới Windows 2000 hoặc Windows XP.
Điểm lợi của việc làm này là bạn chỉ nên thêm các tài khoản computer của DHCP server tới nhóm DNSUpdateProxy nếu bạn có ý định nâng cấp từ các phiên bản trước của Windows 2000 thành Windows 2000 or Windows XP. 1 điểm lưu ý nữa là không bao giờ thêm DHCP server vào nhóm DNSUpdateProxy nếu hệ thống DHCP server đang hoạt động trên domain controller.

Dấu hiệu phát hiện DHCP Servers giả mạo

Cuối cùng, chúng tôi sẽ giới thiệu với các bạn 1 số công cụ hữu ích để phát hiện dấu hiệu nghi ngờ của DHCP server giả mạo trên hệ thống qua đó có thể phòng tránh 1 cách dễ dàng và đơn giản. Chủ yếu chúng ta sẽ sử dụng công cụ kết hợp của Microsoft và các nguồn third-party khác.
Dhcploc.exe
Dhcploc.exe là công cụ với giao diện dòng lệnh, là 1 phần của Windows Support Tools nằm trong thư mục\Support\Tools trên đĩa cài đặt XP hoặc tại đây, và được dùng để hiển thị danh sách tất cả các DHCP server đang được kích hoạt trên hệ thống subnet nội bộ. Hiện tại, Dhcploc.exe vẫn được sử dụng từ Windows NT 4.0, với cơ chế hoạt động bằng cách gửi các tin nhắn DHCPREQUEST, đồng thời hiển thị địa chỉ IP của DHCP server phản hồi lại cùng với DHCPACK. Các bạn có thể tìm thấy cú pháp sử dụng trong file Help đi kèm khi tiến hành cài đặt Support Tools lên hệ thống.
dhcp_probe
1 nhóm nghiên cứu – Network Systems Group của trường đại học Princeton đã phát triển 1 công cụ gọi là dhcp_probe, có khả năng phát hiện DHCP và BOOTP server thông qua Ethernet. Phiên bản có sẵn trước đó được xây dựng để hoạt động trên Solaris 8 và SPARC cùng với gcc, và 1 vài bản vá để hoạt động trên Linux. Tùy vào nền tảng hệ điều hành đang sử dụng mà bạn có thể tìm được công cụ phù hợp trên trang của Network Systems Group

Sunday, July 28, 2013

Seize Roles Windows Server 2003

CHUYỂN ADDITION DOMAIN TO PRIMARY DOMAIN
Nhận biết Domain Master:
mở Active Directory Users and Computers-->phải chuột "tên domain"-->Operations Masters
==>sẽ biết được DC nào nắm giữ các Operation Masters Roles.

Mặc dù W2k/W2k3 hỗ trợ Multi Master (các DC hoạt động song song nhau, không phân biệt chính/phụ ). Tuy nhiên vẫn còn một số chức năng hoạt động ở chế độ Single Master, cụ thể là:
- Schema Master: Quản lý schema, mỗi forest có 1 cái
- Domain Naming: Quản lý danh sách các domain, mỗi forest có 1 cái
- PDC: Giả lập server NT để chứng thực cho các WS đồi cũ (win9x), mỗi domain có 1 cái
- RID: cấp số ID cho user, mỗi domain có 1 cái
- Infrastructer: Quản lý danh sách user ở domain khác tham dự vào các nhóm của domain hiện tại., , mỗi domain có 1 cái

Mặc định các chức năng do DC1 nắm giữ. Khi DC1 chết thì những thao tác liên quan đến 5 chức năng này sẽ không thực hiện được.

Khi DC1 "chết bất đắc kỳ tử", ta cần "cưỡng chế" DC2 giữ 5 chức năng này. Bài viết sẽ hướng dẫn chi tiết các bước thực hiện việc "cưỡng chế"

Yêu cầu : đã làm các bước ở phần I (2 DC chạy song song)

----------------------------------------------------------------
Bài viết này gồm 3 bước:

1. Giả sử master DC bị chết (DC1 bị ngủm bất đắc kỳ tử)
2. Từ Addition DC (DC2) ra CMD gõ các lệnh để cưỡng chế 5 chức năng single master của DC1 sang DC2
3. Sau khi thành công, DC2 tạo user và client join domain bằng user mới tạo thành công.


----------------------------------------------------------------
Khi mình làm bài lab này mình làm trên máy 3,4,5 của nhà trường nên có ký hiệu như sau:

- Tên domain: dom3.com
- DC1 (master domain) : máy pc03
- DC2 (Addition Domain) : máy pc04
- Client : máy pc05


----------------------------------------------------------------
Thực Hiện

1\Giả sử máy DC1 bị chết (shutdown máy pc03)

2\ Ta đứng từ máy DC2 (pc04) ra cmd tiến hành các bước



- Từ CMD đánh lệnh ---> --ntdsutil--



-tiếp theo ta đánh --roles--



ta đánh lênh --connections-- tiếp theo:



Từ dòng nhắc server connection ta đánh --connect to server pc04.dom3.com-- (tên đầy đủ của addition DC)



Sau khi đã connect vào Server ta đánh lệnh--quit--



- Đánh tiếp --seize schema master--



- Bấm yes đồng ý và đợi khoảng 30 giây để nó load chức năng master về cho addition DC



- Đánh tiếp--seize domain naming master--



- Bấm yes đồng ý và đợi khoảng 30 giây để nó load chức năng master về cho addition DC



- Tiếp tục đánh --seize RID master-- (lưu ý chử RID viết hoa)



- Bấm yes đồng ý và đợi khoảng 30 giây để nó load chức năng master về cho addition DC



- TA đánh tiếp theo lệnh --seize PDC--(lưu ý chử PDC viết hoa)



- Bấm yes đồng ý và đợi khoảng 30 giây để nó load chức năng master về cho addition DC



- Tại dòng fsmo mentenance : ta đánh lệnh --seize infrastructure master--



- Bấm yes đồng ý và đợi khoảng 30 giây để nó load chức năng master về cho addition DC



sau đó ta đánh lệnh quit --->quit----> exit là coi như xong



3\ Bây giờ ta thử bằng cách từ máy DC 2(vừa được lên master) ta tạo user và từ máy client có thể join vào domain bằng user mới được tạo. là coi như bạn đã thành công