Ясно, что трафик, относящийся к определенному узлу, проще всего перехватывать вблизи этого узла. По мере удаления от него возрастает техническая сложность перехвата, но зато снижается организационная сложность. По мере удаления от узла падает надежность и, возможно, полнота перехвата трафика, но зато повышается скрытность. Место перехвата трафика в значительной мере определяется наличием возможностей у органа, ведущего ОРД. Для определения мест и методов возможного перехвата обязательно привлечение технического специалиста.
При этом распространенной ошибкой является привлечение специалиста по аппаратуре телефонной связи. Такой специалист, конечно, доступнее, чем ИТ специалист того же уровня. «Телефонист» лучше разбирается в оборудовании, технологиях и протоколах связи 1-го и 2-го уровня (физический и канальный). Но работать на более высоких уровнях сетевых протоколов (3 7) он не способен. А как раз на этих уровнях лежит большинство возможностей перехвата трафика.
Различных мест и методов для перехвата сетевого трафика слишком много, чтобы перечислить их здесь. Выделим лишь организационные варианты:
● перехват при помощи имеющейся аппаратуры СОРМ;
● перехват средствами оператора связи;
● перехват собственными средствами.
В подавляющем большинстве случаев в перехватываемом трафике может содержаться тайна связи или тайна частной жизни. Поэтому необходимо получать судебное решение. Без судебной санкции возможен перехват своего собственного трафика потерпевшим либо с его письменного разрешения.
Перехват трафика может быть реализован на разных уровнях.
● На физическом уровне:
❍ при помощи электрических и оптических разветвителей;
❍ при помощи бесконтактных датчиков;
❍ при помощи перехвата радиосигнала (для Wi-Fi и других беспроводных протоколов).
● На канальном уровне:
❍ при помощи подключения к концентратору (хабу);
❍ при помощи функции зеркалирования порта на коммутаторе (свиче);
❍ при помощи ARP-атак и проксирования трафика;
❍ при помощи установки снифера на целевом или транзитном узле.
● На сетевом уровне:
❍ при помощи изменения маршрутизации и проксирования трафика;
❍ при помощи встроенных функций межсетевого экрана или системы обнаружения атак (IDS).
● На прикладном уровне:
❍ анализом трафика на прокси-сервере (для http-трафика);
❍ анализом трафика на сервере электронной почты (для SMTP-трафика).
Формулируя техническое задание для перехвата трафика, следует непременно прикинуть объем информации. При слишком широких условиях соответствующий трафик может достигнуть астрономических величин. Большой объем не уместится на носителе и поэтому не поддастся последующему анализу.
Например, нас интересуют действия пользователя, работающего за домашним компьютером, который подключен к Интернету через местную домовую сеть. В его трафике мы хотели бы найти доказательства неправомерного доступа к удаленным узлам. Было бы ошибкой ставить задачу так: «перехват исходящего и входящего трафика компьютера с IP-адресом 10.0.0.6». Помимо неправомерного доступа подозреваемый также занимается и другой деятельностью. На его компьютере стоит клиент файлообменных сетей со средним суммарным трафиком 6 кбайт/с (500 Мбайт за сутки, 50 входящего и 450 исходящего). Кроме того, в домовой сети расположен файловый сервер с набором музыки и фильмов. Поскольку внутренний трафик для пользователей бесплатен и не ограничен, подозреваемый скачивает 1-2 фильма в день и немного музыки (1 Гбайт за сутки). Внутрисетевой служебный трафик составляет за сутки еще порядка 2 Мбайт. Причем все перечисленное – в автоматическом режиме, независимо от присутствия подозреваемого дома. На этом фоне суточные 10 Мбайт веб-трафика, 0,5 Мбайт электронной почты и 0,2 Мбайт по протоколу ICQ просто теряются. А доказательства неправомерного доступа содержатся лишь в последнем пункте. Перехват всего перечисленного трафика (1,5 Гбайт в сутки) за несколько дней потребует диска очень большой емкости, которого может и не оказаться в распоряжении специалиста. И потом найти в этой куче полезные 0,013% будет нелегко.
Если же мы, чтобы исключить внутрисетевой трафик, велим специалисту перехватывать информацию за пределами домовой сети, на выходе из нее, то допустим иную ошибку. Поскольку домовая сеть подключена к Интернету не напрямую, а через устройство, осуществляющее трансляцию IP-адресов (NAT), то в этой точке мы не сможем отличить трафик подозреваемого от трафика всех других пользователей той же домовой сети.
В описанной ситуации правильная формулировка задания должна выглядеть примерно так: «перехват исходящего и входящего трафика компьютера с MAC адресом 00:15:f2:20:96:54, относящегося к протоколам HTTP, telnet, SMTP, POP, IMAP, ICQ и имеющего в качестве IP-адреса назначения (destination) или происхождения (source) какие-либо внешние IP-адреса, то есть, IP-адреса кроме 10.0.0.0/8».
Анализ и интерпретация перехваченного трафика должны производиться экспертом в ходе КТЭ. Вместо экспертизы можно оформить это как очередное ОРМ, но тогда доказательством в суде перехваченный трафик не будет.
К перехваченному трафику для его анализа необходимо приложить некоторую информацию о конфигурации и состоянии коммуникационного оборудования, чтобы в ходе КТЭ содержимое трафика можно было интерпретировать уверенно, без предположений. Например, в вышеописанном случае для интерпретации понадобится конфигурация коммутатора домовой сети, MAC-таблица на соответствующем его порту, а также конфигурация устройства, производящего трансляцию адресов (NAT).
При этом распространенной ошибкой является привлечение специалиста по аппаратуре телефонной связи. Такой специалист, конечно, доступнее, чем ИТ специалист того же уровня. «Телефонист» лучше разбирается в оборудовании, технологиях и протоколах связи 1-го и 2-го уровня (физический и канальный). Но работать на более высоких уровнях сетевых протоколов (3 7) он не способен. А как раз на этих уровнях лежит большинство возможностей перехвата трафика.
Различных мест и методов для перехвата сетевого трафика слишком много, чтобы перечислить их здесь. Выделим лишь организационные варианты:
● перехват при помощи имеющейся аппаратуры СОРМ;
● перехват средствами оператора связи;
● перехват собственными средствами.
В подавляющем большинстве случаев в перехватываемом трафике может содержаться тайна связи или тайна частной жизни. Поэтому необходимо получать судебное решение. Без судебной санкции возможен перехват своего собственного трафика потерпевшим либо с его письменного разрешения.
Перехват трафика может быть реализован на разных уровнях.
● На физическом уровне:
❍ при помощи электрических и оптических разветвителей;
❍ при помощи бесконтактных датчиков;
❍ при помощи перехвата радиосигнала (для Wi-Fi и других беспроводных протоколов).
● На канальном уровне:
❍ при помощи подключения к концентратору (хабу);
❍ при помощи функции зеркалирования порта на коммутаторе (свиче);
❍ при помощи ARP-атак и проксирования трафика;
❍ при помощи установки снифера на целевом или транзитном узле.
● На сетевом уровне:
❍ при помощи изменения маршрутизации и проксирования трафика;
❍ при помощи встроенных функций межсетевого экрана или системы обнаружения атак (IDS).
● На прикладном уровне:
❍ анализом трафика на прокси-сервере (для http-трафика);
❍ анализом трафика на сервере электронной почты (для SMTP-трафика).
Формулируя техническое задание для перехвата трафика, следует непременно прикинуть объем информации. При слишком широких условиях соответствующий трафик может достигнуть астрономических величин. Большой объем не уместится на носителе и поэтому не поддастся последующему анализу.
Например, нас интересуют действия пользователя, работающего за домашним компьютером, который подключен к Интернету через местную домовую сеть. В его трафике мы хотели бы найти доказательства неправомерного доступа к удаленным узлам. Было бы ошибкой ставить задачу так: «перехват исходящего и входящего трафика компьютера с IP-адресом 10.0.0.6». Помимо неправомерного доступа подозреваемый также занимается и другой деятельностью. На его компьютере стоит клиент файлообменных сетей со средним суммарным трафиком 6 кбайт/с (500 Мбайт за сутки, 50 входящего и 450 исходящего). Кроме того, в домовой сети расположен файловый сервер с набором музыки и фильмов. Поскольку внутренний трафик для пользователей бесплатен и не ограничен, подозреваемый скачивает 1-2 фильма в день и немного музыки (1 Гбайт за сутки). Внутрисетевой служебный трафик составляет за сутки еще порядка 2 Мбайт. Причем все перечисленное – в автоматическом режиме, независимо от присутствия подозреваемого дома. На этом фоне суточные 10 Мбайт веб-трафика, 0,5 Мбайт электронной почты и 0,2 Мбайт по протоколу ICQ просто теряются. А доказательства неправомерного доступа содержатся лишь в последнем пункте. Перехват всего перечисленного трафика (1,5 Гбайт в сутки) за несколько дней потребует диска очень большой емкости, которого может и не оказаться в распоряжении специалиста. И потом найти в этой куче полезные 0,013% будет нелегко.
Если же мы, чтобы исключить внутрисетевой трафик, велим специалисту перехватывать информацию за пределами домовой сети, на выходе из нее, то допустим иную ошибку. Поскольку домовая сеть подключена к Интернету не напрямую, а через устройство, осуществляющее трансляцию IP-адресов (NAT), то в этой точке мы не сможем отличить трафик подозреваемого от трафика всех других пользователей той же домовой сети.
В описанной ситуации правильная формулировка задания должна выглядеть примерно так: «перехват исходящего и входящего трафика компьютера с MAC адресом 00:15:f2:20:96:54, относящегося к протоколам HTTP, telnet, SMTP, POP, IMAP, ICQ и имеющего в качестве IP-адреса назначения (destination) или происхождения (source) какие-либо внешние IP-адреса, то есть, IP-адреса кроме 10.0.0.0/8».
Анализ и интерпретация перехваченного трафика должны производиться экспертом в ходе КТЭ. Вместо экспертизы можно оформить это как очередное ОРМ, но тогда доказательством в суде перехваченный трафик не будет.
К перехваченному трафику для его анализа необходимо приложить некоторую информацию о конфигурации и состоянии коммуникационного оборудования, чтобы в ходе КТЭ содержимое трафика можно было интерпретировать уверенно, без предположений. Например, в вышеописанном случае для интерпретации понадобится конфигурация коммутатора домовой сети, MAC-таблица на соответствующем его порту, а также конфигурация устройства, производящего трансляцию адресов (NAT).
Комментариев нет:
Отправить комментарий