Файл: Forensics-03.pdf

'finished'

16:00:36.07 4 SMTPI21885([83.222.198.130]) TLS(RC4_SHA) connection

accepted for 'wimax.ru', session 34247

16:00:36.28 4 SMTPI21885([83.222.198.130]) cmd: EHLO fnn.starttele

com.ru

16:00:36.29 3 DNR15701(fnn.starttelecom.ru) A:host name is unknown

16:00:36.29 3 SMTPI21885(fnn.starttelecom.ru) failed to resolve

HELO parameter: host name is unknown. Real address is

[83.222.198.130]

16:00:36.29 4 SMTPI21885([83.222.198.130]) rsp: 250mail1.wimax.ru

host name is unknown fnn.starttelecom.ru\r\n250DSN\r\n250SIZE

104857600\r\n250AUTH LOGIN PLAIN CRAMMD5 DIGESTMD5 GSSAPI MSN

NTLM\r\n250ETRN\r\n250TURN\r\n250ATRN\r\n250NOSOLICITING\r\n250

8BITMIME\r\n250HELP\r\n250PIPELI

16:00:36.33 4 SMTPI21885([83.222.198.130]) cmd: AUTH PLAIN

bi5mZWRvdG92QHN0YXJ0dGVsZWNvbS5ydQBuLmZlZG90b3ZAc3RhcnR0ZWxlY29tLnJ1A

DIzc2Q3c2Rr

16:00:36.46 2 SMTPI21885([83.222.198.130]) 'n.fedotov@starttele

com.ru' connected from [83.222.198.130:51746]

16:00:36.46 2 SMTPI21885([83.222.198.130]) 'n.fedotov@starttele

com.ru' disconnected ([83.222.198.130:51746])

16:00:37.17 4 SMTPI21885([83.222.198.130]) rsp: 235

n.fedotov@starttelecom.ru relaying authenticated

16:00:37.22 4 SMTPI21885([83.222.198.130]) cmd: MAIL

FROM:<fnn@starttelecom.ru> BODY=8BITMIME SIZE=468

16:00:37.22 4 SMTPI21885([83.222.198.130]) rsp: 250 fnn@starttele

com.ru sender accepted

16:00:37.22 4 SMTPI21885([83.222.198.130]) cmd: RCPT

TO:<fnn@fnn.ru>

16:00:37.22 4 SMTPI21885([83.222.198.130]) rsp: 250 fnn@fnn.ru will

relay mail for an authenticated user

16:00:37.22 4 SMTPI21885([83.222.198.130]) cmd: DATA

16:00:37.22 4 SMTPI21885([83.222.198.130]) rsp: 354 Enter mail, end

with "." on a line by itself

16:00:37.30 4 QUEUE([952839]) closed, nOpen=1

...

16:00:39.69 4 SMTP77633(fnn.ru) connected to mail.fnn.ru

[80.94.84.25:25], ESMTP

16:00:39.69 4 SMTP77633(fnn.ru) cmd: EHLO mail1.wimax.ru

16:00:39.74 4 SMTP77633(fnn.ru) rsp: 250aihs.fnn.ru Hello

mail1.wimax.ru [81.16.112.3], pleased to meet you

16:00:39.74 4 SMTP77633(fnn.ru) rsp: 250ENHANCEDSTATUSCODES

16:00:39.74 4 SMTP77633(fnn.ru) rsp: 250PIPELINING

16:00:39.74 4 SMTP77633(fnn.ru) rsp: 2508BITMIME

16:00:39.74 4 SMTP77633(fnn.ru) rsp: 250SIZE

16:00:39.74 4 SMTP77633(fnn.ru) rsp: 250DSN

16:00:39.74 4 SMTP77633(fnn.ru) rsp: 250ETRN

16:00:39.74 4 SMTP77633(fnn.ru) rsp: 250DELIVERBY

16:00:39.74 4 SMTP77633(fnn.ru) rsp: 250 HELP

16:00:39.74 4 SMTP77633(fnn.ru) Connected. DSN SIZE

16:00:39.74 4 SMTP77633(fnn.ru) [952840] sending

16:00:39.74 4 SMTP77633(fnn.ru) cmd: MAIL

FROM:<fnn@starttelecom.ru> SIZE=687

149

Оперативнорозыскные мероприятия

XStatus: RSC

XKMailEncryptionState: N

XKMailSignatureState: N

XKMailMDNSent:  

path test

Nikolay N Fedotov

Information Security Officer

Start Telecom Inc. (Russia)

Два фрагмента лога MTA отправителя (прием и передача). Взяты с

сервера mail.starttelecom.ru, он же mail1.wimax.ru:

16:00:35.57 4 SMTPI21885([83.222.198.130]) got connection on

[81.16.112.3:25](wimax.ru) from [83.222.198.130:51746]

16:00:35.71 4 SMTPI21885([83.222.198.130]) rsp: 220 mail1.wimax.ru

ESMTP CommuniGate Pro 5.0.9

16:00:35.80 4 SMTPI21885([83.222.198.130]) cmd: EHLO fnn.starttele

com.ru

16:00:35.80 3 DNR15700(fnn.starttelecom.ru) A:host name is unknown

16:00:35.80 3 SMTPI21885(fnn.starttelecom.ru) failed to resolve

HELO parameter: host name is unknown. Real address is

[83.222.198.130]

16:00:35.80 4 SMTPI21885([83.222.198.130]) rsp: 250mail1.wimax.ru

host name is unknown fnn.starttelecom.ru\r\n250DSN\r\n250SIZE

104857600\r\n250STARTTLS\r\n250AUTH LOGIN PLAIN CRAMMD5 DIGEST

MD5 GSSAPI MSN NTLM\r\n250ETRN\r\n250TURN\r\n250ATRN\r\n250NO

SOLICITING\r\n2508BITMIME\r\n250HE

16:00:35.84 4 SMTPI21885([83.222.198.130]) cmd: STARTTLS

16:00:35.84 4 SMTPI21885([83.222.198.130]) rsp: 220 please start a

TLS connection

16:00:35.90 4 SMTPI21885([83.222.198.130]) TLSv1 client hello:

method=RC4_SHA, residual=0, session=34247 < 00 00 85 C7 45 82 9C 73

42 FF 69 04 BF 61 AC 45 0F 1E 45 40 1F B0 BE 2C 72 92 44 C2 F2 55

4D 38>

16:00:35.90 4 SMTPI21885([83.222.198.130]) TLS handshake: sending

'server_hello'

16:00:35.90 4 SMTPI21885([83.222.198.130]) TLS handshake: sending

the certificate

16:00:35.90 4 SMTPI21885([83.222.198.130]) TLS handshake: sending

'hello_done'

16:00:36.07 4 SMTPI21885([83.222.198.130]) TLS client key exchange

processed

16:00:36.07 4 SMTPI21885([83.222.198.130]) security initiated

16:00:36.07 4 SMTPI21885([83.222.198.130]) TLS 'change cipher'

processed

16:00:36.07 4 SMTPI21885([83.222.198.130]) TLS 'change cipher'

sending

16:00:36.07 4 SMTPI21885([83.222.198.130]) TLS 'finish handshake'

processed

16:00:36.07 4 SMTPI21885([83.222.198.130]) TLS handshake: sending

148

Н.Н. Федотов

Форензика – компьютерная криминалистика

Dec 15 16:00:43 home smmta[18586]: kBFD0g7M018585:

to=<fnn@home.fnn>, delay=00:00:01, xdelay=00:00:00, mailer=local,

pri=31086, relay=local, dsn=2.0.0, stat=Sent

Сообщение в почтовом ящике получателя (хранится там временно, до

того как получатель заберет свою почту по протоколу POP):

From fnn@starttelecom.ru Fri Dec 15 16:00:43 2006

ReturnPath: <fnn@starttelecom.ru>

Received: from aihs.fnn.ru (aihstun [10.5.0.1])

by home.fnn.ru (8.13.1/8.13.1) with ESMTP id kBFD0g7M018585

for <fnn@home.fnn>; Fri, 15 Dec 2006 16:00:42 +0300 (MSK)

(envelopefrom fnn@starttelecom.ru)

Received: from mail1.wimax.ru (mail1.wimax.ru [81.16.112.3])

by aihs.fnn.ru (8.13.3/8.13.3) with ESMTP id kBFD0bU6010332

for <fnn@fnn.ru>; Fri, 15 Dec 2006 14:00:38 +0100 (CET)

(envelopefrom fnn@starttelecom.ru)

Received: from [83.222.198.130] (account n.fedotov@starttelecom.ru

HELO fnn.starttelecom.ru)

by mail1.wimax.ru (CommuniGate Pro SMTP 5.0.9)

with ESMTPSA id 952840 for fnn@fnn.ru; Fri, 15 Dec 2006 16:00:37

+0300

From: Nikolay Nikolaevich Fedotov <fnn@starttelecom.ru>

Organization: StartTelecom

To: fnn@fnn.ru

Subject: Path test

Date: Fri, 15 Dec 2006 16:00:05 +0300

UserAgent: KMail/1.9.4

MIMEVersion: 1.0

ContentType: text/plain;

charset="koi8r"

ContentTransferEncoding: 7bit

ContentDisposition: inline

MessageId: <200612151600.05273.fnn@starttelecom.ru>

path test

Nikolay N Fedotov

Information Security Officer

Start Telecom Inc. (Russia)

Письмо в архиве входящей почты получателя:

From fnn@starttelecom.ru Fri Dec 15 16:00:43 2006

ReturnPath: <fnn@starttelecom.ru>

Received: from aihs.fnn.ru (aihstun [10.5.0.1])

by home.fnn.ru (8.13.1/8.13.1) with ESMTP id kBFD0g7M018585

for <fnn@home.fnn>; Fri, 15 Dec 2006 16:00:42 +0300 (MSK)

(envelopefrom fnn@starttelecom.ru)

151

Оперативнорозыскные мероприятия

16:00:40.00 4 SMTP77633(fnn.ru) rsp: 250 2.1.0

<fnn@starttelecom.ru>... Sender ok

16:00:40.00 4 SMTP77633(fnn.ru) cmd: RCPT TO:<fnn@fnn.ru>

NOTIFY=FAILURE,DELAY

16:00:40.06 4 SMTP77633(fnn.ru) rsp: 250 2.1.5 <fnn@fnn.ru>...

Recipient ok

16:00:40.06 4 SMTP77633(fnn.ru) cmd: DATA

16:00:40.11 4 SMTP77633(fnn.ru) rsp: 354 Enter mail, end with "."

on a line by itself

16:00:40.11 4 QUEUE([952840]) opened, nOpen=3

16:00:40.11 4 QUEUE([952840]) closed, nOpen=2

16:00:40.17 4 SMTP77633(fnn.ru) rsp: 250 2.0.0 kBFD0bU6010332

Message accepted for delivery

16:00:40.17 2 SMTP77633(fnn.ru) [952840] sent to [80.94.84.25:25],

got:250 2.0.0 kBFD0bU6010332 Message accepted for delivery

16:00:40.17 4 SMTP(fnn.ru) [952840] batch relayed

16:00:40.17 2 DEQUEUER [952840] SMTP(fnn.ru)fnn@fnn.ru relayed:

relayed via mail.fnn.ru

16:00:40.17 4 QUEUE([952840]) dequeued, nTotal=2

16:00:40.17 4 SMTP77633(fnn.ru) cmd: QUIT

16:00:40.17 2 QUEUE([952840]) deleted

16:00:40.23 4 SMTP77633(fnn.ru) rsp: 221 2.0.0 aihs.fnn.ru closing

connection

16:00:40.23 4 SMTP77633(fnn.ru) closing connection

16:00:40.23 4 SMTP77633(fnn.ru) releasing stream

Обратите внимание на идентификатор соединения

«kBFD0bU6010332». Он зафиксирован как в логе этого сервера, так и в
логе следующего. Он же будет записан в маршрутном заголовке письма.

Фрагмент лога MTA получателя. Взят с сервера mail.fnn.ru:

Dec 15 14:00:38 aihs smmta[10332]: kBFD0bU6010332: from=<fnn@start

telecom.ru>, size=661, class=0, nrcpts=1,

msgid=<200612151600.05273.fnn@starttelecom.ru>, proto=ESMTP,

daemon=IPv4, relay=mail1.wimax.ru [81.16.112.3]

Dec 15 14:00:39 aihs smmta[10333]: kBFD0bU6010332: to=fnn@home.fnn,

delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=30881,

relay=home.fnn. [80.94.84.26], dsn=2.0.0, stat=Sent (kBFD0g7M018585

Message accepted for delivery)

Фрагмент лога второго MTA получателя, на который предыдущий

сервер (mail.fnn.ru) пересылает (forward) всю полученную почту. Взят с
сервера home.fnn.ru:

Dec 15 16:00:43 home smmta[18585]: kBFD0g7M018585: from=<fnn@start

telecom.ru>, size=877, class=0, nrcpts=1,

msgid=<200612151600.05273.fnn@starttelecom.ru>, proto=ESMTP,

daemon=IPv4, relay=aihstun [10.5.0.1]

150

Н.Н. Федотов

Форензика – компьютерная криминалистика

From crackpotsaugur's@accion.org Wed Dec 13 02:25:42 2006

ReturnPath: <crackpotsaugur's@accion.org>

Received: from aihs.fnn.ru (aihstun [10.5.0.1])

by home.fnn.ru (8.13.1/8.13.1) with ESMTP id kBCNPfIu006292

for <fnn@home.fnn>; Wed, 13 Dec 2006 02:25:41 +0300 (MSK)

(envelopefrom crackpotsaugur's@accion.org)

Received: from mskm10st01.rtcomm.ru (mskm10st01.rtcomm.ru

[213.59.0.34])

by aihs.fnn.ru (8.13.3/8.13.3) with ESMTP id kBCNPb2X094397

for <nfnn@fnn.ru>; Wed, 13 Dec 2006 00:25:38 +0100 (CET)

(envelopefrom crackpotsaugur's@accion.org)

Received: from mskm10st01.rtcomm.ru (localhost.rtcomm.ru

[127.0.0.1])

by mskm10st01.rtcomm.ru (Postfix) with SMTP id D2E6669E19

for <nfnn@fnn.ru>; Wed, 13 Dec 2006 02:25:37 +0300 (MSK)

Received: from p54BE5FBF.dip.tdialin.net (p54BE5FBF.dip.t

dialin.net [84.190.95.191])

by mskm10st01.rtcomm.ru (Postfix) with ESMTP id

EB48069ED9

for <nfnn@fnn.ru>; Wed, 13 Dec 2006 02:25:35 +0300 (MSK)

Received: from 12.15.162.211 (HELO smtp2.accion.org)

by fnn.ru with esmtp (7(6.674)?F/ 4.43)

id 58T.)?.ATUDDX

for nfnn@fnn.ru; Thu, 1 Jan 1998 11:05:44 0060

From: "Juana Deal" <crackpotsaugur's@accion.org>

To: <nfnn@fnn.ru>

Subject: [!! SPAM] It ready

Date: Thu, 1 Jan 1998 11:05:44 0060

MessageID: <01bd16a5$34c829f0$6c822ecf@crackpotsaugur's>

MIMEVersion: 1.0

ContentType: text/plain;

charset="iso88592"

ContentTransferEncoding: 7bit

XPriority: 3 (Normal)

XMSMailPriority: Normal

XMailer: Microsoft Office Outlook, Build 11.0.5510

XMimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2905

ThreadIndex: Aca6Q,IL*A82<@Y=XJD'59Q+16@.**==

XSpamTestEnvelopeFrom: crackpotsaugur's@accion.org

XSpamTestGroupID: 00000000

XSpamTestInfo: Profiles 597 [Dec 12 2006]

XSpamTestInfo: {Headers: Spam A269}

XSpamTestMethod: headers plus

XSpamTestRate: 100

XSpamTestStatus: SPAM

XSpamTestStatusExtended: spam

XSpamTestVersion: SMTPFilter Version 3.0.0 [0255], KAS30/Release

XAntiVirus: Kaspersky AntiVirus for MailServers 5.5.2/RELEASE,

bases: 12122006 #236282, status:

notchecked

153

Оперативнорозыскные мероприятия

Received: from mail1.wimax.ru (mail1.wimax.ru [81.16.112.3])

by aihs.fnn.ru (8.13.3/8.13.3) with ESMTP id kBFD0bU6010332

for <fnn@fnn.ru>; Fri, 15 Dec 2006 14:00:38 +0100 (CET)

(envelopefrom fnn@starttelecom.ru)

Received: from [83.222.198.130] (account n.fedotov@starttelecom.ru

HELO fnn.starttelecom.ru)

by mail1.wimax.ru (CommuniGate Pro SMTP 5.0.9)

with ESMTPSA id 952840 for fnn@fnn.ru; Fri, 15 Dec 2006 16:00:37

+0300

From: Nikolay Nikolaevich Fedotov <fnn@starttelecom.ru>

Organization: StartTelecom

To: fnn@fnn.ru

Subject: Path test

Date: Fri, 15 Dec 2006 16:00:05 +0300

UserAgent: KMail/1.9.4

MIMEVersion: 1.0

ContentType: text/plain;

charset="koi8r"

ContentTransferEncoding: 7bit

ContentDisposition: inline

MessageId: <200612151600.05273.fnn@starttelecom.ru>

path test

Nikolay N Fedotov

Information Security Officer

Start Telecom Inc. (Russia)

Дотошный читатель может самостоятельно сравнить отправленное

и полученное сообщение и определить, какие именно служебные заго
ловки (кроме упоминавшихся маршрутных заголовков 

«Received»

) у

них отличаются. Также можно сравнить указанные в логах и заголов
ках моменты времени и сделать из них выводы не только о «скорости»
письма, но и о разнице в показаниях часов всех участвующих компью
теров.

Как видно по иллюстрациям, по пути к сообщению добавились три

маршрутных заголовка 

«Received»

соответственно трем серверам

электронной почты (MTA), через которые сообщение прошло. Эти за
головки добавляются сверху, то есть нижний из них – первый, верхний
– последний.

Бывает, что сервер добавляет не один, а два или даже три заголовка,

если он производит какуюлибо дополнительную, «внутреннюю» обра
ботку или пересылку сообщения, например, передает его на проверку ан
тивирусной программе. Приведем в качестве примера такого случая заго
ловки другого сообщения, полученного автором (тело сообщения не при
водится).

152

Н.Н. Федотов

Форензика – компьютерная криминалистика

ловок 

«Received: from 12.15.162.211 (HELO smtp2.accion.org) by

fnn.ru...»

явно подложный, поскольку проставлен он от имени не

существующего сервера 

«fnn.ru»

из домена, который принадлежит

получателю. Это довольно распространенная уловка для рассылки
спама*.

Формат сообщений

Сообщения электронной почты имеют многовариантный, неоднок

ратно расширявшийся формат, который определяется соответствующим
стандартом [31].

В качестве приложений допустимы различные типы данных, в том

числе произвольные, бинарные. При отправке и получении сообщений
электронной почты клиентские программы стараются кодировать и де
кодировать данные без участия и ведома пользователя. Хранящийся в ар
хиве исходный текст сообщения (см. примеры выше) часто совсем не по
хож на то, что видно в почтовом клиенте.

Содержимое тела сообщения и приложений может кодироваться нес

колькими различными способами: UUENCODE, Base64, quotedprint
able. Оно может быть в обычном, текстовом формате, в HTMLформате
или в обоих сразу.

В рамках данной книги невозможно описать всего разнообразия кон

тента электронной почты, поэтому отошлем читателя к соответствующей
литературе [2, 23, 31].

Документирование прохождения сообщений

В рамках предварительного следствия необходимо не только исследо

вать электронные следы с целью установления истины, но и добывать
пригодные доказательства. То есть документировать действия в порядке,
установленном УПК.

Предположим, в рамках расследования необходимо доказать факт

направления сообщения электронной почты от подозреваемого к потер
певшему. Какие доказательства необходимо собрать для этого и как их
закрепить? Автор предлагает три варианта – нестрогий, промежуточный
и строгий.

Деревенский вариант

Производится осмотр или экспертиза компьютера отправителя. Из

архива отправленных извлекается, распечатывается и приобщается к де
лу интересующее нас сообщение.

Производится осмотр или экспертиза компьютера получателя. Из ар

хива полученных извлекается, распечатывается и приобщается к делу ин
тересующее нас сообщение.

155

Оперативнорозыскные мероприятия

Два заголовка 

«Received»

от одного и того же сервера (2й и 3й сни

зу) означают, что сообщение было обработано в два этапа: сначала при
нято, потом проверено антивирусноантиспамовой программой и лишь
после этого отослано дальше. При указанной проверке к служебным за
головкам были добавлены еще несколько заголовков, начинающиеся с

«XSpamTest»

.

Можно ли доверять заголовкам?

Возникает резонный вопрос: насколько сложно фальсифицировать

служебные заголовки письма? Например, чтобы направить следствие по
ложному пути.

Понятно, что, имея доступ на запись к логфайлам и к архиву почты,

можно изменить любые данные. А что можно фальсифицировать, не
имея такого доступа?

Заголовки 

«From»

, 

«To»

, 

«Subject»

, 

«Date»

и некоторые другие прос

тавляются клиентской программой (MUA) отправителя и при дальней
шей передаче не изменяются. Поэтому отправитель может их заполнить
по собственному усмотрению. Если клиентская программа этого сделать
не позволяет, надо использовать другую программу или даже обойтись
вовсе без нее, составив сообщение в любом текстовом редакторе и пере
дав серверу через telnet. То есть заголовкам 

«From»

, 

«To»

, 

«Date»

и

«ReplyTo»

доверять нельзя.

Заголовок 

«ReturnPath»

проставляется принимающим сервером

электронной почты, но его содержимое извлекается из команды 

«mail

from»

, которую отдает клиентская сторона во время сеанса связи (SMTP

сессии). Соответственно, этот заголовок тоже может быть фальсифици
рован.

Заголовки 

«Received»

проставляются принимающим сервером. Поэ

тому передающая сторона подставить в них произвольные данные не мо
жет. Однако фальсификатор может поставить в передаваемое сообщение
несколько подложных 

«Received»

, как будто сообщение уже ранее

прошло через некие сервера. При получении сервер не проверяет соотве
тствия последнего маршрутного заголовка 

«Received»

и адреса передаю

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

«Received»

следует проверять, сверяя их с записями в логах соответствующих серве
ров электронной почты.

Пример подложного заголовка можно увидеть на последней из ил

люстраций в предыдущем параграфе. Первый (самый нижний) заго

154

Н.Н. Федотов

Форензика – компьютерная криминалистика

●

возможность «холостых» писем;

●

возможность выстраивать цепочки из ремейлеров;

●

гарантии отсутствия логов;

●

расположение ремейлера в стране с либеральным законодательством;

●

использование SMTP/TLS с соответствующими сертификатами;

●

письма с приложениями (аттачами);

●

использование отправителем обычного ПО, без какихлибо добавлений;

●

встроенный антивирус.

Как правило, всё взаимодействие пользователя с ремейлером произ

водится по электронной почте при помощи сообщений. Вебсайты есть
не у всех анонимайзеров, ибо наличие вебсайта снижает анонимность.

В основном ремейлеры построены на программном обеспечении двух

типов: «Cypherpunk» и «Mixmaster». Оба кода являются открытыми про
ектами.

Помимо описанных «канонических» ремейлеров существует великое

множество коммерческих проектов на основе проприетарного ПО для
анонимизации отправки электронной почты и других действий пользова
телей. Подписка на такие услуги обходится пользователю от 2 до 20 дол
ларов ежемесячно. Как правило, требуется установить на рабочей стан
ции пользователя программное обеспечение, которое взаимодействует с
сервером и обеспечивает проксирование трафика.

Довольно часто подобные сервисы представляют собой заурядный об

ман потребителей, то есть они както работают, но анонимности не обеспе
чивают. Владельцев таких сервисов можно понять. Кому же захочется выг
лядеть перед властями соучастником и укрывателем террористов, хакеров,
спамеров и прочих правонарушителей, да еще за такие смешные деньги?

История знает несколько случаев, когда владельцы анонимизирую

щих ремейлеров, несмотря на декларации об отсутствии логов, все же
предоставляли властям сведения об IPадресах отправителей. В некото
рых странах попросту запрещено не вести логов или не сохранять их в те
чение положенного времени, например, в США. В таких странах настоя
щий анонимизирующий ремейлер работать не может. Но во многих стра
нах законодательство довольно либерально и вполне позволяет предос
тавлять подобный сервис и не вести логи.

Некоторые анонимизирующие провайдеры (как, впрочем, и иные

провайдеры) склонны сотрудничать с правоохранительными органами в
деле установления личности своих клиентов, некоторые – нет. Сказать
наперед, предоставит ли информацию тот или иной оператор связи,
нельзя. В одних странах операторы обязаны это делать и подлежат нака
занию в случае отказа. В других странах операторы такой обязанности не
имеют. Тем не менее бывает поразному. В первом случае все равно мож
но получить от оператора отказ под благовидным предлогом. А во втором

157

Оперативнорозыскные мероприятия

Оба вышеуказанных сообщения сравниваются. Должны совпасть тело

письма (возможно, с точностью до кодировки) и основные служебные за
головки. Из этого совпадения делается вывод о том, что сообщение ре
ально было отправлено и получено.

Провинциальный вариант

В дополнение к копиям сообщения с компьютеров отправителя и по

лучателя к делу приобщается также документ о логах хотя бы одного сер
вера электронной почты (MTA), через который сообщение прошло, –
протокол осмотра, заключение эксперта или, в крайнем случае, письмен
ный ответ провайдера на запрос. Сервер должен находиться под управле
нием незаинтересованного лица, обычно это оператор связи. Данные из
лога должны коррелировать с заголовками из полученного сообщения.

Таким образом, в лице независимого сервера появляется третья «точ

ка опоры».

Столичный вариант

В деле должно иметься не менее трех независимых друг от друга сви

детельств о прохождении письма. Например, компьютер отправителя,
компьютер получателя и MTA провайдера. Либо компьютер получателя и
MTA двух «промежуточных» провайдеров. Каждое должно быть закреп
лено экспертизой. Естественно, данные должны коррелировать.

Анонимные ремейлеры

Анонимизирующие транзитные сервера электронной почты – ремей

леры – предназначены для сокрытия отправителей сообщений, которые,
согласно официальной политике этих серверов, «могут опасаться неза
конных преследований или политических репрессий». Рассылка спама*
через такой ремейлер невозможна – для этого предприняты соответству
ющие технические меры.

Пользователь отправляет сообщение на специальный адрес. Ремейлер

получает его, расшифровывает, обрабатывает предусмотренным образом
и затем отсылает на адрес, указанный пользователем в специальной ко
манде в теле письма.

Функциональность и особенности хороших ремейлеров на сегодняш

ний день таковы:

●

прием почты только в зашифрованном виде (с сильной криптогра

фией);

●

удаление всех без исключения служебных заголовков исходного письма;

●

удаление всех других идентифицирующих признаков исходного письма;

●

возможность вставлять произвольные заголовки;

●

возможность задавать произвольную задержку в отправке;

156

Н.Н. Федотов

Форензика – компьютерная криминалистика