У нас большой парк систем Red Hat 7/8. У нас есть требование, чтобы все системы соответствовали CIS.
Одно из требований — не производить автоматическую ротацию журналов аудита. То есть настроить следующее:
max_log_file_action = keep_logs
Однако эта настройка заполнит раздел, в котором хранятся журналы. Мы хотим настроить указанную выше настройку на , rotateно это сделает систему несоответствующей.
Я пытаюсь найти механизм, который используют другие участники отрасли для ротации журналов аудита.
Ваше здоровье
решение1
Контроль безопасности — это не вопрос «да» или «нет». Критически подумайте о том, насколько экстремальные меры вы можете принять, чтобы гарантировать, что ни одно событие аудита не будет потеряно. Проявите творческий подход к альтернативным контролям.
CIS, по-видимому, теперь размещает контрольные списки внедрения за контактной формой. Нашел старую копию наCIS_Red_Hat_Enterprise_Linux_7_Benchmark_v2.2.0.pdfдля обсуждения деталей реализации. Терминология и нумерация могут меняться, но обоснование по большей части неподвластно времени.
4.1.1.3 Убедитесь, что журналы аудита не удаляются автоматически (оцениваются) Профиль применимости:
- Уровень 2 - Сервер
- Уровень 2 — Рабочая станция
Описание: Параметр max_log_file_action определяет, как обрабатывать файл журнала аудита, достигший максимального размера файла. Значение keep_logs будет ротировать журналы, но никогда не удалять старые журналы.
Обоснование: В условиях высокой безопасности преимущества ведения длительной истории аудита превышают затраты на хранение истории аудита.
Аудит: выполните следующую команду и проверьте соответствие вывода:
# grep max_log_file_action /etc/audit/auditd.conf max_log_file_action = keep_logsИсправление: Установите следующий параметр в /etc/audit/auditd.conf:
max_log_file_action = keep_logsКонтроль CIS: 6.3 Обеспечение того, чтобы системы регистрации аудита не подвергались потере (т.е. ротации/архивации)
Убедитесь, что все системы, хранящие журналы, имеют достаточно места для хранения журналов, генерируемых на регулярной основе, чтобы файлы журналов не заполнялись между интервалами ротации журналов. Журналы должны архивироваться и иметь цифровую подпись на периодической основе.
Обратите внимание, что в обосновании говорится о средах с высокой степенью безопасности. Уровень 2, который, как я предполагаю, соответствуетгруппа внедрения 2в новой терминологии. Это для ситуаций, когда вы не можете позволить себе потерять какие-либо события вообще, сильное влияние из-за среды соответствия или других рисков.
Безопасным решением было бы позволить процессу архивирования файлов журнала удалить старые файлы, только после их резервного копирования. Конечно, вы можете удалить файлы журнала с хостов. Но будьте осторожны, чтобы сбой в архивировании не привел к раннему удалению файлов ротацией журнала.
Для архивного хранения не допускайте изменения или удаления журналов аудита. Подписывайте файлы, чтобы подтвердить их целостность. Удалите разрешения на редактирование и удаление из учетных записей хранилища объектов. Рассмотрите возможность холодного хранения на ленточных носителях.
Этот контрольный список в некоторых ситуациях также рекомендует admin_space_left_action = halt. Да, это означает, что система аудита отключит хост, если он не сможет вести журнал. Если это ужасает вас из-за ваших целей уровня обслуживания, вам, возможно, придется пересмотреть, подходит ли этот уровень паранойи для вашей среды.
Также внедрите централизованную систему ведения журнала аудита. Пересылайте или иным образом собирайте события в системе с большим объемом хранилища. Легче защищать, запрашивать и сохранять.
Что обеспечивает лучшую безопасность: центральная база данных с данными за 6 месяцев, готовыми к запросам, и годами резервного копирования, или целый парк хостов, на которых постоянно заканчивается свободное место, потому что кто-то решил, что контрольный список запрещает удалять файлы?