Все про трафик с Netflow на MikroTik. IP-трафик ждет трехкратный рост

22.07.2019 Телевизоры (Smart TV)

Аннотация: Обсуждается тема, связанная с качеством обслуживания в IP-сетях. Указываются определения, описаны методики определения качества в IP-сетях. Обсуждаются протоколы, с помощью которых реализуется уровень качественного обслуживания. Приведено сравнение различных технологий обеспечения качества IP-услуг. Вводится понятие очередей и "алгоритмов борьбы" с ними

7.1. Понятие QoS

Сети с коммутацией пакетов на основе протокола IP не обеспечивают гарантированной пропускной способности, поскольку не гарантируют доставку.

Для приложений, где не важен порядок и интервал прихода пакетов, время задержек между отдельными пакетами не имеет решающего значения. IP-телефония является одной из областей передачи данных, где важен порядок прихода пакетов и важна динамика передачи сигнала, которая обеспечивается современными методами кодирования и передачи информации. Транспортные протоколы стека TCP / IP , функционирующие поверх протокола IP , не обеспечивают высокого качества обслуживания трафика, чувствительного к задержкам. Протокол TCP , хоть и гарантирует достоверную доставку информации, но переносит ее с непредсказуемыми задержками. Протокол UDP , который, как правило, используется для переноса информации в реальном времени, обеспечивает меньшее, по сравнению с протоколом TCP , время задержки , но, как и протокол IP , не содержит никаких механизмов обеспечения качества обслуживания.

Вместе с тем необходимо обеспечить механизмы , по которым в периоды перегрузки пакеты с информацией, чувствительной к задержкам (например, речь), не будут простаивать в очередях или получат более высокий приоритет, чем пакеты с информацией, не чувствительной к задержкам. Для этой цели в сети должны быть реализованы механизмы , гарантирующие нужное качество обслуживания ( Quality of Service - QoS ).

Объективными, измеряемыми или рассматриваемыми показателями качества являются:

изменение задержки в сети;
пропускная способность сети.

Время отклика оценивается по:

промежутку времени от момента передачи пакета до момента приема подтверждения;
времени задержки однонаправленного сквозного соединения, также называемой временем запаздывания ( latency );
пропускной способности.

Готовность и надежность оценивается по:

возможности получения доступа к ресурсам сети или коэффициенту использования;
результатам контроля уровня обслуживания 24/7 (при режиме работы 24 часа в сутки, 7 дней в неделю).

Меры обеспечения QoS , применяемые в IP - сетях:

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

В современных IP -сетях перечисленные меры реализуются с помощью технологий IntServ , DiffServ и MPLS с использованием протокола RSVP .

7.2. Трафик реального времени в IP-сетях

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

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

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

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

7.3. Дифференцированное обслуживание разнотипного трафика - Diff-Serv

Опция DiffServ позволяет классифицировать пакеты из трафика, идущего в локальную сеть . Работа DiffServ основывается на идентификаторе DSCP , представляющем собой первые 6 бит поля TOS . DSCP определяет, как будут перенаправляться пакеты в DiffServ -сети (PHB, Per- hop Behavior). Изменяя значение этого идентификатора, различные виды трафика можно распределить по приоритетам в очереди.

Модель Diff-Serv описывает архитектуру сети как совокупность пограничных участков и ядра. Пример сети согласно модели Diff-Serv приведен на рисунке 7.1 .

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

Достоинства модели Diff-Serv:

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

К настоящему времени для Diff-Serv определено два класса трафика:

класс срочной пересылки пакетов (Expedited Forwarding PHB Group);
класс гарантированной пересылки пакетов ( Assured Forwarding PHB Group).

Механизм обеспечения QoS на уровне сетевого устройства, применяемый в Diff-Serv, включает в себя следующие операции . Сначала пакеты классифицируются на основании их заголовков. Затем они маркируются в соответствии с произведенной классификацией (в поле приоритета Diff-Serv в зависимости от маркировки выбирается алгоритм передачи, при необходимости - с выборочным удалением пакетов), позволяющий избежать заторов в сети. Заключительная операция чаще всего состоит в организации очередей с учетом приоритетов.

7.4. Интегрированное обслуживание IntServ

IntServ (Integrated Services) больше подходит для концентрации трафика в пограничной сети IP и не рекомендована для применения в транзитных сетях IP (из-за проблем с масштабируемостью).

Модель с интеграцией услуг была предложена в начале 90-х годов и разрабатывалась для обслуживания единичных потоков, которым предоставляется два вида услуг: гарантированные и с управляемой нагрузкой. Гарантированные услуги позволяют обеспечить определенному объему трафика поддающееся количественному вычислению максимальное значение задержки при прохождении пакетов из конца в конец. Услуги с управляемым уровнем нагрузки предоставляют определенному объему трафика обслуживание best- effort при виртуальной низкой сетевой нагрузке без строгих гарантий.

Рассмотрим структурную схему IntServ ( рис. 7.2).

Рис. 7.2.

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

классификатор - направляет поступающий пакет в один из классов обслуживания согласно информации, полученной из заголовков (сетевого и транспортного уровней) пакета. Класс обслуживания реализуется в виде отдельной очереди. Все пакеты в пределах одного класса обслуживания должны получать одинаковый QoS ;
диспетчер пакетов - извлекает из каждой очереди пакеты и направляет их на канальный уровень . Для IntServ предложен двухступенчатый диспетчер пакетов. Все поступающие пакеты обрабатываются в соответствии с дисциплиной обслуживания WFQ для изоляции потоков, получающих гарантированные услуги, от всех остальных. Потоки с управляемой нагрузкой и потоки best- effort разделяются с помощью приоритетов;
блок управления доступом ( admission control ) - принимает решения о возможности получения трафиком требуемого количества ресурсов, не влияя при этом на ранее предоставленные гарантии. Управление доступом выполняется на каждом узле для принятия или отклонения запроса на выделение ресурсов по всему пути прохождения потока;
протокол резервирования ресурсов - информирует участников соединения (отправителя, получателя, промежуточные маршрутизаторы) о требуемых параметрах обслуживания. Для модели IntServ рекомендуется использовать протокол RSVP .

Сервисная модель IntServ в сочетании с RSVP (см. далее) позволяет организовать гибкое обслуживание разнотипного трафика, максимально учитывая потребности каждого приложения, а использование WFQ для обслуживания пакетов гарантирует максимально допустимое значение задержки. Эта особенность делает IntServ идеальной для обслуживания мультимедийного трафика .

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

Но самый большой недостаток IntServ связан с масштабируемостью RSVP , особенно в высокоскоростных магистральных сетях. Действительно, объем ресурсов, которые необходимы маршрутизатору для обработки и хранения информации RSVP , увеличивается пропорционально количеству потоков QoS . Измерения трафика показывают, что большинство соединений IP "из конца в конец" существует очень недолго, и в каждый момент времени магистральным маршрутизатором поддерживается несколько тысяч активных соединений. Следовательно, многочисленные потоки IntServ в канале с большой пропускной способностью значительно увеличивают нагрузку на маршрутизаторы. Более того, каждый раз при изменении топологии все зарезервированные пути необходимо прокладывать заново.

7.5. Интегро-дифференцированное обслуживание трафика

Опубликованный в 2000 г. стандарт RFC2998 описывает принципы организации взаимодействия IntServ / RSVP и DiffServ для предоставления QoS из конца в конец. Слабые места одной модели компенсируются соответствующими решениями другой. С одной стороны, плохо масштабируемая IntServ на магистральных участках сети может быть заменена на более простую DiffServ , с другой стороны, с помощью RSVP может решаться (если не полностью, то в большей степени) проблема с неопределенностью получаемого сервиса в "чистой" DiffServ -сети.

Рис. 7.3.

Основная проблема при взаимодействии - соответствие ресурсов, запрашиваемых с помощью RSVP и предоставляемых в DiffServ -регионе (так называется непрерывная последовательность DiffServ -доменов, в пределах которых могут предоставляться дифференцированные услуги). Для реализации отображения ресурсов был предложен ряд решений.

Возможна организация двух вариантов взаимодействия протоколов качества обслуживания:

DiffServ -регион не поддерживает RSVP -сигнализацию, и ресурсы выделяются на статической основе;
обработка RSVP -сообщений производится в DiffServ -регионе.

В первом случае совместная работа основана на статическом соглашении клиента с оператором SLS (спецификация уровня сервиса). В простейшей ситуации оно описывает значение пропускной способности, получаемое трафиком пользователя, в DiffServ -сети. В этом случае ( рис. 7.3) Tx (отправитель) генерирует сообщения Path , которые направляются к узлу Rx (получатель) через DiffServ -регион.

При прохождении через DiffServ -регион содержимое RSVP -сообщений игнорируется, и они пересылаются как обычный пакет с данными. При получении узлом Rx сообщения Path генерируется запрос на резервирование RESV , который затем направляется обратно к узлу Tx . В случае успешной обработки запроса каждым RSVP -совместимым маршрутизатором и прохождения через DiffServ -регион сообщение RESV достигает маршрутизатора Er1 . Er1 на основании SLS производит сравнение ресурсов, запрашиваемых в сообщении RESV , и ресурсов, доступных в DiffServ -регионе. Если Er1 подтверждает запрос , сообщение RESV отсылается далее по направлению к узлу Tx . В ином случае сообщение отвергается, и узлу Rx отправляется сообщение об ошибке . В полученном узлом Tx сообщении может содержаться информация о маркировании соответствующим кодом пакетов, адресуемых в узел Rx . Значение кода определяется по умолчанию или из сообщения RESV .

Во втором варианте предполагается, что пограничные маршрутизаторы в DiffServ -регионе (например, маршрутизатор Br1 ) поддерживают протокол RSVP . Отметим, что, несмотря на поддержку RSVP -сигнализации, обрабатываются только агрегированные потоки , а не единичные, как в сети IntServ / RSVP . Порядок обмена RSVP -сообщениями такой же, как и в предыдущем случае. Однако благодаря поддержке

Мировой интернет-трафик вырастет до 1,6 зеттабайта к 2018 году. Ключевыми факторами роста станут распространение видео в формате Ultra-HD/4K и технологий межмашинной связи, включая «умные» автомобили.

По данным исследования Cisco под названием «Индекс развития визуальных сетевых технологий: глобальный прогноз и распространение сервисов за период 2013-2018 гг.» (Cisco VNI), в течение 4 лет мировой IP-трафик практически утроится. Это произойдет за счет роста числа интернет-пользователей и различных устройств, увеличения скоростей ШПД и количества просмотров видео. Как ожидается, к 2018 году годовой объем мирового IP-трафика, проходящего через фиксированные и мобильные соединения, достигнет 1,6 зеттабайта*, т.е. более полутора триллионов гигабайт. Это больше IP-трафика (1,3 зеттабайта), сгенерированного во всем мире за период с 1984 по 2013 гг.

Десятки миллионов болельщиков будут смотреть трансляцию матчей начавшегося чемпионата мира по футболу через Интернет. Потоковое видео и IP-трансляция игр могут сгенерировать 4,3 эксабайта интернет-трафика, что втрое превышает месячный объем трафика в Бразилии. Кроме того, по прогнозам, интернет-трафик, который будут генерировать зрители на каждом стадионе и по пути на матч, превысит средний объем трафика, генерируемого в часы пик** всеми смартфонами, имеющимися в настоящее время у жителей Бразилии.

Как ожидается, к 2018 г. глобальный IP-трафик достигнет 132 эксабайт в месяц. Такой же объем трафика способны сгенерировать:

потоковое видео в сверхвысоком разрешении (Ultra-HD/4K), если его одновременно передать на 8,8 миллиардов экранов во время финального матча за звание чемпиона мира по футболу;
5,5 миллиардов зрителей, которые, пользуясь сервисом «видео по запросу», без перерыва смотрят 4-й сезон «Игр престолов» в высоком разрешении (HD), либо 1,5 миллиарда - в сверхвысоком разрешении;
3-й сезон «Карточного домика», передаваемый одновременно на 24 миллиарда экранов в сверхвысоком разрешении;
940 квадрильонов текстовых сообщений;
4,5 триллиона клипов YouTube.

В ближайшие годы состав IP-трафика кардинально изменится. К 2018 г. большая его часть впервые будет ассоциироваться не с персональными компьютерами, а с другими устройствами. Так же впервые объем Wi-Fi-трафика превысит объем проводного трафика, а объем трафика видео высокого разрешения превзойдет трафик обычного видео.

Всеобъемлющий Интернет также набирает обороты, и к 2018 г. количество модулей межмашинной связи сравняется с количеством людей. Так, на каждый «умный» автомобиль будут приходиться почти 4 соединения.

«В первом такого рода отчете, опубликованном 9 лет назад, мы установили зеттабайт в качестве этапной отметки роста глобального IP-трафика, - напомнил Дуг Уэбстер (Doug Webster), вице-президент компании Cisco по маркетингу продуктов и решений. - Сегодня мы уже живем в эпохе зеттабайта, став свидетелями невероятных отраслевых перемен. Среди основных трендов, выделенных в нынешнем прогнозе и предоставляющих сервис-провайдерам значительные возможности как сегодня, так и в ближайшем будущем, отметим реализацию Всеобъемлющего Интернета, рост спроса на мобильность сетей и появление видео сверхвысокого разрешения».

Прогнозы глобального роста трафика и ключевые факторы распространения сервисов

IP-трафик

За большую часть трафика к 2018 г. будут отвечать мобильные и носимые устройства, без персональных компьютеров. Если в 2013 г. на устройства, отличные от ПК, приходилось 33% IP-трафика, то к 2018 г. их доля вырастет до 57%. Темпы роста трафика ПК составят 10% в год, тогда как для других устройств и соединений этот показатель будет выше: 18% для ТВ, 74% для планшетов, 64% для смартфонов и 84% - для модулей межмашинной связи (M2M).

Трафик в часы пик растет быстрее обычного интернет-трафика. В 2013 г. рост интернет-трафика в час пик составил 32%, тогда как трафик в другое время суток вырос на 25%.

В 2013 г. по городским сетям было передано больше трафика, чем по магистральным соединениям. В период 2013-2018 гг. трафик в городских сетях будет расти почти вдвое быстрее, чем в магистральных соединениях. Частично это объясняется ожидающимся удвоением к 2018 г. интернет-трафика в сетях доставки контента.

IP-видео

К 2018 г. доля IP-видео в общем IP-трафике вырастет до 79% (в 2013 г. она составляла 66%).

Доля видео сверхвысокого разрешения в общем IP-трафике к 2018 г. увеличится на 0,1% по сравнению с 2013 г. и составит 11%. Доля видео высокого разрешения увеличится с 36% в 2013 г. до 52% к 2018 г., а видео стандартного разрешения сократится с 64% до 37% общего IP-трафика.

IP-трафик по типам доступа

К 2018 г. Wi-Fi и мобильные устройства будут генерировать 61% IP-трафика. На долю Wi-Fi придется 49%, на долю сотовых сетей - 12%. Фиксированный трафик к 2018 г. составит лишь 39% общего IP-трафика. Для сравнения: в 2013 г. доля Wi-Fi составляла 41%, сотового трафика - 3%, фиксированного трафика - 56%.

К 2018 г. Wi-Fi и мобильные устройства будут генерировать 76% интернет-трафика. На долю Wi-Fi придется 61%, на долю сотовых сетей - 15%. Фиксированный трафик составит к 2018 г. лишь 24% общего интернет-трафика. Для сравнения: в 2013 г. доля Wi-Fi составляла 55%, сотового трафика - 4%, фиксированного трафика - 41%.

Устройства и соединения

К 2018 г. на каждого жителя нашей планеты будет приходиться в среднем 2,7 сетевых устройства или соединения. В 2013 г. этот показатель составлял 1,7 на душу населения.

Общемировое число межмашинных соединений составит 7,3 миллиарда, или почти одно соединение на человека (если исходить из того, что к 2018 г. население Земли составит 7,6 миллиардов человек).

Число фиксированных и мобильных устройств с поддержкой IPv6 вырастет с 2 миллиардов в 2013 г. до 10 миллиардов в 2018 г.

Рост скоростей ШПД

Скорость ШПД в мире вырастет с 16 Мбит/с в конце 2013 г. до 42 Мбит/с к 2018 г.

Скорость большинства (примерно 55%) широкополосных соединений к 2018 г. превысит 10 Мбит/с. В Японии и Южной Корее средняя скорость ШПД к 2018 г. приблизится к 100 Мбит/с.

Распространение передовых сервисов

Самым быстрорастущим сервисом в жилом секторе станет онлайн-видео: при 10-процентном среднегодовом приросте за период 2013-2018 гг. число пользователей увеличится с 1,2 до 1,9 миллиарда человек.

В потребительском сегменте быстрее всего будут расти мобильные сервисы с учетом местоположения: при 36-процентном среднегодовом приросте за период 2013-2018 гг. число пользователей таких услуг вырастет с 236 миллионов до более миллиарда человек.

В бизнес-сегменте самым быстрорастущим интернет-сервисом станет проведение видеоконференций с использованием персональных устройств и настольных компьютеров: при 45-процентном среднегодовом приросте за период 2013-2018 гг. число пользователей вырастет с 37 миллионов до 238 миллионов человек.

Прогнозы по странам и регионам

К 2018 г. самый большой объем IP-трафика - 47,7 эксабайт в месяц - будет генерироваться в Азиатско-Тихоокеанском регионе. Этот самый густонаселенный регион мира, на который приходится большинство устройств и соединений, сохранит первое место по объемам трафика в течение всего 2018 года.

На Ближнем Востоке и в Африке в период 2013-2018 гг. сохранятся самые высокие темпы роста IP-трафика (пятикратное увеличение при 38-процентном среднегодовом приросте).

К 2018 г. странами, генерирующими наибольшие объемы трафика, станут США и Китай (соответственно, 37 и 18 эксабайтов в месяц).

Самый быстрый рост IP-трафика в период 2013-2018 гг. будет наблюдаться в Индии и Индонезии (соответственно, 39-процентный и 37-процентный среднегодовой прирост).

Что из всего этого следует для сервис-провайдеров

Сетям сервис-провайдеров понадобятся усиленная защита и интеллект. Им придется адаптироваться для работы с растущим числом планшетов, смартфонов и устройств межмашинной связи, которые потребуют аутентификации для доступа к фиксированным и мобильным сетям.

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

Продолжающееся распространение в бизнес-сегменте таких сервисов, как видеоконференции высокого разрешения и веб-видеоконференции, а также бизнес-видео по запросу, может стимулировать усиление роста виртуализации сетей и применения Интернета для передачи видео, что вызовет определенные проблемы как для сервис-провайдеров, так и для независимых поставщиков услуг (over-the-top providers, OTT).

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

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

Посмотрело: 3498

Любой администратор рано или поздно получает инструкцию от руководства: «посчитать, кто ходит в сеть, и сколько качает». Для провайдеров она дополняется задачами «пустить кого надо, взять оплату, ограничить доступ». Что считать? Как? Где? Отрывочных сведений много, они не структурированы. Избавим начинающего админа от утомительных поисков, снабдив его общими знаниями, и полезными ссылками на матчасть.
В данной статье я постараюсь описать принципы организации сбора, учёта и контроля трафика в сети. Мы рассмотрим проблематику вопроса, и перечислим возможные способы съема информации с сетевых устройств.

Это первая теоретическая статья из цикла статей, посвящённого сбору, учёту, управлению и биллингу трафика и IT-ресурсов.

Структура доступа в сеть Интернет

В общем случае, структура доступа в сеть выглядит следующим образом:

Внешние ресурсы - сеть Интернет, со всеми сайтами, серверами, адресами и прочим, что не принадлежит сети, которую вы контролируете.

Устройство доступа - маршрутизатор (аппаратный, или на базе PC), коммутатор, VPN-сервер или концентратор.

Внутренние ресурсы - набор компьютеров, подсетей, абонентов, работу которых в сети необходимо учитывать или контролировать.

Сервер управления или учёта - устройство, на котором работает специализированное программное обеспечение. Может быть функционально совмещён с программным маршрутизатором.

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

Сетевой трафик

Для начала необходимо определить, а что же подразумевается под «сетевым трафиком», и какую полезную статистическую информацию можно извлечь из потока пользовательских данных.
Доминирующим протоколом межсетевого взаимодействия пока остается . Протокол IP соответствует 3му уровню (L3). Информация (данные) между отправителем и получателем упаковывается в пакеты - имеющие заголовок, и «полезную нагрузку». Заголовок определяет, откуда и куда идет пакет (IP-адреса отправителя и получателя), размер пакета, тип полезной нагрузки. Основную часть сетевого трафика составляют пакеты с полезной нагрузкой UDP и TCP - это протоколы 4-го уровня (L4). Помимо адресов, заголовок этих двух протоколов содержит номера портов, которые определяют тип службы (приложения), передающего данные.

Для передачи IP-пакета по проводам (или радио) сетевые устройства вынуждены «оборачивать» (инкапсулировать) его в пакет протокола 2го уровня (L2). Самым распространенным протоколом такого типа является . Фактическая передача «в провод» идет на 1м уровне. Обычно, устройство доступа (маршрутизатор) не занимается анализом заголовков пакетов на уровне, выше 4го (исключение - интеллектуальные межсетевые экраны).
Информация из полей адресов, портов, протоколов и счетчики длин из L3 и L4 заголовков пакетов данных и составляет тот «исходный материал», который используется при учёте и управлении трафиком. Собственно объем передаваемой информации находится в поле Length («Длина пакета») заголовка IP (включая длину самого заголовка). Кстати, из-за фрагментации пакетов вследствие механизма общий объем передаваемых данных всегда больше размера полезной нагрузки.

Суммарная длина интересных нам в данном контексте IP- и TCP/UDP- полей пакета составляет 2...10% общей длины пакета. Если обрабатывать и хранить всю эту информацию попакетно, не хватит никаких ресурсов. К счастью, подавляющий объем трафика структурирован так, что состоит из набора «диалогов» между внешними и внутренними сетевыми устройствами, так называемых «потоков». Например, в рамках одной операции пересылки электронного письма (протокол SMTP) открывается TCP-сессия между клиентом и сервером. Она характеризуется постоянным набором параметров {IP-адрес источника, TCP-порт источника, IP-адрес получателя TCP-порт получателя} . Вместо того, чтобы обрабатывать и хранить информацию попакетно, гораздо удобнее хранить параметры потока (адреса и порты), а также дополнительную информацию - число и сумму длин переданных пакетов в каждую сторону, опционально длительность сессии, индексы интерфейсов маршрутизатора, значение поля ToS и прочее. Такой подход выгоден для ориентированных на соединение протоколов (TCP), где можно явно перехватить момент завершения сессии. Однако и для не ориентированных на сессии протоколов можно проводить агрегацию и логическое завершение записи о потоке по, например, таймауту. Ниже приведена выдержка из SQL-базы , осуществляющей протоколирование информации о потоках трафика:

Необходимо отметить случай, когда устройство доступа осуществляет трансляцию адресов ( , маскарадинг) для организации доступа в Интернет компьютеров локальной сети, используя один, внешний, публичный IP-адрес. В этом случае специальный механизм осуществляет подмену IP-адресов и TCP/UDP портов пакетов трафика, заменяя внутренние (не маршрутизируемые в Интернете) адреса согласно своей динамической таблице трансляции. В такой конфигурации необходимо помнить, что для корректного учета данных по внутренним хостам сети съём статистики должен производиться способом и в том месте, где результат трансляции ещё не «обезличивает» внутренние адреса.

Методы сбора информации о трафике/статистике

Снимать и обрабатывать информацию о проходящем трафике можно непосредственно на самом устройстве доступа (ПК-маршрутизатор, VPN-сервер), с этого устройства передавая ее на отдельный сервер (NetFlow, SNMP), или «с провода» (tap, SPAN). Разберем все варианты по-порядку.

ПК-маршрутизатор

Рассмотрим простейший случай - устройство доступа (маршрутизатор) на базе ПК c ОС Linux.

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

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

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

использование сторонних средств преобразования попакетной статистики (полученной одним из двух предыдущих методов) в поток агрегированной информации netflow

Libpcap

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

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

открыть необходимый интерфейс

указать фильтр, через который пропускать принятые пакеты, размер захватываемой части (snaplen), размер буфера,

задать параметр promisc, который переводит сетевой интерфейс в режим захвата вообще всех проходящих мимо пакетов, а не только адресованных MAC-адресу этого интерфейса

установить функцию (callback), вызываемую на каждый принятый пакет.

При передаче пакета через выбранный интерфейс, после прохождения фильтра эта функция получает буфер, содержащий Ethernet, (VLAN), IP и т.д. заголовки, общим размером до snaplen. Поскольку библиотека libcap копирует пакеты, заблокировать их прохождение при ее помощи невозможно. В таком случае программе сбора и обработки трафика придется использовать альтернативные методы, например вызов скрипта для помещения заданного IP-адреса в правило блокировки трафика.

Межсетевой экран

Захват данных, проходящих через межсетевой экран, позволяет учесть и трафик самого сервера, и трафик пользователей сети, даже при работе трансляции адресов. Главное в этом случае - правильно сформулировать правило захвата, и поставить его в нужное место. Данным правилом активируется передача пакета в сторону системной библиотеки, откуда приложение учета и управления трафиком может его получить. Для ОС Линукс в качестве межсетевого экрана применяют iptables, а средства перехвата - ipq, или . Для OC FreeBSD - ipfw с правилами типа . В любом случае механизм межсетевого экрана дополняется возможностью работы с пользовательской программой следующим способом:

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

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

На каждый проходящий пакет обработчик получает его содержимое в виде буфера памяти (с заголовками IP и т.д. После обработки (учёта) программе необходимо также сообщить ядру операционной системы, что делать далее с таким пакетом - отбросить или передать далее. Как вариант, возможно передать ядру видоизмененный пакет.

Поскольку IP-пакет не копируется, а пересылается в программное обеспечение для анализа, становится возможным его «выброс», а следовательно, полное или частичное ограничение трафика определенного типа (например, до выбранного абонента локальной сети). Однако в случае, если прикладная программа перестала отвечать ядру о своем решении (зависла, к примеру), трафик через сервер просто блокируется.
Необходимо отметить, что описанные механизмы при существенных объемах передаваемого трафика создают избыточную нагрузку на сервер, что связано с постоянным копированием данных из ядра в пользовательскую программу. Этого недостатка лишен метод сбора статистики на уровне ядра ОС, с выдачей в прикладную программу агрегированной статистики по протоколу .

Netflow

Этот протокол был разработан фирмой Cisco Systems для экспорта информации о трафике с маршрутизаторов с целью учета и анализа трафика. Наиболее популярная сейчас предоставляет получателю поток структурированных данных в виде UDP-пакетов, содержащих информацию о прошедшем трафике в виде так называемых flow records:

Объем информации о трафике меньше самого трафика на несколько порядков, что особенно актуально в больших и распределенных сетях. Конечно же, блокировать передачу информации при сборе статистики по netflow невозможно (если не использовать дополнительные механизмы).
В настоящее время становится популярным дальнейшее развитие этого протокола - версия 9, основанная на шаблонной структуре flow record, реализации для устройств других производителей (). Недавно был принят стандарт IPFIX, который позволяет передавать статистику и по протоколам более глубоких уровней (например, по типу приложения).
Реализация netflow-источников (агентов, probe) доступна для ПК-маршрутизаторов, как в виде работающих по описанных выше механизмам утилит (flowprobe, ), так и непосредственно встроенных в ядро ОС (FreeBSD: , Linux: ). Для программных маршрутизаторов поток статистики netflow можно принимать и обрабатывать локально на самом маршрутизаторе, или отправлять по сети (протокол передачи - поверх UDP) на принимающее устройство (коллектор).

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

Функции экспорта netflow поддерживают маршрутизаторы Cisco Systems, Mikrotik, и некоторые другие. Аналогичный функционал (с другими протоколами экспорта) поддерживается всеми крупными производителями сетевого оборудования.

Libpcap в“снаруживЂќ

Немного усложним задачу. Что, если ваше устройство доступа - аппаратный маршрутизатор другого производителя? Например, D-Link, ASUS, Trendnet и т.д. На нем, скорее всего, невозможно поставить дополнительное программное средство съема данных. Как вариант - интеллектуальное устройство доступа у вас есть, но настроить его не представляется возможным (нет прав, или оно управляется вашим провайдером). В таком случае можно собирать информацию о трафике непосредственно в точке стыка устройства доступа с внутренней сетью, пользуясь «аппаратными» средствами копирования пакетов. В таком случае непременно потребуется отдельно стоящий сервер с выделенной сетевой картой для приема копий Ethernet-пакетов.
Сервер должен использовать механизм сбора пакетов по методу libpcap, описанному выше, и наша задача - на вход выделенной для этого сетевой карты подать поток данных, идентичный выходящему из сервера доступа. Для этого можно использовать:

Ethernet - хаб (hub): устройство, просто пересылающее пакеты между всеми своими портами без разбора. В современных реалиях его можно найти где-нибудь на пыльном складе, и применять такой метод не рекомендуется: ненадежно, низкая скорость (хабов на скорости 1 Гбит/с не бывает)

Ethernet - коммутатор с возможностью зеркалирования (мирроринга, . Современные интеллектуальные (и дорогие) коммутаторы позволяют копировать на указанный порт весь трафик (входящий, выходящий, оба) другого физического интерфейса, VLANа, в том числе удаленного (RSPAN)

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

Естественно, вы можете настроить SPAN-порт и на самом устройстве доступа (маршрутизаторе), если оно это позволяет - Cisco Catalyst 6500, Cisco ASA. Вот пример такой конфигурации для коммутатора Cisco:
monitor session 1 source vlan 100 ! откуда берем пакеты
monitor session 1 destination interface Gi6/3! куда выдаем пакеты

SNMP

Что, если маршрутизатора под нашим контролем нет, с netflow связываться нет желания, нас не интересуют детали трафика наших пользователей. Они просто подключены в сеть через управляемый коммутатор, и нам надо просто грубо оценить объем трафика, приходящегося на каждый из его портов. Как вы знаете, сетевые устройства с возможностью удаленного управления поддерживают, и могут отобразить счетчики пакетов (байт), проходящих через сетевые интерфейсы. Для их опроса правильно будет использовать стандартизованный протокол удаленного управления . При помощи его можно достаточно просто получить не только значения указанных счетчиков, но также другие параметры, такие как имя и описание интерфейса, видимые через него MAC-адреса, и другую полезную информацию. Это делается как утилитами командной строки (), графическими SNMP-браузерами, так и более сложными программами мониторинга сети ( , и т.д.). Однако, данный метод имеет два существенных недостатка:

блокировка трафика может производиться только путем полного отключения интерфейса, при помощи того же SNMP

счетчики трафика, снимаемые по SNMP, относятся к сумме длин Ethernet-пакетов (причем unicast, broadcast и multicast по-отдельности), в то время как остальные описанные ранее средства дают величины относительно IP-пакетов. Это создает заметное расхождение (особенно на коротких пакетах) из-за оверхеда, вызванного длиной Ethernet-заголовка (впрочем, с этим можно приближенно бороться: L3_байт = L2_байт - L2_пакетов*38).

VPN

Отдельно стоит рассмотреть случай доступа пользователей к сети путем явного установления соединения к серверу доступа. Классическим примером может служить старый добрый dial-up, аналогом которого в современном мире являются удаленного доступа (PPTP, PPPoE, L2TP, OpenVPN, IPSEC)

Устройство доступа не только маршрутизирует IP-трафик пользователей, но также представляет из себя специализированный VPN-сервер, и терминирует логические туннели (часто зашифрованные), внутри которых передается пользовательский трафик.
Для учета такого трафика можно пользоваться как всеми средствами, описанными выше (и для глубокого анализа по портам/протоколам они хорошо подходят), так и дополнительными механизмами, которые предоставляют средства управления VPN-доступом. В первую очередь речь пойдет о протоколе . Его работа - достаточно сложная тема. Мы же кратко упомянем, что контролем (авторизацией) доступа к VPN-серверу (RADIUS-клиенту) управляет специальное приложение (RADIUS-сервер), имеющее за собой базу (текстовый файл, SQL, Active Directory) допустимых пользователей с их атрибутами (ограничения по скорости подключения, назначенные IP-адреса). Помимо процесса авторизации, клиент периодически передает серверу сообщения аккаунтинга, информацию о состоянии каждой текущей работающей VPN-сессии, в том числе счетчики переданных байт и пакетов.

Заключение

Сведем все описанные выше методы сбора информации о трафике воедино:

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

как и куда попадают собранные данные о трафике

программное обеспечение для учета трафика

чем отличается биллинг от простой в“считалкивЂќ

как можно накладывать ограничение на трафик

учёт и ограничение посещенных веб-сайтов

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

Забросить shell-код на удаленную машину и застолбить там back-door — это только половина дела. А что делать дальше, мы подумали? Необходимо скрыть свой IP-адрес и обойти все брандмауэры, не оставляя никаких следов в логах, анализируемых как вручную, так и автоматизированными системами определения вторжения. Существует множество утилит, прячущих левые сетевые соединения от глаз администраторов, однако на физическом уровне весь «хакерский» трафик элементарно обнаруживается и пресекается практически любым брандмауэром, чего атакующему допускать ни в коем случае нельзя. В идеале необходимо пробить тоннель, открыв секретный канал связи, не создающий никаких дополнительных соединений и не
генерирующий никакого избыточного трафика, чтобы даже самый строгий разбор дампов, награбленных сетевым анализатором, не выявил ничего подозрительного.

Над решением этой проблемы бились лучшие хакерские умы. Сначала идея получила чисто теоретическое обоснование (Andrew Hintz, Craig Rowland) с чисто лабораторной реализацией, непригодной для практического использования. Затем к делу подключилась Жанна Рутковская, разработавшая специальный протокол с кодовым названием NUSHU и вполне жизнеспособные модули, ориентированные на работу в Linux Kernel 2.4. Жанна вручила нам мощное средство для управления удаленными shell’ами, от которого практически невозможно разработать адекватную защиту. Осталось только разобраться, как этим средством воспользоваться.

Скрытые пассивные каналы: основные концепции

С недавних пор в хакерском лексиконе появилось понятие «скрытых пассивных каналов » (Passive Covert Channels , или сокращенно PCC ). Они представляют собой разновидность обычных скрытых каналов (Covert Channels ), однако, в отличие от последних, не только не устанавливают своих соединений, но и вообще не генерируют никакого собственного трафика! Передача информации осуществляется исключительно путем модификации пакетов, пролетающих мимо атакованного узла.

Соль в том, что эти пакеты направляются не к хакеру, а шуруют своими путями на различные узлы интернета, например, www.google.com, за счет чего достигается высочайшая степень анонимности. Естественно, возникает резонный вопрос: как хакер сможет добраться до содержимого пакетов, идущих мимо него? Для этого необходимо подломать один из промежуточных маршрутизаторов (как правило, принадлежащих провайдеру, обслуживающему атакуемую организацию) и установить на него специальный модуль, анализирующий заголовки TCP/IP-пакетов на предмет наличия скрытой информации или ее внедрения.

Таким образом, хакер организует двухсторонний секретный пассивный канал связи с узлом-жертвой, не только засекретив факт передачи левой информации, но еще и надежно замаскировав свой IP, который может определить только администратор взломанного маршрутизатора, но никак не владелец узла-жертвы!

Рассмотрим схему взаимодействия с целевым узлом (жертвой) по скрытому пассивному каналу. Хакер (обозначенный буквой Х) каким-то совершенно не относящимся к обсуждаемой теме образом забрасывает на целевой узел (обозначенный буквой A) shell-код, захватывающий управление и устанавливающий back-door вместе со специальным модулем, обеспечивающим функционирование PCC-канала. Теперь все TCP/IP-пакеты, отправляемые жертвой во внешний мир, содержат незначительные изменения, кодирующие, например, пароли или другую конфиденциальную информацию.

Часть этих пакетов проходит через внешний маршрутизатор B, заблаговременно взломанный хакером, внедрившим в него PCC-модуль. PCC-модуль анализирует заголовки всех TCP/IP-пакетов на предмет скрытого содержимого, после чего декодирует его и отправляет хакеру по открытому каналу. Передача данных от хакера к жертве осуществляется по аналогичной схеме. PCC-модуль, установленный на маршрутизаторе, выявляет пакеты, направленные на целевой IP-адрес, и модифицирует их заголовки в соответствии с выбранным принципом кодирования информации.

Таким образом, мы получаем защищенный канал A-B и открытый B-X, однако хакеру ничего не стоит общаться с узлом B через анонимный proxy-сервер или даже выстроить цепочку из нескольких защищенных хостов. К тому же, выбор маршрутизатора B необязателен. Главное, чтобы маршрутизатор располагался между целевым узлом А и одним из узлов, с которыми общается жертва.

Во власти протокола IP

Возьмем протокол IP и попробуем создать на его основе скрытый пассивный канал. Среди множества полезных и бесполезных полей заголовка наше внимание привлекает 16-битовое поле Identification , генерируемое операционной системой случайным образом и используемое для идентификации дейтаграммы в случае ее фрагментации. Узел-получатель группирует фрагменты с одинаковыми IP-адресами источника/назначения, типом протокола и, разумеется, идентификатором.

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

Фишка в том, что PCC-модуль может беспрепятственно модифицировать поле идентификатора по своему вкусу, передавая с каждым IP-пакетом 16 бит полезных данных. Это в теории. На практике же нам потребуется выделить несколько бит для маркировки своих пакетов, иначе PCC-приемник ни за что не сможет отличить их от остальных. Пусть в 12 младших битах передаются полезные данные, а в четырех старших — их контрольная сумма. Тогда PCC-приемнику останется всего лишь взять 12 бит, рассчитать их CRC и сравнить с оставшимися четырьмя битами. Если они совпадут, значит, это наш пакет, если же нет — пускай идет себе лесом.

Также следует позаботиться о нумерации пакетов, поскольку порядок следования IP-пакетов в общем случае не совпадает с порядком их отправки. А для этого также требуются биты, в результате чего реальная информационная емкость IP-заголовка стремится к одному байту, что, в общем-то, не так уж и плохо. Для передачи небольших объемов данных (типа паролей) вполне сойдет. Главное — не забывать о том, что идентификатор должен: а) быть уникальным; б) выглядеть случайным. Поэтому необходимо прибегнуть к скремблированию, то есть к наложению на передаваемый текст некоторой псевдослучайной последовательности данных (известной как PCC-отправителю, так и PCC-получателю) через оператор XOR.

Кроме идентификатора, можно (с некоторой осторожностью) менять поля TTL (Time To Live – максимальное время жизни пакета), тип сервиса (TOS) и протокола (protocol). Однако это слишком заметно и легко обнаруживается просмотром дампов, полученных любым снифером.

Наш извозчик — протокол TCP

При установке TCP-соединения передающая сторона (узел A) устанавливает флаг SYN и выбирает произвольный 32-битный номер последовательности (Sequence Number, или сокращенно SEQ). Если принимающая сторона (узел B) согласна принять узел А в свои объятия, она отправляет ему пакет с установленным флагом ACK и номером подтверждения (Acknowledgment Number), равным SEQ+1, а также генерирует свой собственный номер последовательности, выбираемый случайными образом. Узел A, получив подтверждение, поступает аналогичным образом, что наглядно демонстрирует следующая схема:

узел A —— SYN(ISN) ————> узел B
узел A <—— SYN(ISN+1)/ACK —— узел B
узел A —— ACK —————-> узел B

ISN – это начальный номер последовательности (Initial Sequence Number ), уникальный для каждого TCP/IP-соединения. С момента установки соединения номера последовательности планомерно увеличиваются на количество принятых/отправленных байт. Впрочем, не будем углубляться в теорию. Остановимся на том факте, что 32-битное поле ISN можно изменять псевдослучайным образом, «промодулированным» секретными данными и… никто ничего не заметит! Конечно, пропускная способность упадет до четырех байт на каждое TCP-соединение, устанавливаемое узлом-жертвой, а TCP-соединений устанавливается не так уж и много (особенно если мы имеем дело не с нагруженным сервером, а с рабочей станцией). Тем не менее, для
перекачки паролей и удаленного управления через командную строку даже такой скромной пропускной способности вполне достаточно.

Жанна Рутковская , решив не ограничивать себя лабораторными опытами, разработала протокол NUSHU , создающий скрытые пассивные каналы посредством модификации ISN с последующим шифрованием последнего алгоритмом DES на основе идентификатора IP-пакета (IP.id), порта-источника (TCP.sport) и IP-адреса назначения (IP.daddr).

Сеанс практической магии

Идем на сайт Жанны Рутковской — invisiblethings.org , видим раздел с инструментами tools, находим в нем «NUSHU — passive covert channel engine for Linux 2.4 kernels » и качаем архив исходных текстов — invisiblethings.org/tools/nushu/nushu.tar.gz (всего 18 Кб). Распаковываем, компилируем. Компиляция осуществляется стандартно. Просто запускаем утилиту make и получаем три модуля ядра: nushu_receiver.o (приемник), nushu_sender.o (передатчик) и nushu_hider.o.

Механизм шифрования ISN в протоколе NUSHU

Приемник устанавливается на поломанный маршрутизатор, передатчик — на целевой узел жертвы. Для организации двухсторонней связи приемник и передатчик устанавливаются на оба узла. Модуль nushu_hider.o в организации скрытого канала не участвует и предназначен для обмана штатных анализаторов (типа tcpdump), не позволяя им обнаруживать факт изменения ISN.

Из readme следует, что модуль-передатчик обрабатывает следующие параметры командной строки:

dev=, где device – сетевое устройство, с которым предполагается работать (например, eth0);
cipher=, где 0 означает передачу без шифрования, а 1 предписывает использование DES;
key="string", где string — произвольная строка-маркер, идентичная строке-маркеру, установленной на модуле-приемнике (используется только в том случае, если шифрование выключено, иначе игнорируется);
src_ip= — IP-адрес узла, на котором установлен передатчик.

Модуль-приемник, помимо описанных выше ключей dev, cipher и key, обрабатывает аргумент exclude_ip=<172.16.*.*>, задающий список неприкосновенных IP-адресов, при отправке пакетов на которые протокол NUSHU задействован не будет, поскольку ISN останется неизменным (этот параметр является опциональным).

Модуль nushu_hider.o загружается без каких-либо параметров и только в том случае, если в этом возникает необходимость.

Хорошо, все модули успешно загружены, ядро функционирует нормально и в панику, судя по всему, впадать не собирается. Что делать дальше? А ничего! Ведь это только движок, обеспечивающий функционирование PCC-каналов . К нему можно прикрутить кейлоггер или удаленный shell, но это уже придется делать самостоятельно. А как?! Ни readme, ни сопроводительные презентации не дают ответа на этот вопрос, поэтому приходится зарываться в исходные тексты и разбирать их на отдельные байты.

Начнем с передатчика, реализованного в файле sender.c. В процедуре init_module(), отвечающей за инициализацию модуля, сразу же бросаются в глаза следующие строки:

create_proc_read_entry ("info", 0, proc_de, cc_read_proc_info, NULL);
struct proc_dir_entry * wpde = create_proc_entry ("message_to_send", 0, proc_de);

Все ясно! Модуль использует псевдофайловую систему /proc, создавая директорию nushu, а в ней — два файла: info и message_to_send, с которыми можно работать с прикладного уровня, как с обычными устройствами (если быть точнее, псевдоустройствами).Аналогичным образом обстоят дела и с приемником, реализованным в файле receiver.c, ключевой фрагмент которого приведен ниже:

Struct proc_dir_entry *proc_de = proc_mkdir ("nushu", NULL);
create_proc_read_entry ("message_received", 0, proc_de, cc_read_proc_message, NULL);
create_proc_read_entry ("info", 0, proc_de, cc_read_proc_info, NULL);

Как видно, вместо устройства message_to_send на этот раз создается message_received, из которого можно читать получаемые сообщения через стандартные функции ввода/вывода. В общем, имея на руках исходные тексты, со всеми этими причиндалами совсем несложно разобраться, тем более что их суммарный объем составляет всего 69 Кб.

Заключение

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

Может ли атакованный администратор обнаружить скрытые пассивные каналы хотя бы теоретически? Скрупулезный анализ сетевого трафика позволяет выявить некоторую ненормальность распределения ISN, но для этого требуется обработать сотни тысяч «хакнутых» пакетов, сравнивая их с оригиналами. Потому намного проще выявить посторонний ядерный модуль, отвечающий за создание и поддержку PCC-каналов, используя общие методики верификации целостности системы. Однако это уже совсем другой разговор, к которому мы еще вернемся.