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