Что вы можете сделать, когда Auditd останавливает систему?
Недавно у меня возникла проблема, когда мой сервер выключался в середине выполнения сценария, по-видимому, случайно, но каждый раз примерно в один и тот же момент, а затем всякий раз, когда я пытался снова включить сервер, он запускал процесс запуска, а затем когда он дошел до определенной точки, просто снова выключите питание, прежде чем перейти к параметрам входа в систему.
Сначала я думал, что это как-то связано с устанавливаемыми скриптом и пакетами, но, просмотрев документацию по безопасности и CIS Benchmark, я обнаружил, что операционная система установлена с конфигурациями уровня 2-сервер, чтобы соответствовать требованиям безопасности.
Что мне нужно сделать на моем собственном сервере, я могу применить обходной путь, отредактировать файл Auditd.conf и изменить этот параметр, чтобы иметь возможность делать то, что мне нужно. Однако в производственной среде этот обходной путь может оказаться неприемлемым или недопустимым.
У меня есть пара вопросов по этому поводу:
Можно ли что-нибудь сделать, когда сервер достигает этого состояния, поскольку в этот момент вы даже не можете войти в систему, или это единственный вариант пересоздать образ сервера? (Это то, к чему я прибегал)
Предположительно (я все еще пытаюсь понять все параметры конфигурации), этого не должно происходить, и в журналах есть какие-то политики ротации и хранения, и я только что столкнулся с крайним случаем, когда то, что мне нужно сделать, в конечном итоге заполняет эти выходит за рамки ожидаемого варианта использования?
1 ответ
Auditd, конечно, относится к Linux.
Ваша организация должна решить, какие действия следует предпринять, если аудит решит, что ей критически не хватает места. В некоторых средах отслеживание событий безопасности или целостности настолько ценно, что пробелы в журналировании недопустимы. Многим другим не приходится жертвовать доступностью ради уменьшения пробелов в журналах аудита.
Что касается ваших вариантов, см.man auditd.confдля директив конфигурации, включая admin_space_left_action. Остановка объясняет ваше отключение хоста. Single может быть полезным компромиссом, останавливающим почти все службы, но позволяющим решить проблему с пространством на консоли. Или просто сообщите о проблеме (системный журнал, электронная почта), потеряйте данные (поверните) или ничего не делайте (игнорируйте). Конечно, некоторые из них означают, что вы не можете утверждать, что выполнили «Убедитесь, что система отключена, когда журналы аудита заполнены».
Обратите внимание, что автоматизированные инструменты могут настроить наиболее консервативный вариант, например, этот плейбук Ansible, по умолчанию останавливающий.
Лично я бы с большим подозрением отнесся к среде, в которой остановкой является политика, но на некоторых хостах есть исключения, выходящие за рамки автоматизации, по сравнению с честной политикой и настроенным системным журналом. Хотя я не комплаенс-человек.
Всегда более одного способа решения проблемы. Можно загрузить аварийный дистрибутив или однопользовательский режим, а затем расширить хранилище или очистить журналы для освобождения места.
Все хранилища имеют возможность пополнения. Найдите причину в данном случае. Оцените необходимость правил. Требования к пространству журнала аудита сильно различаются в зависимости от правил и рабочей нагрузки. Улучшите планирование емкости и оповещения о хранилище, чтобы уменьшить будущие проблемы с пространством.