Tripwire

Работа над Tripwire началась в 1992 году в университете Пердью: аспирант Джин Ким и профессор Юджин Спаффорд искали способ замечать подмену системных файлов на UNIX-машинах^[1]. Первая публичная версия вышла 2 ноября 1992 года^[5]. Авторы сформулировали задачу так: файловые системы Unix уязвимы для несанкционированных пользователей, вирусов, сетевых червей и логических бомб, а тонкий вред трудно заметить штатными средствами^[5]. Требовался инструмент, который замечал бы изменения сразу, а не по следам инцидента^[5].

В 1997 году Ким основал компанию Tripwire Technologies для коммерческого развития продукта^[1]. С 1999 года компания развивает корпоративную линейку Tripwire Enterprise^[1]. Успех академического проекта объяснялся простотой идеи: не пытаться предотвратить вторжение, а гарантированно его заметить^[6]. Такой подход дружил с экономикой: один хостовый агент стоил дешевле постоянного сопровождения^[6].

В октябре 2000 года разработчики выпустили версию для Linux под свободной лицензией GNU GPL^[7]. Проект Open Source Tripwire стартовал в 2002 году на основе исходных текстов выпуска 2000 года^[1].

Свободная ветка развивалась вяло: выпуск 2.3.1 долгое время оставался последней версией^[8]. GitHub-репозиторий открывает исходный код и выпускает версии под Linux^[9]. Коммерческая линейка тем временем выросла в комплекс мониторинга с центральным управлением^[1]. Страница выпусков репозитория фиксирует версии свободной ветки^[10].

Учебные курсы используют Tripwire как типичный пример хостовой системы обнаружения вторжений: установка, настройка политики и разбор отчётов составляют лабораторную работу^[11]. Обзоры систем обнаружения вторжений относят контроль целостности файлов к отдельному классу хостовых средств^[12]. Обзоры отмечают зрелость методики: политика, эталон и отчёт образуют законченный цикл защиты^[13].

Имя Спаффорда придало проекту академический вес: его школа исследований безопасности выросла в влиятельное сообщество^[14]. К 2001 году Tripwire прочно вошла в практику администрирования: обзор издательства «Открытые системы» описывал её как обязательный агент хостового уровня^[15].

Русскоязычные руководства по защите Linux включали главу о Tripwire с готовыми сценариями ежедневной проверки^[3]. Пакет вошёл в основные дистрибутивы как штатный компонент безопасности^[2]. Терминология русскоязычной литературы закрепила за инструментом роль системы контроля целостности^[3].

Ранние версии различались хранением правил: формат tw.config описывал объекты и атрибуты в текстовом виде^[3]. Страница руководства tw.config документировала синтаксис селекторов^[3]. Свободный выпуск для Linux выходил в двух ветках: ASR 1.3.1 с текстовой конфигурацией и Linux Tripwire 2.x с подписанными двоичными файлами^[3].

Коммерческая компания переименовывалась и меняла владельцев, сохраняя линейку Enterprise^[1]. Свободная ветка при этом осталась в распоряжении сообщества^[9]. За четверть века идея выдержала проверку: механизмы Tripwire вошли в стандартный арсенал администратора, а сама программа осталась в дистрибутивах Linux^[2].

В основе лежит эталонная база данных: при установке Tripwire обходит заданные политикой каталоги и записывает для каждого файла набор атрибутов^[4]. Затем программа снова обходит файловую систему и сравнивает фактические значения с сохранёнными^[16].

Набор атрибутов шире простого сравнения дат: контролируются криптографические хеши содержимого, размер, права доступа, принадлежность, отметки времени доступа и изменения, номер узла файловой системы^[1]. Комбинация атрибутов подбирается правилом для каждого объекта^[4]. Политика описывает, что и как проверять: файлы двоичных каталогов — на любое изменение, журналы — только на рост, временные каталоги — игнорировать^[4].

Эталон имеет смысл снимать на свежеустановленной машине: если система скомпрометирована до установки, база зафиксирует чужие файлы как норму^[15]. Авторы подчёркивали, что инструмент должен ставиться сразу после развёртывания^[15]. Отчёт проверки сохраняется в файл и одновременно выводится в кратком виде на консоль^[1].

Разбор отчёта начинается с изменений в каталогах системных программ^[1]. Изменения журналов и кешей оцениваются в последнюю очередь^[1]. Механизм похож на проверку контрольных сумм загружаемых файлов, но ведётся непрерывно и по всей системе^[3].

Производительность зависит от охвата: полный обход больших дисков занимает десятки минут^[16]. Поэтому базу сужают до критичных каталогов, а обход выполняют по расписанию^[17]. Авторы отчёта 1993 года отдельно разбирали хранение эталона на носителях только для чтения^[5].

Тестовый комплект поставки проверяет корректность вычисления подписей на конкретной машине^[5]. Он же сверяет собственные файлы дистрибутива с эталоном^[5].

Штатные обновления системы дают ежедневный поток изменений, который размывает сигнал^[7]. Обновление эталона после подтверждённых пакетов сохраняет отчёты читабельными^[7]. Плотность контроля выбирается по цене ошибки: системные каталоги проверяются всеми атрибутами^[4].

Политика проверки

Правило политики назначает каждому объекту набор контролируемых свойств и категорию критичности^[4]. Пресеты вроде «только чтение» или «критично» описывают типовые наборы атрибутов^[4].

Переменные политики собирают повторяющиеся группы: двоичные файлы, конфигурации, сценарии запуска^[4]. Одна машина обслуживает одну политику — централизованное управление правилами отсутствует в свободной версии^[7]. Политика хранится подписанной двоичным файлом, а её исходный текст администратор получает обратной распечаткой^[3].

Грамотная политика — баланс шума и охвата: слишком широкое покрытие даёт ежедневные ложные сообщения, слишком узкое пропускает компрометацию^[7]. Рекомендации предлагают исключать быстро меняющиеся журналы и кеши, оставляя контроль исполняемых файлов и настроек^[17]. Стандартная политика Fedora задаёт переменные для двоичных файлов, каталогов устройств и сценариев запуска^[4].

Обновление политики — отдельный режим основной программы: новая версия сравнивается со старой, а расхождения отражаются на базе^[16]. Так программа сохраняет непрерывность эталона при смене правил^[16]. Для каталогов допускается проверка только узла без содержимого^[1].

Типовое правило начинается от корня файловой системы и наследуется на подкаталоги^[4]. Параметр рекурсии решает, проверять ли содержимое каталогов целиком^[1].

Защищать систему инструментом, которому можно подделать эталон, бессмысленно, поэтому база и политика хранятся подписанными^[1]. Система использует пару ключей: ключ узла уникален для каждой машины, ключ сайта один на организацию^[4]. Ключи генерируются утилитой twadmin по парольной фразе^[4]. Программа проверяет подписи перед каждым использованием файлов^[16].

Рекомендации советуют хранить копию базы и ключей на съёмном носителе вне машины^[3]. Идеальный вариант — носитель только для чтения: взломщик с правами администратора не сможет подделать эталон^[3]. Для хеширования доступны алгоритмы MD5, SHA-1, HAVAL и циклический избыточный код^[3]. Криптографическая практика рассматривает MD5 и SHA-1 устаревшими для задач подписи, поэтому свежие сборки делают ставку на стойкие схемы ключей^[19].

Криптографическая строгость алгоритмов эволюционировала вместе с угрозами^[19]. Современная практика рекомендует семейство SHA-2 для любых задач подписи^[19]. Защита эталона дополняет общую дисциплину: журналы, снимки системы и резервные копии хранят вне контролируемой машины^[14].

Каждый ключ защищается длинной парольной фразой, вводимой при подписании^[4]. Потеря ключей означает невозможность обновить эталон без полной переинициализации^[4]. Подпись отвечает за целостность и авторство файлов программы, но не шифрует содержимое^[19].

Основное применение — серверы: веб-серверы, шлюзы, узлы баз данных, целостность которых критична^[7]. Инструмент подходит для небольших сетей без центрального управления^[1].

Отчёты изучают вместе с журналами входов и расписаниями задач^[3]. Совпадение времени изменения файла с сеансом администратора — повод для разбора^[3]. Помимо серверов инструмент ставят на рабочие станции администраторов и машины с критичными данными^[7].

Администраторы включают контроль двоичных каталогов и настроек, а отчёты разбирают по утрам^[4]. Обнаруженная подмена утилит означает компрометацию с правами администратора и требует переустановки системы^[14]. В лабораторных стендах курсов информационной безопасности студенты сравнивают реакцию системы на штатные и несанкционированные изменения^[11]. Сравнительные обзоры СОВ используют контроль целостности как отдельный класс хостовых средств^[12].

Контроль целостности дополняет межсетевой экран: периметр не пропускает атаку, а контроль целостности замечает её следы^[20]. Журналы и контрольные суммы в совокупности дают картину инцидента^[17]. Восстановление после сбоя сверяет состояние системы с эталоном и копиями^[14].

Специалисты по анализу защищённости используют контрольные суммы при проверке серверов на посторонние файлы^[21]. Восстановление после инцидента опирается на эталонные снимки и резервные копии^[22]. При расследовании инцидента отчёты образуют хронологию изменений^[16].

Регламенты организаций требуют подтверждённого контроля целостности критичных систем^[6]. Отчёты инструмента служат свидетельством выполнения требований при аудите^[6]. Туннелирование и защищённые каналы нужны, если отчёты передаются по сети^[22].

Классические руководства по администрированию включают контроль целостности в ежедневные обязанности^[23]. Проверка занимает время, поэтому её ставят на ночные часы и сводят результаты в отчёт^[23].

Свободные платформы класса Wazuh и OSSEC развивают хостовый мониторинг в сторону центральных консолей^[12]. Классический инструмент при этом сохраняет нишу простых и автономных проверок^[24]. Tripwire относится к хостовым системам обнаружения вторжений наряду с сетевыми средствами анализа трафика^[25]. Обзоры перечисляют соседей по классу: Samhain, OSSEC, PortSentry, Logcheck^[24].

Свободный аналог AIDE повторяет модель политики и эталонной базы, поддерживается в дистрибутивах активнее^[12]. OSSEC объединяет контроль целостности, анализ журналов и обнаружение руткитов в одной платформе^[12]. Сканировщики руткитов ищут следы известного вредоносного кода, не строя эталон^[7]. Коммерческая линейка Tripwire Enterprise добавляет централизованное управление, отчётность и поддержку широкого круга платформ^[1].

Для серверов без центральной консоли свободная версия остаётся самодостаточной^[7]. Текстовые отчёты и командная строка упрощают автоматизацию^[7]. По сравнению с сетевыми средствами хостовый контроль видит лишь свою машину, зато не пропускает изменения, зашифрованные в каналах^[25].

Аналогичные проверки встроены в современные системы пакетов: подписанные репозитории защищают установку, а контроль целостности — работающую систему^[2]. Учебные стенды ставят эти средства рядом, показывая разные уровни защиты^[11]. Свободные платформы мониторинга наследуют идею эталонной базы в модулях целостности^[13].

Обучающие стенды сравнивают Tripwire, AIDE и OSSEC по одной методике^[11]. Такой разбор даёт студентам представление о классе хостовых средств в целом^[11]. Сканеры руткитов и мониторы журналов дополняют контроль целостности, но не заменяют его^[24].