ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 25.11.2019
Просмотров: 989
Скачиваний: 2
ванные понятые. Все равно действия эксперта сведутся к просмотру и
распечатке нужных данных. Так не проще ли произвести эти же действия
в порядке осмотра (ст. 176177 УПК)?
Стандарты
Правила сбора и фиксации цифровых доказательств (то есть компью
терной информации, используемой в качестве доказательства) не зак
реплены в законе. Нет и ведомственных нормативных актов, закрепляю
щих такие правила. А потом в суде возникает вопрос: были ли доказа
тельства собраны надлежащим образом, который обеспечивал их досто
верность и неизменность? Оценить правильность примененных проце
дур без специальных знаний невозможно. Когда же существуют офици
альные или, по крайней мере, общепризнанные правила обращения с
цифровыми доказательствами, обосновать достоверность и неизмен
ность значительно проще.
В отношении других видов доказательств, которыми криминалисты
занимаются давно, такие правила существуют.
Закрепление стандартов обращения с цифровыми доказательства
ми в законодательстве невозможно в силу быстрой изменчивости
компьютерных систем. Новые устройства, новые носители, новые
протоколы, для которых потребны новые процедуры, появляются нес
колько раз в год. Ежегодно появляются принципиально новые устрой
ства, которые требуют принципиально иного подхода при обнаруже
нии и изъятии цифровых доказательств. Ведомственные методики [85,
86] можно менять достаточно часто. Однако их разработка в нашей
стране затруднена отсутствием грамотных технических специалистов в
этих ведомствах.
Столкнувшись с необходимостью подобных стандартов, специалисты
предложили зафиксировать их на уровне рекомендаций научных или об
щественных профессиональных организаций. Исполнение таких стан
дартов, безусловно, снимет ряд возможных вопросов со стороны суда и
участников процесса. Автор рекомендует три подобных документа [W28,
7, 11], изданных достаточно авторитетными в области форензики органи
зациями. Изложенный в них опыт учтен при написании разделов 2 и 3
настоящей книги.
Автор предлагает соблюдать при проведении следственных действий
требования таких документов и в дальнейшем ссылаться на них для подт
верждения «соблюдения общепринятых и признанных ведущими специ
алистами правил и стандартов».
197
Следственные действия
3. Следственные действия
Осмотр компьютера
Особенности
Когда следы совершенного преступления и возможные доказатель
ства находятся в цифровой форме (в форме компьютерной информации),
их получение, фиксация и документирование представляют определен
ную сложность.
В отличие от многих иных видов доказательств, компьютерная ин
формация не может восприниматься человеком непосредственно –
глазами, ушами, пальцами. Воспринимать ее можно только через пос
редство технических аппаратных и программных средств. Причем ко
личество и сложность этих технических посредников настолько вели
ки, что связь между исходной информацией и тем, что мы видим не эк
ране, не слишком прямая и далеко не всегда очевидная. А порой эта
связь и вовсе условна и зыбка до невозможности (см. главу «Общенауч
ные методы»).
Следует признать, что осмотр компьютерной информации – это не
вполне осмотр (от слова «смотреть»), а скорее инструментальная про
верка, требующая определенных знаний об используемых технических
средствах, принцип действия которых не всегда очевиден. Вероят
ность ошибиться и увидеть не то, что есть на самом деле, при этом по
вышенная, даже при отсутствии целенаправленного воздействия про
тивника.
Высказывалось мнение, что на основании вышеизложенного осмотр
компьютерной информации вообще недопустим, а следует всегда прово
дить экспертизу.
Практика же никак не позволяет принять это утверждение. Провести
компьютернотехническую экспертизу (КТЭ) не всегда возможно даже в
тех случаях, когда она точно нужна. Замена экспертизы осмотром позво
ляет сэкономить очень много времени и сил. Порой перед следователем
стоит выбор: или проводить вместо КТЭ осмотр компьютерной инфор
мации, или вовсе прекращать дело.
Кроме того, есть и такое соображение. Для проведения КТЭ все равно
необходимо изъять носитель информации или скопировать его содержи
мое. А эти действия по своей сложности и по применению специальных
знаний не сильно отличаются от осмотра компьютерной информации на
месте. Все равно нужен специалист. Все равно желательны квалифициро
196
Н.Н. Федотов
Форензика – компьютерная криминалистика
proto=SMTP, daemon=IPv4, relay=customer.klimatstroy.195.slshosting.com
[204.14.1.195]
Dec 14 14:44:17 aihs smmta[5172]: kBEDiFQH005171: to=/dev/null,
ctladdr=bitbucket (26/0), delay=00:00:01, xdelay=00:00:00, mailer=*file*,
pri=38486, dsn=2.0.0, stat=Sent
Dec 14 14:44:39 aihs smmta[5173]: kBEDiZU2005173: from=<terri2546zelig@bar
bary.com>, size=6089, class=0, nrcpts=1,
msgid=<848e01c71f85$0df14333$eb8ddf52@barbary.com>, proto=SMTP, daemon=IPv4,
relay=[59.24.163.104]
Dec 14 14:44:39 aihs smmta[5174]: kBEDiZU2005173: to=/dev/null,
ctladdr=bitbucket (26/0), delay=00:00:03, xdelay=00:00:00, mailer=*file*,
pri=36311, dsn=2.0.0, stat=Sent
Dec 14 14:50:12 aihs smmta[5190]: kBEDoAM6005190: from=<yhky@vampismo.com>,
size=8177, class=0, nrcpts=1,
msgid=<9454295755.20061214074311@vampismo.com>, bodytype=8BITMIME,
proto=SMTP, daemon=IPv4, relay=customer.klimatstroy.195.slshosting.com
[204.14.1.195]
Dec 14 14:50:12 aihs smmta[5191]: kBEDoAM6005190: to=/dev/null,
ctladdr=bitbucket (26/0), delay=00:00:01, xdelay=00:00:00, mailer=*file*,
pri=38444, dsn=2.0.0, stat=Sent
Dec 14 14:53:42 aihs smmta[5192]: kBEDrduu005192:
from=<vvvaldiswwh@gmail.com>, size=8704, class=0, nrcpts=1,
msgid=<67a901c71f88$f5e3e54e$f00600ff@gmail.com>, bodytype=8BITMIME,
proto=ESMTP, daemon=IPv4, relay=mskm10st01.rtcomm.ru [213.59.0.34]
Dec 14 14:53:42 aihs smmta[5193]: kBEDrduu005192: to=/dev/null,
ctladdr=bitbucket (26/0), delay=00:00:03, xdelay=00:00:00, mailer=*file*,
pri=38935, dsn=2.0.0, stat=Sent
Dec 14 14:54:17 aihs smmta[5194]: kBEDsGgS005194:
from=<ynrripinahov@yahoo.com>, size=8734, class=0, nrcpts=1,
msgid=<7fee01c71f8e$052ada06$eb62a1f3@yahoo.com>, bodytype=8BITMIME,
proto=ESMTP, daemon=IPv4, relay=mskm10st01.rtcomm.ru [213.59.0.34]
Dec 14 14:54:17 aihs smmta[5195]: kBEDsGgS005194: to=/dev/null,
ctladdr=bitbucket (26/0), delay=00:00:01, xdelay=00:00:00, mailer=*file*,
pri=38963, dsn=2.0.0, stat=Sent
Dec 14 14:54:31 aihs smmta[5196]: kBEDsTLt005196:
from=<iwmn6@bellsouth.net>, size=7116, class=0, nrcpts=1,
msgid=<6.0.0.22.1.20061214165536.072e7710@bellsouth.net>, proto=SMTP, dae
mon=IPv4, relay=8412317852.onocable.ono.com [84.123.178.52]
Dec 14 14:54:33 aihs smmta[5197]: kBEDsTLt005196: to=fnn@home.fnn,
delay=00:00:03, xdelay=00:00:02, mailer=esmtp, pri=37368, relay=home.fnn.
[80.94.84.26], dsn=2.0.0, stat=Sent (kBEDsZ8K014471 Message accepted for
delivery)
199
Следственные действия
Логфайлы, доказательная сила логов
Определение
Лог (компьютерный лог, компьютерный журнал регистрации собы
тий) – это организованная в виде файла, базы данных или массива в опе
ративной памяти совокупность записей о событиях, зафиксированных
какойлибо программой, группой программ, информационной систе
мой. Лог ведется автоматически, без участия человека. Как правило, соб
людается принцип: одно событие – одна запись. Как правило, каждая за
пись снабжается меткой времени. Обычно записи сохраняются по мере
их генерирования, по возможности, независимо от генерирующей их
программы, чтобы они оказались доступны для изучения даже в случае
сбоя или аварийного завершения программы.
Форма записей может быть произвольной, на усмотрение создателя
программы или оператора, производившего ее настройку. Записи лога
могут иметь более «гуманитарную» форму, то есть ориентироваться на
восприятие человеком. Записи могут быть машинноориентированны
ми, то есть предназначаться для легкого восприятия другой программой.
Чаще придерживаются промежуточной формы.
Ведение логов может осуществляться сам
ó
й генерирующей програм
мой, а может быть передано специализированной (логирующей) програм
ме, такой как «syslogd». Ведение логов (логирование) включает: запись их
в соответствующий файл или базу данных, снабжение меткой времени и
идентификатором источника, агрегирование (объединение одинаковых
или схожих записей), своевременное удаление старых записей и т.д.
Примеры
Ниже автор счел полезным привести образцы некоторых логов, чтобы
те читатели, которые редко с ними сталкивались, чувствовали себя более
уверенно при изучении дальнейшего материала.
Фрагмент лога сервера электронной почты «sendmail» версии 8.13.3:
Dec 14 14:43:12 aihs smmta[5156]: kBEDhBbL005156: from=<sonya95wen
king@barnhallrfc.com>, size=6093, class=0, nrcpts=1,
msgid=<9bd701c71f85$6f70e79a$93c9135a@barnhallrfc.com>, proto=SMTP,
daemon=IPv4, relay=ayc250.internetdsl.tpnet.pl [83.18.106.250]
Dec 14 14:43:16 aihs smmta[5157]: kBEDhBbL005156: to=fnn@home.fnn,
delay=00:00:04, xdelay=00:00:04, mailer=esmtp, pri=36347, relay=home.fnn.
[80.94.84.26], dsn=2.0.0, stat=Sent (kBEDhG4D014447 Message accepted for
delivery)
Dec 14 14:44:17 aihs smmta[5171]: kBEDiFQH005171:
from=<vt@prostimenya.com>, size=8217, class=0, nrcpts=1,
msgid=<0458524863.20061214073716@prostimenya.com>, bodytype=8BITMIME,
198
Н.Н. Федотов
Форензика – компьютерная криминалистика
этих случаях – 401 (см. предпоследнее поле). Последующие записи уже
содержат имя пользователя (в третьем поле – «fnn» и «amak»). То есть, по
лучив в первый раз ответ 401, браузер предлагает пользователю ввести ло
гин и пароль и последующие запросы уже снабжает аутентификационной
информацией, отчего они проходят успешно (код 200).
В большинстве записей код ответа вебсервера 200, что означает ус
пешную обработку. Однако можно заметить коды 500 (внутренняя ошиб
ка сервера) и 404 (страница не найдена).
Последнее поле каждой записи указывает длину ответа вебсервера в
байтах. Как можно заметить, в случае ошибок (401, 404, 500) ответ корот
кий, а в случае успеха (200) более длинный, поскольку передается веб
страница.
Чтобы верно интерпретировать этот лог, нужно знать значение каждо
го поля записи. Нетрудно догадаться, например, что первое поле – это
IPадрес клиента, четвертое поле – это время с указанием на часовой по
яс. А вот о значении последнего поля догадаться нельзя; о том, что это
длина ответа, необходимо знать из документации к вебсерверу.
Лог межсетевого экрана «Netscreen», версия ОС 5.3.0:
Dec 14 09:41:09 ns01 moscowsg2: NetScreen device_id=moscowsg2 [Root]sys
temnotification00257(traffic): start_time="20061214 09:41:08" duration=0
policy_id=320001 service=icmp proto=1 src zone=Null dst zone=self
action=Deny sent=0 rcvd=540 src=81.16.112.4 dst=81.16.115.162 icmp type=8
session_id=0
Dec 14 09:41:10 ns01 moscowsg2: NetScreen device_id=moscowsg2 [Root]sys
temnotification00257(traffic): start_time="20061214 09:41:09" duration=0
policy_id=320001 service=icmp proto=1 src zone=Null dst zone=self
action=Deny sent=0 rcvd=540 src=81.16.112.4 dst=81.16.115.162 icmp type=8
session_id=0
Dec 14 09:41:26 ns01 moscowsg2: NetScreen device_id=moscowsg2 [Root]sys
temnotification00257(traffic): start_time="20061214 09:41:22" duration=3
policy_id=2 service=dns proto=17 src zone=Trust dst zone=Untrust
action=Permit sent=90 rcvd=389 src=172.23.36.115 dst=81.16.112.5
src_port=1025 dst_port=53 srcxlated ip=81.16.115.169 port=3975 dstxlated
ip=81.16.112.5 port=53 session_id=128000
Dec 14 09:41:30 ns01 moscowsg2: NetScreen device_id=moscowsg2 [Root]sys
temnotification00257(traffic): start_time="20061214 09:41:24" duration=5
policy_id=2 service=http proto=6 src zone=Trust dst zone=Untrust
action=Permit sent=803 rcvd=1422 src=172.23.69.67 dst=217.212.227.33
src_port=10088 dst_port=80 srcxlated ip=81.16.115.166 port=3982 dstxlated
ip=217.212.227.33 port=80 session_id=128009
Dec 14 09:41:30 ns01 moscowsg2: NetScreen device_id=moscowsg2 [Root]sys
temnotification00257(traffic): start_time="20061214 09:41:23" duration=6
201
Следственные действия
Первые три поля каждой записи – это метка времени. Следующие два
идентифицируют источник сообщений. Причем эти метки ставятся не ге
нерирующей лог программой (
«sendmail»
), а логирующей программой.
Оставшаяся часть сообщений принадлежит уже генерирующей программе.
Можно заметить, что записи лога группируются попарно: каждая пара
записей имеет одинаковый идентификатор (группа символов после двое
точия, например,
«kBEDsTLt005196»
). Пара записей соответствует двум
этапам обработки сообщения электронной почты – прием и отправка.
Далее приведен образец лога вебсервера
«Apache»
версии 2.1.9beta.
Этот сервер ведет несколько видов логов. Ниже приводится фрагмент
логфайла
«access.log»
– в этом логе фиксируются обработанные зап
росы протокола HTTP:
83.222.198.130 – [28/Nov/2006:14:46:35 +0300] «GET /cgibin/allip_note.pl
HTTP/1.0» 401 475
83.222.198.130 – fnn [28/Nov/2006:14:46:40 +0300] «GET /cgi
bin/allip_note.pl HTTP/1.0» 500 605
83.222.198.130 – fnn [28/Nov/2006:14:47:27 +0300] «GET /cgi
bin/allip_note.pl HTTP/1.0» 200 1053
83.222.198.130 – fnn [28/Nov/2006:14:49:10 +0300] «GET /cgi
bin/allip_note.pl?ip_id=2 HTTP/1.0» 200 2087
83.222.198.130 – fnn [28/Nov/2006:14:49:40 +0300] «GET /cgi
bin/allip_note.pl?ip_id=3 HTTP/1.0» 200 2087
83.222.198.130 – fnn [28/Nov/2006:14:49:49 +0300] «GET /cgi
bin/allip_note.pl?ip_id=4 HTTP/1.0» 200 2087
83.222.198.130 – fnn [28/Nov/2006:14:50:05 +0300] «GET /cgi
bin/allip_note.pl?ip_id=5 HTTP/1.0» 200 2087
83.222.198.130 – fnn [28/Nov/2006:14:56:58 +0300] «POST /cgi
bin/allip_note.pl HTTP/1.0» 200 1101
83.222.198.130 – fnn [28/Nov/2006:14:57:46 +0300] «POST /cgi
bin/allip_note.pl HTTP/1.0» 200 1203
83.222.198.130 – [28/Nov/2006:16:21:58 +0300] «GET / HTTP/1.0» 401 475
83.222.198.130 – amak [28/Nov/2006:16:22:33 +0300] «GET / HTTP/1.0» 200 360
83.222.198.130 – amak [28/Nov/2006:16:22:34 +0300] «GET /cgibin/allip.cgi
HTTP/1.0» 404 289
83.222.198.130 – amak [28/Nov/2006:16:23:24 +0300] «GET /cgibin/allip
view.pl HTTP/1.0» 404 293
83.222.198.130 – amak [28/Nov/2006:16:23:34 +0300] «GET /cgibin/allip
view.pl HTTP/1.0» 404 293
83.222.198.130 – amak [28/Nov/2006:16:23:52 +0300] «GET /cgibin/allip
view.pl HTTP/1.0» 404 293
83.222.198.130 – amak [28/Nov/2006:16:24:22 +0300] «GET /cgi
bin/allip_view.pl HTTP/1.0» 200 1260
83.222.198.130 – amak [28/Nov/2006:16:24:56 +0300] «GET /cgi
bin/allip_add.pl?instype=ip HTTP/1.0» 200 2481
На данном вебсайте включена авторизация. Как можно видеть, в 1й
и 10й записях третье поле содержит «», то есть логин и пароль пользова
теля не были переданы серверу. Соответственно, код ответа вебсервера в
200
Н.Н. Федотов
Форензика – компьютерная криминалистика
ворсинки ткани, пороховой нагар и прочее. Не только можно фальсифи
цировать, но такие попытки регулярно случаются. Несмотря на это, дока
зательствами все такие следы признаются. Чем логи хуже?
Вовторых, фальсификацию логов в ряде случаев можно выявить. И
чем больше информации в распоряжении эксперта, тем больше вероят
ность обнаружения подлога.
Цепочка доказательности
Доказательная сила логов базируется на двух столпах –
корректности и
неизменности
. А именно – она распадается на следующую цепочку эле
ментов:
1) корректность фиксации событий и генерации записей генерирую
щей программой;
2) неизменность при передаче записей от генерирующей программы к
логирующей программе;
3) корректность обработки записей логирующей программой;
4) неизменность при хранении логов до момента изъятия;
5) корректность процедуры изъятия;
6) неизменность при хранении после изъятия, до осмотра, передачи на
экспертизу;
7) корректность интерпретации.
В том случае, когда генерирующая программа сама ведет свои логи (не
применяется специализированная логирующая программа), пункт 2 вы
падает, а пункты 1 и 3 объединяются.
Подчеркнем, что вышеперечисленные пункты составляют именно це
почку, то есть при выпадении одного звена лишаются опоры последующие
звенья. В англоязычной литературе используется термин «custodial chain».
Рассмотрим каждый из пунктов по отдельности и укажем, какие меры
обеспечивают действительность каждого из них.
Корректность генерирующей программы
Любая программа может содержать ошибки. Ошибки эти могут возни
кать спорадически или систематически. В первом случае запись может
быть верной или неверной, в зависимости от сочетания случайных или
псевдослучайных факторов. Во втором случае ошибка будет носить регу
лярный характер. Вероятность ошибки в программе зависит от ее произ
водителя. Считается, что она в целом ниже для производителей, приме
няющих передовые технологии производства программного обеспече
ния, организовавшими процесс производства в соответствии с современ
ными рекомендациями и сертифицировавшими этот процесс по стандар
ту ISO9001. Тем не менее ни у какого производителя вероятность ошиб
ки нельзя считать пренебрежимо малой величиной.
203
Следственные действия
policy_id=2 service=http proto=6 src zone=Trust dst zone=Untrust
action=Permit sent=455 rcvd=3166 src=172.23.69.67 dst=216.127.68.107
src_port=10087 dst_port=80 srcxlated ip=81.16.115.167 port=3969 dstxlated
ip=216.127.68.107 port=80 session_id=127975
Dec 14 09:41:30 ns01 moscowsg2: NetScreen device_id=moscowsg2 [Root]sys
temnotification00257(traffic): start_time="20061214 09:41:26" duration=3
policy_id=2 service=dns proto=17 src zone=Trust dst zone=Untrust
action=Permit sent=90 rcvd=389 src=172.23.36.115 dst=81.16.112.5
src_port=1025 dst_port=53 srcxlated ip=81.16.115.165 port=3965 dstxlated
ip=81.16.112.5 port=53 session_id=128000
Dec 14 09:41:30 ns01 moscowsg2: NetScreen device_id=moscowsg2 [Root]sys
temnotification00257(traffic): start_time="20061214 09:41:23" duration=6
policy_id=2 service=http proto=6 src zone=Trust dst zone=Untrust
action=Permit sent=1341 rcvd=7164 src=172.23.69.67 dst=217.212.227.33
src_port=10085 dst_port=80 srcxlated ip=81.16.115.168 port=4030 dstxlated
ip=217.212.227.33 port=80 session_id=127991
В этом логе форма представления данных более «человечная», прису
тствуют метки, позволяющие легко догадаться, к чему относятся приво
димые числа. Такие аббревиатуры, как
proto, src_port, dst_port,
srcxlated
, говорят специалисту все, что нужно.
Обратите внимание, что в каждой записи присутствуют две метки вре
мени. Одна из них после идентификатора
start_time
ставится генериру
ющей лог программой (ОС межсетевого экрана), а другая – в начале стро
ки логирующей программой (
syslogd
).
Лог как доказательство
Логи, как правило, не являются непосредственным источником дока
зательств, но опосредованным. В качестве посредника выступает мнение
эксперта или специалиста. Вместо самих логов в качестве доказательств
используются: заключение эксперта, заключение специалиста, а также
показания изучавших логи свидетелей специалиста, эксперта, понятых.
То есть компьютерные логи не являются очевидным доказательством,
которое само себя объясняет (такие доказательства, не нуждающиеся в
интерпретации, в англоязычной литературе именуют термином «selfevi
dent»). Логи нуждаются в интерпретации.
Автор полагает, что интерпретация логов во всех случаях требует специ
альных знаний.
Некоторые возражают против доказательности логов, аргументируя
это тем, что логи легко фальсифицировать и не существует никакой мето
дики определения истинности логов, отсутствия фальсификации. Это не
совсем так [W24].
Вопервых, множество следов других типов фальсифицировать тоже
можно. И некоторые – даже проще, чем логи. Волосы, отпечатки зубов,
202
Н.Н. Федотов
Форензика – компьютерная криминалистика
Справедливости ради следует отметить, что ПО «Cisco Systems» поль
зуется хорошей репутацией и имеет далеко не самое высокое удельное
число ошибок, которые к тому же исправно учитываются и своевременно
исправляются.
Итак, следует признать, что генерирующая логи программа может до
пускать ошибки. Однако само по себе это обстоятельство не может слу
жить обоснованием для сомнений
1
. Таковым обоснованием является
лишь наличие известной ошибки, которая удовлетворяет одновременно
трем условиям:
а) подтверждена службой техподдержки производителя, его уполно
моченного представителя (дистрибутора, реселлера) или компетентной
организацией, занимающейся учетом ошибок и уязвимостей, либо уста
новлена в результате КТЭ;
б) имеет отношение к генерации логов и может привести к их некор
ректности, что подтверждается заключением или показаниями эксперта
или специалиста;
в) может возникнуть именно в тех записях лога, которые имеют значе
ние для дела, что также должно быть подтверждено заключением или по
казаниями эксперта или специалиста.
При неисполнении хотя бы одного из трех условий ошибка в програм
ме не является основанием для исключения соответствующего лога из
числа доказательств по делу.
Неизменность при передаче
При передаче записей от генерирующей программы к логирующей
программе ошибки, приводящие к искажению информации, можно не
рассматривать. Их вероятность пренебрежимо мала. Зато не мала вероят
ность недоставки одной или нескольких записей от генерирующей прог
раммы к логирующей. Особенно когда эта доставка происходит по прото
колу syslog [55], который не имеет механизма подтверждения приема со
общения.
То есть на этом этапе не следует сомневаться в корректности записи о
событии, но стоит предусмотреть возможность пропуска одной или нес
кольких записей. Особенно если при экспертном исследовании были ус
тановлены факты пропуска отдельных сообщений при тех же условиях
передачи.
Также целостность лога может быть нарушена при записи в файл. При
выключении компьютера методом обесточивания и некоторых других кри
тических ситуациях может произойти сбой файловой операции, в резуль
тате чего потеряется одна или несколько последних записей логфайла.
205
Следственные действия
Примеры
В качестве иллюстрации систематических ошибок в логах приведем
примеры из практики автора.
Программа
«akpop3d»
– сервер доставки электронной почты (MDA).
Вот фрагмент логфайла
«maillog»
, в котором собираются логи как от
«akpop3d»
, так и от сервера электронной почты (MTA)
«sendmail»
:
Dec 12 21:34:28 home smmta[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=aihstun [10.5.0.1]
Dec 12 21:34:39 home smmta[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 smmta[4051]: kBCIcCrw004051: from=<Most@anderson
agency.net>, size=49465, class=0, nrcpts=1,
msgid=<000c01c71e1c$a3249630$00000000@eigenaarih63rh>, proto=ESMTP,
daemon=IPv4, relay=aihstun [10.5.0.1]
Dec 12 21:38:17 home smmta[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 smmta[4076]: kBCIjBAE004076: from=<dhickling@comi
damexicana.com>, size=5985, class=0, nrcpts=1,
msgid=<000101c71e82$e4adb7ab$9eb3b218@comidamexicana.com>, proto=ESMTP, dae
mon=IPv4, relay=aihstun [10.5.0.1]
Dec 12 21:45:21 home smmta[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 с адреса
0.80.7.40
(см. строку 5), хотя на самом деле доступ был с адреса
10.0.0.2
(в этом
сегменте присутствует вообще единственный клиентский компьютер).
Подобная запись повторяется в логе из раза в раз. Очевидно, что в прог
рамме «akpop3d» имеется систематическая ошибка, приводящая к некор
ректной записи в лог. Скорее всего, в программе происходит непредус
мотренный побитовый сдвиг или данные считываются по неверному ад
ресу памяти.
Другая иллюстрация систематических ошибок в логах. Операционная
система межсетевого экрана «Cisco PIX». Для протокола DNS/UDP вмес
то номера порта показывается ID запроса. Объявлена в версии 4.4(2),
исправлена в версии 6.0(1), идентификатор ошибки (caveats) –
«CSCdt72080»
. Всего в системе учета ошибок (Bug Toolkit) фирмы «Cisco
Systems» зарегистрировано 312 ошибок, связанных с логами. Общее чис
ло ошибок за весь период жизни ПО – десятки тысяч.
204
Н.Н. Федотов
Форензика – компьютерная криминалистика
1
Имеются в виду не любые сомнения, а именно те сомнения, которые
упоминаются в презумпции невиновности (ч. 3 ст. 14 УК).