CIS Benchmark Level 2 для CentOS 7.2: 89 контролей закрываем Ansible, 21 требует разговора с заказчиком

CIS выпустил обновлённый Benchmark для CentOS Linux 7 - документ, который описывает рекомендуемую конфигурацию безопасности для корпоративных развёртываний. Мы как раз готовили базовый образ для нескольких клиентов и решили пройтись по Level 2 методично: каждый контроль - либо закрываем автоматически, либо фиксируем как «требует решения».

Результат: 89 контролей из 110 закрываются одним Ansible playbook-ом на чистом CentOS 7.2, ещё 21 - это разговор с заказчиком или ручная работа, которую автоматизировать нельзя без потери смысла.

Что такое Level 2 и зачем он нужен

CIS Benchmark существует в двух уровнях. Level 1 - базовый набор, минимальная безопасность без значительного влияния на функциональность. Level 2 - более жёсткий профиль, предназначен для сред с повышенными требованиями: финансовые системы, обработка ПДн, госсектор. Часть рекомендаций Level 2 реально ограничивает удобство - и это не баг, а фича.

Benchmark разбит на разделы: начальная настройка ОС, сервисы, сетевая конфигурация, ведение журналов, управление доступом, обслуживание системы. Каждый контроль описывает: что проверить, как проверить, как исправить. Документ достаточно подробный, но читать его подряд и применять руками на десяток серверов - занятие для мазохистов.

Отсюда идея: написать роль, которая закрывает всё автоматизируемое, и получить повторяемый результат.

Что ушло в Ansible без вопросов

Большинство контролей - это конфигурация, которая либо правильная, либо нет, и не зависит от контекста развёртывания. Такие вещи закрываются прямолинейно.

Файловые системы и монтирование. Отдельные точки монтирования для /tmp, /var, /var/log, /var/log/audit, /home с опциями noexec, nosuid, nodev где положено. CIS настаивает на этом потому, что атаки через временные директории и логи - классика. На большинстве минимальных образов этого нет из коробки.

Параметры ядра через sysctl. Отключение перенаправления IP-пакетов, игнорирование ICMP broadcast, защита от SYN flood через syncookies, запрет source routing - всё это пишется в /etc/sysctl.d/99-cis.conf и применяется одной задачей. Параметры не конфликтуют с типичной ролью сервера приложений.

Управление сервисами. Отключить всё, что не нужно на базовом образе: rsh, telnet, ypbind, tftp, chargen-dgram и ещё десяток сервисов, которые не должны работать вообще. systemd делает это через systemctl disable --now, Ansible - через модуль service.

PAM и парольная политика. Требования к паролям через pam_pwquality.so, история паролей через pam_pwhistory.so, блокировка аккаунта после N неудачных попыток через pam_faillock.so. Всё это правится в файлах /etc/pam.d/ и /etc/security/pwquality.conf.

SSH daemon. Классический список: PermitRootLogin no, Protocol 2, IgnoreRhosts yes, HostbasedAuthentication no, PermitEmptyPasswords no, PermitUserEnvironment no, настройка MaxAuthTries, таймаут сессии через ClientAliveInterval. Пишется шаблоном sshd_config.j2.

Ведение журналов. Настройка auditd с правилами из CIS: отслеживание изменений в /etc/passwd, /etc/shadow, /etc/group, изменений в sudo-конфигурации, запуска privileged-команд. Rsyslog для отправки на централизованный сервер логов - параметризованный через переменную.

Права на файлы. Проверка и выставление прав на критические файлы: /etc/passwd, /etc/shadow, /etc/gshadow, /etc/group, crontab-файлы. Ansible-модуль file с mode, owner, group - прямолинейно.

Итого это и есть основная масса контролей. Playbook прогоняется на чистом образе и занимает около пяти минут.

Что не автоматизируется

Оставшиеся 21 контроль - это не технические ограничения Ansible, а случаи, когда правильный ответ зависит от контекста или требует явного решения.

Разбивка диска. CIS требует отдельные разделы под /tmp, /var, /home и другие директории. На уже развёрнутой системе это не переделать без переустановки. На этапе создания образа - вопрос к тому, как делается образ: packer, kickstart, ручная установка. Если kickstart - можно параметризовать, но это другой уровень автоматизации.

Шифрование дисков. Level 2 рекомендует шифрование для переносных устройств и конфиденциальных данных. Включить LUKS на уже работающей системе без потери данных нельзя. Решение принимается на этапе проектирования, не настройки.

NTP и временные серверы. Технически настраивается, но адрес сервера времени - это параметр инфраструктуры, который мы не можем знать заранее. Playbook принимает его как переменную, но без значения по умолчанию: заказчик должен указать явно.

Баннеры. CIS требует /etc/issue, /etc/issue.net, /etc/motd с юридически корректным предупреждением об авторизованном доступе. Текст предупреждения - это документ, который согласовывается с юридическим отделом организации. Шаблон в роли есть, но содержимое - переменная.

Аудит sudo. Включение логирования всех sudo-команд через Defaults logfile - это просто. Но куда писать лог и как его ротировать - зависит от SIEM и инфраструктуры логирования клиента.

Ограничение cron и at. /etc/cron.allow и /etc/at.allow с явным списком пользователей. Список - это бизнес-решение: кому нужен cron. Playbook создаёт файлы с правами 600, содержимое - параметр роли.

Плюс несколько контролей типа «убедитесь, что не установлены пакеты X, Y, Z» - где X, Y, Z это конкретные пакеты типа ypserv, rsh-server, talk-server. Мы их удаляем безусловно, но на некоторых клиентских серверах такие пакеты могут использоваться намеренно. Документируем как явное исключение с обоснованием.

Как это используется

Роль применяется в два прохода. Первый - --check режим на целевой системе, который показывает что изменится без реальных изменений. Второй - боевой прогон. После этого запускается Ansible-based аудитор (отдельный playbook только с assert-задачами), который проверяет состояние и выдаёт отчёт: сколько контролей соответствует, какие нет.

Отчёт пригождается дважды: при сдаче образа заказчику как документация, и при проверке - как доказательство соответствия на конкретную дату.

Работу по подобному аудиту конфигурации мы ведём и для уже работающих систем - не только для новых образов. Там картина обычно интереснее.

Полный список контролей с разбивкой на автоматизированные и ручные ведём в отдельном документе. Если нужна роль под конкретный профиль или интеграция с вашим Ansible-стеком - пишите.