超级会员免费看
系统完整性检查与审计工具全解析
1. 完整性检查的重要性与局限性
在系统管理中，完整性检查是保障系统安全和稳定的重要手段。虽然某些形式的完整性检查可能会被攻击绕过，但有检查总比没有要好。它能帮助管理员及时发现系统文件的异常变化，无论是恶意攻击导致的篡改，还是因硬件故障、软件漏洞引起的数据损坏。
2. Linux 下使用 RPM 进行完整性检查
RPM（RPM Package Manager）系统为检查已安装软件包的文件与系统包数据库的一致性提供了机制。
-
RPM 包的构成
：一个 RPM 包包含特定应用所需的所有文件、安装程序和加密校验和。安装后，包的相关信息（包括文件校验和）会存储在系统数据库中。
-
检查命令
：使用以下命令可以检查
autorpm
包的完整性，并报告与系统数据库的差异：
# rpm -V autorpm
S.5....T c /etc/autorpm.d/redhat-updates.conf
输出的每行表示数据库中记录与实际文件有变化的文件。例如，
/etc/autorpm.d/redhat-updates.conf
文件的大小（S）、MD5 校验和（5）和修改时间（T）与预期不同，因为该配置文件（由
c
表示）已从安装状态被编辑。此命令还会检查文件模式、设备文件的设备号、链接路径以及用户/组所有权。使用
rpm -Va
命令可以检查所有已安装 RPM 包的所有文件。
-
数据库的安全性
：要使
rpm
成为有效的完整性检查工具，必须确保系统包数据库未被篡改。该数据库通常是存储在
/var/lib/rpm
中的一组 Berkeley DB 文件。可以使用之前讨论的技术来验证数据库的完整性，例如将其复制到只读介质或生成 DB 文件的加密签名。
-
局限性
：RPM 包数据库不包含未通过
rpm
安装的软件信息，因此对于大多数系统来说，它不是一个完整的解决方案。例如，如果自定义编译内核且未将其打包为 RPM 包，那么该内核文件的完整性将无法通过 RPM 检查。不过，它易于使用，对于使用 RPM 的系统来说是一个很好的起点，也是提供深度防御的一种方式。
3. BSD 系统中使用 pkg_info 命令进行完整性检查
BSD 的
pkg
（包）系统与 RPM 系统在原理上类似。
-
包的构成
：一个包至少包含文件列表和对其他包的依赖关系。包可以以二进制代码形式下载并安装，也可以从源代码编译安装。
-
pkg_info
命令的功能
：
-
pkg_info
命令列出系统上当前安装的所有包。可以通过选项列出指定包中的所有文件。
- 也可以指定一个文件，该命令会报告是哪个包负责安装该文件。
- 当使用
-g
选项时，该命令会将已安装文件的校验和与包数据库中的校验和进行比较，并报告校验和不匹配的文件。
-
局限性
：
pkg_info
命令对于检查从“ports”目录安装或作为包安装的子系统的一致性很有用，但它无法检查底层操作系统的完整性，因为基础操作系统不是通过包安装的。
4. Tripwire 完整性检查工具
4.1 Tripwire 的需求背景
之前提到的生成文件属性和消息摘要列表的方法存在一些问题。我们并非需要每个文件的所有信息，例如，我们关心
/etc/passwd
文件的所有者或保护模式是否改变，但不关心其大小或校验和，因为其内容会正常变化；而对于
/bin/login
文件，我们非常关注其内容是否被篡改。此外，我们希望能够使用不同的消息摘要算法，在某些情况下，即使比较耗时，也希望使用三种强大的算法，因为其中一种算法可能很快会被破解；在其他环境中，结合其他方法使用快速但安全性较低的算法可能就足够了。
4.2 Tripwire 的特点
Tripwire 是由 Gene Kim 和 Gene Spafford 在普渡大学开发的程序，可在大多数主要版本的 Unix（以及一些不太常见的版本）上运行。它读取一个配置文件，该文件指定了要监控的文件和目录，然后跟踪 inode 信息和内容的变化。其数据库具有高度可配置性，允许管理员指定要监控的特定属性以及每个文件使用的特定消息摘要算法。
4.3 Tripwire 的商业化与开源版本
Tripwire 已由 Tripwire, Inc. 商业化，该公司由 Gene Kim 和 W. Wyatt Starnes 创立。该公司为该程序创建了管理控制台，将其移植到 Windows，并为网络设备（如交换机、路由器和防火墙）创建了专门版本。其商业产品信息可在 http://www.tripwire.com 上查询。
除了商业版本，该公司还负责“Open Tripwire”的开发，这是一个遵循 GNU 公共许可证（GPL）的免费版本，相关信息可在 http://www.tripwire.org 上找到。另一个具有类似功能且遵循 GPL 的替代工具是 AIDE，其信息可在 http://www.cs.tut.fi/~rammer/aide.html 上查询。
4.4 构建 Tripwire
构建 Tripwire 包需要遵循以下步骤：
1.
下载
：从 Tripwire, Inc. 下载副本。如果使用 BSD 系统，可以从
/usr/ports/security/tripwire
目录构建。如果需要，可以验证源代码的数字签名。某些 Linux 发行版也提供 RPM 包。
2.
阅读文档
：阅读发行版中的所有 README 文件，确保理解其中讨论的主题。特别注意根据本地情况进行定制的细节，包括适应本地操作系统。按照提供的说明编译和安装程序。
3.
创建策略文件
：Tripwire 附带一个基本策略文件，可能满足你的需求，但可能需要进行一些自定义。例如，如果未在
/usr/local/krb5
目录安装 Kerberos 5 系统，可以从 Tripwire 配置文件中删除相关行，否则每次运行 Tripwire 时都会出现无法打开这些目录的错误。如果有适用于你操作系统的 Tripwire 策略文件，可以将其作为起点。
4.
安装策略文件
：创建策略文件后，需要安装它。这个过程包括为你的站点创建 Tripwire 密钥、为你的系统创建 Tripwire 密钥、从策略文件创建配置文件，最后让 Tripwire 对系统进行初始扫描。所有这些过程都由 Tripwire 的安装脚本自动执行，你应尽可能遵循这些步骤。
5.
保护文件
：最后，你可以将 Tripwire 的二进制文件和配置文件复制到受保护的目录，该目录通常位于只读存储设备上。这样可以增加在系统被入侵时仍能使用 Tripwire 确定哪些文件被更改的可能性。
一般来说，最好在已知干净的系统上安装 Tripwire，理想情况下是重新安装过软件的系统。但在实际操作中，这并不总是可行的，管理员需谨慎操作。
4.5 运行 Tripwire
定期从受保护的版本运行 Tripwire 以检查文件变化。除了使用 cron 定时任务，还应偶尔手动运行，以确保 Tripwire 实际运行并查看输出结果。
以下是一个 Tripwire 运行的示例输出：
r2# tripwire --check
Parsing policy file: /usr/local/etc/tripwire/tw.pol
*** Processing Unix File System ***
Performing integrity check...
### Warning: File system error.
### Filename: /.login
### No such file or directory
### Continuing...
### Warning: File system error.
### Filename: /kernel.GENERIC
### No such file or directory
### Continuing...
Wrote report file: /var/db/tripwire/report/r2.nitroba.com-20020817-182201.twr
Tripwire(R) 2.3.0 Integrity Check Report
Report generated by: root
Report created on: Sat Aug 17 18:22:01 2002
Database last updated on: Never
=======================================================================
Report Summary:
=======================================================================
Host name: r2.nitroba.com
Host IP address: 64.7.15.234
Host ID: None
Policy file used: /usr/local/etc/tripwire/tw.pol
Configuration file used: /usr/local/etc/tripwire/tw.cfg
Database file used: /var/db/tripwire/r2.nitroba.com.twd
Command line used: tripwire --check
=======================================================================
Rule Summary:
=======================================================================
-----------------------------------------------------------------------
Section: Unix File System
-----------------------------------------------------------------------
Rule Name Severity Level Added Removed Modified
--------- -------------- ----- ------- -
Invariant Directories 66 0 0 0
Sources 100 0 0 0
Temporary directories 33 0 0 0
* Tripwire Data Files 100 1 0 0
* Local files 66 8 8 6
Tripwire Binaries 100 0 0 0
Libraries, include files, and other system files
100 0 0 0
System Administration Programs 100 0 0 0
User Utilities 100 0 0 0
X11R6 100 0 0 0
NIS 100 0 0 0
(/var/yp)
* /etc 100 0 0 2
Security Control 100 0 0 0
Root's home 100 0 0 0
FreeBSD Kernel 100 0 0 0
FreeBSD Modules 100 0 0 0
/dev 100 0 0 0
Linux Compatibility 100 0 0 0
(/compat)
Total objects scanned: 98571
Total violations found: 25
=======================================================================
Object Summary:
=======================================================================
-----------------------------------------------------------------------
# Section: Unix File System
-----------------------------------------------------------------------
-----------------------------------------------------------------------
Rule Name: Local files (/usr/local/etc)
Severity Level: 66
-----------------------------------------------------------------------
Modified:
"/usr/local/etc/mrtg"
"/usr/local/etc/mrtg/mrtg.ok"
"/usr/local/etc/postfix/prng_exch"
"/usr/local/etc/tripwire"
-----------------------------------------------------------------------
Rule Name: Local files (/usr/local/man/man5)
Severity Level: 66
-----------------------------------------------------------------------
Added:
"/usr/local/man/man5/twpolicy.5.gz"
"/usr/local/man/man5/twfiles.5.gz"
"/usr/local/man/man5/twconfig.5.gz"
Removed:
"/usr/local/man/man5/twconfig.5"
"/usr/local/man/man5/twfiles.5"
"/usr/local/man/man5/twpolicy.5"
Modified:
"/usr/local/man/man5"
-----------------------------------------------------------------------
Rule Name: Local files (/usr/local/man/man8)
Severity Level: 66
-----------------------------------------------------------------------
Added:
"/usr/local/man/man8/siggen.8.gz"
"/usr/local/man/man8/tripwire.8.gz"
"/usr/local/man/man8/twadmin.8.gz"
"/usr/local/man/man8/twintro.8.gz"
"/usr/local/man/man8/twprint.8.gz"
Removed:
"/usr/local/man/man8/siggen.8"
"/usr/local/man/man8/tripwire.8"
"/usr/local/man/man8/twadmin.8"
"/usr/local/man/man8/twintro.8"
"/usr/local/man/man8/twprint.8"
Modified:
"/usr/local/man/man8"
-----------------------------------------------------------------------
Rule Name: Tripwire Data Files (/var/db/tripwire)
Severity Level: 100
-----------------------------------------------------------------------
Added:
"/var/db/tripwire/r2.nitroba.com.twd"
-----------------------------------------------------------------------
Rule Name: /etc (/etc)
Severity Level: 100
-----------------------------------------------------------------------
Modified:
"/etc/namedb/sand/sand.PHONESWEEP.COM.bak"
"/etc/namedb/sand/sand.SANDSTORM.NET.bak"
=======================================================================
Error Report:
=======================================================================
-----------------------------------------------------------------------
Section: Unix File System
-----------------------------------------------------------------------
1. File system error.
Filename: /.login
No such file or directory
2. File system error.
Filename: /kernel.GENERIC
No such file or directory
从这个示例可以看出，Tripwire 检测到了某些文件（如 MRTG 输出文件、DNS 临时文件）的变化，以及 Tripwire 手册页被移除并替换为压缩版本的情况。
Tripwire 有许多选项，除了简单的变化检测外，还可用于其他用途。发行版中提供的文档和手册页非常详细，如需更多信息，建议查阅这些资料。
5. 完整性检查机制的关键条件
无论是使用
rdist
、比较副本、清单、RPM 还是 Tripwire，要使完整性检查机制有效工作，需要满足两个关键条件：
-
基础软件副本的可靠性
：用于比较或生成数据库的软件副本必须可靠。如果起始文件已被损坏，检查机制可能会报告与该损坏状态无变化。因此，通常应从发行介质初始化软件基础，以提供已知的良好副本用于比较。
-
软件和数据库的保护
：使用的软件和数据库必须在任何情况下都得到保护。如果入侵者在扫描间隔期间突破防御并获得 root 权限，他们可以更改程序并编辑比较副本和数据库，从而掩盖系统的其他更改。因此，应将软件和数据存储在物理保护的介质上，如写保护磁盘或可移动磁盘，通过物理保护防止数据在系统完全被入侵时被篡改。
6. 系统监控与审计的重要性
在建立系统的保护机制后，需要对其进行监控，以确保保护机制实际有效，并观察是否存在异常行为或其他问题。这个监控系统行为的过程称为监控或审计，它是深度防御策略的一部分，就像俄罗斯谚语“信任，但要验证”所说的那样。
7. Unix 系统中的常见审计方式
- 文件权限的抽查 ：对文件权限进行随机检查，确保其符合安全策略。
- Unix 日志文件的系统审查 ：日志文件记录了一个或多个日志事件，即程序作者认为值得记录的特定操作、活动或条件。
8. 日志文件的重要性
日志文件是安全系统的重要组成部分，它们形成了计算机过去的记录历史或审计轨迹，有助于管理员追踪间歇性问题或攻击。通过日志文件，管理员可以拼凑出足够的信息，发现软件漏洞的原因、入侵的来源以及受损的范围。在无法阻止损害发生的情况下，日志至少可以提供记录，这些记录可能是重建系统、进行调查、提供证词、获得保险赔偿或获得准确现场服务所必需的。
9. 计算机取证的兴起
运行中的 Unix 系统除了日志文件记录的有意信息外，还会记录其他信息，就像沙滩上会留下动物的脚印一样。近年来，计算机取证领域受到了广泛关注，它本质上是读取计算机系统中留下痕迹的艺术。通过分析这些痕迹，可以获取更多关于系统活动和潜在攻击的信息，为安全事件的调查和处理提供有力支持。
综上所述，系统完整性检查和审计是保障系统安全和稳定运行的重要手段。通过合理使用各种工具和方法，管理员可以及时发现和应对系统中的异常情况，确保系统的正常运行和数据安全。同时，随着技术的不断发展，计算机取证等新兴领域也为系统安全提供了更多的保障和支持。
系统完整性检查与审计工具全解析
10. 不同审计方式的对比分析
为了更清晰地了解不同审计方式的特点，下面通过表格进行对比：
| 审计方式 | 优点 | 缺点 | 适用场景 |
| — | — | — | — |
| 文件权限抽查 | 操作简单，能快速发现明显的权限违规问题 | 随机性大，可能遗漏部分问题；无法全面覆盖所有文件 | 日常安全巡检，快速排查明显的权限异常 |
| Unix 日志文件系统审查 | 记录详细，可提供系统历史活动的全面信息；有助于追踪问题根源 | 日志文件可能庞大，分析耗时；需要专业知识进行解读 | 深入调查安全事件、排查系统故障 |
| RPM 完整性检查 | 对使用 RPM 包管理的系统方便快捷，能有效检查已安装包的完整性 | 不包含未通过 RPM 安装的软件信息，有一定局限性 | 使用 RPM 包管理的 Linux 系统 |
| BSD pkg_info 检查 | 适用于 BSD 系统，能检查包安装子系统的一致性 | 无法检查底层操作系统的完整性 | BSD 系统中对包安装子系统的检查 |
| Tripwire | 高度可配置，能灵活监控文件属性和内容变化；提供详细报告 | 构建和配置相对复杂，对系统资源有一定要求 | 对系统安全性要求较高的环境，需要精细监控文件变化 |
11. 日志文件分析的流程
日志文件分析是一个复杂的过程，需要遵循一定的流程，以确保能够准确地发现问题。以下是一个典型的日志文件分析流程：
1.
收集日志
：从系统的各个日志源收集相关的日志文件。这可能包括系统日志、应用程序日志、安全日志等。
2.
整理日志
：对收集到的日志进行整理，去除无用信息，按照时间顺序或其他规则对日志进行排序。
3.
筛选关键信息
：根据分析的目的，筛选出与问题相关的关键信息。例如，如果要排查安全事件，可以关注登录失败记录、异常文件访问记录等。
4.
关联分析
：将筛选出的关键信息进行关联分析，找出事件之间的关联和因果关系。例如，某个用户的异常登录行为可能与后续的文件篡改事件相关。
5.
生成报告
：根据分析结果，生成详细的报告，包括问题描述、影响范围、可能的原因和建议的解决方案。
下面是该流程的 mermaid 流程图：
graph LR
A[收集日志] --> B[整理日志]
B --> C[筛选关键信息]
C --> D[关联分析]
D --> E[生成报告]
12. 计算机取证的关键技术
计算机取证涉及多种关键技术，这些技术有助于从计算机系统中提取和分析有价值的信息。以下是一些常见的计算机取证技术：
-
数据恢复技术
：当系统遭受破坏或数据被删除时，数据恢复技术可以尝试恢复丢失的数据。这可能包括从硬盘、U盘等存储设备中恢复文件。
-
文件系统分析技术
：通过对文件系统的结构和元数据进行分析，可以了解文件的创建、修改和访问历史。例如，分析文件的时间戳、权限信息等。
-
网络流量分析技术
：监控和分析网络流量可以发现异常的网络活动，如黑客的入侵尝试、数据泄露等。可以通过网络抓包工具捕获网络数据包，并进行分析。
-
内存分析技术
：内存中存储着系统运行时的关键信息，如进程信息、网络连接信息等。内存分析技术可以从内存中提取这些信息，帮助调查人员了解系统在特定时刻的状态。
13. 系统完整性检查与审计的最佳实践
为了确保系统的安全性和稳定性，在进行系统完整性检查与审计时，应遵循以下最佳实践：
-
定期检查
：制定定期的完整性检查和审计计划，确保系统的关键文件和配置信息定期得到检查。例如，每周对系统进行一次 RPM 完整性检查，每月进行一次 Tripwire 全面扫描。
-
自动化执行
：利用脚本或自动化工具来执行检查和审计任务，减少人工操作的误差和时间成本。例如，使用 cron 定时任务来定期运行 Tripwire 检查。
-
多工具结合使用
：不同的完整性检查和审计工具具有不同的特点和优势，结合使用多种工具可以更全面地保障系统安全。例如，同时使用 RPM 检查已安装包的完整性，使用 Tripwire 监控关键文件的变化。
-
及时响应
：当发现系统存在异常情况时，应及时采取措施进行处理。例如，当 Tripwire 报告文件有异常变化时，立即调查原因并采取相应的修复措施。
14. 未来发展趋势
随着信息技术的不断发展，系统完整性检查与审计领域也将面临新的挑战和机遇。以下是一些未来可能的发展趋势：
-
智能化分析
：利用人工智能和机器学习技术，实现对日志文件和系统数据的智能化分析。这些技术可以自动识别异常模式和潜在的安全威胁，提高分析效率和准确性。
-
云环境下的审计
：随着云计算的广泛应用，越来越多的企业将系统和数据迁移到云端。因此，需要开发适用于云环境的完整性检查和审计工具，确保云环境下的系统安全。
-
物联网安全审计
：物联网设备的大量普及带来了新的安全风险。未来需要针对物联网设备的特点，开发专门的完整性检查和审计方法，保障物联网系统的安全运行。
15. 总结
系统完整性检查与审计是保障系统安全和稳定的重要手段。通过使用不同的工具和方法，如 RPM、BSD pkg_info、Tripwire 等进行完整性检查，以及对文件权限和日志文件进行审计，可以及时发现系统中的异常情况，包括恶意攻击、硬件故障、软件漏洞等。同时，计算机取证技术的发展为安全事件的调查和处理提供了有力支持。
在实际应用中，应遵循最佳实践，定期进行检查和审计，结合多种工具，及时响应异常情况。随着技术的不断发展，智能化分析、云环境审计和物联网安全审计等将成为未来的发展趋势。管理员应密切关注这些趋势，不断提升系统的安全性和可靠性。
扫一扫
3965
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
