自动化运维技巧——使用saltstack一键部署Linux auditd主机系统安全服务

关于运维自动化

运维自动化更多地是一种指导思想，而不仅仅是几个可以提供远程执行管理命令功能的工具。理想的自动化运维的管理功能，最好是不需要过多的人为干预，可以自动识别主机硬件和系统软件环境条件，然后自动化地做出正确判断和处理操作。

我最近刚刚整理了一份Linux audit主机系统安全服务的配置方案，然后使用saltstack编写了一个可以提供幂等执行的自动化服务部署模块，在这里分享给大家，希望能给大家带去一点启发。

主机安全审计与部署管理的需求

信息安全等级保护认证是我们国内从事计算机软硬件及网络服务行业的IT人，绕不开的一个关卡。目前稍有些影响的计算机系统或网络都要求符合等保三级起步了，做到等保四级标准的也不少见。

关于主机安全审计需求

下图是摘取的等保测评标准2.0中关于安全计算环境——安全审计的测评项要求。针对以上4个安全审计的测评项，我们的解决方案大概是这样：

• 基于Linux Audit服务设计一套主机安全审计策略规则，满足测评项1和测评项2的要求；
• 基于Linux Rsyslog服务，ElasticSearch服务，设计一套采集审计日志记录并集中存储到统一的日志平台的方案，满足测评项3的要求；
• 在Audit审核规则中启动-e 2的配置参数，在这样设置后，任何针对audit服务或配置的变更，都必须重启主机操作才能生效，这样就满足了测评项4的要求。

关于自动化部署需求

1. 支持一键自动化部署从软件包安装、配置审核规则、配置日志采集策略以及重载配置或重启程序的全套服务；
2. 支持幂等执行，可以单独执行，也可以支持集成到其它管理模块中使用，如系统初始化模块；
3. 如果同时有多种主机设备、多种操作系统，需要可以支持按设备号、操作系统版本采取相应的配置策略。

在本文中，我只是基于centos7进行了设计与验证测试，并没有考虑上述第3点需求。如有需求，也是很容易兼容这点的。

功能模块的开发

模块主配置文件

我们是使用saltstack实现的以下配置定义和服务编排管理。参照这个自动化运维的思想，大家同样也可以选择使用其它工具软件做实现。
saltstack在处理系统配置、软件配置以及配置依赖、服务依赖管理方面，功能丰富，也比较灵活。

如果你对saltstack有些了解的话，在salt master服务主机上创建一个/srv/salt/audit目录，作为我们在这里使用的主机安全审计管理模块。

mkdir -p /srv/salt/audit
touch /srv/salt/audit/init.sls

• 创建模块主配置文件init.sls，并编写下面的配置内容。

# 1.安装和运行linux audit软件，设置为自启动
check and install auditd tool:
  pkg.installed:
    - name: audit
  service.running:
    - name: auditd
    - enable: True

# 2.部署用户自定义的audit审核规则
user designed auditd config file:
  file.managed:
    - name: /etc/audit/rules.d/audit.rules
    - source: salt://audit/audit.rules
    - mode: 600
    - user: root
    - group: root

# 3.监视子模块2，当有配置规则变化时自动地执行重启auditd服务的命令。这里有一点需要注意的是，由于auditd服务的特殊性是不能使用systemctl关停或重启auditd服务的。
check and reload auditd service:
  cmd.wait:
    - name: service auditd restart
    - watch:
      - file: user designed auditd config file

# 4.调优rsyslog主配置文件中的日志打印选项，主要是屏蔽了将审计日志输出到/var/log/message中。audit有自己的日志文件，且日志量较多，输出到message中会对其它系统日志记录产生干扰。
rsyslog main configuration file:
  file.replace:
    - name: /etc/rsyslog.conf
    - pattern: '^\*\.info;mail\.none;authpriv\.none;cron\.none */var/log/messages$'
    - repl: '*.info;mail.none;authpriv.none;cron.none;local6.none                /var/log/messages'
    - ignore_if_missing: True

# 5.使用rsyslog来收集audit日志数据
rsyslog audit log config file:
  file.managed:
    - name: /etc/rsyslog.d/audit_log.conf
    - source: salt://audit/audit_log.conf
    - mode: 644
    - user: root
    - group: root

#6.监视子模块4和子模块5，当这两个配置文件的内容有变化时即重新加载rsyslog服务的配置。
check and reload rsyslog service:
  service.running:
    - name: rsyslog
    - watch:
      - file: rsyslog audit log config file
      - file: rsyslog main configuration file

收集audit日志的rsyslog用户配置文件

/etc/rsyslog.d/audit_log.conf

# audit log
$ModLoad imfile
$InputFileName /var/log/audit/audit.log
$InputFileTag tag_audit_log:
$InputFileStateFile audit_log
$InputFileSeverity info
$InputFileFacility local6
$InputRunFileMonitor

用户自定义的audit主机安全审核规则

/etc/audit/rules.d/audit.rules

## First rule - delete all
-D

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

## Set failure mode to syslog
-f 1

-c

# log messages rate limit,100 messages per second at most.
-r 100

## Make the loginuid immutable. This prevents tampering with the auid.
--loginuid-immutable

# This prevents chrony from overwhelming the logs
-a never,exit -F arch=x86_64 -S adjtimex -F auid=unset -F uid=chrony -F subj_type=chronyd_t

## If you are on a 64 bit platform, everything _should_ be running
## in 64 bit mode. This rule will detect any use of the 32 bit syscalls
## because this might be a sign of someone exploiting a hole in the 32
## bit API.
-a always,exit -F arch=b32 -S all -F key=32bit-abi

## This rule suppresses the time-change event when chrony does time updates
-a never,exit -F arch=b64 -S adjtimex -F auid=unset -Fuid=chrony -F subj_type=chronyd_t

# This rule supresses events that originate on the below file systems.
# Typically you would use this in conjunction with rules to monitor
# kernel modules. The filesystem listed are known to cause hundreds of
# path records during kernel module load. As an aside, if you do see the
# tracefs or debugfs module load and this is a production system, you really
# should look into why its getting loaded and prevent it if possible.
-a never,filesystem -F fstype=tracefs
-a never,filesystem -F fstype=debugfs

## Things that could affect time
-w /etc/localtime -p wa -k time-change

## Things that could affect system locale
-a always,exit -F arch=b64 -S sethostname,setdomainname -F key=system-locale
-w /etc/issue -p wa -k system-locale
-w /etc/issue.net -p wa -k system-locale
-w /etc/hosts -p wa -k system-locale
-w /etc/hostname -p wa -k system-locale
-w /etc/sysconfig/network -p wa -k system-locale
-a always,exit -F dir=/etc/NetworkManager/ -F perm=wa -F key=system-locale

## Audit 1, 1(b) Successful and unsuccessful logons and logoffs.
## This is covered by patches to login, gdm, and openssh
## Might also want to watch these files if needing extra information
-w /var/log/tallylog -p wa -k logins
-w /var/run/faillock/ -p wa -k logins
-w /var/log/lastlog -p wa -k logins
-w /var/log/btmp -p wa -k logins
-w /var/run/utmp -p wa -k logins

## unsuccessful creation
-a always,exit -F arch=b64 -S mkdir,creat,link,symlink,mknod,mknodat,linkat,symlinkat -F exit=-EACCES -F key=creation
-a always,exit -F arch=b64 -S mkdir,link,symlink,mkdirat -F exit=-EPERM -F key=creation

## unsuccessful open
-a always,exit -F arch=b64 -S open,openat,open_by_handle_at -F exit=-EACCES -F key=open
-a always,exit -F arch=b64 -S open,openat,open_by_handle_at -F exit=-EPERM -F key=open

## unsuccessful close
-a always,exit -F arch=b64 -S close -F exit=-EIO -F key=close

## unsuccessful modifications
-a always,exit -F arch=b64 -S rename -S renameat -S truncate -S chmod -S setxattr -S lsetxattr -S removexattr -S lremovexattr -F exit=-EACCES -F key=mods
-a always,exit -F arch=b64 -S rename -S renameat -S truncate -S chmod -S setxattr -S lsetxattr -S removexattr -S lremovexattr -F exit=-EPERM -F key=mods

## unsuccessful deletion
-a always,exit -F arch=b64 -S rmdir,unlink,unlinkat -F exit=-EACCES -F key=delete
-a always,exit -F arch=b64 -S rmdir,unlink,unlinkat -F exit=-EPERM -F key=delete

## Unsuccessful ownership change
-a always,exit -F arch=b64 -S lchown,fchown,chown,fchownat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccesful-perm-change
-a always,exit -F arch=b64 -S lchown,fchown,chown,fchownat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccesful-perm-change

## Audit 1, 1(d) Changes in user authenticators.
## Covered by patches to libpam, passwd, and shadow-utils
## Might also want to watch these files for changes
-w /etc/group -p wa -k auth
-w /etc/passwd -p wa -k auth
-w /etc/gshadow -p wa -k auth
-w /etc/shadow -p wa -k auth
-w /etc/security/opasswd -p wa -k auth

## Group add delete modify. This is covered by pam. However, someone could
## open a file and directly create or modify a user, so we'll watch group and
## gshadow for writes
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&03 -F path=/etc/group -F auid>=1000 -F auid!=unset -F key=group-modify
-a always,exit -F arch=b64 -S open -F a1&03 -F path=/etc/group -F auid>=1000 -F auid!=unset -F key=group-modify
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&03 -F path=/etc/gshadow -F auid>=1000 -F auid!=unset -F key=group-modify
-a always,exit -F arch=b64 -S open -F a1&03 -F path=/etc/gshadow -F auid>=1000 -F auid!=unset -F key=group-modify

## Use of special rights for config changes. This would be use of setuid
## programs that relate to user accts. This is not all setuid apps because
## requirements are only for ones that affect system configuration.
-a always,exit -F path=/usr/bin/chfn -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
-a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
-a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
-a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
-a always,exit -F path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
-a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
-a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
-a always,exit -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
-a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
-a always,exit -F path=/usr/bin/pkexec -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
-a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
-a always,exit -F path=/usr/sbin/pam_timestamp_check -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
-a always,exit -F path=/usr/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
-a always,exit -F path=/usr/sbin/usernetctl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
-a always,exit -F path=/usr/sbin/mtr -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
-a always,exit -F path=/usr/sbin/lsof -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
-a always,exit -F path=/usr/sbin/tcpdump -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

## Things that could affect MAC policy
-a always,exit -F dir=/etc/selinux/ -F perm=wa -F key=MAC-policy

## 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/ -p wa -k cron

## Look for pam_tty_audit and add it to your login entry point's pam configs.
## If that is not found, use sudo which should be patched to record its
## commands to the audit system. Do not allow unrestricted root shells or
## sudo cannot record the action.
-w /etc/sudoers -p wa -k actions
-w /etc/sudoers.d/ -p wa -k actions

## The purpose of this rule is to detect when an admin may be abusing power
## by looking in user's home dir.
-a always,exit -F dir=/home -F uid=0 -F auid>=1000 -F auid!=unset -C auid!=obj_uid -F key=power-abuse

## These rules watch for code injection by the ptrace facility.
## This could indicate someone trying to do something bad or
## just debugging
-a always,exit -F arch=b64 -S ptrace -F key=tracing
-a always,exit -F arch=b64 -S ptrace -F a0=0x4 -F key=code-injection
-a always,exit -F arch=b64 -S ptrace -F a0=0x5 -F key=data-injection
-a always,exit -F arch=b64 -S ptrace -F a0=0x6 -F key=register-injection

## These rules watch for kernel module insertion. By monitoring
## the syscall, we do not need any watches on programs.
-a always,exit -F arch=b64 -S init_module,finit_module -F key=module-load
-a always,exit -F arch=b64 -S delete_module -F key=module-unload

## SSH configuration
-w /etc/ssh/sshd_config -p wa -k sshd

## root ssh key tampering
-w /root/.ssh -p wa -k rootkey

# Systemd
-w /bin/systemctl -p x -k systemd
-w /etc/systemd/ -p wa -k systemd

## Shell/profile configurations
-w /etc/profile.d/ -p wa -k shell_profiles
-w /etc/profile -p wa -k shell_profiles
-w /etc/shells -p wa -k shell_profiles
-w /etc/bashrc -p wa -k shell_profiles
-w /etc/csh.cshrc -p wa -k shell_profiles
-w /etc/csh.login -p wa -k shell_profiles
-w /etc/fish/ -p wa -k shell_profiles
-w /etc/zsh/ -p wa -k shell_profiles

## 排除一些干扰性过强的消息
-a always,exclude -F msgtype=USER_START
-a always,exclude -F msgtype=CRED_REFR
-a always,exclude -F msgtype=CRED_ACQ
-a always,exclude -F msgtype=USER_ACCT
-a always,exclude -F msgtype=USER_END
-a always,exclude -F msgtype=CRED_DISP
-a always,exclude -F msgtype=LOGIN
-a always,exclude -F msgtype=PROCTITLE
## Ignore current working directory records
-a always,exclude -F msgtype=CWD
## Cron jobs fill the logs with stuff we normally don't want (works with SELinux)
-a never,user -F subj_type=crond_t
-a never,exit -F subj_type=crond_t
## This is not very interesting and wastes a lot of space if the server is public facing
-a always,exclude -F msgtype=CRYPTO_KEY_USER

## FileBeat 
#-a never,exit -F arch=b64 -F path=/opt/filebeat -k filebeat

## This is to check if the system is making or recieving connections
## externally
#-a always,exit -F arch=b64 -S accept,connect -F key=external-access

## Make the configuration immutable - reboot is required to change audit rules
#-e 2

## 在audit.log文件中保存的时间格式是自1970年以来的秒数，可以用下面方法转成容易理解的日期时间,audit(1364481363.243:24287)
## date --date=@1364481363.243

在上面配置文件中，参数-e 2在确定不会再修改审核规则前，不要启用这个参数。启用后，针对audit服务的任何变更，就都需要重启操作系统才可以生效了。

功能模块的验证

找一个有部署了salt-minion工具且接入了salt master服务管理的测试机，执行下面的命令，一键部署主机安全审计管理模块的服务：

sudo salt-call state.apply audit

或者是在salt master主机上执行下面的命令：

sudo salt test-server-name state.apply audit

第一次执行部署命令时，会有很多配置文件内容增减变更的变化，也有服务重载的操作。
建议反复执行几次对比看，在后续重复执行该部署命令时就不会再有配置或服务的变更操作了，因为已处于了一致状态。

我们做配置管理时很重要的一个思想就是，希望随时可以保持配置文件、服务程序运行状态跟期望目标一致。如果存在局部不一致的地方，则进行变更以达到一致性。如果业务机的配置状态和我们的管理期望之间不存在差异，就仅做个状态检查而已。

将分散在各主机上的日志数据汇聚到ElasticSearch平台有很多技术方案，可以参考网上其它资料，我们在这里就不讨论了。