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

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

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

среда, 23 февраля 2011 г.

ИНТЕРНЕТ ПОИСК КАК МЕТОД ОПЕРАТИВНО-РОЗЫСКНОЙ ДЕЯТЕЛЬНОСТИ

       Несколько примеров.

     Потерпевшим было получено по электронной почте письмо с предложением перевести некую сумму через систему «WebMoney» под угрозой разглашения данных об уязвимости его веб-сервера. Выкуп предлагалось перевести на счет (кошелек) номер Z18364577. Пока один оперативник выяснял у сотрудников платежной системы, кем использовался этот счет, другой ввел строку «Z18364577» в поисковой системе. Оказалось, что этот номер кошелька уже засвечен в Интернете. Один пользователь жаловался, что перевел на него деньги в оплату за некую услугу, но обещанной услуги не получил. Таким образом нашелся второй потерпевший, в деле появился второй эпизод и дополнительные доказательства.
     Поступило заявление о клевете. Неизвестный злоумышленник разместил на веб-форуме информацию, порочащую деловую репутацию потерпевшего. К сожалению, не удалось установить, с какого IP-адреса происходило размещение информации, поскольку злоумышленник воспользовался анонимным прокси-сервером. Тогда оперативник предположил, что преступник мог разместить ту же информацию и на иных интернет-ресурсах. Он ввел характерную фразу из размещенной статьи в поисковую систему и нашел два других веб-форума, на которых, по-видимому, тот же злоумышленник разместил ту же информацию. Во всех случаях он воспользовался анонимизирующим прокси-сервером. Одна ко на одном из найденных форумов, кроме вышеописанного клеветнического материала, было обнаружено еще несколько постингов (статей), судя по их содержанию, размещенных тем же человеком. Размещенных уже без использования прокси. По ним-то оперативники и вышли на исполнителя.
      Подозреваемый в мошенничестве кардер, задержанный в Москве, был отпущен под подписку о невыезде и немедленно скрылся. Оперуполномоченный для розыска подозреваемого нашел в деле несколько адресов электронной почты, которыми тот пользовался в разное время. Поиск в Интернете по этим адресам среди прочих результатов принес одно объявление о продаже номеров кредитных карт. Объявление было размещено давно и явно неактуально. Однако кроме адреса электронной почты в объявлении был указан для контактов также номер ICQ. Оперативник предположил, что подозреваемый может до сих пор пользоваться этим номером. Он ввел номер в контакт-лист своего ICQ-клиента и стал ждать, когда абонент «выйдет в эфир», то есть будет обозначен как «online». Через несколько недель это случилось. Подозреваемый стал пользоваться своим номером ICQ почти ежедневно. Оперативник пытался определить IP-адрес, с которого подозреваемый соединяется, но без прямого контакта с ним это оказалось невозможным. Тогда оперуполномоченный вторично обратился к поисковой системе и стал искать, где еще упоминается номер ICQ подозреваемого. И нашел относительно свежее объявление, касающееся организации DoS-атак на сервер. Это дало повод для контакта. Оперативник по ICQ вышел на контакт с подозреваемым и ежедневно общался с ним, пользуясь найденным предлогом. При обмене сообщениями по ICQ есть возможность определить IP собеседника (правда, не во всех случаях). В течение нескольких дней общения в качестве IP подозреваемого детектировался адрес socks-сервера. Но однажды высветился IP-адрес, похожий на реальный. Он числился за германским провайдером из города Франкфурт-на-Майне. Согласно материалам дела, у подозреваемого в этом городе жил родственник. Дальнейшее было делом техники. Через провайдера установили адрес, и через несколько дней немецкая полиция подозреваемого арестовала. Не прошло и года, как он был экстрадирован в Россию.
      Поисковые системы в Интернете стали не только основной «дорогой в сеть» для обычных пользователей, они также широко используются злоумышленниками. При помощи поисковых систем завлекаются жертвы на веб-сайты мошенников. При помощи поисковых систем находятся как сведения об уязвимостях, так и сервера, имеющие эти уязвимости.
       При помощи поисковых систем маскируется местоположение веб-сайтов. При помощи поисковых систем определяются перспективные слова для киберсквоттинга. И так далее. В работе специалистов по защите информации поисковые системы также используются широко. Почему бы не использовать их и в оперативной работе?
     Для криминалистики поисковые системы представляют большой интерес, поскольку в них также можно обнаружить следы. Очень многие виды сетевой активности оставляют след в поисковых системах. И этот след не только проще найти, но в ряде случаев он держится в базе данных поисковика дольше, чем в оригинальном расположении.
       Например, в ходе одного гражданского дела о нарушении авторских прав истец смог доказать факт размещения ответчиком произведения в сети, хотя ответчик к тому моменту уже успел убрать его с веб-сайта. Но в базе данных двух поисковых систем первоначальная версия сайта ответчика осталась. Заверенные нотариусом распечатки страниц поисковых систем с кэшированным содержимым сайта ответчика признаны судом достаточным доказательством того факта, что в прошлом произведение размещалось в Сети и было общедоступно.
      Также поисковик полезен для других задач. Например, для декомпиляции программ. С целью исследования программ для ЭВМ, доступных исследователю только в виде исполняемого (объектного) кода, можно воспользоваться декомпилятором. Но проблема в том, что восстановленный таким образом исходный текст малопонятен для человека и не соответствует исходному тексту, из которого был сделан объектный код.
    Говорят, что операция компиляции исходного текста необратима. Вместо декомпиляции можно провести поиск в Интернете на предмет исходного кода этой же программы. Злоумышленник, скорее всего, не написал свою программу с нуля, а позаимствовал ее целиком или немного модифицировал чужую программу, взяв ее из того же источника – из Сети. Невозможно по исполняемому коду восстановить исходный код программы на алгоритмическом языке высокого уровня, но возможно доказать, что найденный исходный код соответствует имеющемуся исполняемому коду.
     С другой стороны, со стороны поисковой системы тоже можно вести оперативно-розыскную деятельность. Или получать данные в ходе следственных действий. Поисковая система может протоколировать и сохранять все действия пользователя. Объем этой информации относительно невелик, поэтому хранить ее можно без особых затрат на протяжении нескольких лет. Судя по всему, поисковики так и делают.
    Когда и какие поисковые запросы отправлял пользователь, по каким из показанных ему ссылок переходил – эти сведения могут быть полезны в ОРД и послужить косвенными доказательствами по уголовному делу.
     Поисковая система идентифицирует пользователя по cookie-файлу, а также другим доступным через протокол HTTP параметрам (IP-адрес, версия браузера и ОС, язык, местное время и т.д.).
      По некоторым уголовным делам, обнаружив на компьютере подозреваемого cookie от поисковой системы, имеет смысл затребовать протокол действий этого пользователя у администрации поисковика. При этом нужно будет предоставить содержимое cookie и параметры браузера. Разумеется, потребуется судебная санкция.



КЕЙЛОГЕРЫ

      Кейлогерами (keyloggers) называют устройства (программные или аппаратные) для перехвата сигналов с клавиатуры, то есть для записи последовательности нажатых пользователем клавиш.
      Большинство паролей набирается с клавиатуры. С нее же вводится большая часть переписки, персональных данных и иной информации, которая может интересовать злоумышленников. Поэтому сбор информации о нажатых клавишах является эффективным способом совершения различных компьютерных преступлений.
       Наряду с этим кейлогер может служить инструментом для проведения ОРМ.
     Кейлогер можно отнести к устройствам двойного назначения. У него есть ряд легальных применений: отслеживание владельцем случаев несанкционированного использования его собственного компьютера, архивирование информации пользователя на случай ее утраты при сбоях. Тем не менее очевидно, что основным предназначением кейлогеров является скрытное (негласное) получение информации.

АППАРАТНЫЕ КЕЙЛОГЕРЫ

       Они выполнены в виде переходника, который вставляется в разрыв клавиатурного кабеля. Бывают аппаратные устройства, которые встроены непосредственно в клавиатуру.

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

      Современный кейлогер имеет встроенную память на сотни килобайт или несколько мегабайт, собранную информацию хранит в зашифрованном виде. Взаимодействие с «хозяином» обычно строится на том же самом интерфейсе, то есть при помощи клавиатуры, в которую он включен.
       Любой желающий может без формальностей приобрести аппаратный кейлогер по цене 150 200 долларов.

ПРОГРАММНЫЕ КЕЙЛОГЕРЫ

      Такие программы доступны как за деньги, так и бесплатно. Как правило, они выполнены по технологиям, используемым в троянских программах, каковыми, по сути, и являются.
    Большинство программных кейлогеров будут признаны вредоносными программами, поскольку приспособлены для скрытного внедрения и незаметной для пользователя работы. Однако некоторые из них, имеющие «открытый» режим, добросовестный эксперт вредоносной программой не признает.
     Многие программные кейлогеры имеют дополнительные функции – запись движений мыши и снятие скриншотов.




ПРИНАДЛЕЖНОСТЬ АДРЕСА ЭЛЕКТРОННОЙ ПОЧТЫ

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

ПОЧТОВЫЙ ЯЩИК

     В большинстве случаев адрес электронной почты однозначно связан с почтовым ящиком. И все письма, адресованные на этот адрес, попадают в этот ящик, откуда потом пользователь может их забрать.
      Однако есть исключения:
● групповые или коллективные адреса, которые представляют собой адрес списка рассылки; все поступающие на этот адрес письма рассылаются определенной группе адресатов; таковыми часто бывают ролевые адреса, например, info@company.ru или noc@provider.net;
● технические адреса, за которыми не стоит ни пользователь, ни почтовый ящик; все поступающие на такой адрес письма обрабатываются программой; например, иногда в качестве обратного адреса указывается нечто вроде noreply@domain.com – все, что поступает на такой адрес, отправляется почтовым сервером на устройство /dev/null;
● адреса для пересылки (forward) сообщений; все поступающие на такой адрес сообщения не складываются в почтовый ящик, а перенаправляются на другой, заранее заданный адрес.

УСТАНОВЛЕНИЕ ПРИНАДЛЕЖНОСТИ ПОЧТОВОГО ЯЩИКА

     Для начала следует установить почтовый ящик, с которым связан адрес. Затем выяснить, кто пользуется этим почтовым ящиком. Так будет установлен владелец адреса.
     Для установки места расположения почтового ящика исследователь устанавливает первичный MX домена. Во многих случаях ящик находится на этом же сервере. В других случаях сервер пересылает почту на иной сервер, указанный в его настройках. В обоих случаях требуется узнать эти настройки, чтобы определить местоположение почтового ящика. Для этого потребуется содействие провайдера, обслуживающего сервер. Расположение почтового ящика документируется протоколом осмотра нужного сервера (серверов) или заключением эксперта. В крайнем случае, можно ограничиться получением письменного ответа провайдера на соответствующий запрос, но этот способ доказательства нельзя назвать безупречным.
      Доказательствами факта использования почтового ящика определенным лицом могут служить:
● наличие на компьютере этого лица настроек для доступа к этому ящику (включая пароль);
● наличие на компьютере этого лица полученных сообщений электронной почты со служебными заголовками, свидетельствующими о прохождении сообщений через этот почтовый ящик;
● наличие на сервере, где расположен ящик, логов об успешном соединении и аутентификации пользователя данного почтового ящика;
● наличие у других абонентов сообщений от этого лица, написанных в ответ на сообщения, отправленные на этот почтовый ящик (в ответе часто цитируется исходное сообщение, а также среди служебных заголовков присутствует заголовок со ссылками на предыдущие сообщения).



ДОКУМЕНТИРОВАНИЕ ПРИНАДЛЕЖНОСТИ ДОМЕНА

      Сложно обстоит дело с документированием принадлежности домена.
     Как для уголовного, так и для гражданского процесса необходимо доказать, что такое-то доменное имя принадлежит такому-то лицу.
     На практике применяются следующие методы (упорядочены от наименее к наиболее предпочтительному):
● Оформить получение справки от whois-сервера рапортом оперуполномоченного. Совсем не безупречный способ. Годится только если обвиняемый (ответчик) не намерен отрицать принадлежность доменного имени.
● Заверить у нотариуса содержимое веб-страницы, представляющей собой веб-интерфейс к команде whois, например, такой, как изображена на последней иллюстрации. Применяется для гражданских дел. Далеко не все нотариусы соглашаются заверять содержимое веб-страниц. Но уж если такого нотариуса удалось найти, то нотариальное заверение производит на суд положительное впечатление. Но для специалиста такой способ – почти профанация, ведь нотариус не видит, к какой именно базе данных подключен веб-интерфейс. Следовательно, его заверение – не более чем заверение надписи на заборе, сделанной неизвестно кем неизвестно для каких целей.
● Получить официальный ответ оператора связи (провайдера), который имел отношение к обслуживанию этого доменного имени, например, поддерживал для него DNS-сервер или веб-сайт. Вместо письма провайдера можно взять показания у соответствующего технического сотрудника этого провайдера.
● Получить показания свидетелей. Например, о том, что интересующее нас лицо совершало определенные действия с доменным именем, доступные только его владельцу.
● Доказать факт оплаты соответствующим лицом услуг по регистрации или продлению домена. Хотя оплачивать можно и чужой домен, но тем не менее это хорошее косвенное доказательство.
● Назначить компьютерно-техническую экспертизу, в ходе которой эксперт запросит нужный whois-сервер и о результатах напишет в своем заключении. Способ несложный, но далеко не безупречный. Сомнительна сама возможность проведения компьютерно-технической экспертизы, когда объект исследования (whois-сервер, база данных регистратора) находится не в распоряжении эксперта, а неизвестно где, на другом конце мира.
● Обнаружить в ходе экспертизы на компьютере соответствующего лица свидетельства соединения и успешной авторизации на интерфейсе регистратора доменов. Практически все регистраторы предоставляют владельцам доменных имен возможность удаленно управлять своими доменами через веб-интерфейс на веб-сайте регистратора. На последующей иллюстрации приводится одна из страниц такого веб-интерфейса регистратора АНО «РСИЦ» (товарный знак «РУ-Центр»). Сам факт успешного доступа к этой странице говорит о прохождении авторизации. Значит, лицо, на компьютере которого обнаружена такая веб-страница, знало верный пароль. А это, скорее всего, означает, что оно и было владельцем домена.
● Получить справку о регистрации доменного имени у соответствующего регистратора или в техническом центре РОСНИИРОС, который поддерживает единую базу данных регистраторов зон RU и SU. Очень хороший способ, но годится только для тех случаев, когда регистратор находится в России, в крайнем случае, в Белоруссии или на Украине.
      У иностранного регистратора получить такую справку труднее, придется задействовать Интерпол.



ДОСТОВЕРНОСТЬ ДАННЫХ РЕГИСТРАТОРА ДОМЕННЫХ ИМЕН

      Следует помнить, что данные о владельце домена заносит в базу регистратор. Как для домена RU, так и для других доменов установлен порядок занесения и изменения записей. Разумеется, присутствуют требования об актуальности и достоверности данных. Однако регистраторы не всегда имеют возможности проводить проверку сообщенных им данных.
      И не всегда вовремя обновляют устаревшие.
      Какие же данные о владельце домена можно считать достоверными?
     Те, от которых зависит его право распоряжаться доменным именем.
   Согласно условиям типового договора большинства регистраторов, указание недостоверных данных о владельце доменного имени может повлечь отмену регистрации. Невозможность связаться по указанным контактным данным также может привести к потере права на доменное имя. Многие регистраторы не позволяют передавать доменные имена иному лицу, пока прежний владелец не представит соответствующие документы. Следовательно, указание неверных контактных данных (телефона, почтового адреса, адреса электронной почты) с немалой вероятностью приводит к потере доменного имени. Указание неверного имени (названия) владельца приводит к тому, что домен нельзя будет передать другому владельцу (продать).
      Отсюда можно сделать вывод о том, какие из указанных данных о владельце более достоверны, а какие – менее.




УСТАНОВЛЕНИЕ ПРИНАДЛЕЖНОСТИ ДОМЕННОГО ИМЕНИ

     Домен – область (ветвь) иерархического пространства доменных имен сети Интернет, которая обозначается уникальным доменным именем.     Подробнее о доменных именах и их правовой природе можно прочесть в популярной книге А. Серго. Здесь автор будет исходить из того, что читателю в общих чертах, то есть на уровне пользователя, известно, для чего предназначены и как используются доменные имена.
     Некоторые юристы относят доменное имя к средствам индивидуализации (ст. 138 ГК). Другие не склонны считать его таковым и говорят, что юридическая природа доменного имени пока четко не определена. Есть даже экзотическое мнение, что доменные имена – это ресурс нумерации электросвязи (ст. 2 и 26 ФЗ «О связи»).
     В отличие от юридической, техническая природа доменных имен известна хорошо и четко описана в соответствующих технических стандартах.
     Для справедливого распределения пространства доменных имен и обеспечения их глобальной уникальности действует система регистрации доменных имен. Подлежат регистрации все доменные имена первого уровня (например, org, info, ru, ua), все доменные имена второго уровня (например, gprf.info, fnn.ru) и некоторые, выделенные доменные имена третьего уровня (например, provider.net.ru, london.co.uk). Прочие доменные имена регистрации не подлежат и распределяются по усмотрению владельца соответствующего домена более высокого уровня (например, домены www.fnn.ru и mail.fnn.ru создаются и используются исключительно по воле владельца домена второго уровня fnn.ru).
     Для каждого домена, где предусмотрена обязательная регистрация, назначен регистратор или несколько регистраторов. В последнем случае все регистраторы обязаны использовать единую базу данных (централизованную или распределенную) для обеспечения уникальности регистрируемых доменных имен.
      Все базы данных всех регистраторов являются публично доступными по протоколу whois, аналогично регистраторам IP-адресов.
       Для домена ru регистраторов существует несколько (по состоянию на сегодня – 14). Они имеют централизованную базу данных, а кроме того – индивидуальные базы данных, являющиеся подмножеством центральной.
       Таким образом, чтобы установить владельца какого-либо доменного имени из числа подлежащих регистрации, следует обратиться к базе данных соответствующего регистратора. Для не подлежащих регистрации доменных имен обращаться нужно к владельцу соответствующего домена более высокого уровня.
     Например, нам требуется установить владельца доменного имени 3 го уровня «www.internet-law.ru». (Не путать с веб-сайтом, живущим на этом домене! Домен и веб-сайт иногда могут иметь разных владельцев.)
      Очевидно, что данный домен 3-го уровня не относится к числу регистрируемых. Он находится в полном распоряжении владельца соответствующего домена 2-го уровня, то есть домена «internet-law.ru», который уже зарегистрирован.
       Здесь придется сделать допущение (впоследствии, если понадобится, это надо будет подкрепить соответствующими доказательствами), а именно предположить, что указанный домен 3 го уровня в силу стандартности его имени (www) принадлежит тому же владельцу, что и домен 2-го уровня.
       Чтобы узнать владельца доменного имени «internet-law.ru», обращаемся к базе данных российских регистраторов доменов. Для этого используем команду «whois», имеющуюся в любой ОС (кроме Windows). В качестве аргумента мы задаем искомое доменное имя, а параметр определяет, какой реестр запрашивать. Параметр «- c ru» указывает реестр доменных имен для России.

 
       Нам отвечает whois-сервер технического центра РОСНИИРОСа (TC-RIPN) – именно он поддерживает единую базу данных всех регистраторов в домене ru.
      Ровно ту же самую информацию можно получить через веб-интерфейс, расположенный на веб сайте РОСНИИРОСа (http://www.ripn.net:8080/nic/whois/index.html) или на многих других веб сайтах.
Запрос доменного имени через веб!интерфейс
Ответ веб-интерфейса
ИЗУЧЕНИЕ ОТВЕТА

      Формат ответа устанавливается владельцем соответствующей базы данных. Он не регламентируется стандартами, и у других регистраторов может быть другим.
       Для российского реестра доменов значения полей ответа таково:
domain: запрашиваемое доменное имя;
type: тип домена (GEOGRAPHICAL – географический, GENERIC – общего назначения, CORPORATE – все прочие);
descr: комментарий;
nserver: DNS-сервера, держащие записи об этом домене;
state: состояние домена;
org: имя владельца (для юридических лиц);
person: имя владельца (для физических лиц);
nic-hdl: идентификатор владельца в БД регистратора;
phone: номер телефона владельца;
fax-no: номер факса владельца;
e-mail: адрес электронной почты владельца;
p_addr: почтовый адрес владельца;
registrar: идентификатор регистратора, зарегистрировавшего этот домен;
created: дата первичной регистрации;
paid till: дата окончания действия регистрации;
changed: дата последнего изменения записи;
source: отвечающий whois-сервер.
       Проведем еще один опыт по установлению владельца домена. Запросим, например, кто владеет доменом «fsb.ru»:


     В качестве регистратора выступает организация, обозначенная идентификатором «RTCOMM-REG-RIPN». Попробуем узнать об этом регистраторе больше. Для этого запросим тот же whois-сервер (ведь все российские регистраторы тоже должны быть зарегистрированы):


     В ответе присутствует указание на собственный whois-сервер регистратора. Как указывалось выше, база данных каждого регистратора является подмножеством общей базы данных и не может ей противоречить.
       Однако whois-сервер конкретного регистратора может быть настроен иначе и выдаст нам более подробную информацию. Сделаем запрос к whois-серверу регистратора. Для этого используем в команде ключ «-h», после которого стоит имя whois-сервера.


     Здесь информации чуть больше. Однако возможности whois себя исчерпали. Для дальнейшей информации следует контактировать с регистратором.

ФИЗИЧЕСКОЕ РАСПОЛОЖЕНИЕ ПОЛЬЗОВАТЕЛЯ IP-АДРЕСА

      Из данных регистратора мы узнаем, за кем закреплена соответствующая подсеть или диапазон IP-адресов. Обычно таковым субъектом является оператор связи или его клиент. Очень редко в базе данных регистратора значится непосредственный пользователь IP-адреса.
     Получить или уточнить данные о непосредственном пользователе, а также установить его географическое расположение можно у оператора связи, на которого зарегистрирован соответствующий диапазон IP. Бывает, что этот оператор не знает точного местоположения клиента, поскольку между ним и клиентом находится оператор-посредник или оператор последней мили. Бывает, что посредник не единственный. В таком случае придется пройти по всей цепочке операторов.
   В принципе, функция определения местоположения конечного оборудования (компьютера пользователя) предусмотрена в СОРМе. Однако очень мало надежды, что такая функция в действительности работает в силу того, что операторы связи учитывают своих клиентов по-разному, держат эти данные в самых различных форматах и редко организуют к ним онлайновый доступ для ФСБ. Привести весь клиентский учет всех операторов к единому знаменателю – задача на сегодняшний день невыполнимая.

ПРИМЕР

       Приведем характерный пример.
    Установлено, что неправомерный доступ к компьютерной информации был осуществлен 31.12.06, 21:01:30 по московскому времени с IP-адреса 217.107.0.58. Данный адрес зафиксирован техническими средствами потерпевшего и его провайдера и закреплен протоколами осмотра и актом экспертизы.
   Запрашиваем whois и выясняем, что сеть 217.107.0.0-217.107.255.255 зарегистрирована за провайдером «Главтелеком», а подсеть 217.107.0.0-217.107.0.255 – за провайдером «Урюпинский хостинг». Первой части этих данных можно верить, поскольку «Главтелеком» является LIR'ом и данные о нем заносятся в базу самим региональным регистратором (RIR). Вторая же часть данных вызывает немного меньше доверия, поскольку здесь выше вероятность ошибки, да и времени с момента последнего обновления записи прошло немало.
   Соответствующую распечатку ответа whois-сервера оформляем рапортом оперативного сотрудника. А в «Главтелеком» направляем официальный запрос с требованием предоставить информацию о клиенте.
    Получаем ответ, в котором ОАО «Главтелеком» подтверждает, что диапазон 217.107.0.0-217.107.0.255 на интересующий момент времени был выделен в пользование его клиенту – ЗАО «Урюпинский хостинг». О дальнейшем распределении и использовании этих IP-адресов знают только в Урюпинске.
      Предполагая, что злоумышленником является не сотрудник этого провайдера, а его клиент, и считая провайдера лицом незаинтересованным, запрашиваем ЗАО «Урюпинский хостинг» об интересующем нас адресе 217.107.0.58, указав точный момент времени, когда имел место неправомерный доступ.
     Получаем ответ из Урюпинска, что поддиапазон адресов 217.107.0.2-217.107.0.63 используется для динамического выделения клиентам услуги коммутируемого доступа (dial-up), а в указанный момент (31.12.06, 18:01:30 по Гринвичу) этот адрес использовался клиентом, авторизованным по логину «pupkin». Этот логин, в свою очередь, закреплен за договором №163/2006 на имя Пупкиной Ирины Васильевны.
     Для закрепления доказательств следует изъять и отправить на экспертизу компьютер, на котором функционировали технические средства, производившие авторизацию пользователя, выделение динамического IP-адреса и ведение соответствующих лог-файлов. Вместо изъятия и экспертизы можно ограничиться осмотром указанных компьютеров и лог-файлов (подробнее см. главу «Осмотр места происшествия»). Также следует изъять клиентский договор.
   Окончательное закрепление доказательств производится в ходе экспертизы компьютера из квартиры Пупкина.
    Итак, цепочка доказательств, привязывающая IP-адрес к компьютеру конечного пользователя, у нас сложилась такая:
● рапорт оперуполномоченного Иванова о выделении сети 217.107.0.0-217.107.255.255 российскому провайдеру «Главтелеком»;
● справка из «Главтелекома» о выделении сети 217.107.0.0-217.107.0.255 провайдеру «Урюпинский хостинг»;
● справка из ЗАО «У.Х.» об использовании подсети 217.107.0.2-217.107.0.63 для динамического выделения клиентам;
● протокол осмотра сервера «У.Х.», где в логах значится выделение адреса 217.107.0.58 пользователю «pupkin» в период 31.12.06, 22:45:31 23:20:12 по местному времени;
● клиентский договор, из которого следует принадлежность логина «pupkin»;
● акт экспертизы компьютера, изъятого при обыске в квартире Пупкина, где зафиксирован факт выхода в Интернет в период 31.12.06, 22:46:31 23:21:12 через модемный пул провайдера «У.Х.».
      Цепочка замкнулась и защелкнулась. Некоторые особенности этой цепочки (вхождение одного диапазона IP в другой диапазон, особенности авторизации, разница и регулярное смещение временных интервалов и т.п.) может пояснить эксперт или специалист в ходе его допроса.


вторник, 22 февраля 2011 г.

ДОКУМЕНТИРОВАНИЕ ОТВЕТА WHOIS-СЕРВЕРА

      Для уголовного дела, скорее всего, будет недостаточно простой распечатки ответа whois-сервера. Получить же официальную справку от европейского регионального регистратора RIPE будет весьма затруднительно, поскольку офис его находится в Амстердаме. Офисы других региональных регистраторов – еще дальше.
      Нынешняя практика предусматривает два способа документирования ответа whois сервера. Первый вариант: распечатка такого ответа может быть заверена каким либо местным оператором связи, являющимся одновременно местным регистратором (LIR). Второй вариант: получение сведений о принадлежности IP-адреса оформляется рапортом оперуполномоченного; сведения из базы данных регистратора приводятся прямо в тексте рапорта. Возможны иные варианты документирования (экспертиза, нотариальное заверение, справка от RIR).
    Принадлежность IP-адреса к конкретному компьютеру все равно должна подтверждаться экспертизой этого компьютера и показаниями сотрудников оператора связи. Поэтому описанная нестрогость в документировании ответа whois сервера вполне допустима.


СТАТИЧЕСКИЕ И ДИНАМИЧЕСКИЕ IP-АДРЕСА

      IP-адреса могут переходить от одного пользователя к другому. Некоторые из них выделяются на постоянной основе – они именуются статическими. Другие же IP-адреса выделяются только на конкретный сеанс связи и называются динамическими. Для статических IP адресов период жизни исчисляется месяцами и годами, а для динамических – минутами.
       В записях для тех диапазонов IP-адресов, которые используются для динамического выделения, обычно это указывается. Там можно увидеть слова «dynamic», «dialup» или «NAT».
     В обоих случаях при установлении принадлежности IP-адресов следует учитывать момент времени, по состоянию на который мы хотим установить пользователя этого адреса. Для динамических IP-адресов этот момент надо указывать с точностью до секунды, поскольку бывают совсем короткие сеансы связи. Кроме времени следует указать часовой пояс и возможную погрешность часов, по которым фиксировалось время.




НЕУЛОВИМЫЙ IP-АДРЕС

      Приведем еще один интересный пример. Это «зомби хостинг», то есть содержание публичных сетевых ресурсов не на серверах, а на компьютерах зомби сети (ботнета). Зомбированные клиентские компьютеры используются как в качестве веб серверов, так и в качестве DNS серверов для соответствующего домена. Зомби сервер живет недолго – от нескольких часов до нескольких дней. Однако их много. Поэтому можно поддерживать постоянную доступность.
     Ниже приводятся результаты проделанного автором эксперимента. В листинге показаны результаты запросов относительно NS серверов и IP-адреса для доменного имени «send safe.com», это веб сайт широко известного в узких кругах производителя программного обеспечения для рассылки спама. Сделаем несколько DNS запросов с интервалом в пять минут:


       Как видно, NS сервера довольно часто меняются. Меняются и IP адреса веб сайта, причем в каждый момент их доступно несколько. То есть веб сайт и обслуживающие его DNS сервера рассредоточены и постоянно мигрируют. Если начать наводить справки о принадлежности и географическом положении всех выявленных IP адресов, то окажется, что они равномерно разбросаны по всему Интернету. На самом деле это адреса зомбированных компьютеров, пригодных для размещения веб сайтов. То есть веб сайт как бы «размазан» по большой зомби сети. Благодаря такой технологии веб сайт «send-safe.com» виден пользователям с очень высокой вероятностью, однако прекратить его работу весьма затруднительно.
       Зафиксировать положение такого сайта невозможно, обнаружить его владельца довольно трудно, доказать факт управления таким сайтомпризраком тоже нелегко.
     Описанная технология применяется довольно редко. Подавляющее же большинство веб сайтов живут на фиксированных IP адресах, операторы владельцы которых знают если не о личности владельца сайта, то, по крайней мере, о самом факте размещения.



воскресенье, 20 февраля 2011 г.

ТРАССИРОВКА IP-АДРЕСА

      Также некоторую помощь в установлении местоположения и принадлежности IP адреса может оказать программа «traceroute», которая имеется в составе любой операционной системы, даже Windows.
      Принцип действия этой программы таков. С компьютера исследователя испускаются IP пакеты, адресованные на целевой IP адрес. Обычно это пакеты протокола UDP, но можно использовать и любой другой. Поле TTL каждого испущенного пакета выставляется последовательно равным 1, 2, 3 и так далее. Это поле предназначено для исключения перегрузки каналов на случай образования петель маршрутизации, то есть замкнутых маршрутов. При прохождении каждого маршрутизатора (маршрутизирующего устройства) поле TTL уменьшается на единицу.
     При достижении значения 0 этот IP пакет сбрасывается, а в адрес отправителя посылается специальное уведомление – сообщение протокола ICMP, тип 11, код 0. Следовательно, пакет с TTL=1 будет сброшен на первом маршрутизаторе по пути следования, пакет с TTL=2 – на втором маршрутизаторе и так далее. По обратному адресу принятых ICMP пакетов компьютер исследователя устанавливает, через какие узлы пролегает маршрут до целевого компьютера.
      Вот пример работы программы «traceroute». Попробуем с ее помощью определить, где располагается сервер www.microsoft.com.

       Как видим, пакеты шли через узлы провайдера «rusmedia.net» (шаги 2 и 3), затем через «rt-comm.ru» (шаг 4), потом через «level3.net» (6 9).
    На девятом шаге пакет, очевидно, перешел в сеть «Майкрософт», потому что соответствующий маршрутизатор имеет в своем имени «microsoft», хотя это имя в домене «level3.net». Все прочие шаги – внутри корпоративной сети Майкрософта (msn.net). В именах транзитных маршрутизаторов мы можем заметить названия «msk» (Москва), «london» (Лондон) «sanjose» (Сан Хосе) – это дает представление об их физическом расположении. Финальный сервер, скорее всего, тоже стоит в городе Сан Хосе.
       Попробуем трассировать тот же сервер из другого места Интернета.


   Путь пакетов пролегает через провайдера «Cogent Communications, Inc.» (cogentco.com), откуда непосредственно переходит в корпоративную сеть «Майкрософта» (msn.net).
      Кроме IP адресов установленных в ходе трассировки узлов указаны соответствующие им доменные имена. Среди операторов связи принято назначать маршрутизаторам доменные имена, говорящие об их принадлежности и географическом расположении. Поэтому можно приблизительно судить о местоположении и подключении целевого адреса. В показанном примере в именах маршрутизаторов мы видим метки городов: «fra» (Франкфурт на Майне), «par» (Париж), «jfk» (Нью Йорк), «dca» (Вашингтон), «iad» (Вашингтон), «ash» (Эшбурн), «pao» (Пало Альто). Эти метки аббревиатуры взяты из кодов аэропортов соответствующих городов.
       Иногда полезно трассировать искомый адрес из разных точек Сети, как бы с разных сторон, чтобы получить более надежные сведения. Для этого можно воспользоваться многочисленными публичными сервисами «looking glass», которые установлены у разных провайдеров и доступны через веб формы.
     У каждого провайдера свои принципы наименования маршрутизаторов и свои условные обозначения. Тем не менее все стараются придерживаться определенных правил и использовать понятные мнемоники. В случае неясности можно попробовать посмотреть whois запись для соответствующего IP адреса, в ней также можно найти указание на географическое расположение.

http://whatismyipaddress.com

      Операции по анализу результатов трассировки IP адреса, их сопоставлению с географией частично поддаются автоматизации. Есть несколько программ, которые с большим или меньшим успехом идентифицируют промежуточные узлы в трассировке.
      К сожалению, нельзя полностью доверять доменным именам узлов, которые определяются программой «traceroute». Следить за корректностью этих имен провайдеры не обязаны. Так что результаты трассировки могут служить лишь косвенным указанием на местоположение компьютера.
        Кроме того, «traceroute», работая исключительно на 3 м (сетевом) уровне, не видит туннели, VPN, MPLS и некоторые иные особенности организации сети.



КОРРЕКТНОСТЬ СВЕДЕНИЙ ОБ IP-АДРЕСАХ

       Можно ли доверять данным, полученным через whois-клиент или веб-форму? Обязанности по внесению, изменению и удалению записей лежат на местных регистраторах (LIR). Но за исполнением этих обязанностей строго не следят. Местный регистратор может несвоевременно обновить запись или же, чтобы облегчить себе работу, зарегистрировать одной записью диапазон адресов, выделенных нескольким разным клиентам. Кроме того, данные о пользователях IP адресов заносятся, как правило, со слов клиента, без должной верификации. Всё это приводит к тому, что среди записей указанной базы данных встречаются неверные – устаревшие или с неполными, некорректными сведениями.
     Поэтому всецело доверять таким сведениям не следует. Как правило, сведения о местном регистраторе (LIR) – верные, поскольку LIR является членом регионального регистратора (RIR), имеет с ним договор, платит членские взносы, постоянно взаимодействует. А сведения о клиенте LIR'а, непосредственном пользователе IP, подлежат дальнейшей проверке.



суббота, 19 февраля 2011 г.

УСТАНОВЛЕНИЕ ПРИНАДЛЕЖНОСТИ IP-АДРЕСА ЧЕРЕЗ ВЕБ-ФОРМУ

     Тот же результат можно получить, сделав запрос через веб форму на веб сайте ip-whois.net.
      Разница между получением справки через whois клиент и веб форму невелика. Источник тот же. Просто во втором случае добавляется еще один технический посредник в лице чужого веб сайта.


     Подобных сайтов существует достаточное количество, достатосно ввести в поисковике "Определить IP-адрес".



УСТАНОВЛЕНИЕ ПРИНАДЛЕЖНОСТИ IP-АДРЕСА ЧЕРЕЗ WHOIS-КЛИЕНТ

       Давайте для примера попробуем установить, где живет в настоящее время известный экстремистский ресурс «Кавказ центр». Определим соответствующий ему IP адрес и спросим об этом IP адресе регистратора RIPE.
     Команда «host» разрешает доменное имя в IP адрес, а последующая команда «whois3» связывается с whois сервером указанного регистратора, делает запрос к его базе данных и выводит на экран всю полученную информацию.


    Из полученного ответа усматривается, что диапазон IP адресов с 88.80.0.0 по 88.80.31.255 выделен шведскому оператору связи «prq Inet». Из этого диапазона меньший поддиапазон с 88.80.2.0 по 88.80.7.255 используется как «Co-located customer servers», то есть для клиентских серверов на колокации. В их числе и интересующий нас 88.80.5.42 (www.kavkazcenter.com).
      «Соседями» домена «www.kavkazcenter.com», то есть доменами, имеющими тот же IP адрес, оказались, согласно данным проекта «IP Neighbors Domain Check», следующие:
     kavkaz.org.uk
     kavkaz.tv
     kavkaz.uk.com
     kavkazcenter.com
     kavkazcenter.info
     kavkazcenter.net
     old.kavkazcenter.com
     pda.kavkaz.tv
     pda.kavkazcenter.com
     wap.kavkaz.tv
       
     Из чего можно заключить, что на этом сервере живут только проекты одного клиента. Это значит, что сервер – выделенный, принадлежит клиенту или целиком арендуется им у провайдера.



УНИКАЛЬНОСТЬ IP-АДРЕСОВ

      IP-адрес является уникальным идентификатором компьютера или иного устройства в сети Интернет. Это значит, что в пределах всей глобальной компьютерной сети в каждый момент времени только один единственный компьютер может использовать определенный IP адрес. Из этого правила имеется целый ряд исключений:
● приватные, или так называемые «серые» IP адреса;
● коллективные, или мультикастовые (multicast) IP адреса;
● сетевые и широковещательные (broadcast) IP адреса;
● не выделенные или не присвоенные регистратором IP адреса;
● IP адреса, относящиеся к территориально распределенным кластерам компьютеров.
      Если же IP адрес относится к категории публичных (так называемых «белых») адресов, если он должным образом выделен одним из регистраторов, то этот адрес будет маршрутизироваться. То есть IP пакет, отправленный на этот адрес из любой точки Интернета, найдет свою цель. Это значит, что данный IP адрес – уникальный. И возможно установить компьютер, которому принадлежит этот IP адрес.
     Является ли тот или иной IP адрес уникальным, не принадлежит ли он к упомянутым исключениям – это устанавливает специалист или эксперт.
    Выделением и регистрацией IP адресов в Интернете занимаются организации, именуемые регистраторами IP адресов (IP Registry). Это организации, являющиеся органами самоуправления Интернета.
       Регистраторы образуют трехуровневую иерархию: IANA – RIR – LIR.
Организация IANA является главным регистратором, она выделяет самые крупные блоки        IP адресов региональным регистраторам и большим организациям.
     Региональных регистраторов (RIR) в настоящее время пять. Это ARIN (Северная Америка), RIPE (Европа и Центральная Азия), APNIC (Азиатско Тихоокеанский регион), LACNIC (Латинская Америка), AfriNIC (Африка). Они выделяют крупные и средние блоки адресов местным регистраторам (LIR), а также ведут базу данных выделенных IP адресов и предоставляют доступ к ней.

       Местные регистраторы (LIR) выделяют мелкие блоки IP адресов операторам связи и потребителям и регистрируют их в базе данных своего регионального регистратора. Как правило, роль местного регистратора исполняет оператор связи (интернет провайдер). Таких регистраторов – несколько тысяч.
     Все выделенные IP адреса регистрируются в специальной базе данных, которую поддерживает региональный регистратор (RIR). Сведения из этой базы данных (за исключением некоторых полей) доступны любому лицу по протоколу whois [22]. Обратиться к этой базе достаточно просто. При наличии доступа в Интернет надо набрать в командной строке «whois <ip-адрес>». Такая команда имеется в любой операционной системе, кроме Windows. Для тех, кому она недоступна или неудобна, есть многочисленные веб интерфейсы, то есть веб страницы, на которых можно ввести запрашиваемый IP адрес и получить ответ из соответствующей базы данных при помощи браузера.

ИССЛЕДОВАНИЕ СИСТЕМНЫХ ЛОГОВ

      Логирование событий в операционной системе является одной из трех составляющих безопасности. Имеется в виду модель «AAA» – authentication, authorization, accounting – аутентификация, авторизация, аудит. Запись всех событий, связанных прямо или косвенно с безопасностью системы, и составляет сущность аудита. Логирование само по себе не препятствует злоумышленнику получить несанкционированный доступ к информационной системе. Однако оно повышает вероятность его выявления, а также последующего нахождения и изобличения злоумышленника. Также логирование способствует выявлению уязвимостей защищаемой системы.
    Чем более полон аудит, тем проще расследовать компьютерное преступление. Пользуясь записанными данными, специалист или эксперт может извлечь много полезной для дела информации.
   Рассмотрим устройство системного аудита событий для различных классов операционных систем.

СИСТЕМНЫЕ ЛОГИ WINDOWS

      В операционных системах линейки «Windows NT» – «Windows 2000» – «Windows XP» предусмотрено три лога – прикладных программ (application log), системы (system log) и безопасности (security log).
   В application log пишутся сообщения и события, генерируемые прикладными программами, а также некоторыми сервисами (службами). В system log помещаются события ядра ОС и важнейших сервисов. В security log записываются также события, генерируемые системными сервисами, относящиеся к отслеживаемой активности пользователей, их аутентификации и авторизации. К этим трем могут добавляться иные логи, если на компьютере работают дополнительные программы, такие как DNS сервер.
       По умолчанию логируются очень немногие события, а в security log – вообще никаких. Чтобы в логах осаждалась более полная информация, администратор должен явно включить аудит и настроить политики аудита.
      Все логи Windows просматриваются специальной программой «Event Viewer», которую можно найти в меню «Administrative Tools» или «Management Console».
    В зависимости от того, что именно мы ищем, следы «взлома» исследуемого компьютера или следы противоправной деятельности пользователя, может оказаться полезной разная информация из разных логов.

СИСТЕМНЫЕ ЛОГИ UNIX И LINUX

       Несмотря на разнообразие UNIX подобных операционных систем, у всех у них имеется схожая система сбора и хранения системных логов.
      Логирование событий в операционной системе «MacOS X» устроено точно таким же образом.
      Специальный демон (процесс), называемый syslogd, принимает сообщения о событиях от различных программ и процессов и раскладывает их по соответствующим файлам. Сообщения из одного источника можно направить в разные файлы, сообщения от разных источников можно направить в один и тот же файл – система настраивается довольно гибко.
      Сообщения о событиях можно принимать как локально, так и через сеть; оба способа используют один и тот же протокол.
   Каждое сообщение при его генерации снабжается двумя идентифицирующими признаками – приоритет (priority) и ресурс (facility). Их сочетание служит для последующей сортировки полученных сообщений по файлам.
    Принятые syslogd сообщения снабжаются временнóй меткой и записываются в обычный текстовый файл по принципу одно сообщение – одна строка. Просмотреть эти сообщения можно в любом текстовом редакторе или иной программой, умеющей работать с текстовыми файлами.

СИСТЕМНЫЕ ЛОГИ IOS

     Значительная часть (если не большинство) коммутаторов и маршрутизаторов сети Интернет работают под управлением операционной системы IOS. Другие ОС для коммуникационного оборудования схожи с IOS своими чертами, в частности, ведут логи аналогичным образом. К таким типичным устройствам относится коммуникационное оборудование, выпущенное под марками «Cisco», «Juniper», «Huawei» и некоторыми другими. Оно составляет подавляющее большинство.
       В системе IOS логируются следующие события:
● изменение статуса интерфейса или порта;
● авторизация администратора или устройства;
● изменение и сохранение конфигурации устройства;
● прием транзитного пакета, если такой пакет подпадает под правило (ACL entry), отмеченное флагом логирования;
● некоторые другие.
    Сообщения о событиях обычно отсылаются на внешний логирующий сервер по протоколу syslog или SNMP. Также несколько последних сообщений хранятся в буфере, в оперативной памяти и могут быть просмотрены соответствующей командой (show logging).
     Когда требуется ознакомиться с логами коммуникационного оборудования, следует проделать такие действия:
● получить доступ к текущей конфигурации устройства (конфигурационному файлу), чтобы определить, куда именно отсылаются логи с данного устройства (команда show running config); сохранить и задокументировать вышеуказанную конфигурацию (или только ее часть, касающуюся логов);
● (опционально) просмотреть содержимое буфера устройства с последними сообщениями;
● определить местоположение логирующего сервера, то есть сервера, принимающего и сохраняющего логи;
● получить доступ к логирующему серверу и ознакомиться с конфигурацией его syslog демона, чтобы определить, в какой файл складываются логи, принятые от интересующего нас устройства; сохранить и задокументировать вышеуказанную конфигурацию syslog демона;
● осмотреть или изъять файл (файлы), в котором сохраняются логи с нужного устройства.
       Некоторые коммуникационные устройства, относящиеся к меньшинству, не используют ОС IOS или схожую. В таких нетипичных устройствах логирование может быть устроено иначе. В частности, логи могут храниться локально или передаваться на логирующий сервер по нестандартному протоколу.



суббота, 12 февраля 2011 г.

МОЖНО ЛИ ДОВЕРЯТЬ ЛОГАМ ВЕБ-СЕРВЕРА?

      Какие данные в логах веб сервера возможно фальсифицировать, не имея доступа к самому веб серверу?
      Только поля HTTP запроса. Этот запрос полностью формируется на стороне клиента, поэтому при желании злоумышленник может подставить в него любые поля с любыми значениями.
     Зафиксированному в логе IP адресу можно доверять. Конечно, при этом следует помнить, что это может оказаться IP прокси сервера или сокс сервера или иного посредника.
      Прочие поля – это внутренние данные веб сервера (код ответа, размер страницы и т.п.), которым также можно доверять.
      Для проверки достоверности данных логов веб сервера применяется сопоставление записей между собой, а также с иными логами.
      Приведем пример из практики, иллюстрирующий полезность сопоставления различных логов. Сотрудник службы информационной безопасности интернет казино, анализируя логи веб сервера, заметил, что браузер одного из игроков, согласно полям его HTTP запросов, поддерживает русский язык. При этом IP адрес числился за Кореей. Указания же на корейский язык не было. Это возбудило подозрения. Сотрудник проверил, с каких еще адресов обращался пользователь под этим аккаунтом. Оказалось, что с единственного IP. Тогда он проверил, какие еще пользователи обращались с этого же IP. Оказалось, что больше никто этот корейский IP адрес не использовал. Но сотрудник службы безопасности не успокоился и проверил, какие еще были обращения от браузера с таким же набором настроек (язык, версия браузера, версия ОС, разрешение экрана, принимаемые типы данных). Оказалось, что с такого же браузера было зарегистрировано больше 10 аккаунтов. Все эти пользователи приходили с IP адресов разных стран, причем страна соответствовала имени пользователя, то есть, например, Джон Смит с IP адресом США, Ву Пак с IP адресом Кореи, Ганс Мюллер с IP адресом Германии и так далее. Но идентичный набор настроек браузера всех этих пользователей (включая поддержку русского языка) вызывал большие подозрения. Когда же сотрудник сопоставил периоды активности всех подозрительных пользователей, он увидел, что они не пересекаются и более того – примыкают один к другому. Он понял, что имеет дело с кардером, который регистрирует аккаунты по краденым карточкам, пользуясь сокс-серверами в разных странах. Дальнейшая проверка это подтвердила.



СОДЕРЖАНИЕ ЛОГОВ ВЕБ-СЕРВЕРА

      Логи веб сервера, как понятно из их значения, являются далеко не единственным источником информации о действиях пользователя. Называть этот источник главным нельзя. Один из основных – вот так правильно.
Какие же данные можно найти в логах веб сервера? Набор таких данных различается в зависимости от типа веб сервера и его настроек. Чаще всего в логах присутствуют следующие данные:
● IP адрес клиента;
● время запроса, включая часовой пояс;
● поля HTTP запроса клиента:
❍ идентификатор (логин) пользователя, если присутствует аутентификация,
❍ метод,
 ❍ URL запрашиваемой веб-страницы и отдельные его элементы (домен, путь, параметры),
❍ версия протокола,
❍ истинный IP (при доступе через неанонимный прокси сервер),
❍ идентификационная строка браузера клиента (включая язык и ОС),
❍ реферер (referrer), то есть адрес веб страницы, с которой был осуществлен переход на данную страницу,
❍ тип контента ответа веб сервера (MIME type),
❍ любые другие поля;
 ● код ответа веб сервера (status code);
 ● размер ответа веб сервера (без учета HTTP-заголовка);
● ошибки, происшедшие при доступе к веб страницам;
● ошибки при запуске CGI программ.



ЗНАЧЕНИЕ ЛОГОВ ВЕБ-СЕРВЕРА

      Автор подметил интересную особенность. Выражения «лог файлы» или просто «логи» легко употребляются оперативниками, следователями всеми участниками процесса, однако мало кто из них четко представляет себе, что это такое. Чиновники Минсвязи норовят заставить операторов «хранить логи в течение трех лет», однако затрудняются сказать, какие именно логи и вообще, что это такое. Государственный обвинитель во время процесса лихо ссылается на «логи провайдера», однако когда ему эти логи показывают, в упор их не узнает, удивляясь, что это за невразумительная цифирь.
      Технические же специалисты, которые с лог файлами сталкиваются ежедневно, для которых это неотъемлемая составляющая каждодневной работы, приходят в недоумение от такого вопроса следователя: «Какая информация записывается в лог файл?» Да любая! Какую вы пожелаете, такая и записывается.
      Поэтому необходимо рассмотреть, что же такое логфайл или лог.
     Лог – это журнал автоматической регистрации событий, которые фиксируются в рамках какой либо программы. Обычно каждому событию соответствует одна запись в логе. Обычно запись вносится сразу же после события (его начала или окончания). Записи эти складываются в назначенный файл самóй программой либо пересылаются ею другой, специализированной программе, предназначенной для ведения и хранения логов.
    Как понятно из определения, в логах могут регистрироваться абсолютно любые события – от прихода единичного ethernet фрейма до результатов голосования на выборах президента. Форма записи о событии также целиком остается на усмотрение автора программы. Формат лога может быть машинно ориентированным, а может быть приспособлен для чтения человеком.
     Иногда логи ориентированы на цели безопасности и расследования инцидентов. В таких случаях стараются по возможности изолировать логи от системы, события в которой они фиксируют. Если злоумышленник преодолеет средства защиты и получит доступ в систему, он, возможно, не сможет одновременно получить доступ к логам, чтобы скрыть свои следы.
   Почти каждое действие, производимое человеком при взаимодействии с информационной системой, может отражаться в логе прямо или косвенно, иногда даже в нескольких логах одновременно. И логи эти могут быть разбросаны по различным местам, о которых неспециалист даже не догадается.
     Чтобы узнать о действиях злоумышленника, получить какие либо данные о нем при помощи логов, необходимо:
● узнать, какие компьютеры и их программы вовлечены во взаимодействие;
● установить, какие события логируются в каждой из вовлеченных программ;
● получить все указанные логи за соответствующие промежутки времени;
● исследовать записи этих логов, сопоставить их друг с другом.
      Вот, например, такое обыденное действие, как просмотр одним пользователем одной веб страницы. Перечислим вовлеченные в это действие системы, которые в принципе могут вести логи событий:
● браузер пользователя;
● персональный межсетевой экран на компьютере пользователя;
● антивирусная программа на компьютере пользователя;
● операционная система пользователя;
● DNS-сервер (резолвер), к которому обращался браузер пользователя перед запросом веб страницы, а также DNS сервера (держатели зон), к которым рекурсивно обращался этот резолвер;
● все маршрутизаторы по пути от компьютера пользователя до веб сервера и до DNS серверов, а также билинговые системы, на которые эти маршрутизаторы пересылают свою статистику;
● средства защиты (межсетевой экран, система обнаружения атак, антивирус), стоящие перед веб сервером и вовлеченными DNS серверами;
● веб сервер;
● CGI скрипты, запускаемые веб сервером;
● веб сервера всех счетчиков и рекламных баннеров, расположенных на просматриваемой пользователем веб странице (как правило, они поддерживаются независимыми провайдерами);
● веб сервер, на который пользователь уходит по гиперссылке с просматриваемой страницы;
● прокси сервер (если используется);
● АТС пользователя (при коммутируемом соединении с Интернетом – по телефонной линии) или иное оборудование последней мили (xDSL, Wi Fi, GPRS и т.д.);
● оборудование СОРМ со стороны пользователя и со стороны веб сервера.
    Итого может набраться два три десятка мест, где откладываются взаимно скоррелированные записи, относящиеся к одному единственному действию пользователя – просмотру веб страницы.
      При более сложных видах взаимодействия появляется еще больше мест, в которых могут остаться следы действий пользователя. Определить все эти места и указать, к кому именно следует обращаться за соответствующими логами, – это задача для ИТ специалиста. Даже самый продвинутый следователь не в состоянии его заменить. Поэтому привлечение специалиста в таких случаях обязательно.



ИЗБИРАТЕЛЬНЫЙ ПЕРЕХВАТ ТРАФИКА

      Перехват по сигнатурам используется для защиты информации в таком техническом средстве, как система обнаружения атак (IDS). Она ищет в передаваемых пакетах заранее предопределенные последовательности байтов, соответствующие попыткам несанкционированного доступа, активности вредоносных программ, иным неразрешенным или подозрительным действиям.
     Аналогично можно построить и анализ трафика подозреваемого предопределить характерные последовательности (сигнатуры), соответствующие подозрительным действиям. И ловить только сессии, в которых встречаются эти сигнатуры. Например, подозреваемый пользуется услугами провайдера коммутируемого доступа и, следовательно, соединяется с Интернетом с использованием динамического IP адреса. Наряду с ним IP адреса из той же сети используют еще несколько сотен пользователей. Требуется проконтролировать переписку подозреваемого по электронной почте. Для этого достаточно записывать все SMTP сессии, исходящие из сети, где расположен компьютер подозреваемого, в которых встречается последовательность символов «From: <info@e38.biz>», чтобы выделить письма, направленные от подозреваемого любым адресатам через любые промежуточные узлы.
       Для такого избирательного перехвата можно использовать почти любую IDS. Многие из них поддерживают довольно сложные сигнатуры сомногими условиями.


 

АНАЛИЗ ЗАГОЛОВКОВ ПАКЕТОВ

      Сведения о сетевых соединениях или о заголовках пакетов – это то ли урезанный перехват трафика (без сохранения сведений о содержимом пакетов, но лишь об их заголовках), то ли развернутый вариант статистики (когда записывается не агрегированная по времени информация о переданных пакетах).
     Например, что можно сказать о компьютере 10.0.4.224, получив следующую информацию о переданных пакетах? Перехват заголовков осуществлялся той же программой «tcpdump», что и в примере для главы «Перехват и исследование трафика», но без опций «-v -xX». Использованный в этот раз фильтр «tcp and (net 64.12.0.0/16 or net 205.188.0.0/16)» выделяет из общего потока те пакеты, которые относятся к сетям 64.12.0.0/16 и 205.188.0.0/16 – это сети, где стоят сервера, обслуживающие ICQ.

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



среда, 9 февраля 2011 г.

ИССЛЕДОВАНИЕ СТАТИСТИКИ ТРАФИКА

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

NETFLOW

      Часто статистика ведется по формату «netflow». Он предусматривает запись сведений о каждом «потоке» (flow), то есть серии пакетов, объединенных совокупностью IP-адресов, портов и номером протокола.
      По такой статистике можно установить:
● факт обращения определенного узла (компьютера, идентифицированного IP адресом) к другому узлу;
● время обращения с точностью до интервала дискретизации (от 5 минут до 1 часа);
● количество переданного и полученного трафика;
● протокол;
● номера портов с обеих сторон (для TCP и UDP).

ПРИМЕР

      Приведем пример, как при помощи статистики трафика можно получить ценную оперативную информацию Потерпевшим было получено сообщение электронной почты, отправленное злоумышленником через анонимайзер «remailer@aarg.net».
        Анонимайзер – это сервер электронной почты, который специально предназначен для сокрытия отправителя (подробнее об анонимайзерах – ниже, в параграфе «Анонимные ремейлеры»). Служебные заголовки сообщения не содержали никакой полезной информации. Логи анонимайзером не ведутся из принципа.
       Для вычисления отправителя можно воспользоваться статистикой трафика.
      Для начала сделаем следующие предположения: отправитель находится в России, и он отправил свое сообщение на этот анонимайзер непосредственно, а не через другой анонимайзер. При таких условиях можно попытаться вычислить отправителя.
IP-адрес анонимайзера «remailer@aarg.net» – 206.132.3.41.
       Письмо к потерпевшему пришло 20 января вечером. Значит, отправлено было, скорее всего, в этот же день, поскольку, хотя анонимайзер предусматривает задержку в доставке сообщений, но вводить слишком большую задержку бессмысленно. Будем искать в статистике российских магистральных операторов связи все обращения на IP-адрес 206.132.3.41, совершенные в течение суток 20.01.07 по протоколу SMTP. Для просмотра статистики используем набор утилит «flow tools».
      Итак, для начала, проверим, на какие IP-адреса были обращения за нужную дату по протоколу TCP, на порт 25 (SMTP). Нижеприведенная команда берёт хранящуюся на сервере статистику (flow-cat), отфильтровывает из нее протокол TCP (flow-filter -r6), отфильтровывает трафик, направленный на порт 25 (flow-filter -P 25), и агрегирует данные по IP адресу назначения (flow-stat -f8).

     В списке DST адресов (адресов назначения) мы видим интересующий нас адрес 206.132.3.41 (пятая строка снизу), причем на него зафиксировано 2 обращения (flow), всего 38 пакетов, 27995 байт. Такое небольшое количество пакетов за целые сутки неудивительно. Анонимайзерами пользуются нечасто, поскольку это хоть и относительно безопасно, но не слишком удобно.
     Выше мы запрашивали статистику за сутки. Поскольку статистика собирается с интервалом в 15 минут, поинтересуемся, в какой именно интервал времени в течение суток были зафиксированы эти обращения. Поищем их в каждом из четвертьчасовых файлов. То есть произведем поиск, аналогичный предыдущему, но не для всей суточной статистики, а для каждого из 15 минутных интервалов (команда «for f in … do»).


       Упоминание искомого IP-адреса нашлось в 2 из 96 файлов. Оказалось, что обращения происходили в интервале 9:30 9:45 и 14:30 14:45, причем во втором случае было передано лишь 2 пакета, а этого недостаточно для полноценной SMTP-сессии. Таким образом, все данные следует искать в файле, содержащем статистику за 9:30 9:45.


       Выберем из полной статистики за указанный интервал те пакеты, которые относятся к интересующему нас анонимайзеру. Для этого вместо упорядочивания данных по IP-адресу назначения, как в предыдущих случаях (flow-stat -f8), запросим полную статистику (flow-print) и выделим из нее утилитой «grep» те потоки, которые относятся к адресу анонимайзера 206.132.3.41.


      Мы видим, что у всех относящихся к делу пакетов один и тот же source-адрес – 81.16.118.238. Это, скорее всего, и есть IP-адрес отправителя. Переданный объем информации, 27899 байт, примерно соответствует (с учетом служебных заголовков и шифрования) длине сообщения, полученного потерпевшим, что косвенно подтверждает правильность нашего вывода.
     Вот таким образом заурядная статистика провайдера позволила нам раскрыть инкогнито злоумышленника, понадеявшегося на анонимный ремейлер.
     Другая задача, выполняемая при помощи статистики трафика, это обнаружение источника DoS-атаки или иной атаки с подделанными адресами источника (source IP). По статистике видно, из какого интерфейса пришел на маршрутизатор такой пакет, то есть каков был предыдущий узел в его пути. Обратившись к статистике этого предыдущего узла, мы можем узнать предпредыдущий узел и так далее. К сожалению, это задача непростая, придется устанавливать контакт с несколькими провайдерами. Если один из них откажется сотрудничать или не сохранит статистику, то цепочка оборвется.