MIT License

技术解读

以下内容由 GitRead 中文社区 编辑团队基于项目 README 与官方资料整理, 结合中文开发者的常见使用场景补充技术选型建议。具体以项目官方文档为准。

Ansible CIS Benchmark Compliance Remediation for UBUNTU20

项目背景与痛点

在现代软件开发中,安全性已经成为不可忽视的重要环节。特别是在多云和混合云环境中,服务器配置管理的复杂性大大增加了。CIS(Center for Internet Security)基准是业界公认的黄金标准,用于配置加固Linux系统。然而,手动执行CIS配置既耗时又容易出错,对于大规模的运维团队来说更是如此。

面对这一痛点,ansible-lockdown/UBUNTU20-CIS 项目应运而生,它提供了一套自动化解决方案,能够帮助运维团队轻松实现Ubuntu 20.04系统的CIS基准配置。这不仅极大地简化了配置过程,还显著提高了系统的安全性和合规性。

核心技术揭秘

ansible-lockdown/UBUNTU20-CIS 利用Ansible作为自动化工具,通过一系列预定义的Playbooks和Roles来自动执行CIS基准的配置任务。Ansible的无代理架构确保了配置的执行效率,同时其幂等性保证了配置的稳定性和一致性。

技术栈与架构

项目中使用了Ansible Playbooks和Roles来构建复杂的配置逻辑,每个Playbook专门负责一个子系统的配置。Roles则封装了具体的配置任务,并可以方便地复用和管理。下面是一张Mermaid架构图,展示了项目的配置流程:

graph TD A[用户提交Ansible命令] --> B{"系统类型检查"} B -->|"Ubuntu 20.04"| C[运行CIS Playbook] B -->|"非Ubuntu 20.04"| D[失败并返回错误] C --> E[执行安全加固] C --> F[运行审核模块] C --> G[应用配置变更] E --> H[安全配置日志] F --> I{"配置合规性检查结果"} I -->|"通过"| J[输出合规报告] I -->|"不通过"| K[错误日志与重试]

核心算法与实现

ansible-lockdown/UBUNTU20-CIS 实现的关键算法包括:

  • 配置一致性检查:通过比较当前系统状态和预定义的CIS基准,找到需要调整的设置。
  • 按需自动化配置:利用Ansible Roles逐个执行配置任务,确保所有变更都能顺利应用并记录日志。
  • 配置合规性反馈:通过具体任务模块检查配置执行后的系统状态,并提供合规性报告。

功能亮点与差异

该项目的亮点在于其高度的自动化和全面的配置覆盖。相比手动配置,它大大减少了人工错误,确保了配置的一致性和可审计性。此外,借助Ansible的强大功能,该项目同样支持幂等执行和批量部署,有助于在复杂的多云环境中实现统一管理。

与同类产品相比,ansible-lockdown/UBUNTU20-CIS 的独特之处在于:

  • 易用性:通过简单的Ansible命令即可运行,无需额外工具或复杂配置。
  • 可扩展性:通过增加新的Roles,可以轻松扩展配置范围。
  • 审计友好:每个变更都记录在案,易于追踪与审查。

应用场景与落地建议

该项目非常适合需要快速实施CIS基准配置并确保高安全性的环境,具体应用案例包括:

  • 容器化基础设施:确保所有容器节点都在统一的安全配置下运行。
  • DevSecOps流水线:将安全性与开发流程结合,确保系统上线前满足合规要求。
  • 多云管理:在多个云服务提供商之间保持一致的安全策略。

在实际生产环境中使用时,建议:

  • 定期审核:确保系统持续满足CIS基准要求。
  • 备份配置:执行变更前备份现有设置,以便在必要时回滚。
  • 测试环境先行:在实际部署前,先在测试环境中验证配置的有效性和合规性。

综合评价

综上所述,ansible-lockdown/UBUNTU20-CIS 项目提供了一种高效、安全和自动化的CIS基准配置方案。它通过Ansible Playbooks和Roles,简化了系统配置过程,并确保了高合规性和安全性。不过,项目在依赖Ansible的前提下,对其学习曲线有一定要求。此外,还需注意系统环境的兼容性与备份机制。

总的来说,这是一个值得推荐的安全加固工具,特别是对于运维团队需要快速实施大规模自动化配置且重视系统安全性的场景。

README

Ubuntu 20 CIS

Configure a Ubuntu 20 machine to be CIS compliant

Based on CIS Ubuntu Linux 20.04 LTS Benchmark v3.0.0


Public Repository 📣

Org Stars Stars Forks Followers X URL

Discord Badge

License

Lint & Pre-Commit Tools 🔧

YamlLint Ansible-Lint

Community Release Information 📂

Release Branch Release Tag Release Date

Main Pipeline Status

Devel Pipeline Status Devel Commits

Issues Open Issues Closed Pull Requests

License


Looking for support? 🤝

Lockdown Enterprise

Ansible support

Community 💬

On our Discord Server to ask questions, discuss features, or just chat with other Ansible-Lockdown users


🚨 Caution(s) 🚨

This role will make changes to the system which may have unintended consequences. This is not an auditing tool but rather a remediation tool to be used after an audit has been conducted.

  • Testing is the most important thing you can do.

  • Check Mode is not guaranteed! 🚫 The role will complete in check mode without errors, but it is not supported and should be used with caution.

  • This role was developed against a clean install of the Operating System. If you are implementing to an existing system please review this role for any site specific changes that are needed.

  • To use release version please point to main branch and relevant release for the cis benchmark you wish to work with.

  • Did we mention testing??


Coming From A Previous Release ⏪

CIS release always contains changes, it is highly recommended to review the new references and available variables. This have changed significantly since ansible-lockdown initial release. This is now compatible with python3 if it is found to be the default interpreter. This does come with pre-requisites which it configures the system accordingly.

Further details can be seen in the Changelog


Matching a security Level for CIS

It is possible to only run level 1 or level 2 controls for CIS. This is managed using tags:

  • level1-server
  • level1-workstation
  • level2-server
  • level2-workstation

The control found in defaults main also need to reflect this as this control the testing that takes place if you are using the audit component.


Requirements ✅

General:

  • Basic knowledge of Ansible, below are some links to the Ansible documentation to help get started if you are unfamiliar with Ansible

  • Functioning Ansible and/or Tower Installed, configured, and running. This includes all of the base Ansible/Tower configurations, needed packages installed, and infrastructure setup.

  • Please read through the tasks in this role to gain an understanding of what each control is doing. Some of the tasks are disruptive and can have unintended consequences in a live production system. Also familiarize yourself with the variables in the defaults/main.yml file.

Technical Dependencies:

UBUNTU 20 - Other versions are not supported.

  • Access to download or add the goss binary and content to the system if using auditing (other options are available on how to get the content to the system.)
  • Python3.8
  • Ansible 2.12+
  • python-def
  • libselinux-python

Auditing 🔍

This can be turned on or off within the defaults/main.yml file with the variable run_audit. The value is false by default, please refer to the wiki for more details. The defaults file also populates the goss checks to check only the controls that have been enabled in the ansible role.

This is a much quicker, very lightweight, checking (where possible) config compliance and live/running settings.

A new form of auditing has been developed, by using a small (12MB) go binary called goss along with the relevant configurations to check. Without the need for infrastructure or other tooling. This audit will not only check the config has the correct setting but aims to capture if it is running with that configuration also trying to remove false positives in the process.

Refer to UBUNTU20-CIS-Audit.

Example Audit Summary

This is based on a vagrant image with selections enabled. e.g. No Gui or firewall. Note: More tests are run during audit as we check config and running state.


ok: [default] => {
    "msg": [
        "msg": [
        "The pre remediation audit results are: Count: 763, Failed: 234, Skipped: 4, Duration: 9.741s",
        "The post remediation audit results are: Count: 763, Failed: 19, Skipped: 4, Duration: 12.725s",
        "Full breakdown can be found in /opt",
        ""
    ]
}

PLAY RECAP *******************************************************************************************************************************************
default                    : ok=270  changed=23   unreachable=0    failed=0    skipped=140  rescued=0    ignored=0

Documentation 📖

Ansible Collections (install via ansible-galaxy collection install -r collections/requirements.yml):

  • community.general
  • community.crypto
  • ansible.posix

Python packages:

  • python-def
  • libselinux-python

Galaxy dependencies: None (meta/main.yml declares no role dependencies)

Role Variables

This role is designed that the end user should not have to edit the tasks themselves. All customizing should be done via the defaults/main.yml file or with extra vars within the project, job, workflow, etc.

See defaults/main.yml for the complete list of 250+ individual rule toggles organized by section.

Tags 🏷️

There are many tags available for added control precision. Each control has its own set of tags noting what level, what OS element it relates to, whether it’s a patch or audit, and the rule number. Additionally, NIST references follow a specific conversion format for consistency and clarity.

Conversion Format for NIST References:

  1. Standard Prefix:
- All references are prefixed with "NIST".
  1. Standard Types:
- "800-53" references are formatted as NIST800-53.
- "800-53r5" references are formatted as NIST800-53R5 (with 'R' capitalized).
- "800-171" references are formatted as NIST800-171.
  1. Details:
- Section and subsection numbers use periods (.) for numeric separators.
- Parenthetical elements are separated by underscores (_), e.g., IA-5(1)(d) becomes IA-5_1_d.
- Subsection letters (e.g., "b") are appended with an underscore.

Below is an example of the tag section from a control within this role. Using this example if you set your run to skip all controls with the tag services, this task will be skipped. The opposite can also happen where you run only controls tagged with services.

      tags:
      - level1-server
      - level1-workstation
      - scored
      - avahi
      - services
      - patch
      - rule_2.2.4

Community Contribution 🧑‍🤝‍🧑

We encourage you (the community) to contribute to this role. Please read the rules below.

  • Your work is done in your own individual branch. Make sure to Signed-off-by and GPG sign all commits you intend to merge.
  • All community Pull Requests are pulled into the devel branch
  • Pull Requests into devel will confirm your commits have a GPG signature, Signed-off-by, and a functional test before being approved
  • Once your changes are merged and a more detailed review is complete, an authorized member will merge your changes into the main branch for a new release

Pipeline Testing 🔄

uses:

  • ansible-core 2.16
  • ansible collections - pulls in the latest version based on requirements file
  • runs the audit using the devel branch
  • This is an automated test that occurs on pull requests into devel
  • self-hosted runners using OpenTofu

Known Issues

Local Testing 💻

example

molecule test -s default
molecule converge -s wsl -- --check
molecule verify -s localhost

local testing uses:

  • ansible-core
  • molecule 4.0.1
  • molecule-docker 2.0.0
  • molecule-podman 2.0.2
  • molecule-vagrant 1.0.0
  • molecule-azure 0.5.0

Credits and Thanks 🙏

Massive thanks to the fantastic community and all its members.

This includes a huge thanks and credit to the original authors and maintainers.

Mark Bolwell, George Nalen, Steve Williams, Fred Witty

评论

暂无评论