Одит на Linux сигурността с Lynis, OpenSCAP и Ansible — практическо ръководство

Защо одитът на сигурността е следващата критична стъпка

Ако сте следили предишните ни ръководства, вече имате доста солидна основа — укрепена защитна стена с nftables, модерна SSH конфигурация с пост-квантова криптография, система за откриване на проникване с auditd, AIDE и Wazuh и защитени Docker контейнери. Но остава един въпрос, който повечето хора пропускат: откъде знаете, че всичко наистина работи правилно?

Ръчната проверка на стотици конфигурационни параметри е, честно казано, кошмар. Човешкият фактор е неизбежен — пропуснат параметър в sysctl.conf, забравен отворен порт, права за достъп, които „временно" бяха разширени преди шест месеца и някак си никога не бяха върнати. Познато, нали?

Тук влизат инструментите за автоматизиран одит. Те систематично проверяват конфигурацията на системата спрямо утвърдени стандарти (CIS Benchmarks, DISA STIG, PCI DSS, ISO 27001) и генерират доклади с конкретни препоръки за отстраняване на проблемите.

А числата говорят сами за себе си: според Verizon Data Breach Investigations Report за 2025 г., 68% от пробивите включват грешка в конфигурацията като основен или допринасящ фактор. Datadog DevSecOps Report 2026 пък показва, че организациите с автоматизиран одит откриват и отстраняват уязвимости 4.7 пъти по-бързо. Това не е маловажно.

В това ръководство ще изградим система за одит и автоматизирано укрепване с три инструмента, които се допълват чудесно:

• Lynis — бърз одит с отворен код, който сканира системата и ви дава числов индекс на укрепване (hardening index)
• OpenSCAP — стандартизирано сканиране за съответствие с CIS, STIG и PCI DSS профили
• Ansible — автоматизирано прилагане на корекции и поддържане на съответствието във времето

Всички примери са тествани на Ubuntu 24.04 LTS и RHEL 9 с Lynis 3.1.6, OpenSCAP 1.4.x и Ansible 2.17+ към март 2026 г.

1. Lynis — бърз и задълбочен одит от командния ред

Lynis е инструмент с отворен код, разработван от CISOfy от 2007 г. насам. Извършва над 300 индивидуални проверки — ядро, удостоверяване, файлова система, мрежа, криптография, инсталиран софтуер и още. Накрая получавате числов индекс на укрепване (0–100) и списък с конкретни препоръки.

Защо точно Lynis? Защото е бърз, не изисква агент, работи на почти всяка Unix-подобна система и — може би най-важното — е напълно безопасен за продуктивни среди. Lynis само чете и анализира. Не пипа нищо.

1.1. Инсталация

Има няколко начина за инсталиране. Лично аз предпочитам официалното хранилище на CISOfy, защото пакетите в дистрибуциите понякога изостават с версиите:

# Метод 1: Официално хранилище на CISOfy (препоръчителен)
# Debian / Ubuntu
sudo apt install apt-transport-https
curl -fsSL https://packages.cisofy.com/keys/cisofy-software-public.key | sudo gpg --dearmor -o /etc/apt/keyrings/cisofy.gpg
echo "deb [signed-by=/etc/apt/keyrings/cisofy.gpg] https://packages.cisofy.com/community/lynis/deb/ stable main" | sudo tee /etc/apt/sources.list.d/cisofy-lynis.list
sudo apt update && sudo apt install lynis

# RHEL / Fedora / AlmaLinux
sudo tee /etc/yum.repos.d/cisofy-lynis.repo <<EOF
[cisofy-lynis]
name=CISOfy Software - Lynis package
baseurl=https://packages.cisofy.com/community/lynis/rpm/
enabled=1
gpgkey=https://packages.cisofy.com/keys/cisofy-software-rpms-public.key
gpgcheck=1
priority=2
EOF
sudo dnf install lynis

# Метод 2: Директно от системното хранилище (по-стара версия)
# Debian / Ubuntu
sudo apt install lynis
# RHEL / Fedora
sudo dnf install lynis

# Метод 3: Директно от GitHub (за най-новата версия)
cd /opt
sudo git clone https://github.com/CISOfy/lynis.git
cd lynis
sudo ./lynis audit system

# Проверка на версията
lynis show version
# Очаквано: 3.1.6 (към март 2026 г.)

1.2. Първи одит

Стартирайте пълен одит на системата. Много важно — изпълнете го като root. В противен случай куп проверки ще бъдат пропуснати и резултатът ще е подвеждащо нисък:

# Пълен одит на системата (задължително с root права)
sudo lynis audit system

# Одит с подробен изход (полезно при дебъгване)
sudo lynis audit system --verbose

# Бърз одит без интерактивно изчакване
sudo lynis audit system --quick

# Запис на резултатите в отделен лог файл
sudo lynis audit system --logfile /var/log/lynis-audit-$(date +%Y%m%d).log

Одитът отнема някъде 2–5 минути в зависимост от системата. Lynis показва категории проверки в реално време — ядро, памет, удостоверяване, мрежа, файлова система и т.н. Доста е приятно за гледане, между другото.

1.3. Разчитане на резултатите

След приключване Lynis показва обобщение. Ето какво означават ключовите неща:

# Преглед на индекса на укрепване
sudo lynis show details
# Hardening index : 62 [############        ]
# Tests performed : 284
# Warnings        : 5
# Suggestions     : 38

# Преглед само на предупрежденията (критични проблеми)
sudo grep -E "^warning" /var/log/lynis.log

# Преглед само на предложенията за подобрение
sudo grep -E "^suggestion" /var/log/lynis.log

# Детайлен доклад
cat /var/log/lynis-report.dat | grep "suggestion\[\]"

Какво означава числото? Чисто нова инсталация на Ubuntu 24.04 обикновено получава някъде 55–65 точки. След прилагане на укрепването от предишните ни ръководства (nftables, SSH, auditd) резултатът скача до 72–78. За продуктивен сървър целете 80+, а за среди с високи изисквания — 85+.

1.4. Разбиране на конкретни препоръки

Всяка препоръка идва с уникален идентификатор (AUTH-9328, KRNL-5820 и т.н.), описание и в повечето случаи — конкретна команда за отстраняване. Ето примери за най-често срещаните:

# Примерна препоръка: AUTH-9328 — Default umask в login.defs
# Описание: Стойността на UMASK в /etc/login.defs трябва да бъде 027 вместо 022
# Решение:
sudo sed -i 's/^UMASK.*022/UMASK\t\t027/' /etc/login.defs

# Примерна препоръка: KRNL-5820 — Kernel hardening sysctl параметри
# Описание: Препоръчителни sysctl настройки за укрепване на ядрото
# Решение:
sudo tee /etc/sysctl.d/99-lynis-hardening.conf <<EOF
kernel.kptr_restrict = 2
kernel.dmesg_restrict = 1
kernel.yama.ptrace_scope = 2
kernel.unprivileged_bpf_disabled = 1
net.core.bpf_jit_harden = 2
kernel.kexec_load_disabled = 1
EOF
sudo sysctl --system

# Примерна препоръка: FILE-6310 — /tmp на отделен дял
# Описание: /tmp трябва да бъде монтиран на отделен дял с noexec,nosuid,nodev
# Решение (ако /tmp не е на отделен дял):
echo "tmpfs /tmp tmpfs defaults,rw,nosuid,nodev,noexec,relatime,size=2G 0 0" | sudo tee -a /etc/fstab
sudo mount -o remount /tmp

1.5. Автоматизиран одит с cron

Еднократният одит е хубаво нещо, но истинската стойност идва от редовните проверки. Нека настроим автоматично изпълнение:

# Ежедневен одит в 3:00 сутринта с изпращане на резултатите по имейл
sudo tee /etc/cron.d/lynis-audit <<EOF
0 3 * * * root /usr/bin/lynis audit system --cronjob --quiet 2>&1 | mail -s "Lynis Audit Report - \$(hostname) - \$(date +\%F)" [email protected]
EOF

# Скрипт за проследяване на промените в индекса
sudo tee /usr/local/bin/lynis-trend.sh <<'SCRIPT'
#!/bin/bash
SCORE=$(lynis audit system --cronjob --quiet 2>/dev/null | grep "Hardening index" | awk '{print $4}')
echo "$(date +%F),$SCORE" >> /var/log/lynis-trend.csv
# Алармирайте, ако индексът падне под 75
if [ "$SCORE" -lt 75 ]; then
    echo "WARNING: Lynis hardening index dropped to $SCORE on $(hostname)" | \
    mail -s "SECURITY ALERT: Low Hardening Index" [email protected]
fi
SCRIPT
sudo chmod +x /usr/local/bin/lynis-trend.sh

2. OpenSCAP — стандартизиран одит за съответствие

Докато Lynis е страхотен за бърза оценка, OpenSCAP предлага нещо доста различно — формален одит за съответствие спрямо конкретни индустриални стандарти. OpenSCAP е референтната имплементация на SCAP (Security Content Automation Protocol) на NIST и се използва от правителствени агенции, финансови институции и всеки, който трябва да докаже съответствие с определен стандарт.

Ключовата разлика е проста: Lynis казва „ето какво може да се подобри", а OpenSCAP казва „ето доколко съответствате на стандарт X, правило по правило". За одитори — втората опция е много по-полезна.

2.1. Инсталация и подготовка

# Debian / Ubuntu
sudo apt update
sudo apt install libopenscap8 ssg-debian ssg-base openscap-scanner

# RHEL / Fedora / AlmaLinux (обикновено вече е инсталиран)
sudo dnf install openscap-scanner scap-security-guide openscap-utils

# Проверка на инсталацията
oscap --version
# Очаквано: OpenSCAP command line tool (oscap) 1.4.x

# Преглед на наличните SCAP профили
ls /usr/share/xml/scap/ssg/content/
# Ще видите файлове като ssg-ubuntu2404-ds.xml, ssg-rhel9-ds.xml и т.н.

2.2. Преглед на наличните профили

SCAP Security Guide (SSG) предоставя профили за различни стандарти. Ето как да видите какво имате на разположение:

# Списък на наличните профили за Ubuntu 24.04
oscap info /usr/share/xml/scap/ssg/content/ssg-ubuntu2404-ds.xml

# За RHEL 9
oscap info /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

# Типични профили, които ще видите:
# xccdf_org.ssgproject.content_profile_cis_level1_server  — CIS Level 1 (Server)
# xccdf_org.ssgproject.content_profile_cis_level2_server  — CIS Level 2 (Server)
# xccdf_org.ssgproject.content_profile_stig               — DISA STIG
# xccdf_org.ssgproject.content_profile_pci-dss            — PCI DSS v4.0.1
# xccdf_org.ssgproject.content_profile_standard           — Standard System Security

2.3. Изпълнение на сканиране за CIS съответствие

Нека направим пълно сканиране спрямо CIS Level 1 — това е най-разпространеният бенчмарк за продуктивни сървъри:

# Сканиране за CIS Level 1 съответствие (Ubuntu 24.04)
sudo oscap xccdf eval \
    --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
    --results /tmp/cis-results.xml \
    --report /tmp/cis-report.html \
    /usr/share/xml/scap/ssg/content/ssg-ubuntu2404-ds.xml

# Сканиране за CIS Level 1 съответствие (RHEL 9)
sudo oscap xccdf eval \
    --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
    --results /tmp/cis-results.xml \
    --report /tmp/cis-report.html \
    /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

# Сканиране за DISA STIG съответствие
sudo oscap xccdf eval \
    --profile xccdf_org.ssgproject.content_profile_stig \
    --results /tmp/stig-results.xml \
    --report /tmp/stig-report.html \
    /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

Генерираният HTML доклад (/tmp/cis-report.html) е доста детайлен и визуално ясен — за всяко правило виждате pass, fail или notapplicable. Хубавото е, че този доклад можете директно да покажете на одитори без допълнителна обработка.

2.4. Автоматично генериране на корекции

Едно от най-полезните неща в OpenSCAP е автоматичното генериране на скриптове за отстраняване на несъответствията. Да, чухте правилно — генерира ви готов скрипт:

# Генериране на Bash скрипт за корекция на несъответствията
sudo oscap xccdf generate fix \
    --fix-type bash \
    --result-id "" \
    /tmp/cis-results.xml > /tmp/cis-remediation.sh

# Генериране на Ansible playbook за корекция
sudo oscap xccdf generate fix \
    --fix-type ansible \
    --result-id "" \
    /tmp/cis-results.xml > /tmp/cis-remediation.yml

# ВАЖНО: Винаги прегледайте генерираните скриптове преди изпълнение!
# Никога не изпълнявайте автоматично генерирани корекции сляпо
less /tmp/cis-remediation.sh

# След внимателен преглед, приложете корекциите:
sudo bash /tmp/cis-remediation.sh

# Повторно сканиране за проверка на напредъка
sudo oscap xccdf eval \
    --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
    --results /tmp/cis-results-after.xml \
    --report /tmp/cis-report-after.html \
    /usr/share/xml/scap/ssg/content/ssg-ubuntu2404-ds.xml

2.5. Сканиране на отдалечени системи

OpenSCAP поддържа сканиране по SSH, което е изключително удобно когато управлявате повече от един-два сървъра:

# Сканиране на отдалечена система чрез SSH
sudo oscap-ssh [email protected] 22 xccdf eval \
    --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
    --results /tmp/remote-cis-results.xml \
    --report /tmp/remote-cis-report.html \
    /usr/share/xml/scap/ssg/content/ssg-ubuntu2404-ds.xml

2.6. Персонализиране на профили

На практика рядко един стандартен профил отговаря изцяло на нуждите на конкретна организация. OpenSCAP позволява персонализиране чрез т.нар. tailoring файлове:

# Генериране на tailoring файл от съществуващ профил
# Използвайте SCAP Workbench за графичен интерфейс:
sudo apt install scap-workbench   # Debian/Ubuntu
sudo dnf install scap-workbench   # RHEL/Fedora

# Или ръчно създайте tailoring файл за деактивиране на конкретни правила
# Пример: деактивиране на правилото за отделен /home дял
# (ако използвате облачен сървър с единичен диск)

# Сканиране с персонализиран tailoring файл
sudo oscap xccdf eval \
    --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
    --tailoring-file /etc/scap/my-tailoring.xml \
    --results /tmp/custom-results.xml \
    --report /tmp/custom-report.html \
    /usr/share/xml/scap/ssg/content/ssg-ubuntu2404-ds.xml

3. Ansible — автоматизирано укрепване и непрекъснато съответствие

Добре, Lynis и OpenSCAP ви показват какво трябва да се поправи. Но ръчното прилагане на десетки корекции върху десетки сървъри? Не, благодаря. Тук идва Ansible — той превръща одитните изисквания в изпълним код и автоматизира целия процес.

Проектът Ansible Lockdown предоставя готови роли, които директно имплементират CIS Benchmarks и DISA STIG за основните Linux дистрибуции. Всяка роля покрива стотици контроли и поддържа два режима: audit (само проверка) и enforce (автоматична корекция). Доста удобно, нали?

3.1. Подготовка на Ansible среда

# Инсталиране на Ansible (ако все още не е инсталиран)
# Debian / Ubuntu
sudo apt install ansible-core

# RHEL / Fedora
sudo dnf install ansible-core

# Чрез pip (за най-новата версия)
pip3 install ansible-core

# Проверка на версията
ansible --version
# Очаквано: ansible-core 2.17.x+

# Създаване на директория за проекта
mkdir -p ~/security-audit/{inventory,playbooks,roles}
cd ~/security-audit

3.2. Инсталиране на CIS Hardening роли

# Инсталиране на CIS роля за Ubuntu 24.04 от Ansible Lockdown
ansible-galaxy install git+https://github.com/ansible-lockdown/UBUNTU24-CIS.git

# Инсталиране на CIS роля за RHEL 9
ansible-galaxy install git+https://github.com/ansible-lockdown/RHEL9-CIS.git

# Алтернативно — ролята devsec.hardening от Ansible Galaxy
# (по-лека, но покрива SSH, sysctl и OS укрепване)
ansible-galaxy collection install devsec.hardening

# Преглед на инсталираните роли
ansible-galaxy list

3.3. Inventory файл

# ~/security-audit/inventory/hosts.yml
---
all:
  children:
    webservers:
      hosts:
        web01:
          ansible_host: 192.168.1.10
          ansible_user: deploy
        web02:
          ansible_host: 192.168.1.11
          ansible_user: deploy
    databases:
      hosts:
        db01:
          ansible_host: 192.168.1.20
          ansible_user: deploy
  vars:
    ansible_become: true
    ansible_become_method: sudo

3.4. Playbook за CIS одит (само проверка)

Винаги започвайте с режим на одит. Ще сканира системите без да прави промени — нещо като dry-run:

# ~/security-audit/playbooks/cis-audit.yml
---
- name: CIS Benchmark Audit - само проверка
  hosts: all
  become: true

  vars:
    # Режим само на одит — НЕ прави промени
    ubtu24cis_run_audit: true
    ubtu24cis_skip_reboot: true

    # Секция 1: Начална настройка
    ubtu24cis_rule_1_1_1_1: true   # Деактивиране на cramfs
    ubtu24cis_rule_1_1_1_2: true   # Деактивиране на freevxfs
    ubtu24cis_rule_1_1_1_3: true   # Деактивиране на hfs
    ubtu24cis_rule_1_1_1_4: true   # Деактивиране на hfsplus
    ubtu24cis_rule_1_1_1_5: true   # Деактивиране на squashfs

    # Секция 5: Достъп и удостоверяване
    ubtu24cis_rule_5_2_1: true     # SSH конфигурация
    ubtu24cis_rule_5_3_1: true     # Политика за пароли

  roles:
    - UBUNTU24-CIS

# Изпълнение на одита
ansible-playbook -i inventory/hosts.yml playbooks/cis-audit.yml --check --diff

# Резултатите ще покажат какво БИ БИЛО променено, без реална промяна
# changed=15 означава 15 контроли, които не са в съответствие

3.5. Playbook за автоматично укрепване

След като прегледате резултатите от одита и сте уверени какво ще се промени, можете да пуснете укрепването. Но — и това е важно — първо тествайте на един сървър:

# ~/security-audit/playbooks/cis-harden.yml
---
- name: CIS Benchmark Hardening - прилагане на корекции
  hosts: all
  become: true

  vars:
    # Активиране на укрепването
    ubtu24cis_run_audit: true

    # Деактивирайте правила, които НЕ са подходящи за вашата среда
    # Например: ако имате единичен диск, пропуснете правилата за отделни дялове
    ubtu24cis_rule_1_1_2_1: false  # Отделен /tmp дял (не е приложимо за облак)
    ubtu24cis_rule_1_1_2_2: false  # Отделен /var дял

    # Конфигуриране на специфични стойности
    ubtu24cis_time_synchronization_service: chrony
    ubtu24cis_sshd:
      log_level: VERBOSE
      max_auth_tries: 3
      permit_root_login: "no"
      client_alive_interval: 300
      client_alive_count_max: 2
      login_grace_time: 60

    # Sysctl укрепване на ядрото
    ubtu24cis_sysctl_settings:
      kernel.randomize_va_space: 2
      kernel.kptr_restrict: 2
      kernel.dmesg_restrict: 1
      kernel.yama.ptrace_scope: 2
      net.ipv4.conf.all.send_redirects: 0
      net.ipv4.conf.all.accept_redirects: 0
      net.ipv4.conf.all.rp_filter: 1
      net.ipv4.tcp_syncookies: 1

  roles:
    - UBUNTU24-CIS

  post_tasks:
    - name: Изпълни Lynis одит след укрепването
      command: lynis audit system --cronjob --quiet
      register: lynis_result
      changed_when: false

    - name: Запиши индекса на укрепване
      debug:
        msg: "Lynis Hardening Index след укрепването: {{ lynis_result.stdout | regex_search('Hardening index : ([0-9]+)', '\\1') | first }}"

# Изпълнение — ПЪРВО на един тестов сървър!
ansible-playbook -i inventory/hosts.yml playbooks/cis-harden.yml --limit web01

# След успешен тест — прилагане върху всички сървъри
ansible-playbook -i inventory/hosts.yml playbooks/cis-harden.yml

3.6. Интеграция на Lynis с Ansible

Можете да автоматизирате Lynis одита чрез Ansible и да събирате резултатите на едно място. Ето един playbook, който го прави:

# ~/security-audit/playbooks/lynis-scan.yml
---
- name: Централизиран Lynis одит на всички сървъри
  hosts: all
  become: true

  tasks:
    - name: Уверете се, че Lynis е инсталиран
      package:
        name: lynis
        state: present

    - name: Изпълнение на Lynis одит
      command: lynis audit system --cronjob --quiet
      register: lynis_output
      changed_when: false

    - name: Извличане на индекса на укрепване
      set_fact:
        hardening_index: "{{ lynis_output.stdout | regex_search('Hardening index : ([0-9]+)', '\\1') | first | default('N/A') }}"

    - name: Извличане на броя предупреждения
      set_fact:
        warning_count: "{{ lynis_output.stdout | regex_search('Warnings[^:]*: ([0-9]+)', '\\1') | first | default('0') }}"

    - name: Показване на резултатите
      debug:
        msg: |
          Хост: {{ inventory_hostname }}
          Индекс на укрепване: {{ hardening_index }}
          Предупреждения: {{ warning_count }}

    - name: Копиране на детайлния доклад
      fetch:
        src: /var/log/lynis-report.dat
        dest: "/tmp/lynis-reports/{{ inventory_hostname }}-report.dat"
        flat: true

    - name: АЛЕРТ — ниско ниво на укрепване
      fail:
        msg: "ВНИМАНИЕ: Индексът на укрепване на {{ inventory_hostname }} е {{ hardening_index }} (под 75)!"
      when: hardening_index | int < 75
      ignore_errors: true

# Изпълнение на централизиран одит
ansible-playbook -i inventory/hosts.yml playbooks/lynis-scan.yml

# Резултатите ще бъдат показани за всеки хост, а докладите —
# копирани в /tmp/lynis-reports/ за централен анализ

4. Интеграция в CI/CD — непрекъснато съответствие

Тук нещата стават наистина интересни. Когато интегрирате одита в CI/CD пайплайна, всяка промяна в инфраструктурата автоматично се проверява за съответствие. Никой не може да „забрави" да пусне сканиране.

4.1. GitHub Actions пример

# .github/workflows/security-audit.yml
name: Security Compliance Audit

on:
  push:
    branches: [main]
    paths:
      - 'ansible/**'
      - 'infrastructure/**'
  schedule:
    # Ежеседмично сканиране — всяка неделя в 02:00 UTC
    - cron: '0 2 * * 0'

jobs:
  compliance-audit:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4

      - name: Install audit tools
        run: |
          sudo apt-get update
          sudo apt-get install -y lynis libopenscap8 ssg-base

      - name: Run Lynis audit
        run: |
          sudo lynis audit system --cronjob --quiet
          SCORE=$(sudo grep "hardening_index" /var/log/lynis-report.dat | cut -d= -f2)
          echo "LYNIS_SCORE=$SCORE" >> $GITHUB_ENV
          if [ "$SCORE" -lt 70 ]; then
            echo "::error::Lynis hardening index ($SCORE) is below threshold (70)"
            exit 1
          fi

      - name: Run OpenSCAP CIS scan
        run: |
          sudo oscap xccdf eval \
            --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
            --results results.xml \
            --report report.html \
            /usr/share/xml/scap/ssg/content/ssg-ubuntu2404-ds.xml || true

      - name: Upload compliance reports
        uses: actions/upload-artifact@v4
        with:
          name: compliance-reports
          path: |
            report.html
            /var/log/lynis-report.dat

4.2. GitLab CI пример

# .gitlab-ci.yml
security-audit:
  stage: test
  image: ubuntu:24.04
  script:
    - apt-get update && apt-get install -y lynis openscap-scanner ssg-base
    - lynis audit system --cronjob --quiet
    - |
      SCORE=$(grep "hardening_index" /var/log/lynis-report.dat | cut -d= -f2)
      echo "Lynis Hardening Index: $SCORE"
      if [ "$SCORE" -lt 70 ]; then
        echo "FAILED: Score below threshold"
        exit 1
      fi
    - oscap xccdf eval
        --profile xccdf_org.ssgproject.content_profile_cis_level1_server
        --results cis-results.xml
        --report cis-report.html
        /usr/share/xml/scap/ssg/content/ssg-ubuntu2404-ds.xml || true
  artifacts:
    paths:
      - cis-report.html
      - /var/log/lynis-report.dat
    when: always
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"
    - if: $CI_COMMIT_BRANCH == "main"
      changes:
        - ansible/**
        - infrastructure/**

5. Lynis срещу OpenSCAP — кога кое да използвате

Нека си го кажем направо — двата инструмента не се конкурират. Те се допълват и имат различни силни страни:

• Ежедневен мониторинг → Lynis (бърз, лек, ясен индекс)
• Формален одит за одитори → OpenSCAP (стандартизирани доклади, профили по стандарти)
• PCI DSS / HIPAA / STIG съответствие → OpenSCAP (директни профили за тези стандарти)
• Бърза оценка на нов сървър → Lynis (работи без конфигурация, дава моментална оценка)
• Автоматизирано укрепване → Ansible Lockdown + двата инструмента за валидация

Най-добрият подход според мен е тристепенна стратегия:

1. Lynis ежедневно — за бързо следене на тенденцията в индекса на укрепване
2. OpenSCAP ежеседмично — за формална проверка на съответствието с избрания стандарт
3. Ansible ежемесечно — за автоматично прилагане на натрупаните корекции

6. Практически сценарий: От нулата до 85+ точки

Нека обединим всичко в един конкретен сценарий. Имате нов Ubuntu 24.04 сървър и искате да го доведете до ниво на укрепване 85+. Ето как става стъпка по стъпка.

Стъпка 1: Първоначален одит

# Инсталирайте инструментите
sudo apt install lynis libopenscap8 ssg-base ansible-core

# Изпълнете първоначален Lynis одит
sudo lynis audit system
# Очакван резултат: ~58-62 за нов Ubuntu 24.04

# Изпълнете OpenSCAP CIS Level 1 сканиране
sudo oscap xccdf eval \
    --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
    --report /tmp/initial-cis.html \
    /usr/share/xml/scap/ssg/content/ssg-ubuntu2404-ds.xml
# Очакван резултат: ~45-55% покритие

Стъпка 2: Автоматизирано укрепване с Ansible

# Инсталирайте CIS ролята
ansible-galaxy install git+https://github.com/ansible-lockdown/UBUNTU24-CIS.git

# Приложете укрепването (първо с --check за преглед)
ansible-playbook cis-harden.yml --check --diff
# Прегледайте промените

# Приложете реално
ansible-playbook cis-harden.yml

Стъпка 3: Повторен одит и финална настройка

# Повторен Lynis одит
sudo lynis audit system
# Очакван резултат: ~78-82

# Ръчни корекции на останалите предложения
# Прегледайте: sudo grep "suggestion" /var/log/lynis.log

# Типични оставащи елементи:
# 1. Настройка на NTP/chrony за точна синхронизация
sudo apt install chrony
sudo systemctl enable chrony

# 2. Деактивиране на ненужни ядрени модули
sudo tee /etc/modprobe.d/hardening.conf <<EOF
install cramfs /bin/false
install freevxfs /bin/false
install hfs /bin/false
install hfsplus /bin/false
install udf /bin/false
install usb-storage /bin/false
EOF

# 3. Активиране на process accounting
sudo apt install acct
sudo systemctl enable acct

# Финален одит
sudo lynis audit system
# Очакван резултат: 85+

Стъпка 4: Автоматизация на продължаващия мониторинг

# Настройте cron за ежедневен Lynis одит
echo "0 3 * * * root /usr/bin/lynis audit system --cronjob" | sudo tee /etc/cron.d/lynis

# Настройте cron за ежеседмичен OpenSCAP одит
echo "0 4 * * 0 root /usr/bin/oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis_level1_server --report /var/log/scap/weekly-\$(date +\%F).html /usr/share/xml/scap/ssg/content/ssg-ubuntu2404-ds.xml" | sudo tee /etc/cron.d/openscap

# Създайте директория за SCAP доклади
sudo mkdir -p /var/log/scap

7. Често допускани грешки и как да ги избегнете

Ето грешките, които виждам отново и отново при работа с тези инструменти:

• Изпълнение на Lynis без root права — получавате подвеждащо нисък резултат, защото десетки проверки просто са пропуснати. Винаги използвайте sudo. Сериозно, това е грешка номер едно.
• Сляпо прилагане на всички CIS правила — не всяко правило е подходящо за вашата среда. Правило за отделен /home дял е безсмислено на облачна виртуална машина с един диск. Винаги прегледайте и персонализирайте.
• Еднократен одит без последващи проверки — съответствието е непрекъснат процес. Конфигурационно отклонение (configuration drift) е реално и неизбежно. Автоматизирайте редовните проверки, иначе си губите времето.
• Игнориране на tailoring файловете на OpenSCAP — ако деактивирате правило без tailoring файл, одиторът няма да знае защо. Документирайте изключенията си.
• Прилагане на укрепване без тестване — някои CIS правила могат буквално да счупят работещи приложения. Винаги тествайте първо в staging среда. Научих го по трудния начин.

Често задавани въпроси

Каква е разликата между Lynis и OpenSCAP?

Lynis е инструмент за бърз одит — дава ви общ индекс на укрепване и конкретни препоръки. OpenSCAP е за формален одит спрямо конкретни стандарти (CIS, STIG, PCI DSS). Ако искате бърза проверка, ползвайте Lynis. Ако трябва да покажете доклад на одитори — OpenSCAP е вашият инструмент.

Безопасно ли е да се изпълнява Lynis на продуктивен сървър?

Да, напълно. Lynis е инструмент само за четене — проверява конфигурации и права за достъп, но не пипа нищо по системата. Можете спокойно да го пуснете на всеки продуктивен сървър без риск от прекъсване.

Колко често трябва да се извършва одит на сигурността?

Препоръчвам следното: Lynis — ежедневно чрез cron (бързо е и не натоварва системата), OpenSCAP — ежеседмично, а пълен одит с Ansible и ръчен преглед — поне веднъж месечно. И разбира се, пускайте одит след всяка значима промяна в конфигурацията.

Мога ли да използвам тези инструменти за съответствие с PCI DSS?

Да. OpenSCAP има специализиран профил за PCI DSS v4.0.1 (xccdf_org.ssgproject.content_profile_pci-dss), който покрива техническите изисквания. Lynis също включва свързани проверки. Комбинацията от двата плюс Ansible за автоматизация дава солидна основа за PCI DSS съответствие.

Как да интегрирам одита на сигурността с Wazuh?

Ако вече ползвате Wazuh (както описахме в предишното ръководство), можете да вкарате резултатите от Lynis и OpenSCAP директно в него. Wazuh агентът поддържа SCA (Security Configuration Assessment) модул, който изпълнява проверки базирани на CIS Benchmarks и визуализира резултатите в централния dashboard. Така получавате единна точка за мониторинг на сигурността и съответствието — доста удобно е.