【免费下载链接】Cybersecurity-ProjectsBuilding 70 Projects ranging from beginner to advanced so anyone can — learn from, build upon, use as a reference, or even copy directly. Gamified Cybersecurity learning 项目地址https://gitcode.com/gh_mirrors/cy/Cybersecurity-Projects点击查看免费下载cisaudit 是一个面向 Linux 系统的 CIS 基准合规审计工具VERSION1.0.0基准为CIS Debian Linux 12 Benchmark v1.1.0全部由纯 Bash 编写、零外部依赖。本篇架构指南围绕 02-ARCHITECTURE.md 展开从入口编排、控制注册表、检查函数到评分引擎与三种报告输出逐层剖析数据如何流经系统并说明为什么这套模块化设计能让新增控制项、新增输出格式、升级基准版本都只触及极少量代码。读完你既能从零理解一个合规审计器的分层架构也能直接拿它作为自己实现审计类工具的设计蓝本。cisaudit 审计运行结果截图高层架构一条命令、四个职责区cisaudit 的整个系统由四个职责区构成入口点cisaudit.sh、控制注册表controls/、检查函数checks/和核心库lib/。它们在运行时通过source拼装成一个完整进程结构如下┌──────────────────────────────────────────────────────────┐ │ cisaudit.sh (entry point) │ │ Parse CLI args → Load modules → Orchestrate audit │ └────────────────┬──────────────────────────┬──────────────┘ │ │ ┌────────────▼────────────┐ ┌──────────▼──────────────┐ │ controls/ │ │ lib/ │ │ registry_data.sh │ │ constants.sh │ │ │ │ utils.sh │ │ register_control │ │ registry.sh │ │ calls defining every │ │ engine.sh │ │ controls metadata │ │ baseline.sh │ └────────────┬────────────┘ │ report_terminal.sh │ │ │ report_json.sh │ ┌────────────▼────────────┐ │ report_html.sh │ │ checks/ │ └──────────────────────────┘ │ 01_initial_setup.sh │ │ 02_services.sh │ │ 03_network.sh │ │ 04_logging.sh │ │ 05_access.sh │ │ 05_access_password.sh │ │ 06_maintenance.sh │ │ │ │ check_X_Y_Z() │ │ functions that │ │ inspect the system │ │ and call │ │ record_result() │ └─────────────────────────┘对应到仓库的实际路径这四个区的落点分别是入口点src/cisaudit.sh控制注册表src/controls/registry_data.sh检查函数src/checks/ 下的 7 个文件01 初始配置、02 服务、03 网络、04 日志、05 访问控制、05 访问控制密码、06 系统维护核心库src/lib/ 下的 8 个模块组件分解每个模块只做一件事cisaudit.sh入口编排层它是唯一由用户直接调用的脚本职责边界非常清晰解析命令行参数写入全局变量OPT_LEVEL、OPT_FORMAT、OPT_OUTPUT、OPT_CATEGORIES等依次 source 全部库模块、控制定义与检查函数编排审计主流程检测 OS → 运行检查 → 计算评分 → 输出报告处理 baseline 保存/对比以及阈值退出码判定。从 src/cisaudit.sh 源码看主函数main()的调用顺序是check_bash_version→parse_args→可选list_controls→detect_os→check_root→run_checks→compute_scores→generate_report→ baseline 处理 → 阈值比较后exit。这里有个关键细节脚本在顶部source了所有模块后才开始干活因此模块加载顺序即是架构依赖顺序——常量最先其次是工具与注册表最后才是报告器与控制数据。controls/registry_data.sh控制注册表这是这个工具审计什么的唯一事实来源。文件内是密集的register_control调用每条调用完整定义一个 CIS 控制项的七个维度控制 ID、所属板块名、标题、级别1/2、是否计分yes/no、安全描述、修复命令。文档写作时统计为 104 条调用当前仓库源码中实际已增长到 109 条见 registry_data.sh覆盖全部六个板块板块覆盖内容示例Initial Setup禁用 cramfs/freevxfs/jffs2/hfs/hfsplus/squashfs/udf/vfat 等遗留文件系统模块、/tmp 独立分区与 noexec/nosuid/nodev、软件源与 GPG 密钥、GRUB 密码与权限、单用户模式认证、ASLR、核心转储限制、prelinkServicesxinetd 到 rsync 的服务加固Network Configurationsysctl 网络参数、防火墙策略、无线、非常用协议Logging and Auditingauditd、审计规则、rsyslogAccess, Authentication and Authorizationcron、SSH 加固、密码策略、账户锁定System Maintenance文件权限、重复 UID/GID、遗留账号条目cisaudit 控制清单截图checks/*.sh检查函数每个 CIS 基准板块对应一个文件文件内是形如check_X_Y_Z()的函数。这些函数只看不动——读取配置文件、查询 sysctl 值、校验文件权限、探测已装软件包最后调用record_result()记录结论。以 01_initial_setup.sh 为例check_1_1_1~check_1_1_8复用一个私有辅助函数_check_module_disabled通过lsmod探测模块是否已加载、检查/etc/modprobe.d/module.conf是否含install module /bin/true|false或blacklist条目check_1_2_2/3/4复用_check_tmp_mount_option从/etc/fstab提取/tmp行的挂载选项找不到时回退到findmnt。这种同构检查共享一个辅助函数的模式让 109 条控制项的检查逻辑高度内聚。lib/核心库constants.sh版本号、基准名、ANSI 颜色码、退出码EXIT_OK0/EXIT_FAIL1/EXIT_USAGE2、四种状态标签PASS/FAIL/WARN/SKIP、六个板块名及其展示顺序默认SYSROOT/utils.sh日志输出info/success/warn/fail受QUIET控制、OS 检测、file_exists/read_file/get_sysctl/get_config_value等系统访问助手、service_is_enabled/package_is_installed等服务/包查询registry.shregister_control()与record_result()及结果存储engine.sh按板块、按级别计算评分report_*.sh三种输出格式化器终端 / JSON / HTMLbaseline.sh将结果存为 JSON 基准、加载并与历史基准做差异对比。数据流从sudo cisaudit到一份报告完整审计流程以文档示例命令sudo cisaudit -l 1 -f json -o report.json为例系统内的完整执行链路如下1. cisaudit.sh 启动 └─ source lib/constants.sh, utils.sh, registry.sh, engine.sh └─ source lib/report_*.sh, baseline.sh └─ source controls/registry_data.sh填充 CTRL_* 数组 └─ source checks/*.sh定义 check_X_Y_Z 函数 2. parse_args() 处理 CLI 参数 └─ OPT_LEVEL1, OPT_FORMATjson, OPT_OUTPUTreport.json 3. detect_os() 读取 /etc/os-release └─ DETECTED_IDdebian, DETECTED_VERSION12 4. run_checks() 遍历 REGISTERED_IDS[] └─ 对每个控制 ID ├─ should_run_check() 按级别与板块过滤 ├─ 通过 CTRL_CHECK_FN 查表调用 check_X_Y_Z() 函数 └─ 检查函数调用 record_result(id, status, evidence) └─ 追加到 RESULT_STATUS[]/RESULT_EVIDENCE[]/RESULT_ORDER[] └─ 递增 TOTAL_PASS/FAIL/WARN/SKIP 计数器 5. compute_scores() 汇总结果 └─ 统计每板块 pass/fail → SCORE_BY_SECTION[] └─ 计算 SCORE_OVERALL, SCORE_LEVEL1, SCORE_LEVEL2 6. generate_report() 分发到 emit_json_report() └─ 遍历 RESULT_ORDER[] 与 SECTION_ORDER[] └─ 输出含 metadata/summary/sections/controls 的 JSON └─ 通过 OPT_OUTPUT 写入 report.json 7. 阈值检查若 SCORE_OVERALL OPT_THRESHOLDexit 1关于第 4 步源码中有两个值得注意的过滤细节should_run_check()先比较OPT_LEVEL与CTRL_LEVEL再对-c指定的板块号从控制 ID 首位数字提取做包含匹配而第 5 步的评分公式在 engine.sh 中明确为pass / (pass fail) * 100WARN 与 SKIP 不参与分母某个板块没有任何计分结果时SCORE_BY_SECTION记为N/A。控制注册流程每条控制从定义到出结果走同一条流水线registry_data.sh checks/0X_section.sh │ │ register_control( check_1_1_1() { 1.1.1, status PASS Initial Setup, evidence Ensure cramfs disabled, # inspect system 1, yes, # ... description..., record_result( remediation... 1.1.1, ) status, │ evidence ▼ ) CTRL_TITLE[1.1.1] } CTRL_SECTION[1.1.1] │ CTRL_LEVEL[1.1.1] ▼ CTRL_SCORED[1.1.1] RESULT_STATUS[1.1.1] CTRL_DESCRIPTION[1.1.1] RESULT_EVIDENCE[1.1.1] CTRL_REMEDIATION[1.1.1] RESULT_ORDER 1.1.1 CTRL_CHECK_FN[1.1.1] TOTAL_PASS check_1_1_1命名约定是自动的register_control 1.1.1通过把点替换为下划线生成函数名check_1_1_1。检查函数必须以该确切名字存在否则引擎会记录一条 SKIP证据为Check function check_1_1_1 not implemented。这一点在 cisaudit.sh 的 run_checks() 中体现为declare -f $fn /dev/null的函数存在性探测。设计模式让扩展只发生在一处注册表模式Registry Pattern核心架构模式。全部控制项通过单一函数register_control注册进关联数组引擎不硬编码任何控制逻辑——它遍历REGISTERED_IDS[]从CTRL_CHECK_FN[]查函数名并动态调用。在 registry.sh 中register_control一次性填充 6 个关联数组CTRL_TITLE/SECTION/LEVEL/SCORED/DESCRIPTION/REMEDIATION、推导CTRL_CHECK_FN并追加REGISTERED_IDS。该模式带来的直接收益新增一个控制项只需两处改动一条register_control调用 一个check_X_Y_Z函数引擎、报告器、基准模块与有哪些控制完全解耦增删控制项无需触碰任何核心代码。register_control 1.1.1 \ Initial Setup \ Ensure mounting of cramfs is disabled \ 1 \ yes \ The cramfs filesystem type is... \ echo install cramfs /bin/true /etc/modprobe.d/cramfs.conf echo blacklist cramfs /etc/modprobe.d/cramfs.conf报告器策略模式Strategy Patternreport_terminal.sh、report_json.sh、report_html.sh各暴露一个入口函数emit_terminal_report、emit_json_report、emit_html_report。cisaudit.sh中的generate_report依据OPT_FORMAT分发到正确实现。三个报告器读取同一份全局状态RESULT_STATUS、RESULT_EVIDENCE、SCORE_BY_SECTION等彼此之间零共享代码——因为每种输出格式的文档结构本质不同。以 report_json.sh 为例它内置了三个保障 JSON 合法性的小工具json_escape对\ \n \t \r逐一转义、_json_score把N/A序列化为null、_json_bool把yes/no映射为true/false。新增一种格式CSV、SARIF、Markdown意味着写一个新文件、实现一个emit_X_report函数、在generate_report的 case 里加一个分支其余系统完全不变。SYSROOT 抽象测试根目录重定向所有文件访问都经由预先拼接SYSROOT变量的助手函数完成file_exists() { [[ -f ${SYSROOT}${1} ]] } read_file() { local path${SYSROOT}${1} if [[ -f $path ]]; then cat $path else return 1 fi } get_sysctl() { local param$1 local proc_path${SYSROOT}/proc/sys/${param//\.//} if [[ -f $proc_path ]]; then cat $proc_path return 0 fi # ... }SYSROOT/时访问真实系统SYSROOTtestdata/fixtures时访问模拟文件系统。get_sysctl的路径转换逻辑值得单独说明参数net.ipv4.ip_forward会被替换为/proc/sys/net/ipv4/ip_forward点变斜杠在真实系统上先读 proc 文件、失败后再回退到sysctl -n命令。而run_cmd在SYSROOT ! /时直接返回 1阻断确保测试模式下不会执行任何真实系统命令。这一层抽象让整套测试无需 root、无需真实主机即可运行。分层架构四层单向依赖┌──────────────────────────────────────┐ │ Layer 1: CLI / Orchestration │ │ cisaudit.sh │ │ - Parses arguments │ │ - Controls execution order │ │ - Does NOT inspect the system │ └──────────────────────────────────────┘ ↓ ┌──────────────────────────────────────┐ │ Layer 2: Control Definitions │ │ controls/registry_data.sh │ │ - Declares what to check │ │ - Contains no check logic │ │ - Pure metadata │ └──────────────────────────────────────┘ ↓ ┌──────────────────────────────────────┐ │ Layer 3: Check Functions │ │ checks/01_initial_setup.sh ... │ │ - Inspects the system │ │ - Calls record_result() │ │ - Does NOT format output │ └──────────────────────────────────────┘ ↓ ┌──────────────────────────────────────┐ │ Layer 4: Scoring and Reporting │ │ lib/engine.sh, report_*.sh │ │ - Computes scores from results │ │ - Formats output │ │ - Does NOT know what was checked │ └──────────────────────────────────────┘为什么要分层可测试性Testability检查函数可针对模拟文件系统单独测试无需经过 CLI 层评分引擎可用合成结果数据测试无需运行任何检查可扩展性Extensibility升级一个 CIS 基准版本只更新 Layer 2控制定义和 Layer 3检查函数Layer 1 与 Layer 4 原封不动关注点分离Separation of Concerns检查函数永不接触格式化报告器永不接触文件系统每个模块只有一个职责。数据模型Bash 关联数组即数据库cisaudit 用 Bash 关联数组作为唯一数据模型没有任何外部数据存储。控制注册数据由 register_control 填充CTRL_TITLE[1.1.1] Ensure mounting of cramfs is disabled CTRL_SECTION[1.1.1] Initial Setup CTRL_LEVEL[1.1.1] 1 CTRL_SCORED[1.1.1] yes CTRL_DESCRIPTION[1.1.1] The cramfs filesystem type is... CTRL_REMEDIATION[1.1.1] echo install cramfs /bin/true ... CTRL_CHECK_FN[1.1.1] check_1_1_1 REGISTERED_IDS[] (1.1.1 1.1.2 1.1.3 ...)结果存储由 record_result 填充RESULT_STATUS[1.1.1] PASS RESULT_EVIDENCE[1.1.1] cramfs disabled via /etc/modprobe.d/cramfs.conf RESULT_ORDER[] (1.1.1 1.1.2 ...) TOTAL_PASS 72 TOTAL_FAIL 18 TOTAL_WARN 6 TOTAL_SKIP 8评分聚合由 compute_scores 填充SECTION_PASS[Initial Setup] 16 SECTION_FAIL[Initial Setup] 2 SCORE_BY_SECTION[Initial Setup] 88.9 SCORE_OVERALL 80.0 SCORE_LEVEL1 82.5 SCORE_LEVEL2 75.0三个评分维度各有用途SCORE_OVERALL面向整体合规度、SCORE_LEVEL1/2面向不同强度的安全基线、SCORE_BY_SECTION用于定位薄弱板块。compute_scores还维护get_section_total助手汇总某板块的四类结果总数。测试架构无 root、无真实主机的 fixture 测试基于 Fixture 的测试测试套件对两套模拟文件系统运行检查testdata/ ├── fixtures/ # 已加固系统绝大多数检查 PASS │ ├── etc/ │ │ ├── modprobe.d/ # cramfs.conf, dccp.conf, etc. │ │ ├── ssh/sshd_config │ │ ├── pam.d/ │ │ ├── audit/rules.d/cis.rules │ │ ├── sysctl.conf │ │ ├── fstab │ │ ├── passwd, shadow, group, gshadow │ │ └── ... │ └── proc/sys/ # 模拟 /proc 值 │ ├── kernel/randomize_va_space (contains 2) │ ├── net/ipv4/ip_forward (contains 0) │ └── ... │ └── fixtures_fail/ # 未加固系统绝大多数检查 FAIL ├── etc/ │ ├── modprobe.d/ # empty │ ├── ssh/sshd_config (PermitRootLogin yes, etc.) │ └── ... └── proc/sys/ # Insecure values ├── net/ipv4/ip_forward (contains 1) └── ...每个/proc/sys/参数就是一个包含期望值的普通文件。get_sysctl读取${SYSROOT}/proc/sys/net/ipv4/ip_forward而不是调用sysctl -n net.ipv4.ip_forward——这样测试 fixture 就能模拟内核参数无需运行在真实内核上。仓库中这两套 fixture 位于 testdata/fixtures/ 与 testdata/fixtures_fail/前者还包含了模拟的/usr/sbin/auditd、rsyslogd可执行文件用于服务存在性检查。测试框架测试运行器是 test_helpers.sh 中的自定义框架提供三个断言函数assert_status 1.1.1 $STATUS_PASS assert_evidence_contains 1.1.1 cramfs disabled assert_json_valid $json_outputassert_status比较某控制项记录的 status 与期望值assert_evidence_contains在证据字符串中查找子串assert_json_valid通过python3 -m json.tool校验 JSON支持文件路径与内联字符串两种输入。测试遵循一致的模式test_cramfs_disabled_pass() { CURRENT_TESTtest_cramfs_disabled_pass setup_test ${PROJECT_DIR}/testdata/fixtures check_1_1_1 assert_status 1.1.1 $STATUS_PASS } test_cramfs_disabled_fail() { CURRENT_TESTtest_cramfs_disabled_fail setup_test ${PROJECT_DIR}/testdata/fixtures_fail check_1_1_1 assert_status 1.1.1 $STATUS_FAIL }每个测试先通过setup_test重置结果状态内部调用reset_results并固定SYSROOT与 OS 探测值debian/12再把SYSROOT指向相应 fixture调用检查函数最后断言期望状态。从 tests/ 目录看测试按板块文件组织test_01_initial_setup.sh~test_06_maintenance.sh另有test_engine.sh评分引擎、test_baseline.sh基准对比、test_report_json.shJSON 报告合法性等独立测试。安全架构审计器的自我保护威胁模型cisaudit 保护什么未经加固的 Linux 系统直接进入生产环境配置漂移——系统加固随时间退化通过基准对比检测合规盲区——组织不知道自己哪些 CIS 控制项通过、哪些失败。cisaudit 不保护什么服务的运行时漏洞利用它是审计工具不是 IDS正在进行的主动攻击cisaudit 是时点快照不是持续监控结果造假有人可以篡改 fixture 文件来伪造一份通过审计。工具自身的防御措施每个脚本启用set -euo pipefail未定义变量、管道错误、未捕获错误都会导致立即失败见 cisaudit.sh 第 27 行及各模块文件头json_escape与html_escape防止 JSON 与 HTML 报告中的注入SYSROOT默认/以 root 运行而不加-t时工具不可能意外审计到测试 fixture只读设计工具从不修改系统。所有检查函数只用grep、cat、stat、sysctl检查而绝不改变状态。基线对比配置漂移检测baseline.sh 提供了漂移检测闭环save_baseline直接复用emit_json_report把当前结果存为 JSONload_baseline用正则解析控制 ID 与状态无需 JSON 库diff_baseline把每条控制归入improved / regressed / unchanged / new / removed五类用颜色标注PASS → FAIL红色回归与FAIL → PASS绿色改进汇总后若存在回归则发出告警。关键设计决策与权衡为什么选 BashCIS 审计需要运行在精简系统上这些系统可能未安装 Python、Ruby 或 Go。Bash 4 存在于所有现代 Linux 发行版工具除标准 GNU 工具grep、awk、sed、stat、date外零外部依赖意味着它可以在任何配置管理或软件包安装发生之前在刚交付的裸服务器上直接运行。代价是 Bash 关联数组比编译型语言的哈希表慢、字符串操作冗长——但对 109 条控制而言性能差异可忽略审计在典型系统上通常 2 秒内完成。为什么不自研或选用现有工具OpenSCAP 与 Lynis 提供类似功能。本项目是从第一性原理演示合规审计如何工作的学习资源OpenSCAP 依赖难读的 XCCDF/OVAL XML 定义Lynis 是 7000 行的单体脚本cisaudit 刻意保持模块化与可读性让每个设计决策都透明可见。为什么用关联数组而非 JSON/SQLite关联数组保持工具零依赖——用jq操作 JSON 或sqlite3做存储都会引入外部依赖。代价是数据模型是隐式的数组必须按正确顺序声明与填充而非 schema 强制。对 109 条控制而言简单性值得这个取舍。CLI 全参数速查在阅读架构时顺手掌握入口参数能帮你把各层串起来完整帮助见cisaudit --help定义于 cisaudit.sh 的 print_help参数含义默认值-l, --level基准级别1、2 或 allall-f, --format输出terminal / json / htmlterminal-o, --output报告写入文件默认 stdout空stdout-c, --categories审计板块1,2,3,4,5,6all-b, --baseline与历史 baseline JSON 对比空-s, --save-baseline把结果存为 baseline JSON空-t, --test-root使用 DIR 作为系统根测试用/--threshold PCT最低通过百分比低于则 exit 10--list-controls列出全部已注册控制并退出false-q, --quiet抑制进度输出false-v, --version打印版本并退出—-h, --help打印帮助并退出—对应到内部变量-t直接重写SYSROOT全局变量剥掉尾部斜杠--threshold写入OPT_THRESHOLD并在main()末尾与SCORE_OVERALL的整数部分比较。运行cisaudit -t testdata/fixtures -f json | python3 -m json.tool可以无 root 地快速体验完整审计链路并把输出反向追溯到上面的每一步。关键文件参考架构对应的核心文件速查表文档原文标注路径已转换为仓库根相对路径src/cisaudit.sh — CLI 入口、参数解析、编排src/lib/constants.sh — 全部常量版本、颜色、状态码、板块名src/lib/registry.sh —register_control()与record_result()函数src/lib/engine.sh — 评分计算逻辑src/lib/utils.sh — 系统检查助手get_sysctl、read_file、file_existssrc/controls/registry_data.sh — 全部 109 条控制定义src/checks/01_initial_setup.sh — 文件系统与引导加载器检查src/checks/03_network.sh — 网络参数与防火墙检查src/lib/report_terminal.sh — 终端报告渲染src/lib/report_html.sh — 自带 CSS 的独立 HTML 报告src/lib/baseline.sh — 基准保存/加载/对比tests/test_helpers.sh — 测试断言函数下一步把架构读成代码理解架构后的两条推荐路径阅读 03-IMPLEMENTATION.md 获得每个模块的代码级讲解运行cisaudit -t testdata/fixtures -f json | python3 -m json.tool把 JSON 输出逐字段回溯到run_checks、compute_scores、emit_json_report的实现上——当你能在头脑中把一条控制项从registry_data.sh一路追踪到报告里的 JSON 对象时你就真正吃透了这套架构。赞分享【免费下载链接】Cybersecurity-ProjectsBuilding 70 Projects ranging from beginner to advanced so anyone can — learn from, build upon, use as a reference, or even copy directly. Gamified Cybersecurity learning 项目地址https://gitcode.com/gh_mirrors/cy/Cybersecurity-Projects点击查看免费下载相关推荐ERPNext 免费开源 ERP30 分钟装完财务库存销售一套打通ERPNext 免费开源 ERP30 分钟装完财务库存销售一套打通 ERPNext 是一款代码全开源、完全免费的企业资源计划系统ERP一套平台覆盖记账FeHelper核心架构深度剖析Manifest V3规范与模块化设计FeHelper核心架构深度剖析Manifest V3规范与模块化设计 FeHelper前端助手作为一款功能强大的浏览器扩展工具其核心架构基于Chrom前端开发工具npx skills 交互式安装一条命令三次按键装好 AI 技能npx skills 交互式安装一条命令三次按键装好 AI 技能 第一次在终端里给 AI 助手装技能不用记任何参数。npx skills 交互式安装把整个过AI 技能CLI开发工具人工智能上一篇Civitai 功能开关清理审计从 flags 定义到消费者全链路排查的实战指南下一篇AURA Omni 在线推理部署指南基于 vLLM-Omni 的四阶段 ASR→VLM→TTS 全链路服务创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
【免费下载链接】Cybersecurity-ProjectsBuilding 70 Projects ranging from beginner to advanced so anyone can — learn from, build upon, use as a reference, or even copy directly. Gamified Cybersecurity learning 项目地址https://gitcode.com/gh_mirrors/cy/Cybersecurity-Projects点击查看免费下载cisaudit 是一个面向 Linux 系统的 CIS 基准合规审计工具VERSION1.0.0基准为CIS Debian Linux 12 Benchmark v1.1.0全部由纯 Bash 编写、零外部依赖。本篇架构指南围绕 02-ARCHITECTURE.md 展开从入口编排、控制注册表、检查函数到评分引擎与三种报告输出逐层剖析数据如何流经系统并说明为什么这套模块化设计能让新增控制项、新增输出格式、升级基准版本都只触及极少量代码。读完你既能从零理解一个合规审计器的分层架构也能直接拿它作为自己实现审计类工具的设计蓝本。cisaudit 审计运行结果截图高层架构一条命令、四个职责区cisaudit 的整个系统由四个职责区构成入口点cisaudit.sh、控制注册表controls/、检查函数checks/和核心库lib/。它们在运行时通过source拼装成一个完整进程结构如下┌──────────────────────────────────────────────────────────┐ │ cisaudit.sh (entry point) │ │ Parse CLI args → Load modules → Orchestrate audit │ └────────────────┬──────────────────────────┬──────────────┘ │ │ ┌────────────▼────────────┐ ┌──────────▼──────────────┐ │ controls/ │ │ lib/ │ │ registry_data.sh │ │ constants.sh │ │ │ │ utils.sh │ │ register_control │ │ registry.sh │ │ calls defining every │ │ engine.sh │ │ controls metadata │ │ baseline.sh │ └────────────┬────────────┘ │ report_terminal.sh │ │ │ report_json.sh │ ┌────────────▼────────────┐ │ report_html.sh │ │ checks/ │ └──────────────────────────┘ │ 01_initial_setup.sh │ │ 02_services.sh │ │ 03_network.sh │ │ 04_logging.sh │ │ 05_access.sh │ │ 05_access_password.sh │ │ 06_maintenance.sh │ │ │ │ check_X_Y_Z() │ │ functions that │ │ inspect the system │ │ and call │ │ record_result() │ └─────────────────────────┘对应到仓库的实际路径这四个区的落点分别是入口点src/cisaudit.sh控制注册表src/controls/registry_data.sh检查函数src/checks/ 下的 7 个文件01 初始配置、02 服务、03 网络、04 日志、05 访问控制、05 访问控制密码、06 系统维护核心库src/lib/ 下的 8 个模块组件分解每个模块只做一件事cisaudit.sh入口编排层它是唯一由用户直接调用的脚本职责边界非常清晰解析命令行参数写入全局变量OPT_LEVEL、OPT_FORMAT、OPT_OUTPUT、OPT_CATEGORIES等依次 source 全部库模块、控制定义与检查函数编排审计主流程检测 OS → 运行检查 → 计算评分 → 输出报告处理 baseline 保存/对比以及阈值退出码判定。从 src/cisaudit.sh 源码看主函数main()的调用顺序是check_bash_version→parse_args→可选list_controls→detect_os→check_root→run_checks→compute_scores→generate_report→ baseline 处理 → 阈值比较后exit。这里有个关键细节脚本在顶部source了所有模块后才开始干活因此模块加载顺序即是架构依赖顺序——常量最先其次是工具与注册表最后才是报告器与控制数据。controls/registry_data.sh控制注册表这是这个工具审计什么的唯一事实来源。文件内是密集的register_control调用每条调用完整定义一个 CIS 控制项的七个维度控制 ID、所属板块名、标题、级别1/2、是否计分yes/no、安全描述、修复命令。文档写作时统计为 104 条调用当前仓库源码中实际已增长到 109 条见 registry_data.sh覆盖全部六个板块板块覆盖内容示例Initial Setup禁用 cramfs/freevxfs/jffs2/hfs/hfsplus/squashfs/udf/vfat 等遗留文件系统模块、/tmp 独立分区与 noexec/nosuid/nodev、软件源与 GPG 密钥、GRUB 密码与权限、单用户模式认证、ASLR、核心转储限制、prelinkServicesxinetd 到 rsync 的服务加固Network Configurationsysctl 网络参数、防火墙策略、无线、非常用协议Logging and Auditingauditd、审计规则、rsyslogAccess, Authentication and Authorizationcron、SSH 加固、密码策略、账户锁定System Maintenance文件权限、重复 UID/GID、遗留账号条目cisaudit 控制清单截图checks/*.sh检查函数每个 CIS 基准板块对应一个文件文件内是形如check_X_Y_Z()的函数。这些函数只看不动——读取配置文件、查询 sysctl 值、校验文件权限、探测已装软件包最后调用record_result()记录结论。以 01_initial_setup.sh 为例check_1_1_1~check_1_1_8复用一个私有辅助函数_check_module_disabled通过lsmod探测模块是否已加载、检查/etc/modprobe.d/module.conf是否含install module /bin/true|false或blacklist条目check_1_2_2/3/4复用_check_tmp_mount_option从/etc/fstab提取/tmp行的挂载选项找不到时回退到findmnt。这种同构检查共享一个辅助函数的模式让 109 条控制项的检查逻辑高度内聚。lib/核心库constants.sh版本号、基准名、ANSI 颜色码、退出码EXIT_OK0/EXIT_FAIL1/EXIT_USAGE2、四种状态标签PASS/FAIL/WARN/SKIP、六个板块名及其展示顺序默认SYSROOT/utils.sh日志输出info/success/warn/fail受QUIET控制、OS 检测、file_exists/read_file/get_sysctl/get_config_value等系统访问助手、service_is_enabled/package_is_installed等服务/包查询registry.shregister_control()与record_result()及结果存储engine.sh按板块、按级别计算评分report_*.sh三种输出格式化器终端 / JSON / HTMLbaseline.sh将结果存为 JSON 基准、加载并与历史基准做差异对比。数据流从sudo cisaudit到一份报告完整审计流程以文档示例命令sudo cisaudit -l 1 -f json -o report.json为例系统内的完整执行链路如下1. cisaudit.sh 启动 └─ source lib/constants.sh, utils.sh, registry.sh, engine.sh └─ source lib/report_*.sh, baseline.sh └─ source controls/registry_data.sh填充 CTRL_* 数组 └─ source checks/*.sh定义 check_X_Y_Z 函数 2. parse_args() 处理 CLI 参数 └─ OPT_LEVEL1, OPT_FORMATjson, OPT_OUTPUTreport.json 3. detect_os() 读取 /etc/os-release └─ DETECTED_IDdebian, DETECTED_VERSION12 4. run_checks() 遍历 REGISTERED_IDS[] └─ 对每个控制 ID ├─ should_run_check() 按级别与板块过滤 ├─ 通过 CTRL_CHECK_FN 查表调用 check_X_Y_Z() 函数 └─ 检查函数调用 record_result(id, status, evidence) └─ 追加到 RESULT_STATUS[]/RESULT_EVIDENCE[]/RESULT_ORDER[] └─ 递增 TOTAL_PASS/FAIL/WARN/SKIP 计数器 5. compute_scores() 汇总结果 └─ 统计每板块 pass/fail → SCORE_BY_SECTION[] └─ 计算 SCORE_OVERALL, SCORE_LEVEL1, SCORE_LEVEL2 6. generate_report() 分发到 emit_json_report() └─ 遍历 RESULT_ORDER[] 与 SECTION_ORDER[] └─ 输出含 metadata/summary/sections/controls 的 JSON └─ 通过 OPT_OUTPUT 写入 report.json 7. 阈值检查若 SCORE_OVERALL OPT_THRESHOLDexit 1关于第 4 步源码中有两个值得注意的过滤细节should_run_check()先比较OPT_LEVEL与CTRL_LEVEL再对-c指定的板块号从控制 ID 首位数字提取做包含匹配而第 5 步的评分公式在 engine.sh 中明确为pass / (pass fail) * 100WARN 与 SKIP 不参与分母某个板块没有任何计分结果时SCORE_BY_SECTION记为N/A。控制注册流程每条控制从定义到出结果走同一条流水线registry_data.sh checks/0X_section.sh │ │ register_control( check_1_1_1() { 1.1.1, status PASS Initial Setup, evidence Ensure cramfs disabled, # inspect system 1, yes, # ... description..., record_result( remediation... 1.1.1, ) status, │ evidence ▼ ) CTRL_TITLE[1.1.1] } CTRL_SECTION[1.1.1] │ CTRL_LEVEL[1.1.1] ▼ CTRL_SCORED[1.1.1] RESULT_STATUS[1.1.1] CTRL_DESCRIPTION[1.1.1] RESULT_EVIDENCE[1.1.1] CTRL_REMEDIATION[1.1.1] RESULT_ORDER 1.1.1 CTRL_CHECK_FN[1.1.1] TOTAL_PASS check_1_1_1命名约定是自动的register_control 1.1.1通过把点替换为下划线生成函数名check_1_1_1。检查函数必须以该确切名字存在否则引擎会记录一条 SKIP证据为Check function check_1_1_1 not implemented。这一点在 cisaudit.sh 的 run_checks() 中体现为declare -f $fn /dev/null的函数存在性探测。设计模式让扩展只发生在一处注册表模式Registry Pattern核心架构模式。全部控制项通过单一函数register_control注册进关联数组引擎不硬编码任何控制逻辑——它遍历REGISTERED_IDS[]从CTRL_CHECK_FN[]查函数名并动态调用。在 registry.sh 中register_control一次性填充 6 个关联数组CTRL_TITLE/SECTION/LEVEL/SCORED/DESCRIPTION/REMEDIATION、推导CTRL_CHECK_FN并追加REGISTERED_IDS。该模式带来的直接收益新增一个控制项只需两处改动一条register_control调用 一个check_X_Y_Z函数引擎、报告器、基准模块与有哪些控制完全解耦增删控制项无需触碰任何核心代码。register_control 1.1.1 \ Initial Setup \ Ensure mounting of cramfs is disabled \ 1 \ yes \ The cramfs filesystem type is... \ echo install cramfs /bin/true /etc/modprobe.d/cramfs.conf echo blacklist cramfs /etc/modprobe.d/cramfs.conf报告器策略模式Strategy Patternreport_terminal.sh、report_json.sh、report_html.sh各暴露一个入口函数emit_terminal_report、emit_json_report、emit_html_report。cisaudit.sh中的generate_report依据OPT_FORMAT分发到正确实现。三个报告器读取同一份全局状态RESULT_STATUS、RESULT_EVIDENCE、SCORE_BY_SECTION等彼此之间零共享代码——因为每种输出格式的文档结构本质不同。以 report_json.sh 为例它内置了三个保障 JSON 合法性的小工具json_escape对\ \n \t \r逐一转义、_json_score把N/A序列化为null、_json_bool把yes/no映射为true/false。新增一种格式CSV、SARIF、Markdown意味着写一个新文件、实现一个emit_X_report函数、在generate_report的 case 里加一个分支其余系统完全不变。SYSROOT 抽象测试根目录重定向所有文件访问都经由预先拼接SYSROOT变量的助手函数完成file_exists() { [[ -f ${SYSROOT}${1} ]] } read_file() { local path${SYSROOT}${1} if [[ -f $path ]]; then cat $path else return 1 fi } get_sysctl() { local param$1 local proc_path${SYSROOT}/proc/sys/${param//\.//} if [[ -f $proc_path ]]; then cat $proc_path return 0 fi # ... }SYSROOT/时访问真实系统SYSROOTtestdata/fixtures时访问模拟文件系统。get_sysctl的路径转换逻辑值得单独说明参数net.ipv4.ip_forward会被替换为/proc/sys/net/ipv4/ip_forward点变斜杠在真实系统上先读 proc 文件、失败后再回退到sysctl -n命令。而run_cmd在SYSROOT ! /时直接返回 1阻断确保测试模式下不会执行任何真实系统命令。这一层抽象让整套测试无需 root、无需真实主机即可运行。分层架构四层单向依赖┌──────────────────────────────────────┐ │ Layer 1: CLI / Orchestration │ │ cisaudit.sh │ │ - Parses arguments │ │ - Controls execution order │ │ - Does NOT inspect the system │ └──────────────────────────────────────┘ ↓ ┌──────────────────────────────────────┐ │ Layer 2: Control Definitions │ │ controls/registry_data.sh │ │ - Declares what to check │ │ - Contains no check logic │ │ - Pure metadata │ └──────────────────────────────────────┘ ↓ ┌──────────────────────────────────────┐ │ Layer 3: Check Functions │ │ checks/01_initial_setup.sh ... │ │ - Inspects the system │ │ - Calls record_result() │ │ - Does NOT format output │ └──────────────────────────────────────┘ ↓ ┌──────────────────────────────────────┐ │ Layer 4: Scoring and Reporting │ │ lib/engine.sh, report_*.sh │ │ - Computes scores from results │ │ - Formats output │ │ - Does NOT know what was checked │ └──────────────────────────────────────┘为什么要分层可测试性Testability检查函数可针对模拟文件系统单独测试无需经过 CLI 层评分引擎可用合成结果数据测试无需运行任何检查可扩展性Extensibility升级一个 CIS 基准版本只更新 Layer 2控制定义和 Layer 3检查函数Layer 1 与 Layer 4 原封不动关注点分离Separation of Concerns检查函数永不接触格式化报告器永不接触文件系统每个模块只有一个职责。数据模型Bash 关联数组即数据库cisaudit 用 Bash 关联数组作为唯一数据模型没有任何外部数据存储。控制注册数据由 register_control 填充CTRL_TITLE[1.1.1] Ensure mounting of cramfs is disabled CTRL_SECTION[1.1.1] Initial Setup CTRL_LEVEL[1.1.1] 1 CTRL_SCORED[1.1.1] yes CTRL_DESCRIPTION[1.1.1] The cramfs filesystem type is... CTRL_REMEDIATION[1.1.1] echo install cramfs /bin/true ... CTRL_CHECK_FN[1.1.1] check_1_1_1 REGISTERED_IDS[] (1.1.1 1.1.2 1.1.3 ...)结果存储由 record_result 填充RESULT_STATUS[1.1.1] PASS RESULT_EVIDENCE[1.1.1] cramfs disabled via /etc/modprobe.d/cramfs.conf RESULT_ORDER[] (1.1.1 1.1.2 ...) TOTAL_PASS 72 TOTAL_FAIL 18 TOTAL_WARN 6 TOTAL_SKIP 8评分聚合由 compute_scores 填充SECTION_PASS[Initial Setup] 16 SECTION_FAIL[Initial Setup] 2 SCORE_BY_SECTION[Initial Setup] 88.9 SCORE_OVERALL 80.0 SCORE_LEVEL1 82.5 SCORE_LEVEL2 75.0三个评分维度各有用途SCORE_OVERALL面向整体合规度、SCORE_LEVEL1/2面向不同强度的安全基线、SCORE_BY_SECTION用于定位薄弱板块。compute_scores还维护get_section_total助手汇总某板块的四类结果总数。测试架构无 root、无真实主机的 fixture 测试基于 Fixture 的测试测试套件对两套模拟文件系统运行检查testdata/ ├── fixtures/ # 已加固系统绝大多数检查 PASS │ ├── etc/ │ │ ├── modprobe.d/ # cramfs.conf, dccp.conf, etc. │ │ ├── ssh/sshd_config │ │ ├── pam.d/ │ │ ├── audit/rules.d/cis.rules │ │ ├── sysctl.conf │ │ ├── fstab │ │ ├── passwd, shadow, group, gshadow │ │ └── ... │ └── proc/sys/ # 模拟 /proc 值 │ ├── kernel/randomize_va_space (contains 2) │ ├── net/ipv4/ip_forward (contains 0) │ └── ... │ └── fixtures_fail/ # 未加固系统绝大多数检查 FAIL ├── etc/ │ ├── modprobe.d/ # empty │ ├── ssh/sshd_config (PermitRootLogin yes, etc.) │ └── ... └── proc/sys/ # Insecure values ├── net/ipv4/ip_forward (contains 1) └── ...每个/proc/sys/参数就是一个包含期望值的普通文件。get_sysctl读取${SYSROOT}/proc/sys/net/ipv4/ip_forward而不是调用sysctl -n net.ipv4.ip_forward——这样测试 fixture 就能模拟内核参数无需运行在真实内核上。仓库中这两套 fixture 位于 testdata/fixtures/ 与 testdata/fixtures_fail/前者还包含了模拟的/usr/sbin/auditd、rsyslogd可执行文件用于服务存在性检查。测试框架测试运行器是 test_helpers.sh 中的自定义框架提供三个断言函数assert_status 1.1.1 $STATUS_PASS assert_evidence_contains 1.1.1 cramfs disabled assert_json_valid $json_outputassert_status比较某控制项记录的 status 与期望值assert_evidence_contains在证据字符串中查找子串assert_json_valid通过python3 -m json.tool校验 JSON支持文件路径与内联字符串两种输入。测试遵循一致的模式test_cramfs_disabled_pass() { CURRENT_TESTtest_cramfs_disabled_pass setup_test ${PROJECT_DIR}/testdata/fixtures check_1_1_1 assert_status 1.1.1 $STATUS_PASS } test_cramfs_disabled_fail() { CURRENT_TESTtest_cramfs_disabled_fail setup_test ${PROJECT_DIR}/testdata/fixtures_fail check_1_1_1 assert_status 1.1.1 $STATUS_FAIL }每个测试先通过setup_test重置结果状态内部调用reset_results并固定SYSROOT与 OS 探测值debian/12再把SYSROOT指向相应 fixture调用检查函数最后断言期望状态。从 tests/ 目录看测试按板块文件组织test_01_initial_setup.sh~test_06_maintenance.sh另有test_engine.sh评分引擎、test_baseline.sh基准对比、test_report_json.shJSON 报告合法性等独立测试。安全架构审计器的自我保护威胁模型cisaudit 保护什么未经加固的 Linux 系统直接进入生产环境配置漂移——系统加固随时间退化通过基准对比检测合规盲区——组织不知道自己哪些 CIS 控制项通过、哪些失败。cisaudit 不保护什么服务的运行时漏洞利用它是审计工具不是 IDS正在进行的主动攻击cisaudit 是时点快照不是持续监控结果造假有人可以篡改 fixture 文件来伪造一份通过审计。工具自身的防御措施每个脚本启用set -euo pipefail未定义变量、管道错误、未捕获错误都会导致立即失败见 cisaudit.sh 第 27 行及各模块文件头json_escape与html_escape防止 JSON 与 HTML 报告中的注入SYSROOT默认/以 root 运行而不加-t时工具不可能意外审计到测试 fixture只读设计工具从不修改系统。所有检查函数只用grep、cat、stat、sysctl检查而绝不改变状态。基线对比配置漂移检测baseline.sh 提供了漂移检测闭环save_baseline直接复用emit_json_report把当前结果存为 JSONload_baseline用正则解析控制 ID 与状态无需 JSON 库diff_baseline把每条控制归入improved / regressed / unchanged / new / removed五类用颜色标注PASS → FAIL红色回归与FAIL → PASS绿色改进汇总后若存在回归则发出告警。关键设计决策与权衡为什么选 BashCIS 审计需要运行在精简系统上这些系统可能未安装 Python、Ruby 或 Go。Bash 4 存在于所有现代 Linux 发行版工具除标准 GNU 工具grep、awk、sed、stat、date外零外部依赖意味着它可以在任何配置管理或软件包安装发生之前在刚交付的裸服务器上直接运行。代价是 Bash 关联数组比编译型语言的哈希表慢、字符串操作冗长——但对 109 条控制而言性能差异可忽略审计在典型系统上通常 2 秒内完成。为什么不自研或选用现有工具OpenSCAP 与 Lynis 提供类似功能。本项目是从第一性原理演示合规审计如何工作的学习资源OpenSCAP 依赖难读的 XCCDF/OVAL XML 定义Lynis 是 7000 行的单体脚本cisaudit 刻意保持模块化与可读性让每个设计决策都透明可见。为什么用关联数组而非 JSON/SQLite关联数组保持工具零依赖——用jq操作 JSON 或sqlite3做存储都会引入外部依赖。代价是数据模型是隐式的数组必须按正确顺序声明与填充而非 schema 强制。对 109 条控制而言简单性值得这个取舍。CLI 全参数速查在阅读架构时顺手掌握入口参数能帮你把各层串起来完整帮助见cisaudit --help定义于 cisaudit.sh 的 print_help参数含义默认值-l, --level基准级别1、2 或 allall-f, --format输出terminal / json / htmlterminal-o, --output报告写入文件默认 stdout空stdout-c, --categories审计板块1,2,3,4,5,6all-b, --baseline与历史 baseline JSON 对比空-s, --save-baseline把结果存为 baseline JSON空-t, --test-root使用 DIR 作为系统根测试用/--threshold PCT最低通过百分比低于则 exit 10--list-controls列出全部已注册控制并退出false-q, --quiet抑制进度输出false-v, --version打印版本并退出—-h, --help打印帮助并退出—对应到内部变量-t直接重写SYSROOT全局变量剥掉尾部斜杠--threshold写入OPT_THRESHOLD并在main()末尾与SCORE_OVERALL的整数部分比较。运行cisaudit -t testdata/fixtures -f json | python3 -m json.tool可以无 root 地快速体验完整审计链路并把输出反向追溯到上面的每一步。关键文件参考架构对应的核心文件速查表文档原文标注路径已转换为仓库根相对路径src/cisaudit.sh — CLI 入口、参数解析、编排src/lib/constants.sh — 全部常量版本、颜色、状态码、板块名src/lib/registry.sh —register_control()与record_result()函数src/lib/engine.sh — 评分计算逻辑src/lib/utils.sh — 系统检查助手get_sysctl、read_file、file_existssrc/controls/registry_data.sh — 全部 109 条控制定义src/checks/01_initial_setup.sh — 文件系统与引导加载器检查src/checks/03_network.sh — 网络参数与防火墙检查src/lib/report_terminal.sh — 终端报告渲染src/lib/report_html.sh — 自带 CSS 的独立 HTML 报告src/lib/baseline.sh — 基准保存/加载/对比tests/test_helpers.sh — 测试断言函数下一步把架构读成代码理解架构后的两条推荐路径阅读 03-IMPLEMENTATION.md 获得每个模块的代码级讲解运行cisaudit -t testdata/fixtures -f json | python3 -m json.tool把 JSON 输出逐字段回溯到run_checks、compute_scores、emit_json_report的实现上——当你能在头脑中把一条控制项从registry_data.sh一路追踪到报告里的 JSON 对象时你就真正吃透了这套架构。赞分享【免费下载链接】Cybersecurity-ProjectsBuilding 70 Projects ranging from beginner to advanced so anyone can — learn from, build upon, use as a reference, or even copy directly. Gamified Cybersecurity learning 项目地址https://gitcode.com/gh_mirrors/cy/Cybersecurity-Projects点击查看免费下载相关推荐ERPNext 免费开源 ERP30 分钟装完财务库存销售一套打通ERPNext 免费开源 ERP30 分钟装完财务库存销售一套打通 ERPNext 是一款代码全开源、完全免费的企业资源计划系统ERP一套平台覆盖记账FeHelper核心架构深度剖析Manifest V3规范与模块化设计FeHelper核心架构深度剖析Manifest V3规范与模块化设计 FeHelper前端助手作为一款功能强大的浏览器扩展工具其核心架构基于Chrom前端开发工具npx skills 交互式安装一条命令三次按键装好 AI 技能npx skills 交互式安装一条命令三次按键装好 AI 技能 第一次在终端里给 AI 助手装技能不用记任何参数。npx skills 交互式安装把整个过AI 技能CLI开发工具人工智能上一篇Civitai 功能开关清理审计从 flags 定义到消费者全链路排查的实战指南下一篇AURA Omni 在线推理部署指南基于 vLLM-Omni 的四阶段 ASR→VLM→TTS 全链路服务创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
