Chính sách hạn chế của Applocker vs Software

Mục tiêu là để ngăn người dùng chạy các chương trình không mong muốn trên máy chủ đầu cuối.

Tôi đã đọc nhiều bài viết từ Microsoft và những người khác nói rằng tính năng Applocker mới tốt hơn 100% so với Chính sách hạn chế phần mềm cũ và được đề xuất thay thế sau này.

Tôi không chắc chắn để hiểu những lợi thế thực sự của Applocker ngoài việc thực thi chế độ kernel. Hầu hết các chức năng của nó có thể được sao chép bằng Chính sách hạn chế phần mềm.

Đồng thời, nó có một nhược điểm LỚN khiến nó trở nên vô dụng: nó không thể mở rộng và bạn không thể thêm các phần mở rộng tệp tùy chỉnh mà bạn muốn hạn chế.

Ưu điểm của Applocker so với SRP là gì và bạn muốn giới thiệu gì cho việc kiểm soát phần mềm?

Chính sách hạn chế phần mềm không được Microsoft phản đối ( Technet tuyên bố hiệu quả SRP không được hỗ trợ ), kể từ khi Windows 7 Enterprise / Ultimate giới thiệu AppLocker.

Trong thực tế SRP có những cạm bẫy nhất định, đối với cả âm tính giả và dương tính giả. AppLocker có lợi thế là nó vẫn đang được duy trì và hỗ trợ tích cực. Nếu AppLocker là một tùy chọn thì nó có thể là một lựa chọn rẻ hơn - sau khi tính toán thời gian và rủi ro của bạn. Cũng có thể có một lựa chọn bên thứ ba phù hợp (nhưng câu hỏi này không bao gồm tùy chọn đó :).

Hy vọng rằng bạn sẽ có được sự hiểu biết hoàn hảo về những cạm bẫy của SRP trước khi bạn rơi vào bất kỳ vấn đề nào trong số đó </sarcasm>. Một số trong số chúng được mô tả trong một bài viết bảo mật tốt đẹp từ Vadims Podāns .

Cạm bẫy được biết đến

1. Theo mặc định, thực thi từ \Windowsthư mục được cho phép. Một số thư mục con có thể được ghi bởi người dùng. Applocker là như nhau, nhưng ít nhất tài liệu chính thức đề cập đến giới hạn này .

   EDIT: "Để liệt kê tất cả các thư mục có quyền truy cập ghi người dùng, bạn có thể sử dụng, ví dụ, tiện ích AccessEnum từ gói Sysi INTERNals." (hoặc AccessChk ).

   Về mặt kỹ thuật, tài liệu cũng cảnh báo bạn về việc ghi đè các quy tắc mặc định . EDIT: Tài liệu NSA đưa ra 16 ví dụ về các thư mục vào danh sách đen với SRP , mặc dù các quy tắc đường dẫn đăng ký sử dụng dấu gạch chéo ngược không chính xác nên phải được sửa chữa (xem điểm trên đường dẫn đăng ký bên dưới) và cảnh báo về một mục trong danh sách đen phổ biến.

   Câu hỏi rõ ràng là tại sao chúng ta không cẩn thận liệt kê các đường dẫn riêng lẻ bên dưới \Windows. (Bao gồm các \Windows\*.exedi sản System32\*.exe, vv). Tôi không nhận thấy bất kỳ câu trả lời cho bất cứ nơi nào :(.

2. Sử dụng các biến môi trường như %systemroot%, SRP có thể được người dùng bỏ qua bằng cách xóa biến môi trường. EDIT: Chúng không được sử dụng trong các mặc định được đề xuất. Tuy nhiên, chúng có thể được sử dụng. Khẩu súng này được cố định trong AppLocker, vì nó không bao giờ nhìn vào các biến môi trường.

3. Mặc định được đề xuất bỏ qua để cho phép hai loại khác nhau \Program Filesđược sử dụng trên các bản cài đặt 64 bit hiện đại. Khi giải quyết vấn đề này bằng cách sử dụng "đường dẫn đăng ký" an toàn hơn, có các báo cáo về từ chối sai trong các tình huống ngẫu nhiên, có thể dễ dàng bị bỏ qua trong thử nghiệm. ví dụ: xem bình luận về SpiceWorks SRP . EDIT: Điều này được thực hiện với các ứng dụng 32 bit đọc các đường dẫn có liên quan từ WOW6432Node của sổ đăng ký: độ phân giải là thêm cả hai đường dẫn này vào SRP để cho phép tất cả các chương trình hoạt động trên các máy 32 bit và 64 bit khi không bị giới hạn cho dù bắt đầu từ một quá trình máy chủ x64 hoặc x86:%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)% %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%
4. Các tiện ích mở rộng mặc định bỏ qua việc cấm các tập lệnh PowerShell (* .PS1) được Windows hỗ trợ . (Xem video ). Và APPX cũng vậy ... cũng theo bảng so sánh của Microsoft, SRP không thể quản lý "Ứng dụng đóng gói" trong Windows 8, tôi không biết điều này có nghĩa là gì.
5. Quy tắc Registry con đường không phải có dấu gạch chéo ngay sau khi ký hiệu phần trăm cuối cùng (dù đã được bao gồm trong Microsoft riêng tích hợp trong các quy tắc cho XP / Server 2003) và bất kỳ dấu xồ nguợc phải được thay thế bằng forwardslashes để các quy tắc để làm việc ( 1 / 2 / 3 ).
6. Trong số các nguồn tôi tìm thấy cho SRP, không có nguồn nào đưa danh sách đầy đủ ở trên cho bạn. Và tôi chỉ tình cờ phát hiện ra bài báo của Vadims Podāns. Có gì khác đang rình rập ngoài kia?
7. Nhiều nguồn khuyến nghị chỉ cần loại bỏ các tệp LNK khỏi danh sách. (Và Phím tắt Web để tránh phá vỡ Mục ưa thích?!). Xa lạ, dường như không có nguồn nào thảo luận về các lỗ hổng LNK ... hoặc có được các trình thông dịch tập lệnh để chạy các tệp có phần mở rộng không mong muốn, ví dụwscript /e ... hoặc có thể nhồi đủ shellcode trong một tham số tập lệnh nội tuyến ... vv
8. Nếu bạn cố gắng thỏa hiệp bằng cách cho phép các tệp LNK trên máy tính để bàn và bạn để người dùng có quyền truy cập ghi vào máy tính để bàn, giờ đây họ có thể bỏ qua hoàn toàn chính sách của bạn. Mẹo đáng yêu từ Vadims Podāns một lần nữa. Lưu ý rằng giải thích áp dụng cho việc sử dụng bất kỳ tiện ích mở rộng nào trong quy tắc đường dẫn. Microsoft trình bày nhiều ví dụ về điều này bao gồm *.Extension, không có cảnh báo. Vì vậy, bạn không thể tin tưởng vào tài liệu chính thức và dường như không thể sửa chữa ngay bây giờ.
9. [Bất lợi AppLocker tiềm năng]. Báo cáo của Podims Podāns rằng các mục SRP sử dụng các ổ đĩa được ánh xạ không hoạt động. Đường dẫn UNC phải được sử dụng thay thế. Có lẽ sau đó họ sẽ áp dụng để truy cập thông qua một ổ đĩa được ánh xạ? nó không rõ ràng 100%. Rõ ràng AppLocker khác: nó không hoạt động với :(. "Vì lý do không rõ, đường dẫn UNC không hoạt động trong Applocker! Điều này có nghĩa là nếu ứng dụng của bạn được cài đặt trong mạng, bạn phải tạo quy tắc băm hoặc nhà xuất bản . "

Cách tiếp cận thực dụng

Danh sách trắng phần mềm có khả năng bảo vệ rất mạnh mẽ. Nếu chúng ta trở nên hoài nghi: đây chính xác là lý do tại sao Microsoft không chấp nhận các phiên bản giá thấp hơn và phát minh ra các phiên bản phức tạp hơn.

Có thể không có tùy chọn nào khả dụng (bao gồm các giải pháp của bên thứ 3). Sau đó, một cách tiếp cận thực tế sẽ là thử cấu hình SRP một cách đơn giản nhất có thể. Coi nó như một lớp phòng thủ bổ sung, với các lỗ đã biết. Phù hợp với những cạm bẫy ở trên:

1. Bắt đầu từ các quy tắc mặc định (từ thời tiền Win7 :).
2. Không thích sử dụng các biến môi trường, ví dụ %systemroot%.
3. Thêm quy tắc để đảm bảo cả hai \Program Files\thư mục đều được phép trên các máy 64 bit hiện đại. Các "đường dẫn đăng ký" bổ sung mà bạn sẽ cần thêm cho \Program Files\các máy tính 64 bit là %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%và %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%.
4. Khi thêm vào quy tắc đường dẫn đăng ký, hãy bỏ qua bất kỳ dấu gạch chéo ngược nào ngay sau dấu phần trăm và thay thế bất kỳ dấu gạch chéo ngược nào khác \bằng dấu gạch chéo /(ví dụ %HKEY_LOCAL_MACHINE\Software\CompanyName\CustomApps%App/Bin/start.exe)
5. Thêm PS1 vào danh sách các phần mở rộng được kiểm soát.
6. Hiểu rằng cấu hình SRP có thể quản lý không an toàn trước người dùng quyết tâm đánh bại nó. Mục đích là để giúp / khuyến khích người dùng làm việc trong chính sách này, để bảo vệ họ trước các cuộc tấn công như "tải xuống theo ổ đĩa".
7. Cho phép tập tin LNK. (Tốt nhất là bằng cách xóa nó khỏi danh sách tiện ích mở rộng, không thông qua một số quy tắc đường dẫn).
8. Xem ở trên :).
9. Hãy chắc chắn rằng thư mục kịch bản đăng nhập của bạn được cho phép. Tài liệu NSA đề nghị thêm \\%USERDNSDOMAIN%\Sysvol\. (Xem điểm # 2, thở dài, sau đó xem điểm # 6).

Tôi đồng ý rằng SRP có một số tính năng bổ sung mà AppLocker có thể thực sự được hưởng lợi.

Điều đó đang được nói, tôi thấy những lợi ích lớn của AppLocker (như được ghi lại trong so sánh này ) là:

• Các quy tắc AppLocker có thể được nhắm mục tiêu đến một người dùng cụ thể hoặc một nhóm người dùng, trong khi SRP được thi hành trên toàn bộ máy tính.
• AppLocker hỗ trợ chế độ kiểm toán để các quy tắc có thể được kiểm tra trong sản xuất trước khi được thi hành. SRP không có chế độ chỉ đăng nhập tương đương.

Lợi thế lớn nhất đối với tôi là khả năng lập danh sách trắng thực thi có chữ ký của nhà xuất bản. Hãy xem http://technet.microsoft.com/en-us/l Library / ee460943 (v = ws.10) .aspx này

Không có lợi ích nào của AppLocker, những lời nói dối trắng trợn được Microsoft công bố: 1. GPO với quy tắc SAAX có thể được đính kèm với người dùng và nhóm người dùng; 2. Windows Vista đã giới thiệu nhiều GPO cục bộ đạt được kết quả tương tự mà không cần bộ điều khiển miền; 3. chế độ kiểm toán có sẵn thông qua tính năng ghi nhật ký mở rộng mà KHÔNG thực thi.

Tôi sử dụng Applocker trong công ty của tôi. Chiến lược chúng tôi sử dụng là: Từ chối mọi thứ làm cơ sở (trên thực tế: Applocker mặc định), và sau đó thực hiện những gì được đề xuất: tạo quy tắc chỉ cho phép các ứng dụng đã ký (office, adobe, wintools, ax, v.v.). Hầu hết, có thể tất cả phần mềm độc hại là phần mềm chưa được ký nên sẽ không thực thi. Nó hầu như không được bảo trì. Tôi chỉ phải cho phép thêm 3 ứng dụng cũ.

Hơn nữa tôi không thể xác nhận một người không thể sử dụng đường dẫn UNC. Trong một số quy tắc từ chối an toàn bổ sung, tôi sử dụng thành công của UNC-path. Cạm bẫy là trong việc sử dụng các biến môi trường: chúng không hoạt động cho Applocker. Sử dụng * ký tự đại diện. Tôi sử dụng nó trên Windows 2008 R2 và Windows 2012 R2.

Tôi thích nó rất nhiều: hầu như không có bất kỳ sự suy giảm hiệu suất nào. Như tài liệu nói: Applocker dựa vào Dịch vụ Nhận dạng Ứng dụng (đảm bảo rằng nó bắt đầu tự động).