Điều gì khiến Bộ điều khiển miền của tôi ghi nhật ký hàng chục lần thử xác thực thành công mỗi giây?


7

Chúng tôi có một tên miền với khoảng 15 máy chủ và khoảng 30 máy trạm. Máy chủ chủ yếu là 2008r2 và máy trạm chủ yếu là Windows 7. Hai DC là 2012r2. Cứ sau vài tuần, một trong những tài khoản quản trị viên của chúng tôi sẽ bị khóa. Tôi đang cố gắng thu hẹp nguyên nhân và tôi đã đi vào ngõ cụt.

Đây là những gì tôi có.

Nhật ký sự kiện trên PDC hiển thị sự kiện 4776 - kiểm toán thành công:

Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon Account:  username
Source Workstation: 
Error Code: 0x0

Tất cả cho cùng một tên người dùng và định kỳ nhiều lần trong một giây.

Dựa trên ID sự kiện, đây là các thông tin đăng nhập NTLM chứ không phải Kerberos. Mặc dù loại xác thực được sử dụng ít đáng lo ngại hơn so với số lượng cắt. Điều này xảy ra vài lần một giây và lặp lại cứ sau vài giây quảng cáo, tất cả các ngày hoặc đêm hoặc cuối tuần.

Nhật ký sự kiện cũng hiển thị ID sự kiện thành công kiểm toán 4624 (đăng nhập) và 4634 (đăng xuất) cho tên người dùng này, nhưng như trong sự kiện phía trên trường "máy trạm" trống.

Tôi đã kích hoạt tính năng ghi nhật ký netlogon và chương trình netlogon.log

02/28 17:11:03 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation1) Entered
02/28 17:11:03 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation1) Returns 0x0
02/28 17:11:04 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation2) Entered
02/28 17:11:04 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation2) Returns 0x0
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via server1) Entered
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via server1) Returns 0x0
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via server2) Entered
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via server2) Returns 0x0
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation3) Entered
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation3) Returns 0x0
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation2) Entered
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation2) Returns 0x0
02/28 17:11:19 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation4) Entered
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation5) Entered
02/28 17:11:19 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation4) Returns 0x0
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation5) Returns 0x0
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via server3) Entered
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via server3) Returns 0x0
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via server4) Entered
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via server4) Returns 0x0

Vân vân và vân vân. Nguồn rõ ràng của các thông tin đăng nhập này (thông qua XYZ) có thể bao gồm các máy trạm và máy chủ trên toàn mạng.

Rõ ràng điều này trông giống như một tự động hóa hoặc kịch bản. Vì các lần đăng nhập nói chung đều thành công, tôi không tin đó là một nỗ lực xâm nhập. Tuy nhiên, một số lần đăng nhập thỉnh thoảng không thành công nhưng tôi không xác định được bất kỳ mô hình nào cho sự thất bại và chúng xảy ra rất ít khi (hầu hết các ngày) chúng không khóa tài khoản. Mã lỗi khi có mã thường là 0xc0000022 (Truy cập bị từ chối)

Tôi đã vô hiệu hóa và gỡ cài đặt đại lý giám sát từ xa của chúng tôi (hiện là Kaseya, nhưng cuối cùng chúng tôi sẽ chuyển sang LabTech) từ một trong các máy chủ, nhưng vẫn thấy các sự kiện mới bắt nguồn từ máy chủ đó, vì vậy điều này loại bỏ các tác vụ tự động hóa. Tôi cũng đã kiểm tra lịch trình tác vụ trên một vài máy chủ và không tìm thấy gì khác thường. Tôi đã kiểm tra các dịch vụ để xác minh tài khoản đăng nhập và tài khoản này không được sử dụng trong bất kỳ dịch vụ nào.

Tôi đã chạy Netstat trong một thời gian dài và thấy các kết nối chủ yếu đến PDC từ "Hệ thống" và "Quá trình nhàn rỗi hệ thống". Tôi đã thấy các kết nối không thường xuyên từ spoolsrv và lsass và ismserv (máy chủ mà tôi đang thử nghiệm là máy chủ Citrix XenApp, nhưng các máy chủ "nguồn" khác không có trong trang trại XenApp và tất nhiên các máy trạm "nguồn" cũng không). Tôi đã dừng dịch vụ bộ đệm in chỉ để kiểm tra và nó không ảnh hưởng đến các sự kiện đăng nhập.

Tôi làm việc tại MSP và đây là tài khoản quản trị viên kỹ thuật viên chính của chúng tôi, vì vậy ưu tiên cao là nó hoạt động và an toàn. Ý tưởng cuối cùng tôi còn lại là thay đổi mật khẩu và xem những gì bị phá vỡ, nhưng không biết tài khoản nào đang được sử dụng cho việc này có thể gây ra hậu quả thảm khốc. Tuy nhiên, sự nghi ngờ của tôi là đây có thể chỉ là một AD bị định cấu hình sai.

Có ai đã trải nghiệm một cái gì đó như thế này trước đây và có thể xác định nguồn?


Đối với bất kỳ ai tò mò về số lượng máy chủ cao, họ có các máy chủ XenApp với SharePoint phải đối mặt công khai với lực lượng lao động di động cao với BYOD. Họ cũng có một đội ngũ nhân viên CNTT trước đây đã đi quá xa về cơ sở hạ tầng cho quy mô kinh doanh của họ. Vì họ ký hợp đồng với chúng tôi, chúng tôi đã cố gắng giảm bớt một chút để phù hợp hơn với nhu cầu của họ.
Thomas

Một cái gì đó bạn có thể thử là cài đặt Microsoft Network Monitor trên một trong các máy chủ, bắt đầu chụp, đợi một mục từ máy chủ để đăng nhập vào nhật ký netlogon và sau đó xem bản chụp và xem bạn có thể tìm thấy cuộc hội thoại trong Network Monitor không . Giám sát mạng sẽ cho bạn thấy quá trình chịu trách nhiệm cho cuộc trò chuyện. Nếu điều đó không thu hẹp đủ, bạn có thể sử dụng Network Monitor kết hợp với Process Monitor để xác định quy trình chịu trách nhiệm.
joeqwerty

Microsoft Network Monitor không được dùng nữa và được thay thế bởi Microsoft Message Analyzer. Thỏa thuận tương tự như Wireshark. Tôi đã chạy một gói chụp và thấy hoàn toàn không có gì hữu ích. Các sự kiện duy nhất tương quan chặt chẽ với các sự kiện NetLogon là các kết nối WMI và RPC.
Thomas

Phải, NetMon không được dùng nữa nhưng nó vẫn là một công cụ tốt. Nếu bạn chưa sử dụng Trình phân tích thư trước thì có thể hơi quá. NetMon khá đơn giản và trực quan. Tôi thường sử dụng nó trước bất cứ điều gì khác. - Đối với chụp của bạn, lưu lượng RPC có thể có một số manh mối.
joeqwerty

Vâng, không có gì. Có một MSRPC Bind được gửi và Ack nhận được để xây dựng một phiên được mã hóa theo sau là gói NRPC được gửi và nhận có chứa Yêu cầu và Phản hồi NetrLogonSamLogonEx, hai phiên bản sau được mã hóa. Quá trình gọi trên máy tính nguồn là LSASS, chạy dịch vụ Netlogon. Không có chi tiết hữu ích nào trong dữ liệu gói của lưu lượng Bind và tất nhiên các gói được mã hóa là vô dụng đối với tôi.
Thomas

Câu trả lời:


1

Tôi khuyên bạn nên tiếp tục cho phép kiểm tra NTLM trên DC của bạn. Sử dụng Chính sách bộ điều khiển miền mặc định, kích hoạt các cài đặt chính sách sau:

Bảo mật mạng: Hạn chế NTLM: Kiểm tra lưu lượng truy cập đến = Cho phép kiểm tra tất cả các tài khoản Bảo mật mạng: Hạn chế NTLM: Kiểm tra xác thực NTLM trong miền này = Bật tất cả bảo mật mạng: Hạn chế lưu lượng NTLM: Lưu lượng truy cập NTLM đến máy chủ từ xa = Kiểm toán tất cả

https://support.symantec.com/en_US/article.HOWTO79508.html

https://docs.microsoft.com/en-us/preingly-versions/windows/it-pro/windows-server-2008-R2-and-2008/jj865682(v=ws.10)

Sau khi được bật, hãy điều hướng trong trình xem sự kiện của bạn tới: Nhật ký ứng dụng và dịch vụ> Microsoft> Windows> NTLM> Hoạt động

Sẽ có (các) sự kiện có dấu thời gian khớp với dấu thời gian sự kiện netlogon của bạn. Nhật ký này sẽ tiết lộ Tên máy trạm thực tế.

Và đặc biệt để giúp bạn xác định thêm nguồn, Tên kênh an toàn trong nhật ký này sẽ giúp thu hẹp nguồn gốc quá trình.


Cảm ơn câu trả lời. Thật không may, khách hàng cụ thể này không còn là khách hàng của chúng tôi nữa nên tôi không thể thử hướng dẫn của bạn. Tôi đã đi trước và chấp nhận câu trả lời của bạn, tho, vì sự hiểu biết của tôi về AD nói với tôi rằng sẽ cung cấp cho tôi các chi tiết tôi cần. (Không chắc tại sao tôi không nghĩ đến việc điều chỉnh chính sách kiểm toán, nhưng bạn đá vì đã gợi ý nó.)
Thomas
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.