Проверка целостности против аудита
В Руководстве по безопасности RHEL5 рекомендуется использовать AIDE для проверки целостности программного обеспечения. А также встроенная функциональность проверки целостности RPM. Но частые проверки могут быть ресурсоемкими, а редкие - не очень полезными. С другой стороны, постоянный аудит критически важных частей относительно дешев. И это все еще обеспечивает целостность в некоторой степени.
Поэтому в основном мой вопрос: в каких случаях проверка целостности (AIDE, RPM или что-то новое) лучше, чем аудит?
UPD: просто чтобы немного уточнить. Под "аудитом" я подразумеваю службу аудита RHEL на основе конкретного демона audd. Он может быть правильно настроен для постоянного контроля файлов и каталогов. Чтобы не пройти проверку целостности, файл должен быть как-то изменен, и это будет отмечено системой аудита. Так зачем беспокоиться о последствиях (например, о неудачной контрольной сумме), когда мы можем проследить причину этой модификации?
1 ответ
Я не знаю, можно ли ответить на этот вопрос осмысленно, хотя я не совсем уверен в этом, чтобы проголосовать, чтобы закрыть его.
Но я думаю, что при любом анализе затрат и выгод вы не должны забывать о выгоде: что в данном случае является предотвращением стоимости неудачи. Вы говорите, что частая проверка может быть "ресурсоемкой", и это вполне может быть так: но как ресурсоемкая перестройка вашей серверной инфраструктуры из золотых резервных копий, потому что произошло некоторое вторжение?
То, сколько вы тратите на защиту системы, зависит от ее ценности с точки зрения целостности и функциональности. Что касается меня, то любой компьютер, который будет подключен к Интернету, получает ежедневные проверки на наличие неисправностей и отчеты по электронной почте. Почти все syslogs к централизованному журналу, вне системы; любые следы, которые злоумышленник может сгенерировать по дороге, не могут быть удалены из удаленного системного журнала. Более чувствительные машины могут также пройти проверку целостности RPM, selinux включен (со всеми ужасными хлопотами, которые возникают при работе с нестандартным программным обеспечением), tripwire работает с носителя только для чтения и еще больше защиты целостности. Все зависит от того, сколько стоит машина.
Изменить: я не понял, что вы имели в виду auditd Программный сервис, а не общая концепция аудита, это правда, но даже если бы у меня был мой ответ, был бы тот же самый: глубокая защита, глубина, оправданная стоимостью актива. Если бы существовал один простой, дешевый, абсолютно надежный сервис complete-securitydмы бы все это запустили; в противном случае, чем больше мер предосторожности вы принимаете, тем меньше вероятность того, что компромисс (а) случится и (б) останется незамеченным, когда это произойдет.
Поскольку вы спрашиваете о типах вторжений, которые auditd может пропустить и tripwire может подхватить, подстроенный эксплойт модуля ядра является одним из таких, потому что tripwire может быть запущен с носителя и ядра только для чтения, и auditd не может.