доказательная сила логов
В судебно-следственной практике автор встречал такие крайности, как полное отрицание следователем какого-либо значения логов вообще или принятие судьей в качестве доказательства распечатки логов, принесенной потерпевшим (даже без подписи).
В данной работе ставится задача определить условия, при которых логи (конечно, не сами по себе логи, а производные от них доказательства) могут и должны иметь доказательную силу.
определение
Лог (компьютерный лог, компьютерный журнал регистрации событий) – организованный в виде файла, базы данных (реже – массива в оперативной памяти) массив записей о событиях, зафиксированных какой-либо программой, группой программ, информационной системой. Лог ведется автоматически, без участия человека. Как правило, соблюдается принцип: одно событие – одна запись. Как правило, каждая запись снабжается меткой времени; записи сохраняются на диске (реже – печатаются на принтере) по мере их генерирования, по возможности, независимо от генерирующей их программы, чтобы они оказались доступны для изучения даже в случае сбоя или аварийного завершения программы.
Форма записей может быть произвольной, на усмотрение автора программы. Записи лога могут иметь более «гуманитарную» форму, то есть, ориентироваться на восприятие человеком. Также записи могут быть машинно-ориентированными, то есть предназначаться для легкого восприятия другой программой. Чаще придерживаются промежуточной формы.
Следует отличать генерацию логов и ведение логов. Ведение логов включает: запись их в соответствующий файл или базу данных, снабжение меткой времени и идентификатором источника, агрегирование (объединение одинаковых или схожих записей), своевременное удаление старых записей и т.д. Ведение логов может осуществляться самой генерирующей программой, а может быть передано специализированной (логирующей) программе, такой как «syslogd».
цепочка доказательности
Доказательная сила логов базируется на их коректности и неизменности. Суд должен быть уверен, что представленные логи отражают реальные события с корректными параметрами. Также суд должен быть уверен, что логи не были изменены каким-либо образом, искажающим их смысл. Кроме того, следует позаботиться о корректной интерпретации логов.
Доказательность обеспечивается следующей цепочкой элементов:
- корректность фиксации событий и генерации записей генерирующей программой;
- неизменность при передаче записей от генерирующей программы к логирующей программе;
- корректность обработки записей логирующей программой;
- неизменность при хранении логов до момента изъятия;
- корректность процедуры изъятия;
- неизменность при хранении после изъятия, до осмотра или передачи на экспертизу;
- корректность интерпретации.
В том случае, когда генерирующая программа сама ведет свои логи (не применяется специализированная логирующая программа), пункт 2 исключается, а пункты 1 и 3 объединяются.
Подчеркнем, что вышеперечисленные пункты составляют именно цепочку, то есть, при выпадении одного звена лишаются опоры последующие звенья. Рассмотрим каждый из пунктов по отдельности и укажем, какие меры обеспечивают действительность каждого из них.
корректность генерирующей программы
Любая программа может содержать ошибки. Ошибки эти могут возникать спорадически или систематически. В первом случае запись может быть верной или неверной, в зависимости от сочетания случайных или псевдослучайных факторов. Во втором случае ошибка будет носить регулярный характер. Вероятность наличия ошибки в программе зависит от ее производителя. Считается, что она в целом ниже для производителей, применяющих передовые технологии производства программного обеспечения, организовавших процесс производства в соответствии с современными рекомендациями и сертифицировавших этот процесс по стандарту ISO-9001. Тем не менее, ни у какого производителя вероятность ошибки нельзя считать пренебрежимо малой величиной.
В качестве иллюстрации систематических ошибок в логах приведем примеры из практики автора.
Программа «akpop3d» версии 0.7.6 - сервер доставки электронной почты (MDA).
Вот фрагмент лог-файла «maillog», в котором собираются логи как от «akpop3d», так и от сервера электронной почты (MTA) «sendmail».
Dec 12 21:34:28 home sm-mta[4045]: kBCIYOxr004045: from=<chadwicks_coupon@1-coupon.com>, size=3494, class=0, nrcpts=1,
msgid=<01c71e1c$7a5d7050$6c822ecf@chadwicks_coupon>, proto=ESMTP, daemon=IPv4, relay=aihs-tun [10.5.0.1]
Dec 12 21:34:39 home sm-mta[4046]: kBCIYOxr004045: to=<fnn@home.fnn>, delay=00:00:12, xdelay=00:00:11, mailer=local, pri=33713, relay=local, dsn=2.0.0, stat=Sent
Dec 12 21:38:15 home sm-mta[4051]: kBCIcCrw004051: from=<Most@andersonagency.net>, size=49465, class=0, nrcpts=1,
msgid=<000c01c71e1c$a3249630$00000000@eigenaarih63rh>, proto=ESMTP, daemon=IPv4, relay=aihs-tun [10.5.0.1]
Dec 12 21:38:17 home sm-mta[4052]: kBCIcCrw004051: to=<fnn@home.fnn>, delay=00:00:03, xdelay=00:00:02, mailer=local, pri=79666, relay=local, dsn=2.0.0, stat=Sent
Dec 12 21:39:08 home akpop3d[1353]: Connection from 0.80.7.40:1033 Dec 12 21:39:08 home akpop3d[4054]: Authenticated fnn
Dec 12 21:41:01 home akpop3d[4054]: Connection closed
Dec 12 21:45:16 home sm-mta[4076]: kBCIjBAE004076: from=<dhickling@comidamexicana.com>, size=5985, class=0, nrcpts=1,
msgid=<000101c71e82$e4adb7ab$9eb3b218@comidamexicana.com>, proto=ESMTP, daemon=IPv4, relay=aihs-tun [10.5.0.1]
Dec 12 21:45:21 home sm-mta[4077]: kBCIjBAE004076: to=<fnn@home.fnn>, delay=00:00:09, xdelay=00:00:05, mailer=local, pri=36186, relay=local, dsn=2.0.0, stat=Sent
В логе зафиксирован доступ по протоколу POP с IP-адреса 0.80.7.40 (см. пятую запись), хотя на самом деле доступ был с адреса 10.0.0.2 (в этом сегменте присутствует вообще единственный клиентский компьютер). Подобная запись с некорректным IP-адресом повторяется в логе из раза в раз. Очевидно, что в программе akpop3d имеется систематическая ошибка, приводящая к некорректной записи в лог. Скорее всего, происходит
непредусмотренный побитовый сдвиг или данные считываются по неверному адресу памяти.
Другая иллюстрация систематических ошибок в логах.
Операционная система межсетевого экрана Cisco PIX. Для протокола DNS/UDP вместо номера порта показывается ID запроса. Объявлена в версии 4.4(2), исправлена в версии 6.0(1), идентификатор ошибки (caveats) – CSCdt72080. Всего в системе учета ошибок (Bug Toolkit) фирмы Cisco Systems зарегистрировано 312 ошибок, связанных с логами. Общее же число ошибок за весь период жизни ПО – десятки тысяч.
Справедливости ради следует отметить, что ПО Cisco Systems пользуется хорошей репутацией и имеет далеко не самое высокое удельное число ошибок, которые, к тому же, исправно учитываются и своевременно исправляются.
Итак, следует признать, что генерирующая логи программа может допускать ошибки. Однако само по себе это обстоятельство не может служить обоснованием для сомнений (имеются в виду именно те сомнения, которые упоминаются в презумпции невиновности). Таковым обоснованием является лишь наличие известной ошибки, которая:
а) подтверждена службой техподдержки производителя, его уполномоченного представителя (дистрибутора, реселлера) или компетентной организацией, занимающейся учетом ошибок и уязвимостей;
б) имеет отношение к генерации логов и может привести к их некорректности, что подтверждается заключением или показаниями эксперта или специалиста;
в) может возникнуть именно в тех записях лога, которые имеют значение для дела, что также должно быть подтверждено заключением или показаниями эксперта или специалиста.
неизменность при передаче
При передаче записей от генерирующей программы к логирующей программе ошибки, приводящие к искажению информации, можно не рассматривать. Их вероятность пренебрежимо мала. Зато не мала вероятность недоставки одной или нескольких записей от генерирующей программы к логирующей. Особенно когда эта доставка происходит через сеть по протоколу syslog (RFC-3164 "The BSD syslog Protocol"), который не имеет механизма подтверждения приема сообщения.
То есть, на этом этапе не следует сомневаться в корректности записи о событии, но стоит предусмотреть возможность пропуска одной или нескольких записей. Особенно если при экспертном исследовании были установлены факты пропуска отдельных сообщений при тех же условиях передачи.
корректность логирующей программы
Вероятность ошибки, связанной с искажением записи в процессе ведения логов весьма мала, хотя и ненулевая. Зато весьма существенной является вероятность ошибки, связанной с меткой времени. Время события может содержаться в самой сгенерированной записи, а может и не содержаться. Эта запись передается логирующей программе, которая обычно добавляет свою собственную метку времени. Часы на разных компьютерах могут показывать разное время. Ошибка в установке часов компьютера может быть небольшой, вследствие естественной их неточности; такая ошибка обычно не превышает 1-3 минут. Она может быть большой вследствие ошибочной установки часов, намеренно сдвинутого времени или путаницы часового пояса; такая ошибка может исчисляться часами, годами и даже десятилетиями.
В связи с изложенным, при осмотре и экспертном исследовании необходимо фиксировать показания часов обоих компьютеров – где работает генерирующая логи программа и где работает логирующая программа.
неизменность при хранении логов
Логи обычно хранятся в текстовом файле, бинарном файле или базе данных. Собственно процесс хранения не чреват ошибками и искажениями содержания логов. Следует учитывать лишь два фактора: возможную намеренную фальсификацию логов каким-либо лицом и уничтожение логов по истечении установленного срока хранения.
Поэтому во время изъятия логов или при изучении их экспертом необходимо отметить права доступа на запись для различных пользователей, а также настройки систем хранения, ротации и чистки логов.
Сомнения по поводу намеренного искажения логов не могут возникнуть лишь в силу существования самой технической возможности их искажения. Для обоснованности сомнений требуется наличие признаков, свидетельствующих о факте доступа на запись к логам.
корректность изъятия
Когда логи осматриваются и изымаются «на месте», без передачи компьютера целиком на экспертизу, возможны следующие ошибки и сложности. Логи могут иметь достаточно большой размер – миллионы записей и больше. Просмотреть глазами и распечатать на бумаге такие логи невозможно. Для их просмотра и распечатки приходится применять фильтры, например, программу «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» или специальным аппаратным дупликатором дисков.
неизменность после изъятия
Изъятые логи либо распечатываются на бумаге и прилагаются к протоколу, либо записываются на компьютерный носитель, который опечатывается и хранится в деле. Лучше совместить оба способа.
Еще одной гарантией корректности осмотра логов и неизменности информации после изъятия является участие в следственном действии специально подобранных понятых.
В соответствии с УПК, понятой призван удостоверить факт производства следственного действия, а также его содержание, ход и результы. Для тех действий, которые проводятся непосредственно, понятой не должен обладать какими-то особенными свойствами кроме исправности зрения, слуха, а также дееспособности. Все действия с компьютерной информацией проводятся при посредстве разнообразных технических средств. Для применения этих технических средств, разумеется, нужен специалист. Но понятые также должны понимать смысл проводимых действий, их содержание и последствия. Рекомендуется для участия в таких следственных действиях привлекать понятых, обладающих познаниями относительно осматриваемых аппаратных и программных средств, о чем сделать запись в протоколе.
корректность интерпретации
В ряде случаев записи лога интерпретируются следователем. Иногда спрашивают совета специалиста.
Вспоминается случай, когда материал относительно неправомерного доступа принесли одному генералу. Большую часть материалов составляли разнообразные логи. Также были приложены распечатки записей из базы данных RIPE (регистратора IP-адресов) относительно встречавшихся в логах адресов. Посмотрев бумаги с умным видом, генерал приказал задержать и допросить хакера. Когда опер ему возразил, что злоумышленник пока еще не установлен, генерал заявил, что доказательства, конечно, еще предстоит собрать и оформить, но мы-то хакера уже знаем: вот в логах его фамилия, адрес и телефон – и ткнул пальцем в запись типа person в распечатке из whois.
Автору представляется, что интерпретация лога как такового, без предварительного ознакомления с программами, его создавшими и обработавшими, а также их настройками – некорректна. Поэтому следует документировать не только сами логи, но также имеющие к ним отношение программы, их настройки и окружение. Кроме того, следует получить мнение специалиста или эксперта относительно интерпретации логов на основании вышеуказанной информации.
процедура приобщения логов
Итак, на основании вышеописанной «цепочки доказательности логов» дадим рекомендации по процедуре получения и приобщения к делу соответствующих доказательств.
Предположим, имеются основания считать, что на известном сервере в логах зафиксированы события, связанные с преступлением и позволяющие установить и изобличить преступника. Как провести следственные действия?
Понятно, что нет возможности доказать отсутствие всех ошибок во всех программах и настройках, нет возможности строго доказать отсутствие любых фальсификаций со стороны любых лиц. Однако это не означает, что следует ударяться в противоположную крайность и вовсе никак не проверять и не удостоверять корректность и неизменность информации из логов. Вредны обе крайности – как вообще не проверять условий и окружения, так и требовать полного аудита безопасности осматриваемого сервера.
Степень строгости и подробности зависит от возможностей следствия и от судебной практики. Автор предлагает три варианта, отличающиеся подробностью и строгостью доказывания – нестрогий, промежуточный и строгий. Назовем их соответственно...
деревенский вариант
Следователь или оперуполномоченный совместно со специалистом (из числа сотрудников, обслуживающих осматриваемый сервер) и понятыми проводит осмотр содержимого сервера. При этом используются штатные программные и аппаратные средства, имеющиеся на сервере. Составляется протокол осмотра, где отражается следующее:
- аппаратные характеристики сервера, версия ОС;
- наличие и рабочее состояние программы, генерирующей и программы, обрабатывающей логи;
- наличие файлов с логами, их временные метки;
- права доступа к лог-файлам;
- учетные записи (аккаунты) пользователей, имеющих права на запись в лог-файлы или таблицы БД.
Нужные записи из нужных логов выбираются при помощи соответствующих фильтров, распечатываются на принтере и прилагаются к протоколу осмотра. Все листы протокола и приложений подписываются участниками осмотра.
провинциальный вариант
Для участия в следственном действии приглашается независимый специалист. Представитель владельца сервера (желательно из числа технических сотрудников) также участвует в осмотре. Понятые приглашаются не любые, а квалифицированные. В протоколе делается запись, что «понятые имеют необходимую квалификацию в области ИТ, знания по осматриваемой технике и ПО и поэтому полностью понимают смысл всех производимых в ходе осмотра действий».
Помимо указанных в предыдущем варианте данных, также собираются и отражаются в протоколе следующие:
- сведения о защищенности системы, ее проверке на наличие вредоносных программ;
- подробные данные о генерирующей логи программе, всех ее настройках и окружении (чтобы можно было узнать о выявленных ошибках и оценить вероятность невыявленных);
- данные о протоколе и параметрах передачи логов от генерирующей программы к логирующей;
- подробные данные о логирующей программе, в том числе настройки касательно размещения, срока хранения и ротации логов;
- сведения, помогающие интерпретировать логи, например, описания используемых программ.
Существенные записи из логов выбираются и в печатном виде прилагаются к протоколу. При этом полные логи, задействованные программы и их настройки копируются на компакт-диск типа CD-R или DVD-R, который опечатывается и прилагается к протоколу. В случае необходимости этот диск можно будет отправить на экспертизу.
столичный вариант
При участии следователя, квалифицированных понятых, специалиста и представителя владельца сервера нужный сервер отключается, опечатывается должным образом и отправляется на экспертизу.
Перед экспертом ставятся вопросы касательно содержания логов, их интерпретации, а также вопросы о возможности случайных ошибок, о защищенности системы, о следах возможной фальсификации или несанкционированного удаления логов.
В качестве альтернативы изъятию сервера целиком возможно снятие на месте полной копии его дисков при помощи специализированного аппаратного устройства или программным способом. Копия диска или образ диска затем передается на экспертизу с такими же вопросами.
заключение
Сами по себе логи никакой доказательной силы не имеют. Доказательствами по делу служат производные от логов материалы:
- протокол осмотра;
- заключение эксперта;
- заключение специалиста;
- показания свидетелей, понятых, эксперта и специалиста касательно осмотра и интерпретации логов.
Из доказательств должны следовать корректность и неизменность логов на всех этапах их жизненного цикла от генерации до интерпретации. Не могут являться доказательством логи (их копии, распечатки, акты осмотра), полученные заинтересованной стороной.
Николай Федотов, нач. отдела информационной безопасности ЗАО "Старт-Телеком", к.ф-м.н.
В данной работе ставится задача определить условия, при которых логи (конечно, не сами по себе логи, а производные от них доказательства) могут и должны иметь доказательную силу.
определение
Лог (компьютерный лог, компьютерный журнал регистрации событий) – организованный в виде файла, базы данных (реже – массива в оперативной памяти) массив записей о событиях, зафиксированных какой-либо программой, группой программ, информационной системой. Лог ведется автоматически, без участия человека. Как правило, соблюдается принцип: одно событие – одна запись. Как правило, каждая запись снабжается меткой времени; записи сохраняются на диске (реже – печатаются на принтере) по мере их генерирования, по возможности, независимо от генерирующей их программы, чтобы они оказались доступны для изучения даже в случае сбоя или аварийного завершения программы.
Форма записей может быть произвольной, на усмотрение автора программы. Записи лога могут иметь более «гуманитарную» форму, то есть, ориентироваться на восприятие человеком. Также записи могут быть машинно-ориентированными, то есть предназначаться для легкого восприятия другой программой. Чаще придерживаются промежуточной формы.
Следует отличать генерацию логов и ведение логов. Ведение логов включает: запись их в соответствующий файл или базу данных, снабжение меткой времени и идентификатором источника, агрегирование (объединение одинаковых или схожих записей), своевременное удаление старых записей и т.д. Ведение логов может осуществляться самой генерирующей программой, а может быть передано специализированной (логирующей) программе, такой как «syslogd».
цепочка доказательности
Доказательная сила логов базируется на их коректности и неизменности. Суд должен быть уверен, что представленные логи отражают реальные события с корректными параметрами. Также суд должен быть уверен, что логи не были изменены каким-либо образом, искажающим их смысл. Кроме того, следует позаботиться о корректной интерпретации логов.
Доказательность обеспечивается следующей цепочкой элементов:
- корректность фиксации событий и генерации записей генерирующей программой;
- неизменность при передаче записей от генерирующей программы к логирующей программе;
- корректность обработки записей логирующей программой;
- неизменность при хранении логов до момента изъятия;
- корректность процедуры изъятия;
- неизменность при хранении после изъятия, до осмотра или передачи на экспертизу;
- корректность интерпретации.
В том случае, когда генерирующая программа сама ведет свои логи (не применяется специализированная логирующая программа), пункт 2 исключается, а пункты 1 и 3 объединяются.
Подчеркнем, что вышеперечисленные пункты составляют именно цепочку, то есть, при выпадении одного звена лишаются опоры последующие звенья. Рассмотрим каждый из пунктов по отдельности и укажем, какие меры обеспечивают действительность каждого из них.
корректность генерирующей программы
Любая программа может содержать ошибки. Ошибки эти могут возникать спорадически или систематически. В первом случае запись может быть верной или неверной, в зависимости от сочетания случайных или псевдослучайных факторов. Во втором случае ошибка будет носить регулярный характер. Вероятность наличия ошибки в программе зависит от ее производителя. Считается, что она в целом ниже для производителей, применяющих передовые технологии производства программного обеспечения, организовавших процесс производства в соответствии с современными рекомендациями и сертифицировавших этот процесс по стандарту ISO-9001. Тем не менее, ни у какого производителя вероятность ошибки нельзя считать пренебрежимо малой величиной.
В качестве иллюстрации систематических ошибок в логах приведем примеры из практики автора.
Программа «akpop3d» версии 0.7.6 - сервер доставки электронной почты (MDA).
Вот фрагмент лог-файла «maillog», в котором собираются логи как от «akpop3d», так и от сервера электронной почты (MTA) «sendmail».
Dec 12 21:34:28 home sm-mta[4045]: kBCIYOxr004045: from=<chadwicks_coupon@1-coupon.com>, size=3494, class=0, nrcpts=1,
msgid=<01c71e1c$7a5d7050$6c822ecf@chadwicks_coupon>, proto=ESMTP, daemon=IPv4, relay=aihs-tun [10.5.0.1]
Dec 12 21:34:39 home sm-mta[4046]: kBCIYOxr004045: to=<fnn@home.fnn>, delay=00:00:12, xdelay=00:00:11, mailer=local, pri=33713, relay=local, dsn=2.0.0, stat=Sent
Dec 12 21:38:15 home sm-mta[4051]: kBCIcCrw004051: from=<Most@andersonagency.net>, size=49465, class=0, nrcpts=1,
msgid=<000c01c71e1c$a3249630$00000000@eigenaarih63rh>, proto=ESMTP, daemon=IPv4, relay=aihs-tun [10.5.0.1]
Dec 12 21:38:17 home sm-mta[4052]: kBCIcCrw004051: to=<fnn@home.fnn>, delay=00:00:03, xdelay=00:00:02, mailer=local, pri=79666, relay=local, dsn=2.0.0, stat=Sent
Dec 12 21:39:08 home akpop3d[1353]: Connection from 0.80.7.40:1033 Dec 12 21:39:08 home akpop3d[4054]: Authenticated fnn
Dec 12 21:41:01 home akpop3d[4054]: Connection closed
Dec 12 21:45:16 home sm-mta[4076]: kBCIjBAE004076: from=<dhickling@comidamexicana.com>, size=5985, class=0, nrcpts=1,
msgid=<000101c71e82$e4adb7ab$9eb3b218@comidamexicana.com>, proto=ESMTP, daemon=IPv4, relay=aihs-tun [10.5.0.1]
Dec 12 21:45:21 home sm-mta[4077]: kBCIjBAE004076: to=<fnn@home.fnn>, delay=00:00:09, xdelay=00:00:05, mailer=local, pri=36186, relay=local, dsn=2.0.0, stat=Sent
В логе зафиксирован доступ по протоколу POP с IP-адреса 0.80.7.40 (см. пятую запись), хотя на самом деле доступ был с адреса 10.0.0.2 (в этом сегменте присутствует вообще единственный клиентский компьютер). Подобная запись с некорректным IP-адресом повторяется в логе из раза в раз. Очевидно, что в программе akpop3d имеется систематическая ошибка, приводящая к некорректной записи в лог. Скорее всего, происходит
непредусмотренный побитовый сдвиг или данные считываются по неверному адресу памяти.
Другая иллюстрация систематических ошибок в логах.
Операционная система межсетевого экрана Cisco PIX. Для протокола DNS/UDP вместо номера порта показывается ID запроса. Объявлена в версии 4.4(2), исправлена в версии 6.0(1), идентификатор ошибки (caveats) – CSCdt72080. Всего в системе учета ошибок (Bug Toolkit) фирмы Cisco Systems зарегистрировано 312 ошибок, связанных с логами. Общее же число ошибок за весь период жизни ПО – десятки тысяч.
Справедливости ради следует отметить, что ПО Cisco Systems пользуется хорошей репутацией и имеет далеко не самое высокое удельное число ошибок, которые, к тому же, исправно учитываются и своевременно исправляются.
Итак, следует признать, что генерирующая логи программа может допускать ошибки. Однако само по себе это обстоятельство не может служить обоснованием для сомнений (имеются в виду именно те сомнения, которые упоминаются в презумпции невиновности). Таковым обоснованием является лишь наличие известной ошибки, которая:
а) подтверждена службой техподдержки производителя, его уполномоченного представителя (дистрибутора, реселлера) или компетентной организацией, занимающейся учетом ошибок и уязвимостей;
б) имеет отношение к генерации логов и может привести к их некорректности, что подтверждается заключением или показаниями эксперта или специалиста;
в) может возникнуть именно в тех записях лога, которые имеют значение для дела, что также должно быть подтверждено заключением или показаниями эксперта или специалиста.
неизменность при передаче
При передаче записей от генерирующей программы к логирующей программе ошибки, приводящие к искажению информации, можно не рассматривать. Их вероятность пренебрежимо мала. Зато не мала вероятность недоставки одной или нескольких записей от генерирующей программы к логирующей. Особенно когда эта доставка происходит через сеть по протоколу syslog (RFC-3164 "The BSD syslog Protocol"), который не имеет механизма подтверждения приема сообщения.
То есть, на этом этапе не следует сомневаться в корректности записи о событии, но стоит предусмотреть возможность пропуска одной или нескольких записей. Особенно если при экспертном исследовании были установлены факты пропуска отдельных сообщений при тех же условиях передачи.
корректность логирующей программы
Вероятность ошибки, связанной с искажением записи в процессе ведения логов весьма мала, хотя и ненулевая. Зато весьма существенной является вероятность ошибки, связанной с меткой времени. Время события может содержаться в самой сгенерированной записи, а может и не содержаться. Эта запись передается логирующей программе, которая обычно добавляет свою собственную метку времени. Часы на разных компьютерах могут показывать разное время. Ошибка в установке часов компьютера может быть небольшой, вследствие естественной их неточности; такая ошибка обычно не превышает 1-3 минут. Она может быть большой вследствие ошибочной установки часов, намеренно сдвинутого времени или путаницы часового пояса; такая ошибка может исчисляться часами, годами и даже десятилетиями.
В связи с изложенным, при осмотре и экспертном исследовании необходимо фиксировать показания часов обоих компьютеров – где работает генерирующая логи программа и где работает логирующая программа.
неизменность при хранении логов
Логи обычно хранятся в текстовом файле, бинарном файле или базе данных. Собственно процесс хранения не чреват ошибками и искажениями содержания логов. Следует учитывать лишь два фактора: возможную намеренную фальсификацию логов каким-либо лицом и уничтожение логов по истечении установленного срока хранения.
Поэтому во время изъятия логов или при изучении их экспертом необходимо отметить права доступа на запись для различных пользователей, а также настройки систем хранения, ротации и чистки логов.
Сомнения по поводу намеренного искажения логов не могут возникнуть лишь в силу существования самой технической возможности их искажения. Для обоснованности сомнений требуется наличие признаков, свидетельствующих о факте доступа на запись к логам.
корректность изъятия
Когда логи осматриваются и изымаются «на месте», без передачи компьютера целиком на экспертизу, возможны следующие ошибки и сложности. Логи могут иметь достаточно большой размер – миллионы записей и больше. Просмотреть глазами и распечатать на бумаге такие логи невозможно. Для их просмотра и распечатки приходится применять фильтры, например, программу «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» или специальным аппаратным дупликатором дисков.
неизменность после изъятия
Изъятые логи либо распечатываются на бумаге и прилагаются к протоколу, либо записываются на компьютерный носитель, который опечатывается и хранится в деле. Лучше совместить оба способа.
Еще одной гарантией корректности осмотра логов и неизменности информации после изъятия является участие в следственном действии специально подобранных понятых.
В соответствии с УПК, понятой призван удостоверить факт производства следственного действия, а также его содержание, ход и результы. Для тех действий, которые проводятся непосредственно, понятой не должен обладать какими-то особенными свойствами кроме исправности зрения, слуха, а также дееспособности. Все действия с компьютерной информацией проводятся при посредстве разнообразных технических средств. Для применения этих технических средств, разумеется, нужен специалист. Но понятые также должны понимать смысл проводимых действий, их содержание и последствия. Рекомендуется для участия в таких следственных действиях привлекать понятых, обладающих познаниями относительно осматриваемых аппаратных и программных средств, о чем сделать запись в протоколе.
корректность интерпретации
В ряде случаев записи лога интерпретируются следователем. Иногда спрашивают совета специалиста.
Вспоминается случай, когда материал относительно неправомерного доступа принесли одному генералу. Большую часть материалов составляли разнообразные логи. Также были приложены распечатки записей из базы данных RIPE (регистратора IP-адресов) относительно встречавшихся в логах адресов. Посмотрев бумаги с умным видом, генерал приказал задержать и допросить хакера. Когда опер ему возразил, что злоумышленник пока еще не установлен, генерал заявил, что доказательства, конечно, еще предстоит собрать и оформить, но мы-то хакера уже знаем: вот в логах его фамилия, адрес и телефон – и ткнул пальцем в запись типа person в распечатке из whois.
Автору представляется, что интерпретация лога как такового, без предварительного ознакомления с программами, его создавшими и обработавшими, а также их настройками – некорректна. Поэтому следует документировать не только сами логи, но также имеющие к ним отношение программы, их настройки и окружение. Кроме того, следует получить мнение специалиста или эксперта относительно интерпретации логов на основании вышеуказанной информации.
процедура приобщения логов
Итак, на основании вышеописанной «цепочки доказательности логов» дадим рекомендации по процедуре получения и приобщения к делу соответствующих доказательств.
Предположим, имеются основания считать, что на известном сервере в логах зафиксированы события, связанные с преступлением и позволяющие установить и изобличить преступника. Как провести следственные действия?
Понятно, что нет возможности доказать отсутствие всех ошибок во всех программах и настройках, нет возможности строго доказать отсутствие любых фальсификаций со стороны любых лиц. Однако это не означает, что следует ударяться в противоположную крайность и вовсе никак не проверять и не удостоверять корректность и неизменность информации из логов. Вредны обе крайности – как вообще не проверять условий и окружения, так и требовать полного аудита безопасности осматриваемого сервера.
Степень строгости и подробности зависит от возможностей следствия и от судебной практики. Автор предлагает три варианта, отличающиеся подробностью и строгостью доказывания – нестрогий, промежуточный и строгий. Назовем их соответственно...
деревенский вариант
Следователь или оперуполномоченный совместно со специалистом (из числа сотрудников, обслуживающих осматриваемый сервер) и понятыми проводит осмотр содержимого сервера. При этом используются штатные программные и аппаратные средства, имеющиеся на сервере. Составляется протокол осмотра, где отражается следующее:
- аппаратные характеристики сервера, версия ОС;
- наличие и рабочее состояние программы, генерирующей и программы, обрабатывающей логи;
- наличие файлов с логами, их временные метки;
- права доступа к лог-файлам;
- учетные записи (аккаунты) пользователей, имеющих права на запись в лог-файлы или таблицы БД.
Нужные записи из нужных логов выбираются при помощи соответствующих фильтров, распечатываются на принтере и прилагаются к протоколу осмотра. Все листы протокола и приложений подписываются участниками осмотра.
провинциальный вариант
Для участия в следственном действии приглашается независимый специалист. Представитель владельца сервера (желательно из числа технических сотрудников) также участвует в осмотре. Понятые приглашаются не любые, а квалифицированные. В протоколе делается запись, что «понятые имеют необходимую квалификацию в области ИТ, знания по осматриваемой технике и ПО и поэтому полностью понимают смысл всех производимых в ходе осмотра действий».
Помимо указанных в предыдущем варианте данных, также собираются и отражаются в протоколе следующие:
- сведения о защищенности системы, ее проверке на наличие вредоносных программ;
- подробные данные о генерирующей логи программе, всех ее настройках и окружении (чтобы можно было узнать о выявленных ошибках и оценить вероятность невыявленных);
- данные о протоколе и параметрах передачи логов от генерирующей программы к логирующей;
- подробные данные о логирующей программе, в том числе настройки касательно размещения, срока хранения и ротации логов;
- сведения, помогающие интерпретировать логи, например, описания используемых программ.
Существенные записи из логов выбираются и в печатном виде прилагаются к протоколу. При этом полные логи, задействованные программы и их настройки копируются на компакт-диск типа CD-R или DVD-R, который опечатывается и прилагается к протоколу. В случае необходимости этот диск можно будет отправить на экспертизу.
столичный вариант
При участии следователя, квалифицированных понятых, специалиста и представителя владельца сервера нужный сервер отключается, опечатывается должным образом и отправляется на экспертизу.
Перед экспертом ставятся вопросы касательно содержания логов, их интерпретации, а также вопросы о возможности случайных ошибок, о защищенности системы, о следах возможной фальсификации или несанкционированного удаления логов.
В качестве альтернативы изъятию сервера целиком возможно снятие на месте полной копии его дисков при помощи специализированного аппаратного устройства или программным способом. Копия диска или образ диска затем передается на экспертизу с такими же вопросами.
заключение
Сами по себе логи никакой доказательной силы не имеют. Доказательствами по делу служат производные от логов материалы:
- протокол осмотра;
- заключение эксперта;
- заключение специалиста;
- показания свидетелей, понятых, эксперта и специалиста касательно осмотра и интерпретации логов.
Из доказательств должны следовать корректность и неизменность логов на всех этапах их жизненного цикла от генерации до интерпретации. Не могут являться доказательством логи (их копии, распечатки, акты осмотра), полученные заинтересованной стороной.
Николай Федотов, нач. отдела информационной безопасности ЗАО "Старт-Телеком", к.ф-м.н.
Сетевые решения. Статья была опубликована в номере 01 за 2007 год в рубрике закон и порядок
