ServerAdmin.ru
31.6K subscribers
848 photos
57 videos
23 files
3K links
Авторская информация о системном администрировании.

Информация о рекламе: @srv_admin_reklama_bot
Автор: @zeroxzed

Второй канал: @srv_admin_live
Сайт: serveradmin.ru

Ресурс включён в перечень Роскомнадзора
Download Telegram
У меня в канале в разное время выходили разборы рекомендаций по безопасности от проекта CIS — Center for Internet Security. Кто не видел их, рекомендую. Я почерпнул оттуда некоторые настройки для своих установок. Сами документы объёмные. Постарался взять из них самую суть, которая пригодится в среднестатистическом применении:

▪️ Nginx
▪️ MySQL 5.7
▪️ Apache 2.4
▪️ Debian 11
▪️ Docker
▪️ Ubuntu 22.04 LTS
▪️ PostgreSQL 16

Софт с тех пор уже обновился, вышли новые рекомендации на основе старых, но я не прорабатывал обновления. Базовые настройки чаще всего остаются те же самые с минимальными изменениями.

Отдельно отмечу проект Docker Bench for Security, который автоматически проверяет образы Docker на соответствие рекомендациям CIS.

Сегодня хочу развить эту тему и познакомить вас с проектом CIS Debian 10/11/12 Hardening от известного международного хостера OVH, который когда-то сильно горел. Этот проект состоит из bash скриптов для проверки вашей системы на базе Debian на соответствие рекомендациям по безопасности.

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

Покажу кратко, как пользоваться этими скриптами. Клонируем репозиторий:

# git clone https://github.com/ovh/debian-cis.git && cd debian-cis

Создаём файл /etc/default/cis-hardening и добавляем туда информацию о директории, из которой мы будем запускать скрипты:

# cp debian/default /etc/default/cis-hardening
# sed -i "s#CIS_LIB_DIR=.*#CIS_LIB_DIR='$(pwd)'/lib#" /etc/default/cis-hardening
# sed -i "s#CIS_CHECKS_DIR=.*#CIS_CHECKS_DIR='$(pwd)'/bin/hardening#" /etc/default/cis-hardening
# sed -i "s#CIS_CONF_DIR=.*#CIS_CONF_DIR='$(pwd)'/etc#" /etc/default/cis-hardening
# sed -i "s#CIS_TMP_DIR=.*#CIS_TMP_DIR='$(pwd)'/tmp#" /etc/default/cis-hardening

Теперь можно запускать как по отдельности проверки, так и все разом. Проверки находятся в директории bin/hardening. На каждый тест – отдельный bash скрипт с осмысленным названием. Например, 1.1.11_var_log_partition.sh. Запускаем:

# ./1.1.11_var_log_partition.sh
1.1.11_var_log_partition [INFO] Working on 1.1.11_var_log_partition
1.1.11_var_log_partition [INFO] [DESCRIPTION] /var/log on separate partition.
1.1.11_var_log_partition [INFO] Checking Configuration
1.1.11_var_log_partition [INFO] Performing audit
1.1.11_var_log_partition [INFO] Verifying that /var/log is a partition
1.1.11_var_log_partition [ KO ] /var/log is not a partition
1.1.11_var_log_partition [ KO ] Check Failed

Я проверку провалил. У меня /var/log находится на корневом разделе. С точки зрения безопасности и стабильности работы системы это не очень хорошо. Во-первых, логи могут заполнить весь корневой раздел. Во-вторых, отдельный раздел под логи можно смонтировать для большей безопасности с некоторыми дополнительными настройками, типа noexec, nosuid, noatime и т.д. Я всё это понимаю, но мне чаще всего удобнее с одним общим разделом для всего.

Для того, чтобы запустить все тесты разом, можно использовать отдельный скрипт в папке bin:

# ./hardening.sh --audit

Будут выполнены все проверки, результат вывалится в консоль. Это неудобно, так как он может быть огромным. Лучше сразу направить вывод в текстовый файл:

# ./hardening.sh --audit > ~/cis.txt

Потом файл можно спокойно посмотреть, осмыслить. Смотреть удобно в less с подсветкой:

# less -R ~/cis.txt

В конце увидите итоговый результат:

Total Passed Checks : [ 102/243 ]
Total Failed Checks : [ 141/243 ]
Enabled Checks Percentage : 100.00 %
Conformity Percentage : 41.97 %

Его можно получить в json:

# ./hardening.sh --audit --summary-json

Для каждой проверки есть свой конфиг в etc/conf.d, где её можно настроить или отключить. По проверкам можно делать либо аудит, либо вносить изменения в систему.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#cis #security
2👍131👎2
На прошлой неделе делал подборку инструментов для логирования действий пользователя в консоли. В комментариях справедливо заметили, что всё это умеет делать практически штатный инструмент - auditd. Его всегда рекомендуют включать и настраивать в контексте вопросов безопасности. Например, в руководствах CIS (#cis) о нём всегда упоминают.

Auditd я знаю, иногда настраиваю. Я о нём писал, как об инструменте для контроля за изменениями файлов. С его помощью это сделать относительно просто. Но честно скажу, не очень его люблю. Настройка неинтуитивна, логи перенасыщены информацией, чтобы просто посмотреть лог и что-то там найти, надо вспоминать команды или грепать текстовый лог.

Тем не менее, auditd это линуксовая база, так что знать его полезно. Настроим в нём логирование пользовательских команд. Auditd будет записывать не только запущенную команду, но и реально выполненную, а так же сопутствующую информацию: рабочая директория, файлы, связанные с выполнением, системный вызов, pid, uid, gid, tty и другие вещи.

Устанавливаем auditd:

# apt install auditd

Создаём правило, добавив в файл /etc/audit/rules.d/audit.rules несколько новых строк:

-a always,exit -F arch=b64 -F euid=0 -F auid=0 -S execve -S execveat -k root_auth_command_execution
-a always,exit -F arch=b32 -F euid=0 -F auid=0 -S execve -S execveat -k root_auth_command_execution

-a always,exit -F arch=b64 -F auid!=-1 -S execve -S execveat -k generic_command_execution                                             
-a always,exit -F arch=b32 -F auid!=-1 -S execve -S execveat -k generic_command_execution


По совету читателя добавил два правила: для пользователя root и для всех остальных. Правила идентичные, пользователя root идентифицировали через euid=0 и auid=0. Нулевые значения соответствуют root.

Применяем правила:

# auditctl -R /etc/audit/rules.d/audit.rules

Теперь все команды пользователей записываются в соответствием с правилами. Смотрим команды root:

# ausearch -k root_auth_command_execution

Вывалится большая портянка. Каждая команда в своём блоке, где будет указано:

◽️Дата и время выполнения
◽️PROCTITLE - выполненная команда
◽️PATH - файлы, связанные с выполнением (какие-нибудь библиотеки, сам исполняемый файл и т.д.)
◽️CWD - рабочая директория
◽️EXECVE - аргументы команды, если есть.
◽️SYSCALL - выполненный системный вызов со всеми свойствами в виде пользователя, pid, самой команды, исполняемого файла и т.д.

Как можно увидеть, информация исчерпывающая. Вроде и хорошо, что так подробно. С точки зрения безопасности полезная информация. Но быстро глянуть, кто тут что запускал, не получится. Например, если пользователь просто запустил mc, то в лог улетит не только эта команда, но и сопутствующие. Mc открывает свой bash и это тоже будет отражено в логе, также он запускает бинарники cons.saver, dircolors. Избыток подробной информации может сбивать с толку и усложнять аудит. С точки зрения безопасности это полезная информация, а с точки зрения посмотреть, кто тут что делал, не очень.

Может помочь команда, которая выведет список всех выполненных исполняемых файлов:

# aureport -x -i

Также неудобно смотреть команды, запущенные через pipe. В auditd они будут отображены по отдельности.

По умолчанию auditd хранит логи в /var/log/audit/audit.log. Читать их или грепать напрямую неудобно. Там всё сплошным потоком, без дат. Можно через ausearch или aureport выгружать их в файлы:

# aureport -x -i > /var/log/audit_exec_summary.log

Либо настроить пересылку логов в syslog. Для локального syslog сервера есть плагин с настройками в файле /etc/audit/plugins.d/syslog.conf. С локального можно на внешний пересылать.

Auditd – мощный инструмент для мониторинга событий операционной системы. Он взаимодействует напрямую с ядром, наблюдает за системными вызовами. Всё, что с ними связано, может записывать. Можно создавать отдельные правила для конкретных приложений и наблюдать за ними.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#auditd #ssh #security
4👍124👎2