Перевірка цілісності системи за допомогою tripwire

Відповідаючи на питання про частоту використання tripwire, все залежить від важливості інформації, і кількості користувачів, що мають доступ до даного хосту. В ідеалі, перевірка цілісності системи повинна війт в щоденну звичку, як, наприклад, читання листів. Чим рідше буде проводитися перевірка цілісності системи, тим більше змін вам доведеться досліджувати.

tripwire поставляється з деякими утилітами, які використовуються для створення і підтримки бази даних tripwire, файлу конфігурацій і файлу політик. Команда man twintro виведе наступне:

tripwire (8): використовується для створення бази даних tripwire, і перевірки цілісності файлової системи.

twadmin (8): використовується для створення, шифрування і ведення політик tripwire, конфігураційних файлів і файлів ключів.

twconfig (4): описує файл конфігурацій

twpolicy (4): описує файл політик і вказує файли і директорії, а також метод сканування.

В процесі інсталяції за замовчуванням буде створена база даних в / var / db / tripwire. У ній будуть зберігається файли:

Слід уточнити, що база даних инициализируется, використовуючи параметри з файлу політик. Під час ініціалізації, tripwire робить «знімок» всіх файлів системи. При періодичної перевірки цілісності системи, існує можливість відстежити, які файли були змінені, і чому.

Під час установки, база даних була инициализирована зі стандартними політиками безпеки. Для перевірки цілісності бази даних слід скористатися командою

Файл звіту буде залежати від імені хоста і дати створення звіту.

Так виглядає звіт tripwire:

Звіт дає короткий опис про кількість нових, віддалених і змінених файлів з часу останньої перевірки системи. В даному випадку був доданий файл tripwire і змінений файл в директорії root`а. Далі слід звіт про змінених файлах:

В кінці рапорту буде дано перелік всіх помилок. У цьому випадку - це помилки Kerberos, з якими довелося зіткнутися при установці tripwire.

Наведений вище рапорт є зразком, і не показує будь-які аномалії. Ми повторили перевірку ще раз, попередньо:

Створивши нового користувача в системі
Видаливши бінарний файл tip

Даний рапорт повинен показати зміни, вироблені в системі. Нижче наведені відповідні дані:

Зауважте, як багато подій сталося в системі, коли був доданий користувач. Зроблені зміни в файлах passwd і master.passwd, в group database і її копії, в базах даних pwd.db і spwd.db.

Оскільки звіт містить дату і час зміни, можна почати розслідування, спираючись на них. Для початку, можна вивчити логи або опитати користувачів, намагаючись з'ясувати, хто міг працювати на даній системі в певний час.

За замовчуванням, всі зміни позначаються як x. Це означає, що зміни не будуть повторюватися, коли буде створений новий звіт.

До цього часу використовувалися стандартні політики. Наступний приклад продемонструє деякі зміни в файлі політик для отримання інформації про помилки в звіті tripwire

При утстановке tripwire, файл політик за замовчуванням був створений в /usr/local/etc/tripwire/tw.pol. Цей файл використовується tripwire під час перевірки в базі. Його неможливо безпосередньо редагувати, так як файл зашифрований і підписаний, хоча існує текстовий файл в /usr/local/etc/tripwire/twpol.txt. Слід вносити всі зміни саме в цей текстовий файл, а потім за допомогою утиліти внести зміни в файл політик.

Почнемо з вивчення змісту цього файлу / usr / local / etc / tripwire:

Зауважимо, що файл політик (tw.pol) і файл конфігурацій (tw.cfg) є типу data. Кожен з них має свій еквівалент у вигляді текстового файлу (копія файлу політик - twpol.txt.bak).

Найкраще робити перевірку цілісності системи відразу ж після зміни політик, через можливість виникнення конфліктів в базі даних tripwire через зміну деяких файлів з моменту останньої перевірки. Хоча даний спосіб і є незручним, це практично єдино правильне рішення, яке дозволяє уникнути внесення змін до інших файли, до перезапису файлу політик. У разі невдалого оновлення файлу політик, необхідно провести перевірку системи на цілісність ще раз, і потім спробувати знову оновити файл політик.

Може виникнути помилка синтаксису, якщо відсутній параметр -S site.key.

Для дотримання запобіжних заходів, бажано текстові файли конфігурацій і звіти зберігати не на жорсткому диску, а на змінних носіях, таких як дискети, диски або плівки.