СВЕЖИЕ НОВОСТИ ИНТЕРНЕТА

WM.копилка - Копилка для Вашего сайта.

Поиск по этому блогу

воскресенье, 13 марта 2011 г.

КОРРЕКТНОСТЬ ИНТЕРПРЕТАЦИИ ЛОГОВ

       В ряде случаев записи лога интерпретируются следователем. Иногда спрашивают совета специалиста.
     Вспоминается случай, когда материал относительно неправомерного доступа принесли одному генералу. Бóльшую часть материалов составляли разнообразные логи. Также были приложены распечатки записей из базы данных RIPE (регистратора IP-адресов) относительно встречавшихся в логах IP-адресов. Посмотрев бумаги с умным видом, генерал приказал задержать и допросить хакера. Когда опер ему возразил, что злоумышленник пока еще не установлен, генерал заявил, что доказательства, конечно, еще предстоит собрать и оформить, но мы-то хакера уже знаем: вот в логах его фамилия, адрес и телефон – и ткнул пальцем в запись типа «person» в распечатке из whois.
    Интерпретация лога как такового, без предварительного ознакомления с программами, его создавшими и обработавшими, а также их настройками – некорректна. Поэтому следует документировать не только сами логи, но также имеющие к ним отношение программы, их настройки и окружение. Кроме того, следует получить мнение специалиста или эксперта относительно интерпретации логов на основании вышеуказанной информации.




НЕИЗМЕННОСТЬ ЛОГОВ ПОСЛЕ ИЗЪЯТИЯ

      Изъятые логи либо распечатываются на бумаге и прилагаются к протоколу, либо записываются на компьютерный носитель, который опечатывается и хранится в деле. Лучше совместить оба способа: наиболее существенные записи лога распечатать, а лог целиком записать на компактдиск.
      Еще одной гарантией корректности осмотра логов и неизменности информации после изъятия является участие в следственном действии специально подобранных понятых. В соответствии с УПК понятой призван удостоверить факт производства следственного действия, а также его содержание, ход и результаты (ст. 60 УПК). Для тех действий, которые проводятся непосредственно, понятой не должен обладать какими-то особенными свойствами, кроме исправности зрения, слуха, а также дееспособности. Но действия с компьютерной информацией проводятся отнюдь не непосредственно, а при посредстве разнообразных технических средств. Для применения этих технических средств, разумеется, нужен специалист. Но понятые также должны понимать смысл проводимых действий, их содержание и последствия. Рекомендуется для участия в таких следственных действиях привлекать понятых, обладающих познаниями относительно осматриваемых аппаратных и программных средств, о чем сделать запись в протоколе.


 

КОРРЕКТНОСТЬ ИЗЪЯТИЯ ЛОГОВ

      Когда логи осматриваются и изымаются «на месте», без передачи компьютера целиком на экспертизу, возможны следующие ошибки.
      Логи могут иметь достаточно большой размер – миллионы записей и больше. Просмотреть глазами и распечатать на бумаге такие логи невозможно. Для их просмотра приходится применять фильтры, например, программу «grep». Задать «фильтрующие» выражения – задача простая лишь на первый взгляд. Здесь легко ошибиться даже для специалистам.
     Например, мы осматриваем лог веб-сервера «Apache». Сервер активно используется в основном локальными пользователями из сети 10.0.0.0/16. Есть сведения, что злоумышленник осуществлял несанкционированный доступ к этому серверу, используя IP-адрес из другой сети, какой именно, неизвестно. В суточном логе пара сотен тысяч записей, и просмотреть или распечатать его целиком нельзя.
     Участвующий в осмотре специалист, особенно не задумываясь, набирает команду, которая на первый взгляд очевидна. Она должна отфильтровать обращения со всех местных IP-адресов, начинающихся на «10.0.», оставив только «чужие» IP-адреса:

grep -v " 10.0." /data/apache/logs/access.log

(показать все записи лога, кроме тех, где встречается подстрока, указанная в кавычках; перед «10» поставлен пробел, чтобы не попали записи, где «10» – это второй или третий октет IP-адреса).
      В результате происходит незамеченная, но фатальная ошибка! Не обнаруженными оказываются все записи, в которых метка времени соответствует заданному шаблону. То есть все записи в период с 10:00:00 до 10:09:59. В эти-то десять минут злоумышленник и осуществил свой доступ. Специалист забыл, что в шаблоне команды «grep» символ «.» означает не точку, а любой одиночный символ.
     Эту ошибку можно обнаружить постфактум, если в протоколе осмотра точно воспроизведена примененная команда. Эту ошибку можно не только обнаружить, но и исправить, если кроме распечатки выдержки из лога полный лог был скопирован на компакт-диск и приложен к протоколу.
      Логи могут храниться в нескольких местах, например, в нескольких файлах. Причем содержимое разных лог-файлов может (а) совпадать, (б) являться подмножеством одно другого, (в) частично пересекаться, (г) взаимно дополнять друг друга без пересечения. Поэтому при изъятии следует зафиксировать настройки, отвечающие за распределение записей по местам хранения. Также важно не упустить какой либо лог, который может храниться в нестандартном месте.
     В протоколе осмотра должны быть указаны сведения, относящиеся как к корректности, так и к полноте осмотра. То есть желательно описать все возможные места хранения логов, привести настройки программ, отвечающих за их хранение, осмотреть и приложить к протоколу в бумажном виде наиболее существенные записи, а все прочие логи, программы, настройки в полном объеме скопировать на диск и приложить к протоколу.
    Когда есть такая возможность, лучше произвести полное копирование всего содержимого жесткого диска на самом низком из возможных уровней. Например, при помощи программы «dd» или специальным аппаратным дупликатором дисков.


 

НЕИЗМЕННОСТЬ ПРИ ХРАНЕНИИ ЛОГОВ

      Логи обычно хранятся в текстовом файле, бинарном файле или базе данных. Собственно процесс хранения не чреват ошибками и искажениями содержания логов. Следует учитывать лишь два фактора: возможную намеренную фальсификацию логов каким-либо лицом и уничтожение некоторых записей по истечении установленного срока хранения.
     Поэтому во время изъятия логов или при изучении их экспертом необходимо отметить права доступа на запись для различных пользователей, а также настройки систем хранения, ротации и чистки логов.
     Сомнения по поводу намеренного искажения логов не могут возникнуть лишь в силу существования самóй технической возможности их искажения. Для обоснованности сомнений требуется наличие признаков, свидетельствующих о факте доступа на запись к логам.




КОРРЕКТНОСТЬ ЛОГИРУЮЩЕЙ ПРОГРАММЫ

      Вероятность ошибки, связанной с искажением записи, весьма мала, хотя и не нулевая. Зато весьма существенной является вероятность ошибки, связанной с меткой времени. Время события может содержаться в самой сгенерированной записи, а может и не содержаться. Эта запись передается логирующей программе, которая обычно добавляет свою собственную метку времени. Часы на разных компьютерах могут показывать разное время. Ошибка в установке часов компьютера может быть небольшой, вследствие естественной их неточности; такая случайная ошибка обычно не превышает 1-3 минут. Она может быть большой вследствие ошибочной установки часов, намеренно сдвинутого времени или путаницы часового пояса; такая регулярная ошибка может исчисляться часами, годами и даже десятилетиями.
     В связи с изложенным при осмотре и экспертном исследовании необходимо фиксировать показания часов обоих компьютеров – где работает генерирующая логи программа и где работает логирующая программа.




НЕИЗМЕННОСТЬ ЛОГОВ ПРИ ПЕРЕДАЧЕ

      При передаче записей от генерирующей программы к логирующей программе ошибки, приводящие к искажению информации, можно не рассматривать. Их вероятность пренебрежимо мала. Зато не мала вероятность недоставки одной или нескольких записей от генерирующей программы к логирующей. Особенно когда эта доставка происходит по протоколу syslog, который не имеет механизма подтверждения приема сообщения.
      То есть на этом этапе не следует сомневаться в корректности записи о событии, но стоит предусмотреть возможность пропуска одной или нескольких записей. Особенно если при экспертном исследовании были установлены факты пропуска отдельных сообщений при тех же условиях передачи.
      Также целостность лога может быть нарушена при записи в файл. При выключении компьютера методом обесточивания и некоторых других критических ситуациях может произойти сбой файловой операции, в результате чего потеряется одна или несколько последних записей лог-файла.




КОРРЕКТНОСТЬ ПРОГРАММЫ, ГЕНЕРИРУЮЩЕЙ ЛОГИ

      Любая программа может содержать ошибки. Ошибки эти могут возникать спорадически или систематически. В первом случае запись может быть верной или неверной, в зависимости от сочетания случайных или псевдослучайных факторов. Во втором случае ошибка будет носить регулярный характер. Вероятность ошибки в программе зависит от ее производителя. Считается, что она в целом ниже для производителей, применяющих передовые технологии производства программного обеспечения, организовавшими процесс производства в соответствии с современными рекомендациями и сертифицировавшими этот процесс по стандарту ISO-9001. Тем не менее ни у какого производителя вероятность ошибки нельзя считать пренебрежимо малой величиной.




ДОКАЗАТЕЛЬНАЯ СИЛА ЛОГОВ

      Доказательная сила логов базируется на двух столпах – корректности и неизменности. А именно – она распадается на следующую цепочку элементов:
     1) корректность фиксации событий и генерации записей генерирующей программой;
     2) неизменность при передаче записей от генерирующей программы к логирующей программе;
     3) корректность обработки записей логирующей программой;
     4) неизменность при хранении логов до момента изъятия;
     5) корректность процедуры изъятия;
     6) неизменность при хранении после изъятия, до осмотра, передачи на экспертизу;
     7) корректность интерпритацииl.
     В том случае, когда генерирующая программа сама ведет свои логи (не применяется специализированная логирующая программа), пункт 2 выпадает, а пункты 1 и 3 объединяются.
     Необходимо подчеркнуть, что вышеперечисленные пункты составляют именно цепочку, то есть при выпадении одного звена лишаются опоры последующие звенья. В англоязычной литературе используется термин «custodial chain».
     Рассмотрим каждый из пунктов по отдельности и укажем, какие меры обеспечивают действительность каждого из них.




ЛОГ КАК ДОКАЗАТЕЛЬСТВО

     Логи, как правило, не являются непосредственным источником доказательств, но опосредованным. В качестве посредника выступает мнение эксперта или специалиста. Вместо самих логов в качестве доказательств используются: заключение эксперта, заключение специалиста, а также показания изучавших логи свидетелей специалиста, эксперта, понятых.
      То есть компьютерные логи не являются очевидным доказательством, которое само себя объясняет (такие доказательства, не нуждающиеся в интерпретации, в англоязычной литературе именуют термином «self-evident»). Логи нуждаются в интерпретации.
       Полагают, что интерпретация логов во всех случаях требует специальных знаний.
      Некоторые возражают против доказательности логов, аргументируя это тем, что логи легко фальсифицировать и не существует никакой методики определения истинности логов, отсутствия фальсификации. Это не совсем так.
    Во-первых, множество следов других типов фальсифицировать тоже можно. И некоторые – даже проще, чем логи. Волосы, отпечатки зубов,
ворсинки ткани, пороховой нагар и прочее. Не только можно фальсифицировать, но такие попытки регулярно случаются. Несмотря на это, доказательствами все такие следы признаются. Чем логи хуже?
      Во-вторых, фальсификацию логов в ряде случаев можно выявить. И чем больше информации в распоряжении эксперта, тем больше вероятность обнаружения подлога.