Quản lý việc sử dụng phần mềm với AppLocker – Phần 2


Như đã đề cập trong phần mở đầu, tính năng AppLocker có trong một số phiên bản Windows 7 và Windows Server 2008 R2 cung cấp cho các nhà quản trị hệ thống một công cụ đắc lực để kiểm soát việc sử dụng phần mềm của người dùng trong nội bộ tổ chức, doanh nghiệp.

Vậy trong các phiên bản Windows trước đó, đã có cơ chế tương tự nào với cùng mục đích như AppLocker chưa? Câu trả lời là “Có, nhưng các giải pháp ban đầu đó lại chưa thực sự chặt chẽ và hiệu quả vì chúng vẫn tồn tại một số kẽ hở cho những kẻ tinh quái có thể vượt qua.

Phần dưới đây sẽ tóm tắt một số biện pháp quản lý việc sử dụng phần mềm trong các phiên bản trước Windows 7 và những hạn chế của chúng.

  • Sử dụng policy “Don’t run specified Windows applications

Đây có thể coi là chính sách Blacklisting: chỉ ác chương trình nằm trong danh sách này thì không được phép chạy. Dễ nhận thấy rằng việc tạo blacklisting cho một số lượng lớn các chương trình là khá vất vả.

Mặt khác, nếu bạn đã vô hiệu hóa các công cụ quản trị quan trọng như Task Manager, Local Security Policy Editor, Computer Management, System Configuration, Registry Editor, CMD… thì kẻ xấu vẫn có thể chạy các phần mềm có chức năng tương tự như SysInternals, TuneUp… để thay đổi hệ thống. Rõ ràng bạn không thể thống kê hết và liệt vào danh sách blacklist các chương trình thay thế mà kẻ xấu có thể sử dụng.

  • Sử dụng policy “Run only specified Windows applications

Đây là chính sách Whitelisting: chỉ cho phép chạy các chương trình nằm trong danh sách này, còn lại tất cả các chương trình khác đều bị khóa. Kế sách này xem ra còn khó khả thi hơn blacklisting vì sẽ có rất nhiều file thực thi liên quan tới ứng dụng được phép chạy cần được thêm vào whitelisting.

Có thể tìm thấy 2 policy này theo cách sau:

–    Mở hộp thoại Run và gõ gpedit.msc

–    Tại cửa sổ Local Group Policy Editor vừa hiện ra duyệt tới nhánh Local Computer Policy | User Configuration | Administrative Templates | System

–    Hai policy đó nằm ở khung bên phải như hình dưới đây

Thêm nữa, cả 2 policy trên đều xuất hiện một số lỗ hổng sau:

–   Chỉ có thể ngăn chặn người dùng chạy các chương trình được khởi chạy bởi tiến trình cha (parent process) là Windows Explorer. Giả dụ, khi bạn chạy file thực thi (.exe) của chương trình A trong cửa sổ Windows Explorer hoặc chạy từ shortcut của nó, khi đó explorer.exe sẽ sinh ra một process con là của chương trình A kia. Nhưng bạn không thể ngăn chặn họ chạy các chương trình như là Task Manager do process của nó là taskmgr.exe được sinh ra bởi process system hoặc bởi process khác không phải của Windows Explorer.

–   Nếu ai đó có quyền chạy chương trình CMD.exe thì họ vẫn có thể chạy các chương trình bị cấm bởi 2 policy này từ dòng lệnh.

–   Ngoài ra, họ có thể đổi tên file thực thi của chương trình muốn chạy sao cho hợp lệ với 2 policy trên.

Vậy còn giải pháp nào hiệu quả và linh hoạt hơn 2 policy trên không? Trong thế giới Windows, bạn vẫn còn một công cụ khác mà khá quen thuộc với các quản trị hệ thống Windows XP và Windows Server 2003 đó là Software Restriction Policies (SRP).

Ở đây, bài viết sẽ không đi sâu về cơ chế làm việc cũng như cách quản lý các rule trong SRP mà chỉ nêu lên một số chiến lược sử dụng SRP cơ bản và những điểm hạn chế chúng để từ đó thấy được những điểm mạnh của AppLocker so với người tiền nhiệm SRP này.

Bạn có thể cấu hình cho SRP đạt tới “cảnh giới” cao nhất bằng cách triển khai chính sách Whitelisting – xu thế phổ biến trên các hệ thống Firewall và có thể sẽ được áp dụng trong các hệ thống Anti-malware sau này. Với Whitelisting thì mặc định tất cả các ứng dụng đều không được phép chạy (deny all). Sau đó, nếu bạn muốn cho người dùng chạy ứng dụng nào thì sẽ tạo thêm các allow rule cho ứng dụng đó. Dưới đây là các kiểu rule trong SRP:

  • Certificate Rule

Đây là rule quan trọng nhất trong các rule mà SRP cung cấp. Rule được thi hành dựa trên chữ ký số đi kèm với phần mềm. Vấn đề ở đây là khi SRP được giới thiệu trong Windows XP vào năm 2001 thì hầu như ít người để ý tới việc tạo chữ ký số cho ứng dụng của họ. Thêm nữa, phạm vi ảnh hưởng của rule này quá rộng.

  • Hash Rule

Ý tưởng của rule này là Windows sẽ tạo cho mỗi file thực thi của chương trình một giá trị hash duy nhất dùng để nhận diện chương trình đó. Sau đó, dựa trên giá trị hash này SRP sẽ kiểm tra xem chương trình được chạy hay không. Dễ dàng thấy được ở đây nảy sinh một bất cập là nếu bạn cập nhật cho chương trình thì bạn phải sửa lại giá trị hash trong rule do việc cập nhật có thể đã làm thay thế file thực thi của chương trình đó.

Ví dụ, nếu bạn chỉ chặn phiên bản 1.0 của phần mềm A dựa trên hash rule thì có thể bạn sẽ không ngăn được ai đó chạy phiên bản 1.1 của phần mềm A này do có thể file thực thi của 2 phiên bản có giá trị hash khác nhau.

  • Path Rule

Bạn sẽ ngăn chặn một chương trình dựa trên đường dẫn đường dẫn cài đặt của chương trình đó. Đường dẫn ở đây có thể là Filesystem path hoặc Registry path. Vấn đề ở đây là nếu người dùng có quyền cài đặt phần mềm thì họ có thể đặt ứng dụng tới vị trí mà không chịu sự chi phối của Path rule.

  • Internet Zone Rule

Cho phép bạn kiểm soát việc tải về và cài đặt các ứng dụng từ Internet. Nhược điểm của rule này là chỉ áp dụng cho các file .MSI. Hơn nữa, rule này chỉ có hiệu lực tại thời điểm file được tải về. Điều này có nghĩa rằng nếu người dùng tải về một file .ZIP bên trong có chứa file .msi thì rule này hoàn toàn vô tác dụng.

  • Network Zone Rule

Giống với Internet Zone Rule nhưng được bổ sung thêm việc xem xét các vị trí mạng – nơi mà file được tải về. Nhưng một lần nữa, nếu người dùng có đủ thẩm quyền cài đặt chương trình, họ sẽ khôn khéo chuyển chương trình sang một vị trí mạng khác để tránh sự ảnh hưởng của rule này.

Ngoài các giải pháp có sẵn trong Windows ở trên bạn có thể sử dụng tiện ích của hãng thứ ba như: Parity, Application Locker. Hiển nhiên, điều này cũng đồng nghĩa với việc bạn phải trả thêm chi phí cho bản quyền phần mềm.

Trên đây bạn đã nắm một số nét khái quát về SRP cũng như là những hạn chế của nó trong các phiên bản Windows trước đây. Sở dĩ phần này đề cập tới các rule trong SRP là vì AppLocker vẫn còn thừa hưởng một số tính năng đã có ở SRP. Đồng thời với việc bổ sung thêm các tính năng mới và cải thiện tính linh hoạt trong các SRP Rule, AppLocker được kỳ vọng sẽ là trợ thủ đắc lực trong việc giúp các quản trị viên kiểm soát tốt hơn vấn đề sử dụng phần mềm của người dùng.

Trong phần kế tiếp, bạn sẽ nắm được các kiểu rule trong AppLocker và quản lý các rule này như thế nào.

–manthang

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s