Hình 45. Thơng tin chi tiết của file log
đã thay đổi
Hình 46. Ghi nhận thay đổi của auditing
Object Access
9.4.8 Audit privilege use
Chính sách giám sát này sẽ thẩm định sự kiện có liên quan đến việc thực hiện một nhiệm vụ nào đó được điều khiển bởi một người dùng có thẩm quyền. Mặc định mức thẩm định này khơng được cấu hình để kiểm tra các sự kiện cho các hệ điều hành nào. Danh sách các quyền người dùng khá rộng, gồm có:
9.4.9 Audit process tracking
Chính sách giám sát này sẽ thẩm định sự kiện có liên quan đến các q trình
trên máy tính. Xác định để giám sát các thông tin theo dõi chi tiết cho các sự kiện như
kích hoạt chương trình, thốt tiến trình, xử lý sao chép, và truy cập các đối tượng gián tiếp.
Nếu định nghĩa thiết lập này, ta có thể chỉ định những giám sát thành cơng và cả thất bại, hoặc không để giám sát các loại ở tất cả các sự kiện. Những giám sát thành cơng sẽ được tạo ra khi q trình được theo dõi là thành công, và cũng tương tự đối với những giám sát không thành công.
Một số event ID liên quan:
4689: tiến trình bị thốt, ngừng, hoặc được khởi động lại 4696: Một token đầu tiên được gán cho tiến trình sau khi tạo 4688: tiến trình mới được tạo
Đầu tiên ta bật hộp thoại dịch vụ DNS và khởi động chương trình lên, như
trong hình lab bên dưới ta sẽ thấy filelog 4696 (process creation) ghi nhận chung cho các tiến trình khởi tạo và cụ thể ở đây là tiến trình của dịch vụ DNS.
Các thơng tin được ghi nhận như:
Process Name: C://Windows\System32\services.exe
Target Process Name: C://Windows\System32\dns.exe
Thông tin trên được hiểu như services được ghi nhận là một tiến trình đang được khởi tạo, mà cụ thể hơn trong tiến trình đó, đối tượng thật sự khởi tạo là dịch vụ
Hình 48.Khởi tạo tiến trình của dịch vụ DNS.
Khi một tiến trình được khởi tạo, kèm theo đó là một token (mã thông báo) được tạo và gán cho tiến trình mới này, tùy theo loại tiến trình sẽ được gán một token
khác nhau. Lab mơ phỏng dưới đây của tiến trình khởi tạo dns được gán token loại 1.
Token Elevation Type: TokenElevationTypeDefault(1)
Quá trình gán token cũng được gọi là quá trình khởi tạo (Process Creation)
Mơ hình lab tiếp theo đề cập đến tình huống cho dừng dịch vụ DNS, quá trình giám sát sẽ xuất hiện ngay một filelog 4689 (Process Termination) với các thông tin:
A process has exited. //tiến trình đã thốt Account Name: DC //tên máy
Accoun Domain: TEST //tên domain
Process Name: C:\\Windows\System32\dns.exe //tên tiến trình
Hình 50.Thốt tiến trình
Các loại mã thơng báo (token) cho biết loại mã thông báo đã được gán cho q trình mới theo chính sách của kiểm soát tài khoản người dùng.
- Loại 1 là một mã thơng báo đầy đủ khơng có quyền loại bỏ hoặc tắt. Một mã
thông báo đầy đủ chỉ được sử dụng nếu việc kiểm soát tài khoản người dùng bị vơ
hiệu hố hoặc nếu người dùng là tài khoản admin có sẵn hoặc tài khoản của một dịch vụ.
- Loại 2 là một mã thông báo cao hơn khơng có quyền loại bỏ hoặc vơ hiệu hóa. Một mã thơng báo được sử dụng khi việc kiểm soát tài khoản người dùng được kích hoạt và người sử dụng lựa chọn để bắt đầu chương trình bằng cách sử dụng Run as administrator. Một mã thông báo cũng được sử dụng khi một ứng dụng
được cấu hình để ln yêu cầu đặc quyền quản trị và người sử dụng là thành viên
của nhóm quản trị viên.
- Loại 3 là một mã thông báo hạn chế với quyền quản trị gở bỏ và vô hiệu hóa. Các mã thơng báo giới hạn được sử dụng khi việc kiểm soát tài khoản người dùng
được kích hoạt, các ứng dụng khơng địi hỏi đặc quyền hành chính, và người dùng
khơng chọn để bắt đầu chương trình bằng cách sử dụng Run as administrator.
9.4.10 Audit system events
Chính sách giám sát này sẽ thẩm định sự kiện có liên quan đến việc khởi động lại hoặc tắt máy tính. Các sự kiện có liên quan với bản ghi bảo mật và bảo mật hệ thống cũng sẽ được kiểm tra khi cách thức thẩm định này được kích hoạt. Đây là một cấu hình thẩm định được yêu cầu cho máy tính cần kiểm tra khơng chỉ khi các sự kiện xuất hiện mà cả khi bản thân bản ghi được xóa.
Chúng ta sẽ kiểm chứng chính sách giám sát này qua bằng cách bật và tắt firewall trong hệ thống. Đầu tiên ta sẽ vào services.msc để bật cho firewall khởi động, ngay lập tức bên hệ thống giám sát sẽ xuất hiện file log 5024 (Other System Events) có ghi thơng tin về trạng thái của firewall hệ thống là:
The Windows Firewall Service has started successfully.
Tiếp theo là trường hợp ta cho tắt firewall hệ thống, cũng tương tự sẽ xuất hiện file log 5025 (Other System Events) với thông tin ghi nhận:
The Windows Firewall Service has been stopped.
Hình 52.Ghi nhận sự kiện tắt Firewall
Như tên gọi của chính sách giám sát này, nó chỉ có thể giám sát những dịch vụ,
thành phần của hệ thống và nhiễm nghiên các thành phần không thuộc sẽ không được giám sát.
9.5 Giám sát hệ thống bằng command-line
Sử dụng công cụ auditpol.exe để giám sát các chính sách bằng command-line.
Tính năng này chỉ có trên Window Server 2008 để xem xét và thiết lập các chính sách
giám sát danh mục con, công cụ này không nhầm lẫn với Group Policy Object Editor (gpedit.msc).
Hình 53. Danh sách giám sát trong command-line
GPO Editor ở chỗ nó hiển thị đầy đủ các danh mục con trong từng chính sách giám sát, để ta có một cái nhìn cụ thể hơn về những chính sách cần thiết lập.
Như các bài lab mô phỏng ở trên ta đã thấy giao diện của Audit Policy gồm 9
chính sách giám sát nhưng ta không thể hiểu trong những chính sách ấy có những
thành phần gì, thì hình minh họa bên dưới đây sẽ hiển thị cho ta xem các thành phần con có trong từng chính sách tương ứng.
Hình 54. Liệt kê chi tiết giám sát command-line
Ta sẽ thiết lập chính sách giám sát “Account Logon”bằng một số lệnh như sau:
Auditpol /set /category:”Account Logon” /success:enable
Để biết thơng tin sau khi cấu hình ta sẽ dùng lệnh cấu hình như sau:
Đồng thời để kiểm tra, ta sẽ cho user đăng nhập vào domain, trong event viewer sẽ ghi
nhận lại sự kiện chứng thực Keberos, vì khi ta thiết lập khởi động cho chính sách
Account Logon trong đó có danh mục con chứng thực Keberos.
Hình 55. Thơng tin giám sát của account logon trong command-line
Giữa 2 cơng cụ này thì chúng ta nên sử dụng một trong 2 để tránh những sự nhầm lẫn qua lại khơng đáng có. Tuy những thơng tin thiết lập chính sách giám sát trên GPO sẽ hiển thị và replicate qua auditpol nhưng ngược lại thì thiết lập trên auditpol sẽ không được hiển thị trên GPO mặc dù là những thiết lập đó đều được áp
đặt lên hệ thống.
9.6 Nhận xét
Công việc giám sát sự kiện của hệ thống luôn là khâu quan trọng trong quá trình làm việc của quản trị viên. Chỉ với một số chính sách giám sát tuy đơn giản
nhưng biết cách thiết lập kết hợp từng loại chính sách với nhau sao cho hợp lý và hiệu
quả nhất với từng hệ thống khác nhau. Bên cạnh đó ta cần phải thường xuyên theo dõi, phân loại và lọc các thông báo sự kiện để kiểm sốt được tình trạng của hệ thống, nhằm bảo đảm hệ thống luôn trong trạng thái an tồn. Đồng thời có thể nhanh chóng phát hiện những đăng nhập trái phép, các rủi ro nguy hiểm hoặc báo lỗi từ hệ thống để kịp thời khắc phục chúng.
10. Xây dựng hệ thống giám sát với SNORT 10.1 Giới thiệu Snort 10.1 Giới thiệu Snort
Snort là công cụ phát hiện xâm nhập khá phổ biến và hổ trợ cho nhiều hệ điều
hành như: CentOS, Fedora, Linux, Window, OpenBSD, Solaris…Snort là một dạng
NIDS (Network Instruction Detection System) sẽ đóng vai trị là một hệ thống được
cài đặt trong mạng làm nhiệm vụ giám sát những packet vào ra hệ thống mạng. Khi
Snort phát hiện ra một cuộc tấn cơng hay thăm dị thì nó có thể phản ứng bằng nhiều cách khác nhau tùy thuộc vào cấu hình mà người quản trị mạng thiết lập.
Snort bao gồm một hoặc nhiều sensor và một server cơ sở dữ liệu chính. Các sensor có thể được đặt trước hoặc sau firewall nhằm :
- Giám sát các cuộc tấn công nhằm vào firewall và hệ thống mạng. - Có khẳ năng ghi nhớ các cuộc vượt firewall thành công.
10.2 Cấu trúc của Snort
Cấu trúc của Snort được chia thành nhiều phần. Những phần này làm việc cùng nhau nhằm một mục đích là phát hiện các loại tấn công và tạo ra các đáp trả theo một
định dạng đã được cấu hình. Một Snort IDS cơ bản gồm các thành phần chính sau:
Packet Decoder : Bộ giải mã gói Preprocessors : Bộ tiền xử lý
Detection Engine : Bộ máy phát hiện
Logging and Alerting System : Hệ thống ghi và cảnh báo Output Modules : Các module xuất
- Packet Decoder (Bộ giải mã gói)
Bộ phận này thu nhập các gói tin từ các giao diện mạng khác nhau và chuẩn bị cho gói tin được xử lý hoặc được gửi cho bộ phận phát hiện. Giao diện mạng gồm: PPP, L2TP, Ethernet,v.v…
- Preprocessor (Bộ tiền xử lý)
Là những thành phần hay những plug-in được sử dụng cùng với Snort để sắp xếp và thay đổi những gói dữ liệu trước khi detection engine thực hiện
cơng việc tìm kiếm nếu gói dữ liệu đó là nguy hiểm. Một vài preprocessor có
thể thực hiện tìm ra những dấu hiệu bất thường trong tiêu đề gói và tạo ra các cảnh báo. Preprocessor rất là quan trọng đối với IDS có chức năng chuẩn bị
những gói dữ liệu để phân tích cho việc thiết lập rule trong detection engine. Hacker sử dụng nhiều kỹ thuật khác nhau nhằm đánh lừa IDS bằng
nhiều cách. Hacker cũng sử dụng sự phân mảnh để đánh bại IDS. Preprocessor
thường được dùng để bảo vệ những loại tấn công này. Preprocessor trong Snort
có thể tái hợp các gói, giải mã HTTP URI, tái hợp luồng TCP,v.v... Những chức năng này rất là quan trọng trong thành phần IDS.
- Detection Engine (Bộ máy phát hiện)
Đây chính là thành phần quan trọng nhất của Snort. Detection Engine chịu
trách nhiệm phát hiện nếu có hành vi xâm nhập trong một gói. Detection engine sử dụng những rule Snort để làm việc này. Nếu một gói nào đó khớp với rule,
hành động thích hợp sẽ được tạo ra. Những hành động đó có thể là ghi gói hay cảnh báo. Đây là bộ phận đóng vai trị quyết định về thời gian thực thi của Snort. Phụ thuộc vào hệ năng của hệ thống và có bao nhiêu rule được định nghĩa mà nó có thể tốn những khoảng thời gian cho cơng việc đáp ứng các gói. Nếu lưu lượng trên mạng là quá lớn khi Snort đang hoạt động trong chế độ NIDS, có thể mất một vài gói tin và có thể thời gian đáp ứng sẽ khơng chính xác. Lưu lượng của detection engine phụ thuộc vào các yếu tố:
o Số lượng các luật.
o Lưu lượng trên mạng.
Detection engine làm việc khác nhau trong mỗi phiên bản Snort. Trong tất cả phiên bản Snort 1.x, detection engine ngừng xử lý trên gói đó khi ph ù
hợp với một rule. Phụ thuộc vào rule, detection engine có những hành động tương ứng. Điều này có nghĩa là nếu một gói tin phù hợp với nhiều rule, chỉ có
một rule đầu tiên được áp dụng mà khơng xem xét tới các rule cịn lại. Đây là một vấn đề. Một rule có độ ưu tiên thấp sẽ tạo ra một cảnh báo có độ ưu tiên
thấp, nếu một rule có độ ưu tiên cao bị xếp sau trong chuỗi rule. Vấn đề này đã
được sửa trong Snort phiên bản 2, tất cả các rule đều được so khớp vào một gói
trước khi tạo một cảnh báo. Sau khi so khớp tất cả các rule, rule nào trọn vẹn nhất sẽ được chọn để tạo cảnh báo.
Detection engine trong Snort 2.x đã được làm lại một cách hoàn chỉnh để nó so sánh tốt hơn, phát hiện sớm hơn so với các phiên bản trước.
- Logging and Alerting System (Hệ thống ghi và cảnh báo)
Phụ thuộc vào detection engine tìm trong gói, gói có thể được dùng để
ghi hành động hay tạo ra cảnh báo. Các thông tin ghi lại được giữ trong các file text đơn giản hoặc các dạng khác.
- Output Modules (Các module xuất)
Output modules hay plug-in thực hiện những hoạt động khác nhau phụ
thuộc vào việc muốn lưu kết quả tạo ra bởi logging và cảnh báo t hế nào.
10.3 Các chế độ hoạt động của Snort
Snort có 3 cơ chế hoạt động: Hoạt động như một Sniffer, Packet Logger hay là một NIDS.
10.3.1 Snort hoạt động như một Sniffer
Sử dụng Snort như một Sniffer là một cách giúp snort bắt được các gói tin thơng qua bộ cảm biến của mình. Kết quả của chế độ Snort sniffer hơi khác so
với các phần mềm sniffer khác. Một đặc tính hay của chế độ này là việc tóm tắt
lưu lượng mạng khi kết thúc việc bắt giữ gói tin.
Ví dụ về snort trên Win:
Liệt kê các card mạng hiện có: snort -W
Hình 57. Lệnh snort -W
Để sử dụng Snort như là một sniffer, ta dùng câu lệnh:
snort -v –ix
với x là số hiệu card mạng mà Snort sẽ sử dụng để sniffer
Hình 58. Lệnh snort –v -ix
Ví dụ: lấy máy client ping thử một máy trong mạng
Khi dừng chế độ sniffer, Snort sẽ tạo ra một bản tóm tắt các gói tin được bắt giữ, bao gồm các giao thức.
Hình 60. Bảng tóm tắt các gói tin được bắt giữ trên Win
Để xem dữ liệu gói tin bắt được một cách chi tiết hơn, ta sử dụng cờ -d
snort -vd -ix
Hình 61. Lệnh snort –vd -ix
Với tùy chọn cờ -e, ta được cung cấp nhiều thông tin nhất ,bao gồm địa chỉ
MAC và địa chỉ IP
Để lưu lại trong file log thay vì xuất ra console, ta sử dụng
snort -vde -i1 > C:/log1/temp.log
10.3.2 Snort là một Packet Logger
Sau khi Sniffer các gói tin, nhiệm vụ tiếp theo là ghi log. Việc ghi log chỉ đơn giản bằng cách thêm tùy chọn –l, theo sau đó là thư mục muốn lưu trữ file log. Thư mục mặc định trong Snort là C:\snort\log. Ta có thể thiết lập thư
mục log ở nơi khác. Ví dụ: snort –l C:\log1.
Khi chạy chế độ này, Snort thu thập mỗi gói tin nó thấy và lưu chúng
vào thư mục log theo kiểu phân cấp. Snort lưu các gói tin thành các file ASCII,
với tên file được tạo ra từ giao thức và số cổng.
10.3.3 Snort là một NIDS
Khi cài đặt ở chế độ Snort mặc định trên Win, vị trí file này là
C:\snort\etc\snort.conf. Các cảnh báo được đặt trong file alert trong thư mục log C:\snort\log. Snort sẽ thoát ra với một lỗi nếu file cấu hình hoặc thư mục log khơng tồn tại. Khi sử dụng chế độ này cần chỉ rõ file cấu hình với cờ –c .
“snort -c c:\snort\etc\snort.conf -l c:\snort\log”
Dịng lệnh trên mặc định các thơng tin sniffer sẽ được ghi vào file alerts và sẽ tạo ra một file snort.log theo kiểu phân cấp. Nếu gói tin so trùng với một rule thì sự ghị nhận hoặc cảnh báo được tạo ra. Ngược lại, nếu gói tin khơng trùng với một rule thì khơng cảnh bảo nào tạo ra.
“snort -c c:\snort\etc\snort.conf -l c:\snort\log -A console”
Dùng lệnh này không ghi vào file alerts, nhưng sẽ tạo ra một file snort.log theo kiểu phân cáp. Với cờ -A là thiết lập chế độ cảnh báo, “console” là ở giao diện điều khiển. Bình thường trên giao diện ở cmd sẽ không hiện các sniffer, nhưng khi dùng