it-swarm-vi.com

Ví dụ đơn giản cấu hình Audd?

Auditd được đề xuất trong câu trả lời cho ghi nhật ký lệnh Linux?

Cài đặt mặc định trên Ubuntu dường như hầu như không đăng nhập bất cứ thứ gì. Có một số ví dụ đi kèm với nó (capp.rules, nispom.rules, stig.rules) nhưng không rõ tác động hiệu suất của từng loại sẽ như thế nào, cũng như loại môi trường hoặc giả định nào phù hợp nhất.

Điều gì sẽ là điểm khởi đầu tốt nhất để triển khai audd trên, giả sử, một máy chủ web? Điều này sẽ bao gồm tệp aud.rules, cài đặt để cho phép gửi luồng nhật ký kiểm toán đến một máy từ xa trong thời gian thực và các công cụ đơn giản nhất để xem những gì đã được ghi lại.

Tiếp theo, làm thế nào về một máy tính để bàn điển hình?

Cập nhật: dannysauer lưu ý rằng để bảo mật, điều quan trọng là bắt đầu với mục tiêu và tôi đồng ý. Nhưng mục đích chính của tôi là spark một số giải thích hữu ích hơn về việc sử dụng công cụ này và xem ví dụ hoạt động trong thực tế, cùng với ý nghĩa về hiệu suất và lưu trữ, v.v ... Nếu điều đó đã tồn tại và tôi đã bỏ lỡ nó, xin vui lòng chỉ ra nó. Nếu không, tôi đề nghị rằng một ví dụ được tạo cho một trong những tình huống phổ biến hơn (ví dụ: máy chủ web đơn giản, chạy theo lựa chọn của bạn), trong đó mục tiêu có thể là lưu giữ thông tin trong trường hợp đột nhập để giúp theo dõi lại để tìm ra nơi thâm nhập bắt đầu. Nếu có mục tiêu phù hợp hơn hoặc có thể đạt được để sử dụng ví dụ: một doanh nghiệp nhỏ không có nhân viên CNTT quan trọng, điều đó cũng có ích.

48
nealmcb

Auditd là một công cụ giám sát cực kỳ mạnh mẽ. Như bất cứ ai đã từng nhìn vào nó đều có thể chứng thực, khả năng sử dụng là điểm yếu chính. Thiết lập một cái gì đó như Audd đòi hỏi rất nhiều suy nghĩ sâu sắc về chính xác cái gì đó là cần kiểm toán trên hệ thống cụ thể được đề cập. Trong câu hỏi bạn đã quyết định trên một máy chủ web là hệ thống ví dụ của chúng tôi, điều này tốt vì nó cụ thể.

Để tranh luận, giả sử rằng có một sự phân chia chính thức giữa máy chủ web test/dev và máy chủ web sản xuất nơi các nhà phát triển web thực hiện tất cả công việc của họ trên các hệ thống test/dev và thay đổi môi trường sản xuất được thực hiện trong một triển khai có kiểm soát.

Vì vậy, làm cho những giả định khá lớn và tập trung vào hệ thống sản xuất, chúng ta có thể bắt tay vào làm việc. Nhìn vào đề xuất kiểm toán trong điểm chuẩn CIS cho RHEL5 chúng ta có thể bắt đầu xây dựng các quy tắc được đề xuất sau:

-a exit,always -S unlink -S rmdir
-a exit,always -S stime.*
-a exit,always -S setrlimit.*
-w /etc/group -p wa 
-w /etc/passwd -p wa 
-w /etc/shadow -p wa 
-w /etc/sudoers -p wa
-b 1024
-e 2

Điều này sẽ khiến các bản ghi được ghi ra bất cứ khi nào hệ thống rmdir, hủy liên kết, stime hoặc setrlimit gọi thoát. Điều này sẽ cho chúng tôi biết nếu có ai cố gắng xóa các tập tin hoặc trình phân tích theo thời gian. Chúng tôi cũng thiết lập đồng hồ tệp cụ thể trên các tệp xác định nhóm, người dùng, mật khẩu và quyền truy cập Sudo. Thay vì nhìn vào các cuộc gọi hệ thống cho mỗi một trong số đó, nhật ký kiểm toán sẽ được viết mỗi khi một trong các tệp đó là:

  1. được mở bằng các chế độ O_WRONLY hoặc O_RDWR
  2. một thuộc tính được thay đổi

Vì chúng tôi đã đưa ra giả định rằng chúng tôi đang nói về một máy chủ web sản xuất, tôi khuyên bạn nên thêm dòng:

-w /var/www -p wa

Điều này sẽ theo dõi đệ quy tất cả các tệp trong /var/www cây thư mục.

Bây giờ chúng ta có thể thấy lý do cho giả định "môi trường được kiểm soát" được đưa ra trước đó. Giữa việc giám sát tất cả các tệp trong web root, cũng như tất cả các sự kiện hủy liên kết hoặc rmdir, điều này có thể gây ồn ào trong môi trường phát triển. Nếu chúng ta có thể dự đoán các thay đổi hệ thống tệp, chẳng hạn như trong các cửa sổ bảo trì hoặc triển khai các sự kiện, chúng ta có thể lọc tiếng ồn này một cách hợp lý hơn.

Kết hợp tất cả những điều này thành một tập tin duy nhất, mạch lạc, chúng tôi muốn /etc/audit/audit.rules để trông giống như

# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# The rules are simply the parameters that would be passed
# to auditctl.

# First rule - delete all
-D

# Increase the buffers to survive stress events.
# Make this bigger for busy systems
-b 1024

-a exit,always -S unlink -S rmdir
-a exit,always -S stime.*
-a exit,always -S setrlimit.*
-w /var/www -p wa
-w /etc/group -p wa
-w /etc/passwd -p wa
-w /etc/shadow -p wa
-w /etc/sudoers -p wa

# Disable adding any additional rules - note that adding *new* rules will require a reboot
-e 2
41
Scott Pack

Cập nhật: Bài viết này là một lời giải thích hay về các quy tắc kiểm toán và đưa ra các ví dụ cho mỗi sự kiện bạn có thể muốn đăng nhập:

HOWTO_ thông minh_the_auditing_of_the_system_auditd


Kiểm tra báo cáo lỗi ở đây:

https://github.com/gds-operations/puppet-auditd/pull/1

Họ đưa ra một tệp ví dụ rất dài chứa nhiều thay đổi quan trọng có thể được thực hiện đối với một hệ thống. Sao chép bên dưới để thuận tiện (với sửa đổi nhỏ):

## Remove any existing rules
-D

## Buffer Size
## Feel free to increase this if the machine panic's
-b 8192

## Failure Mode
## Possible values are 0 (silent), 1 (printk, print a failure message),
## and 2 (panic, halt the system).
-f 1

## Audit the audit logs.
## successful and unsuccessful attempts to read information from the
## audit records; all modifications to the audit trail
-w /var/log/audit/ -k auditlog

## Auditd configuration
## modifications to audit configuration that occur while the audit
## collection functions are operating.
-w /etc/audit/ -p wa -k auditconfig
-w /etc/libaudit.conf -p wa -k auditconfig
-w /etc/audisp/ -p wa -k audispconfig

## Monitor for use of audit management tools
-w /sbin/auditctl -p x -k audittools
-w /sbin/auditd -p x -k audittools

## special files
-a exit,always -F Arch=b32 -S mknod -S mknodat -k specialfiles
-a exit,always -F Arch=b64 -S mknod -S mknodat -k specialfiles

## Mount operations
-a exit,always -F Arch=b32 -S mount -S umount -S umount2 -k mount
-a exit,always -F Arch=b64 -S mount -S umount2 -k mount

## changes to the time
##
-a exit,always -F Arch=b32 -S adjtimex -S settimeofday -S stime -S clock_settime -k time
-a exit,always -F Arch=b64 -S adjtimex -S settimeofday -S clock_settime -k time

## Use stunnel
-w /usr/sbin/stunnel -p x -k stunnel

## cron configuration & scheduled jobs
-w /etc/cron.allow -p wa -k cron
-w /etc/cron.deny -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /etc/cron.daily/ -p wa -k cron
-w /etc/cron.hourly/ -p wa -k cron
-w /etc/cron.monthly/ -p wa -k cron
-w /etc/cron.weekly/ -p wa -k cron
-w /etc/crontab -p wa -k cron
-w /var/spool/cron/crontabs/ -k cron

## user, group, password databases
-w /etc/group -p wa -k etcgroup
-w /etc/passwd -p wa -k etcpasswd
-w /etc/gshadow -k etcgroup
-w /etc/shadow -k etcpasswd
-w /etc/security/opasswd -k opasswd

## monitor usage of passwd
-w /usr/bin/passwd -p x -k passwd_modification

#Monitor for use of tools to change group identifiers
-w /usr/sbin/groupadd -p x -k group_modification
-w /usr/sbin/groupmod -p x -k group_modification
-w /usr/sbin/addgroup -p x -k group_modification
-w /usr/sbin/useradd -p x -k user_modification
-w /usr/sbin/usermod -p x -k user_modification
-w /usr/sbin/adduser -p x -k user_modification

## login configuration and information
-w /etc/login.defs -p wa -k login
-w /etc/securetty -p wa -k login
-w /var/log/faillog -p wa -k login
-w /var/log/lastlog -p wa -k login
-w /var/log/tallylog -p wa -k login

## network configuration
-w /etc/hosts -p wa -k hosts
-w /etc/network/ -p wa -k network

## system startup scripts
-w /etc/inittab -p wa -k init
-w /etc/init.d/ -p wa -k init
-w /etc/init/ -p wa -k init

## library search paths
-w /etc/ld.so.conf -p wa -k libpath

## local time zone
-w /etc/localtime -p wa -k localtime

## kernel parameters
-w /etc/sysctl.conf -p wa -k sysctl

## modprobe configuration
-w /etc/modprobe.conf -p wa -k modprobe

## pam configuration
-w /etc/pam.d/ -p wa -k pam
-w /etc/security/limits.conf -p wa  -k pam
-w /etc/security/pam_env.conf -p wa -k pam
-w /etc/security/namespace.conf -p wa -k pam
-w /etc/security/namespace.init -p wa -k pam

## GDS specific secrets
-w /etc/puppet/ssl -p wa -k puppet_ssl

## postfix configuration
-w /etc/aliases -p wa -k mail
-w /etc/postfix/ -p wa -k mail

## ssh configuration
-w /etc/ssh/sshd_config -k sshd

## changes to hostname
-a exit,always -F Arch=b32 -S sethostname -k hostname
-a exit,always -F Arch=b64 -S sethostname -k hostname

## changes to issue
-w /etc/issue -p wa -k etcissue
-w /etc/issue.net -p wa -k etcissue

## this was to noisy currently.
# log all commands executed by an effective id of 0 aka root.
-a exit,always -F Arch=b64 -F euid=0 -S execve -k rootcmd
-a exit,always -F Arch=b32 -F euid=0 -S execve -k rootcmd

## Capture all failures to access on critical elements
-a exit,always -F Arch=b64 -S open -F dir=/etc -F success=0 -k unauthedfileacess
-a exit,always -F Arch=b64 -S open -F dir=/bin -F success=0 -k unauthedfileacess
-a exit,always -F Arch=b64 -S open -F dir=/sbin -F success=0 -k unauthedfileacess
-a exit,always -F Arch=b64 -S open -F dir=/usr/bin -F success=0 -k unauthedfileacess
-a exit,always -F Arch=b64 -S open -F dir=/usr/sbin -F success=0 -k unauthedfileacess
-a exit,always -F Arch=b64 -S open -F dir=/var -F success=0 -k unauthedfileacess
-a exit,always -F Arch=b64 -S open -F dir=/home -F success=0 -k unauthedfileacess
-a exit,always -F Arch=b64 -S open -F dir=/srv -F success=0 -k unauthedfileacess

## Monitor for use of process ID change (switching accounts) applications
-w /bin/su -p x -k priv_esc
-w /usr/bin/Sudo -p x -k priv_esc
-w /etc/sudoers -p rw -k priv_esc

## Monitor usage of commands to change power state
-w /sbin/shutdown -p x -k power
-w /sbin/poweroff -p x -k power
-w /sbin/reboot -p x -k power
-w /sbin/halt -p x -k power

## Make the configuration immutable
-e 2
14
dberm22

Bạn đang phần nào tiếp cận câu hỏi sai cách. Bạn cần phải quyết định những gì bạn muốn đăng nhập, và tìm hiểu làm thế nào để đăng nhập đó. Tạo ra một loạt các tệp nhật ký là tuyệt vời, nhưng nếu bạn không bao giờ nhìn vào chúng hoặc không biết những gì bạn đang tìm kiếm, nó chỉ lãng phí thời gian và không gian.

Khi quyết định đăng nhập cái gì, bạn cần xác định hành vi mà bạn quan tâm, và sau đó tìm hiểu cách đăng nhập hoạt động đó. Một cách tốt để bắt đầu làm điều này là đọc về AppArmor và đọc lướt qua audctl trang man. sau đó tìm hiểu những cuộc gọi hệ thống nào có sẵn bằng cách học lập trình cho Unix và xác định các cuộc gọi có thể được quan tâm. Đó thực sự là một công việc khá lớn. Tôi biết đây là một câu trả lời ngắn gọn và không cung cấp "đây là tập lệnh Shell sẽ ghi nhật ký mọi thứ bạn quan tâm trên máy chủ của bạn" - nhưng lý do những câu trả lời đó không tồn tại là vì, mọi tình huống đều khác nhau vì vậy không thể đưa ra câu trả lời "một kích thước vừa vặn nhất".

Tại nơi tôi thừa nhận, nơi chúng tôi làm việc, chúng tôi có cả một nhóm người chỉ dành riêng cho việc ghi nhật ký hệ thống - chưa kể các nhóm quản trị viên và bảo mật khác nhau đóng góp. Đây không phải là một chủ đề nhỏ. : /

11
dannysauer