Thứ năm, 16/07/2015 | 00:00 GMT+7

Cách sử dụng Hệ thống kiểm toán Linux trên CentOS 7

Hệ thống Kiểm toán Linux giúp administrator hệ thống tạo ra một dấu vết kiểm tra, một log cho mọi hành động trên server . Ta có thể theo dõi các sự kiện liên quan đến bảo mật, ghi lại các sự kiện trong file log và phát hiện các hoạt động sử dụng sai hoặc trái phép bằng cách kiểm tra file log kiểm tra. Ta có thể chọn các hành động trên server để giám sát và ở mức độ nào. Kiểm tra không cung cấp bảo mật bổ sung cho hệ thống của bạn, thay vào đó, nó giúp theo dõi bất kỳ vi phạm nào đối với policy hệ thống và cho phép bạn thực hiện các biện pháp bảo mật bổ sung để ngăn chặn chúng.

Hướng dẫn này giải thích hệ thống kiểm toán, cách cấu hình hệ thống, cách tạo báo cáo và cách đọc các báo cáo này. Ta cũng sẽ xem cách tìm kiếm log kiểm tra cho các sự kiện cụ thể.

Yêu cầu

Đối với hướng dẫn này, bạn cần các thành phần sau :

  • CentOS 7 Server (cũng hoạt động với CentOS 6)
  • User không phải root có quyền sudo. Để cài đặt user kiểu này, hãy làm theo hướng dẫn Cài đặt server ban đầu với CentOS 7 . Tất cả các lệnh sẽ được chạy với quyền user này.

Xác minh cài đặt kiểm tra

Có hai phần chính trong hệ thống kiểm toán:

  1. Thành phần kernel kiểm toán chặn các cuộc gọi hệ thống từ các ứng dụng của user , ghi lại các sự kiện và gửi các thông báo kiểm tra này đến daemon kiểm tra
  2. Trình auditd thu thập thông tin từ kernel và tạo các mục nhập trong file log

Hệ thống kiểm toán sử dụng các gói sau: auditaudit-libs . Các gói này được cài đặt theo mặc định trên CentOS 7 Server mới (và CentOS 6 Server mới). Bạn nên xác minh bạn đã cài đặt chúng trên server của bạn bằng cách sử dụng:

  • sudo yum list audit audit-libs

Bạn sẽ thấy cả hai gói trong Installed Packages trong kết quả :

Installed Packages audit.x86_64 audit-libs.x86_64 

Cấu hình kiểm tra

Tệp cấu hình chính cho auditd/etc/audit/auditd.conf . Tệp này bao gồm các thông số cấu hình bao gồm vị trí ghi các sự kiện, cách xử lý các ổ đĩa đầy đủ và xoay vòng log . Để chỉnh sửa file này, bạn cần sử dụng sudo:

  • sudo nano /etc/audit/auditd.conf

Ví dụ: để tăng số file log kiểm tra được lưu giữ trên server của bạn lên 10, hãy chỉnh sửa tùy chọn sau:

/etc/audit/auditd.conf
num_logs = 10 

Bạn cũng có thể cấu hình kích thước file log tối đa tính bằng MB và hành động cần thực hiện khi đạt đến kích thước:

/etc/audit/auditd.conf
max_log_file = 30 max_log_file_action = ROTATE 

Khi bạn áp dụng các thay đổi đối với cấu hình, bạn cần khởi động lại dịch vụ kiểm toán bằng cách sử dụng:

  • sudo service auditd restart

để các thay đổi có hiệu lực.

Tệp cấu hình khác là /etc/audit/rules.d/audit.rules . (Nếu bạn đang sử dụng CentOS 6, file sẽ là /etc/audit/audit.rules .) Nó được sử dụng để thêm vĩnh viễn các luật kiểm tra.

Khi auditd đang chạy, các thông báo kiểm tra sẽ được ghi lại trong file /var/log/audit/audit.log .

Hiểu file log kiểm tra

Theo mặc định, hệ thống kiểm tra ghi log các thông báo kiểm tra vào file /var/log/audit/audit.log . Các file log kiểm tra mang nhiều thông tin hữu ích, nhưng việc đọc và hiểu các file log có thể có vẻ khó khăn đối với nhiều user do lượng thông tin được cung cấp quá lớn, các từ viết tắt và mã được sử dụng, v.v. Trong phần này, ta sẽ cố gắng hiểu một số của các trường trong thông báo kiểm tra thông thường trong file log kiểm tra.

'Lưu ý: Nếu auditd không chạy vì bất kỳ lý do gì, các thông báo kiểm tra sẽ được gửi đến rsyslog.

Đối với ví dụ này, giả sử ta có một luật kiểm tra được cấu hình trên server với nhãn ( key ) sshconfigchange để ghi lại mọi quyền truy cập hoặc sửa đổi vào file /etc/ssh/sshd_config . Nếu muốn, bạn có thể thêm luật này tạm thời bằng cách sử dụng:

  • sudo auditctl -w /etc/ssh/sshd_config -p rwxa -k sshconfigchange

Chạy lệnh sau để xem file sshd_config sẽ tạo ra một sự kiện mới trong file log kiểm tra:

  • sudo cat /etc/ssh/sshd_config

Sự kiện này trong file audit.log trông như sau:

/var/log/audit/audit.log
 type=SYSCALL msg=audit(1434371271.277:135496): arch=c000003e syscall=2 success=yes exit=3 a0=7fff0054e929 a1=0 a2=1fffffffffff0000 a3=7fff0054c390 items=1 ppid=6265 pid=6266 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=113 comm="cat" exe="/usr/bin/cat" key="sshconfigchange"  type=CWD msg=audit(1434371271.277:135496):  cwd="/home/sammy"  type=PATH msg=audit(1434371271.277:135496): item=0 name="/etc/ssh/sshd_config" inode=392210 dev=fd:01 mode=0100600 ouid=0 ogid=0 rdev=00:00 objtype=NORMAL 

Sự kiện trên bao gồm ba bản ghi (mỗi bản ghi bắt đầu bằng type= keyword), có chung dấu thời gian ( 1434371271.277 ) và id ( 135496 ). Mỗi bản ghi bao gồm một số cặp tên = giá trị được phân tách bằng khoảng trắng hoặc dấu phẩy. Ta sẽ xem chi tiết một số trường đó tượng trưng cho điều gì.

Trong bản ghi đầu tiên:

  • type=SYSCALL

Trường type chứa loại thông báo kiểm tra. Trong trường hợp này, giá trị SYSCALL cho thấy rằng thông báo này được kích hoạt bởi một lệnh gọi hệ thống tới kernel .

  • msg=audit(1434371271.277:135496):

Dấu thời gian và ID của thông báo kiểm tra trong audit(time_stamp:ID) biểu mẫu audit(time_stamp:ID) . Nhiều bản ghi / thông báo kiểm tra có thể chia sẻ cùng một dấu thời gian và ID nếu chúng được tạo như một phần của cùng một sự kiện kiểm tra. Trong ví dụ của ta , ta có thể thấy cùng một dấu thời gian (1434371271.277) và ID (135496) trên cả ba thông báo được tạo bởi sự kiện kiểm tra.

  • arch=c000003e

Trường arch chứa thông tin về kiến trúc CPU của hệ thống. Giá trị, c000003e, ở dạng ký hiệu thập lục phân và là viết tắt của x86_64.

  • syscall=2

Trường syscall biểu thị loại lệnh gọi hệ thống đã được gửi đến kernel . Trong trường hợp này, 2 là lệnh gọi hệ thống đang open . Tiện ích ausyscall cho phép bạn chuyển đổi các số gọi của hệ thống thành các số tương đương mà con người có thể đọc được. Ví dụ: chạy lệnh sau để chuyển đổi giá trị 2 thành giá trị tương đương mà con người có thể đọc được:

  • sudo ausyscall 2

Kết quả cho thấy:

open 

Lưu ý: Bạn có thể sử dụng sudo ausyscall --dump để xem danh sách tất cả các lệnh gọi hệ thống cùng với số của chúng.

  • success=yes

Trường success cho biết liệu lệnh gọi hệ thống trong sự kiện cụ thể đó thành công hay thất bại. Trong trường hợp này, cuộc gọi đã thành công. User sammy có thể mở và đọc file sshd_config khi sudo cat /etc/ssh/sshd_config được chạy.

  • ppid=6265

Trường ppid ghi lại ID quy trình chính (PPID). Trong trường hợp này, 6265 là PPID của quá trình bash .

  • pid=6266

Trường pid ghi lại ID quy trình (PID). Trong trường hợp này, 6266 là PID của quá trình cat .

  • auid=1000

auid là UID kiểm tra hoặc UID ban đầu của user đã kích hoạt thông báo kiểm tra này. Hệ thống kiểm tra sẽ ghi nhớ UID ban đầu của bạn ngay cả khi bạn nâng cấp quyền thông qua su hoặc sudo sau khi đăng nhập lần đầu.

  • uid=0

Trường uid ghi lại ID user của user đã bắt đầu quá trình được phân tích. Trong trường hợp này, lệnh cat được bắt đầu bởi user root với uid 0.

  • comm="cat"

comm ghi lại tên của lệnh đã kích hoạt thông báo kiểm tra này.

  • exe="/usr/bin/cat"

Trường exe ghi lại đường dẫn đến lệnh được sử dụng để kích hoạt thông báo kiểm tra này.

  • key="sshconfigchange"

Trường key ghi lại chuỗi do administrator xác định được liên kết với luật kiểm tra đã tạo ra sự kiện này trong log . Các khóa thường được đặt trong khi tạo các luật kiểm tra tùy chỉnh để giúp tìm kiếm các loại sự kiện nhất định từ log kiểm tra dễ dàng hơn.

Đối với bản ghi thứ hai:

  • type=CWD

Trong bản ghi thứ hai, loại là CWD - Thư mục làm việc hiện tại. Loại này được sử dụng để ghi lại folder làm việc mà từ đó quá trình kích hoạt lệnh gọi hệ thống được chỉ định trong bản ghi đầu tiên được thực thi.

  • cwd="/home/sammy"

Trường cwd chứa đường dẫn đến folder mà từ đó lệnh gọi hệ thống được gọi. Trong trường hợp của ta , lệnh cat đã kích hoạt cuộc gọi tổng hợp open trong bản ghi đầu tiên được thực thi từ folder /home/sammy .

Đối với bản ghi thứ ba:

  • type=PATH

Trong bản ghi thứ ba, kiểu là PATH . Một sự kiện kiểm tra chứa một bản ghi PATH cho mọi đường dẫn được chuyển đến lệnh gọi hệ thống dưới dạng đối số. Trong sự kiện kiểm tra của ta , chỉ một đường dẫn ( /etc/ssh/sshd_config ) được sử dụng làm đối số.

  • msg=audit(1434371271.277:135496):

Trường msg hiển thị cùng một dấu thời gian và kết hợp ID như trong bản ghi đầu tiên và thứ hai vì cả ba bản ghi đều là một phần của cùng một sự kiện kiểm tra.

  • name="/etc/ssh/sshd_config"

Trường name ghi lại đường dẫn đầy đủ của file hoặc folder đã được chuyển đến lệnh gọi hệ thống (mở) dưới dạng đối số. Trong trường hợp này, đó là file /etc/ssh/sshd_config .

  • ouid=0

Trường ouid ghi lại ID user của chủ sở hữu đối tượng. Ở đây đối tượng là file /etc/ssh/sshd_config .

Lưu ý: Thông tin thêm về các loại profile đánh giá có sẵn từ các liên kết ở cuối hướng dẫn này.

Tìm kiếm Nhật ký kiểm tra cho các sự kiện

Hệ thống Kiểm toán Linux cung cấp một công cụ mạnh mẽ được gọi là ausearch để tìm kiếm log kiểm tra. Với ausearch , bạn có thể lọc và tìm kiếm các loại sự kiện. Nó cũng có thể diễn giải các sự kiện cho bạn bằng cách dịch các giá trị số sang các giá trị mà con người có thể đọc được như lệnh gọi hệ thống hoặc tên user .

Ta hãy xem xét một vài ví dụ.

Lệnh sau sẽ tìm kiếm log kiểm tra cho tất cả các sự kiện kiểm tra thuộc loại LOGIN từ hôm nay và diễn giải tên user .

  • sudo ausearch -m LOGIN --start today -i

Lệnh dưới đây sẽ tìm kiếm tất cả các sự kiện có id sự kiện 27020 (miễn là có sự kiện với id đó).

  • sudo ausearch -a 27020

Lệnh này sẽ tìm kiếm tất cả các sự kiện (nếu có) khi chạm vào file /etc/ssh/sshd_config và diễn giải chúng:

  • sudo ausearch -f /etc/ssh/sshd_config -i

Tạo báo cáo kiểm toán

Thay vì đọc log kiểm tra thô, bạn có thể nhận được bản tóm tắt các thông báo kiểm tra bằng cách sử dụng công cụ aureport . Nó cung cấp các báo cáo ở định dạng con người có thể đọc được. Các báo cáo này được dùng như các khối xây dựng để phân tích phức tạp hơn. Khi aureport được chạy mà không có bất kỳ tùy chọn nào, nó sẽ hiển thị tóm tắt về các loại sự kiện khác nhau có trong log kiểm tra. Khi được sử dụng với các tùy chọn tìm kiếm, nó sẽ hiển thị danh sách các sự kiện phù hợp với tiêu chí tìm kiếm.

Hãy để ta thử một vài ví dụ cho aureport . Nếu bạn muốn tạo báo cáo tóm tắt về tất cả các lần thực thi lệnh trên server , hãy chạy:

  • sudo aureport -x --summary

Đầu ra sẽ giống như thế này với các giá trị khác nhau:

Executable Summary Report ================================= total  file ================================= 117795  /usr/sbin/sshd 1776  /usr/sbin/crond 210  /usr/bin/sudo 141  /usr/bin/date 24  /usr/sbin/autrace 18  /usr/bin/su 

Cột đầu tiên hiển thị số lần lệnh đã được thực hiện và cột thứ hai hiển thị lệnh đã được thực hiện. Xin lưu ý không phải tất cả các lệnh đều được ghi theo mặc định. Chỉ những cái liên quan đến bảo mật mới được ghi lại.

Lệnh sau sẽ cung cấp cho bạn số liệu thống kê của tất cả các sự kiện không thành công:

  • sudo aureport --failed

Đầu ra trông tương tự như:

Failed Summary Report ====================== Number of failed logins: 11783 Number of failed authentications: 41679 Number of users: 3 Number of terminals: 4 Number of host names: 203 Number of executables: 3 Number of files: 4 Number of AVC's: 0 Number of MAC events: 0 Number of failed syscalls: 9 

Để tạo báo cáo về các file được truy cập bằng lệnh gọi hệ thống và tên user :

  • sudo aureport -f -i

Đầu ra mẫu:

File Report =============================================== # date time file syscall success exe auid event =============================================== 1. Monday 15 June 2015 08:27:51 /etc/ssh/sshd_config open yes /usr/bin/cat sammy 135496 2. Tuesday 16 June 2015 00:40:15 /etc/ssh/sshd_config getxattr no /usr/bin/ls root 147481 3. Tuesday 16 June 2015 00:40:15 /etc/ssh/sshd_config lgetxattr yes /usr/bin/ls root 147482 4. Tuesday 16 June 2015 00:40:15 /etc/ssh/sshd_config getxattr no /usr/bin/ls root 147483 5. Tuesday 16 June 2015 00:40:15 /etc/ssh/sshd_config getxattr no /usr/bin/ls root 147484 6. Tuesday 16 June 2015 05:40:08 /bin/date execve yes /usr/bin/date root 148617 

Để xem cùng một định dạng tóm tắt, bạn có thể chạy:

  • sudo aureport -f -i --summary

Lưu ý: Công cụ aureport cũng có thể lấy đầu vào từ stdin thay vì file log miễn là đầu vào ở định dạng dữ liệu log thô.

Phân tích quy trình bằng tính năng tự động

Thực hiện kiểm toán một quá trình cá nhân, ta có thể sử dụng autrace công cụ. Công cụ này theo dõi các cuộc gọi hệ thống được thực hiện bởi một quy trình. Điều này có thể hữu ích trong việc điều tra một trojan bị nghi ngờ hoặc một quy trình có vấn đề. Đầu ra của autrace được ghi vào /var/log/audit/audit.log và trông tương tự như các mục nhập log kiểm tra tiêu chuẩn. Sau khi thực thi, autrace sẽ cung cấp cho bạn một ví dụ lệnh ausearch để điều tra log . Luôn sử dụng đường dẫn đầy đủ đến file binary để theo dõi bằng autrace, ví dụ: sudo autrace /bin/ls /tmp .

Lưu ý: Xin lưu ý việc chạy autrace sẽ xóa tất cả các luật kiểm tra tùy chỉnh. Nó thay thế chúng bằng các luật cụ thể cần thiết để theo dõi quy trình bạn đã chỉ định. Sau khi autrace hoàn tất, nó sẽ xóa các luật mới được thêm vào. Vì lý do tương tự, tính autrace tự động sẽ không hoạt động khi các luật kiểm toán của bạn được đặt là bất biến.

Hãy để ta thử một ví dụ, chẳng hạn, ta muốn theo dõi date xử lý và xem các file và lệnh gọi hệ thống được sử dụng bởi nó. Chạy như sau:

  • sudo autrace /bin/date

Bạn sẽ thấy một cái gì đó tương tự như sau:

Waiting to execute: /bin/date Wed Jun 17 07:22:03 EDT 2015 Cleaning up... Trace complete. You can locate the records with 'ausearch -i -p 27020' 

Bạn có thể sử dụng lệnh ausearch từ kết quả ở trên để xem các log liên quan hoặc thậm chí chuyển nó vào aureport để nhận được kết quả có định dạng tốt mà con người có thể đọc được:

  • sudo ausearch -p 27020 --raw | aureport -f -i

Lệnh này tìm kiếm sự kiện với ID sự kiện 27020 từ log kiểm tra, extract nó ở định dạng log thô và chuyển nó đến aureport , từ đó diễn giải và đưa ra kết quả ở định dạng tốt hơn để dễ đọc hơn.

Bạn sẽ thấy kết quả tương tự như sau:

File Report =============================================== # date time file syscall success exe auid event =============================================== 1. Wednesday 17 June 2015 07:22:03 /bin/date execve yes /usr/bin/date sammy 169660 2. Wednesday 17 June 2015 07:22:03 /etc/ld.so.preload access no /usr/bin/date sammy 169663 3. Wednesday 17 June 2015 07:22:03 /etc/ld.so.cache open yes /usr/bin/date sammy 169664 4. Wednesday 17 June 2015 07:22:03 /lib64/libc.so.6 open yes /usr/bin/date sammy 169668 5. Wednesday 17 June 2015 07:22:03 /usr/lib/locale/locale-archive open yes /usr/bin/date sammy 169683 6. Wednesday 17 June 2015 07:22:03 /etc/localtime open yes /usr/bin/date sammy 169691 

Kết luận

Ta đã trình bày những kiến thức cơ bản về Hệ thống Kiểm toán Linux trong hướng dẫn này. Đến đây bạn đã hiểu rõ về cách hệ thống kiểm tra hoạt động, cách đọc log kiểm tra và các công cụ khác nhau có sẵn để giúp bạn kiểm tra server của bạn dễ dàng hơn.

Theo mặc định, hệ thống kiểm tra chỉ ghi lại một số sự kiện trong log như user đăng nhập và user sử dụng sudo. Các thông báo liên quan đến SELinux cũng được ghi lại. Daemon kiểm tra sử dụng các luật để theo dõi các sự kiện cụ thể và tạo các mục log liên quan. Có thể tạo các luật kiểm tra tùy chỉnh để theo dõi và ghi lại vào log bất cứ điều gì ta muốn. Đây là nơi hệ thống kiểm toán trở nên mạnh mẽ đối với người quản trị hệ thống. Ta có thể thêm các luật bằng cách sử dụng công cụ dòng lệnh auditctl hoặc vĩnh viễn trong file /etc/audit/rules.d/audit.rules . Viết luật tùy chỉnh và sử dụng bộ luật xác định trước được thảo luận chi tiết trong hướng dẫn Viết luật kiểm tra hệ thống tùy chỉnh trên CentOS 7 .

Bạn cũng có thể xem các tài nguyên sau để biết thêm thông tin về hệ thống kiểm toán:


Tags:

Các tin liên quan

Cách sử dụng Hệ thống kiểm toán Linux trên CentOS 7
2015-07-16
Thiết lập ban đầu của server Fedora 22
2015-07-08
Cách thiết lập Shiny Server trên Ubuntu 14.04
2015-06-28
Cách backup server LAMP bằng Bacula trên Ubuntu 14.04
2015-06-11
Cách cấu hình sao chép DNS trên server Slave PowerDNS trên Ubuntu 14.04
2015-06-04
Cách thay đổi mật khẩu tài khoản trên server OpenLDAP
2015-05-29
Cách thay đổi mật khẩu tài khoản trên server OpenLDAP
2015-05-29
Cách chạy mail server và lưu trữ tệp của riêng bạn với PEPS trên Ubuntu 14.04
2015-05-22
Cách chạy mail server của riêng bạn với Mail-in-a-Box trên Ubuntu 14.04
2015-05-15
Thiết lập server ban đầu với Debian 8
2015-05-11