企业官网建设流程全解析

很多运维和安全从业者接到Linux主机安全加固任务时，第一反应往往是上Agent、部署HIDS（主机入侵检测系统）。但在Agent覆盖不到、内网隔离、或者需要给重保前的机器快速做一轮基线核查时，最朴素也最可靠的两样东西就是AIDE和Rkhunter——一个管文件完整性，一个管系统后门。这篇文章不是简单介绍工具，而是想把我从搭建环境、写策略到处理误报警告的完整过程整理出来，从原理到配置、从部署到排错，起码让你拿到以后能直接照做。

这套组合非常适合这么几类人：刚接手服务器资产清单的运维新人，需要满足合规检查项的安全工程师，以及被要求“自查一遍”但又不想装一堆额外组件的实战派。只要你能拿到root权限、能用包管理器装软件，剩下的就是策略设计和日常维护的事。

1. 为什么要在Linux服务器上同时装AIDE和Rkhunter

1.1 AIDE和Rkhunter各自管什么

AIDE（Advanced Intrusion Detection Environment）是文件完整性校验工具，核心逻辑就一句话：给系统里的关键文件拍一张“身份证照片”，记录哈希值、权限、属主、文件大小、inode等属性，之后定期复查，一旦有文件被改动、替换或篡改，立刻告诉你哪里变了。Rkhunter（Rootkit Hunter）则是系统级后门扫描器，它通过对比二进制命令的哈希值、检查内核模块、隐藏文件、启动项、网络端口、特权进程等，尝试找出已经植入系统的Rootkit和后门程序。

两者不是替代关系。AIDE更像守门员，关注“正在发生的变化”；Rkhunter更像体检医生，关注“系统中是否有已知病灶”。一个管静态状态，一个管动态进程，放在一起才能把主机安全的覆盖面拉完整。

1.2 二者如何配合，关键在“时间维度”

AIDE的核心是基线对比，所以它特别依赖“第一次建立的数据库是否干净”。如果一台机器已经被入侵，你才装AIDE做快照，那等于为被篡改过得文件背书，后面每次扫描都会通过。Rkhunter则不需要基线，它靠的是规则库和已知特征库，装完以后立刻可以查，更擅长发现“系统层面已经被动过手脚”的问题。

我在实际部署中的做法很简单：新装系统或者刚完成重装时，先装Rkhunter做一轮快速体检，确认没有异常项；然后更新软件包、打好补丁，再装AIDE做基线初始化。这样AIDE的数据库是干净可靠的，后续所有告警才有意义。

1.3 这类工具在真实环境中的定位

别指望AIDE和Rkhunter能替代商业化HIDS。它们没有云端关联分析、没有实时拦截能力，连扫描都要靠cron定时触发。但它们有不可替代的优势：完全开源、不依赖外网、不引入额外 agent、对系统性能影响极低，特别适合内网隔离的离线环境。

很多等保测评项里都要求“应对重要服务器建立文件完整性监控”，AIDE就是最直接的落地证据；重保前扫描“是否存在后门、rootkit”，Rkhunter出的告警日志和检测报告就是安全自查的原始记录。我甚至见过一些应急响应场景中，分析人员第一时间就是跑一遍Rkhunter，再结合AIDE的数据库比对结果确认被篡改文件的范围。

2. AIDE：文件完整性校验的实操手册

2.1 AIDE原理与数据库机制

AIDE的机制可以理解为“快照比对”。它首次扫描指定的目录和文件，把每个文件的属性计算出来存进数据库，后续再扫描时重新计算并和数据库对比。重点在于它支持的属性维度很多：

• 权限（permissions）
• 属主和属组（owner、group）
• 文件类型（type）
• 文件大小（size）
• 关键哈希值：md5、sha1、sha256、sha512
• inode号、链接数、硬链接信息
• 扩展属性、ACL、SELinux上下文等

这意味着AIDE不仅能发现文件内容变化，连权限被悄悄放大的操作也能抓到。默认配置里通常用sha256+rmd160的组合，或者只选sha512，这类变更是需要评估的。

注意：AIDE数据库一旦生成，它的位置本身也是攻击者可能篡改的目标。默认路径是/var/lib/aide/aide.db.gz，最好把它放到独立挂载点并设置只读权限，再配合文件系统层面的保护。至少也要把数据库所在目录的写权限收紧。

2.2 配置文件的语法与规则设计

AIDE的主配置文件是/etc/aide.conf，语法核心是“规则名 = 属性列表”和“路径 = 规则名”。我们可以先定义一组通用规则，再对特殊目录单独覆盖。

我常用的规则设计逻辑是：

# 核心规则：内容、权限、属主、大小都要记录 CoreRules = p+i+n+u+g+s+m+c+sha256 # 只检查是否存在和权限，不关心内容变化 LogRules = p+i+n+u+g

然后对目录进行分组，例如：

/bin CoreRules /sbin CoreRules /etc CoreRules /usr/bin CoreRules /usr/sbin CoreRules /usr/local/bin CoreRules /var/log LogRules !/var/log/.*\.log$

!前缀表示排除。/var/log这种高频变化目录只监控权限和属主，不校验内容，否则每次日志轮转都会把你淹没在告警里。对于动态目录，比如/tmp、/var/tmp、/run，原则上不纳入AIDE。原因很直接：正常运行时这些目录变化极频繁，监控它们等于自找误报。

配置里还有几个容易被忽略的“隐藏开关”：

• database_out：数据库输出路径，初始化时生效。
• database_new：生成的新数据库，配合更新时使用。
• report_url：告警报告输出位置，可以是文件、标准输出或邮件。
• warn_deletes：是否对文件删除告警，我一般开启。
• changed_attributes：决定哪些属性变化需要报告，可自定义。

2.3 初始化数据库与日常检查

配置文件写完后，先做一次语法检查：

aide -V

然后初始化数据库：

aide -i

参数-i就是init。初始化后生成的默认文件是/var/lib/aide/aide.db.new.gz，需要手动重命名：

mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

日常检查使用：

aide --check

每次检查的结果会写入/var/log/aide/aide.log，如果发现差异，日志里会具体列出哪个文件变了、哪些属性变了。比如正文风格如下：

File: /etc/passwd Size : 1023 | 1019 Mtime : 2024-11-12 10:30:21 | 2024-11-12 09:15:00 SHA256 : xXXX | yYYY

看到这类输出，先别急着重启服务。先确认这个改动是不是我们人为操作的产物，比如正常添加用户、修改密码、重装软件包，都会导致/etc下内容变化。确认无问题后再更新数据库：

aide -u

这个命令会基于当前文件状态生成新的数据库，覆盖旧版本。注意：更新数据库等同于“接受当前状态为合法”，如果机器已经被入侵，这步操作就等于替攻击者背书，一定要在确认安全的前提下执行。

3. Rkhunter：系统级后门扫描的黑盒清单

3.1 Rkhunter扫描什么

Rkhunter的检查项非常多，按类别可以归成几组，我列个表方便对照它的扫描过程。

每次Rkhunter检查完毕，日志写到/var/log/rkhunter.log，报告写到/var/log/rkhunter.log的尾部。它还会发送邮件告警，前提是配置好MAILON和邮件命令。

3.2 配置文件与白名单管理

Rkhunter的主配置是/etc/rkhunter.conf，实际使用中我会把自定义配置写到/etc/rkhunter.conf.local，这样系统升级时不会覆盖掉自己的白名单设置。

比较关键的几个配置项：

# 使root用户邮件告警 MAILON=warning MAIL_CMD=mail -s "[rkhunter] Warning: ${HOSTNAME}" # 允许的隐藏目录，按"目录:所属包"的格式 ALLOWHIDDENDIR=/etc/.git:systemd ALLOWHIDDENFILE=/usr/share/.keep:package # 允许的异常文件属性，例如某些二进制正常带特定位 ALLOW_SSH_PROT_V1=0 # 跳过某些扫描项 DISABLE_TESTS=hidden_procs

其中ALLOWHIDDENDIR和ALLOWHIDDENFILE是降低误报的关键。默认情况下Rkhunter会把少见但正常的隐藏目录、隐藏文件也报出来，比如某些软件会在/usr/share下创建点开头的目录，还有systemd相关的临时目录。这类告警直接排查后，如果确认无恶意行为，就把路径加进对应的ALLOW配置。

配置文件更新后，建议先跑一次属性更新：

rkhunter --propupd

这条命令的作用是更新系统命令的哈希数据库。绝大多数“系统命令哈希警告”都源于系统升级或安全加固后补丁替换了二进制文件，这时候不是被入侵，而是基线过期，执行--propupd之后告警就会消失。

3.3 从日志中读懂告警

Rkhunter的告警级别分三类：

• info：普通信息，不一定是问题。
• warning：建议核查，通常是文件属性变化或可疑配置。
• error：明确发现问题，比如检查项执行失败或发现可疑进程。

我在日志里最常见的是两类：

第一类是“System command has been changed”，这种告警几乎每次都吓到新人。展开日志可以看到类似：

Warning: The command /usr/bin/ldd has been replaced by a script

这往往是软件包升级带来的正常结果，运行rkhunter --propupd就能解决。第二类是“Suspicious file in hidden directory”，比如：

Warning: Hidden directory found: /usr/share/.javaws

需要人工判断这个目录是否属于正常软件留下的。排查思路是先看包管理器的文件列表：

rpm -qf /usr/share/.javaws

能查到归属就是正常的，查不到又出现在可疑位置，就要提高警惕。

4. 完整部署实战：结合cron与日志平台

4.1 安装与基础配置

在主流发行版上，安装很简单：

# Debian/Ubuntu apt install aide rkhunter # RHEL/CentOS（EPEL源） yum install aide -y yum install rkhunter -y

安装完成后，先别急着跑。AIDE要结合自己的目录清单配置策略；Rkhunter要先更新数据库：

rkhunter --update rkhunter --propupd

--update是将特征库更新到最新，--propupd是建立命令哈希基线。这两个命令要在系统干净的情况下执行。

然后建立一个基础巡检目录结构：

mkdir -p /opt/security/{scripts,logs,reports}

把所有脚本放到/opt/security/scripts下，日志和报告分开存放，方便日志平台采集。

4.2 建立定时任务

AIDE扫描和Rkhunter扫描的频率，我个人的经验是：重保期间一天两到四次，平时一天一次。全盘扫描AIDE在高配机器上也就几分钟，但旧机器上会有些吃力，所以可以拆开做。

创建巡检脚本，内容风格大致如下：

#!/bin/bash # /opt/security/scripts/security_daily_check.sh DATE=$(date +%Y%m%d) AIDE_LOG=/opt/security/logs/aide_${DATE}.log RKH_LOG=/opt/security/logs/rkhunter_${DATE}.log REPORT=/opt/security/reports/report_${DATE}.txt # 1. AIDE检查 /usr/sbin/aide --check > ${AIDE_LOG} 2>&1 if [ $? -ne 0 ]; then echo "[AIDE] 发现差异，详见 ${AIDE_LOG}" >> ${REPORT} fi # 2. Rkhunter检查 /usr/sbin/rkhunter --check --skip-keypress > ${RKH_LOG} 2>&1 if [ $? -ne 0 ]; then echo "[Rkhunter] 发现告警，详见 ${RKH_LOG}" >> ${REPORT} fi # 3. 报告发送 if [ -s ${REPORT} ]; then mail -s "[Security] Daily Report $(hostname)" admin@example.com < ${REPORT} fi

注意Rkhunter的--skip-keypress参数非常关键。交互模式下每按一次回车才能继续，脚本里不加这个参数会卡死。之后写入crontab：

0 3 * * * /opt/security/scripts/security_daily_check.sh >/dev/null 2>&1

凌晨3点跑，是考虑到这个时间段业务低峰，文件变化最少，误报概率也最低。如果夜间有备份任务或日志轮转，就把时间错开，比如备份是凌晨2点，cron就排到凌晨4点。

另外，AIDE的“扫描前先做预处理”这个习惯很重要。比如日志清理、软件包安装这类操作尽量集中在固定窗口期，在跑扫描之前确保文件系统稳定，否则一堆半更新状态下的差异会形成脏基线。

4.3 告警输出与SIEM联动

日志平台集成其实不复杂，只要把/opt/security/logs下的文件输出到采集器即可。常用的做法是配置Filebeat采集：

# filebeat.yml 片段 filebeat.inputs: - type: log enabled: true paths: - /opt/security/logs/aide_*.log - /opt/security/logs/rkhunter_*.log fields: log_type: security

然后输出到Elasticsearch或Syslog服务器。但这只是收集，真正要让告警有价值，需要做规则解析。AIDE日志中的“File:”行和Rkhunter日志中的“Warning:”或“Error:”行才是关键，采集后建议在SIEM里建规则，遇到对应关键字就生成告警事件。

没有SIEM的小环境也有更朴素的方案：脚本检查后发现差异，直接调curl把告警消息推到企业微信/钉钉的Webhook。这类脚本我在生产上验证过，几行bash就够用：

send_alert() { local msg="$1" curl -s -H 'Content-Type: application/json' \ -d "{\"msgtype\":\"text\",\"text\":{\"content\":\"$msg\"}}" \ "$WEBHOOK_URL" >/dev/null }

对我来说，邮件告警和Webhook告警的区别在于：邮件适合退居二线做证据存档，Webhook适合第一时间找运维负责人。

5. 常见问题与排查技巧实录

5.1 AIDE误报

AIDE最常见的误报来源是“数据库过期”。比如你昨天跑完巡检，今天上午运维同事改了/etc/nginx/conf.d下某个配置，下午AIDE就跑出新告警。这不是误报，是真实变化，但通常在预期内。处理流程是：

1. 检查变化文件列表。
2. 问清楚是谁改的、改的目的是什么。
3. 确认变更合规后执行aide -u更新数据库。

还有一种容易踩的坑是AIDE把数据库本身也纳入监控。默认配置中/var/lib/aide路径经常被包含进去，当你aide -u更新完数据库后，下次扫描会发现“数据库又变了”，形成无限循环告警。解决办法是/var/lib/aide放到排除列表，或者单独用一个规则只监控目录权限，不监控内容。

配置示例：

/var/lib/aide$ LogRules

注意$表示精确匹配，不带它可能会匹配到子目录，把自己坑到。

5.2 Rkhunter误报

Rkhunter误报里头号选手是“系统命令哈希变化”。这类告警大多数是包管理器升级导致，特别是内核版本升级后，内核模块路径也会变，Rkhunter会把新的模块文件再报一遍。解决方式就是：

rkhunter --propupd

第二类常见误报是隐藏文件。装了某些商业软件或监控客户端的机器，经常在/usr/share、/opt下留下隐藏文件和隐藏目录。这时候不要盲目删除，先看包归属：

rpm -qf /path/to/file dpkg -S /path/to/file

能查到归属就加入ALLOWHIDDENDIR或ALLOWHIDDENFILE。查不到的再结合文件时间、内容特征判断，必要时现场取证。

5.3 减少误报的整理策略

误报太多就会让人麻木，最后变成“见怪不怪”，这才是安全体系失效的开端。我对付误报的办法是分三层：

• 规则层：能在配置里排除的就排除，比如AIDE的!排除、Rkhunter的ALLOW*配置。
• 流程层：把“变更管理”纳入巡检，白天有人改配置、装软件时，在变更记录里提前标注，晚上巡检看到差异就知道是预期内的。
• 响应层：定义告警等级，比如AIDE的权限类变化直接高优先级，内容类变化若发生在/etc、/usr/bin等核心目录也要高优先级，但日志类目录变化降级为提示。

有一个方法我很推荐：首次部署AIDE后，先摸清这台设备在业务运行时的“变化节奏”，连续观察一周，把每天产生的差异都记录下来，然后针对每条差异做处置，要么改配置排除、要么确认合法。这一周花的时间，换来的是后面几个月不被打扰的清爽告警，值。

6. 个人实操心得与工具边界

AIDE和Rkhunter这对组合，我用下来的感觉是：它们不是“装完就完事”的工具，更像是一套需要持续维护的安全基线。AIDE的数据库维护、Rkhunter的特征库更新、白名单的补充，每一个环节都需要跟随业务状态调整，否则就是一台会报错但没人看的机器。

有几个建议供参考：

• 新装机器第一时间先跑Rkhunter，再装AIDE，顺序不要反。确保基线文件干净是AIDE信任体系的前提。
• 每次系统升级、内核调整、批量部署脚本执行后，记得评估是否需要重新跑rkhunter --propupd。及时更新基线能避免一大半误报。
• AIDE的数据库位置、Rkhunter的日志文件位置，最好都通过脚本定期备份到独立的审计存储中，防止本地丢日志后无法取证。
• 定期换一种思路去验证这套机制本身：手动改一个测试文件，等扫描后看告警有没有出来。不要让“巡检脚本跑了”变成一句空话，安全工具最怕的就是形同虚设。

最后分享一个小经验：我在实际使用中总是把告警“阈值”想清楚再上生产。第一次部署时宁可告警多，也不要遗漏；跑两周之后，再逐步收紧白名单和排除规则。等到告警确实变少且每条都能解释时，这套巡检才算真正能在团队里信任起来。希望这篇经验能帮你少踩几个坑，快速在自己负责的机器上把AIDE和Rkhunter用明白。