Прячем трафик: техника сокрытия IP-трафика с помощью секретных пассивных каналов. Принципы организации учёта IP-трафика

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

Забросить 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-каналов, используя общие методики верификации целостности системы. Однако это уже совсем другой разговор, к которому мы еще вернемся.

Передача IP трафика по сетям SDH, или Есть ли у ATM альтернатива?

Олег АЛЛЕНОВ
AMT Group

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

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

Для увеличения пропускной способности Internet прежде всего необходим высокоскоростной "транспорт". Один из вариантов - использование популярной технологии ATM. Следует отметить, что в качестве транспортного протокола ATM вызывает все больше нареканий как у производителей оборудования, так и у конечных пользователей. Мы постараемся проанализировать недостатки ATM более подробно и рассмотреть аргументы в пользу другого способа передачи трафика Internet - прямой инкапсуляции протоколов TCP/IP в протоколы SONET/SDH.

Технология ATM

Асинхронный режим передачи, ATM, был представлен на суд производителей и провайдеров сетевых услуг как технология, позволяющая обеспечить необходимую полосу пропускания по требованию и гарантированное качество обслуживания широкому спектру мультимедийных приложений, среди которых на первом месте находился Internet. Таким образом, не самая последняя часть компонентов ATM была ориентирована и разрабатывалась специально для передачи трафика Internet. Предполагалось, что в ближайшем будущем Сеть будет в значительной степени состоять из пользователей ATM и клиентов LANE (LAN Emulation), что обеспечит легкую и естественную миграцию Internet-приложений в новый транспортный протокол, обещающий безграничные возможности.

Однако (возможно, из-за дороговизны новых решений или их неорганичности) этого почему-то не произошло. Более того, все отчетливее стала проявляться тенденция к усилению влияния протоколов TCP/IP именно как транспортных протоколов.

Действительно, стек протоколов TCP/IP давно отработан и испытан, в его создание и отладку вложено немало средств и сил. Если у протокола IPv4 и есть определенные недостатки, то готовящаяся к выходу версия IPv6 позволит устранить большинство из них. Впрочем, существующая версия IPv4 тоже устраивает очень многих и, по мнению экспертов, в состоянии продержаться еще несколько лет. Изрядное число производителей рассматривает именно IP как перспективный транспортный протокол для современной телекоммуникационной инфраструктуры. Так при чем же здесь ATM?

ATM была предложена ITU-T как базовая технология для широкополосного ISDN (или B-ISDN). Поскольку B-ISDN предназначен в основном для передачи мультимедийного трафика, ATM имела все возможности для поддержки такого рода трафика в реальных сетях.

Прошло некоторое время, и производители телекоммуникационного оборудования обратили на ATM свое внимание. Был создан ATM Forum, который занялся воплощением новой технологии в жизнь. При этом задачи, возлагаемые на ATM Forum, состояли в стандартизации и разработке эффективного наращиваемого протокола, поддерживающего трафик с диаметрально противоположными характеристиками (мультимедиа), гарантирующего определенное качество обслуживания (QoS) и поддерживающего многоадресное вещание. Кроме того, данный протокол должен быть совместимым с существующими технологиями LAN и WAN.

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

Технология IP

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

Думаю, многие клиенты, имеющие опыт использования адаптеров ATM для персональных компьютеров, согласятся со мной, что сетевая карта Fast Ethernet 100 Мбит/с (не говоря уже про Full Duplex) работает по крайней мере не медленнее, чем адаптер ATM на 155 Мбит/с. Это связано с большей избыточностью протокола ATM и задержками на сборку/разборку ячеек. Что же касается гарантированного качества обслуживания ATM, оно практически не реализовано в LANE, да и для передачи IP-трафика через ATM сейчас используется AAL5 UBR (максимум UBR+ или ABR). Так что говорить о QoS не приходится.

Несомненно, новая технология должна поддерживать широкий диапазон уровней качества обслуживания. Однако IP был выбран в качестве протокола для всеобщего межсетевого взаимодействия и прекрасно работал в Internet, насчитывавшем тогда 20 тыс. компьютеров, уже в середине 1980 г. и продолжает успешно соединять несколько миллионов хостов сегодня. Действительно ли IP изжил себя? Сторонники ATM, вероятно, ответят "да".

Огромные средства были вложены в разработку семейства Internet-протоколов и доведение их до нынешнего состояния. Действует не только ATM Forum, но и IETF (Internet Engineering Task Force) - продолжается поиск путей для применения IP в появляющихся высокоскоростных мультимедийных сетях. Созданы протоколы поддержки многоадресного вещания (IGMP, DVMRP, PIM) и протоколы, обеспечивающие резервирование ресурсов для передачи трафика (RSVP). Имеется возможность осуществлять маршрутизацию (правда, пока еще не так гибко, как при использовании PNNI) на основе требуемого качества обслуживания (Tag Switching), а готовящийся к выходу в IETF стандарт MPLS (Multiprotocol Label Switching) обеспечит интероперабельность всех устройств, поддерживающих коммутацию меток, и, вероятно, ощутимо потеснит позиции MPOA (Multiprotocol Over ATM).

Так имеет ли смысл заменять хорошо проработанную технологию IP на только появляющуюся ATM ?

IP через ATM

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

Прежде всего обратим внимание на то, что практически все (за редким исключением, например ATM25, TAXI и т.п.) физические интерфейсы ATM-коммутаторов работают в формате кадров SDH/SONET/PDH. Это сделано для облегчения интеграции с широко распространенными транспортными сетями SDH. Но даже когда SDH напрочь отсутствует и не предусмотрен проектом, все равно в передачу пользовательского трафика вносится SDH overhead, что, мягко говоря, не увеличивает скорость и производительность сети.

Уместно также будет отметить, что SDH - синхронный метод передачи, а ATM - асинхронный. При передаче ATM-трафика через транспортные сети SDH мы теряем все преимущества асинхронного метода переноса ячеек, не говоря уже о дублировании ряда функций (например, OA&M).

Улучшению ситуации отнюдь не способствует инкапсуляция IP в ATM, в свою очередь работающий через SDH. Протокол ATM является ориентированным на соединение, в то время как IP таковым не является. Это несоответствие также ведет к дополнительному усложнению и дублированию ряда функций.

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

На недостатках методов эмуляции локальных сетей даже нет нужды останавливаться, поскольку любой квалифицированный сетевой специалист согласится, что технологию LANE никак нельзя назвать органичной и перспективной. Со многих точек зрения эта технология - неудачная попытка "притянуть" протоколы, разработанные для сред с широковещательной рассылкой, к работе в среде, где подобный режим передачи данных невозможен (NBMA, Nonbroadcast Multiple Access).

Таким образом, если Internet все-таки остается самим собой и продолжает базироваться на IP, нужна ли дополнительная "прослойка" в виде ATM между IP и действительно эффективным, действительно высокоскоростным транспортным проколом SDH, который одинаково хорошо служит для передачи трафика практически любого вида?

IP через SDH

Технология SDH широко используется для организации надежного транспорта. SDH была разработана для того, чтобы получить стандартный протокол для взаимодействия провайдеров; унифицировать американские, европейские и японские цифровые системы; обеспечить мультиплексирование цифровых сигналов на гигабитных скоростях; обеспечить поддержку функций эксплуатации и технического обслуживания OA&M (operation, administration and maintenance).

Хотя SDH и работает с кадрами и имеет свою канальную структуру, с точки зрения сетевого уровня SDH - всего лишь поток октетов. Для того чтобы корректно вложить пакет IP в SDH-контейнер, необходимо четко определить границы пакета (или группы пакетов) в рамках синхронного транспортного модуля STM (synchronous transport module). Иными словами, между IP и SDH нужна некоторая протокольная "прослойка" для формирования кадров канального уровня.

Поскольку SDH предоставляет соединения типа точка-точка, применение в качестве промежуточного протокола PPP (Point-to-Point Protocol) представляется вполне логичным. PPP широко используется в Internet в качестве протокола канального уровня для организации соединений через глобальные сети. Кроме того, PPP позволяет задействовать дополнительные функции PPP-протокола:

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

Впрочем, надо отметить, что в качестве сетевого протокола для нас сейчас представляет интерес только IP, а кроме того, ряд функций протокола NCP (например, динамическое присвоение IP-адресов) в нашем случае не актуален. Что нас действительно интересует, так это инкапсуляция IP в PPP с последующим размещением PPP-кадров в SDH.

Инкапсуляция IP в PPP не представляет проблемы, поскольку хорошо отработана и повсеместно используется. Процедура инкапсуляции PPP в SDH (определено значение Path Signal Label = 207hex), показанная на рисунке, должна осуществляться специальным сервис-адаптером на уровне тракта SDH. Сервис-адаптер может представлять собой "черный ящик", принимающий поток PPP-кадров и "выдающий" поток транспортных модулей STM. PPP весьма удачно подходит для работы с SDH, так как оба протокола ориентированы на работу в однобайтном режиме.

Таким образом, используя непосредственную инкапсуляцию трафика Internet в существующую транспортную службу SDH, мы существенно упрощаем сложную сетевую инфраструктуру, а тем самым уменьшаем ее стоимость и увеличиваем эффективную пропускную способность. С появлением новых возможностей передачи IP-трафика на гигабитных скоростях (Gigabit Ethernet) и технологий быстрой коммутации IP-пакетов (Multiprotocol Label Switching - MPLS) становится реальным использование именно IP-протокола как основы единой транспортной службы для передачи видео, телефонии и других мультимедийных приложений - благо основная часть работ по внедрению протокола IP во Всемирную сеть уже выполнена. В связи с этим очень своевременным кажется появление стандартов (RFC 1619) и первых практических реализаций интерфейсов типа "PPP over SDH" (или Packets Over Sonet - POS) на предназначенных для Internet современных маршрутизаторах, в частности GSR 12000 от Cisco Systems.

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

ОБ АВТОРЕ

Олег Алленов - инструктор учебного центра компании AMT Group, CCSI/CCIE. С ним можно связаться по тел. 725 - 7660

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

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

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

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

• Внешние ресурсы – сеть Интернет, со всеми сайтами, серверами, адресами и прочим, что не принадлежит сети, которую вы контролируете.
• Устройство доступа – маршрутизатор (аппаратный, или на базе PC), коммутатор, VPN-сервер или концентратор.
• Внутренние ресурсы – набор компьютеров, подсетей, абонентов, работу которых в сети необходимо учитывать или контролировать.
• Сервер управления или учёта – устройство, на котором работает специализированное программное обеспечение. Может быть функционально совмещён с программным маршрутизатором.

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

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

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

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

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

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

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

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

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

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

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

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

Libpcap

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

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

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

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

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

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

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

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

Netflow

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

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


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

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

Libpcap “снаружи”

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

• Ethernet – хаб (hub): устройство, просто пересылающее пакеты между всеми своими портами без разбора. В современных реалиях его можно найти где-нибудь на пыльном складе, и применять такой метод не рекомендуется: ненадежно, низкая скорость (хабов на скорости 1 Гбит/с не бывает)
• Ethernet – коммутатор с возможностью зеркалирования (мирроринга, SPAN портов . Современные интеллектуальные (и дорогие) коммутаторы позволяют копировать на указанный порт весь трафик (входящий, выходящий, оба) другого физического интерфейса, VLANа, в том числе удаленного (RSPAN)
• Аппаратный раздвоитель , который может потребовать установки для сбора двух сетевых карт вместо одной – и это помимо основной, системной.

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

SNMP

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

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

VPN

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


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

Заключение

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

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

• как и куда попадают собранные данные о трафике
• программное обеспечение для учета трафика
• чем отличается биллинг от простой “считалки”
• как можно накладывать ограничение на трафик
• учёт и ограничение посещенных веб-сайтов

IP Traffic Monitor is a bandwidth monitor, which allows you to analyze Internet traffic in real time. IP Traffic Monitor provides you with detailed analysis about network bandwidth usage.

Security and audit of resources are the key questions of the modern Internet environment. IP Traffic Monitor allows you to solve such questions effectively and at the proper time.

IP Traffic Monitor is a tool that helps you watch your network activity and see which connections take a lot of traffic. It works with Proxy Servers. Also, it saves daily logs and allows you to view the saved logs.

Tracking of internet traffic helps to detect spyware, adware, viruses and other suspicious activities, before they compromise you system’s security.

Product Overview

There are many reasons why you may want to monitor your Internet traffic flows. I’ll point out only a few of the most popular reasons. No anti-virus can guarantee you 100% protection from Trojan Horses and malicious spyware or adware programs. Some of them are highly customized and checking against anti-virus databases does nothing. They also slow down your Internet connection. Needless to say that identity theft or using your computer as a peer-to-peer network hub for pirated software, music and video downloads without you even knowing about this may certainly have unwanted consequences. If you share your computer with family members or you administer computers in your office, knowing the Internet traffic details becomes essential. Network load balance, security reasons and more. IP Traffic Monitor is an application designed to stay quietly in your system tray and monitors all your network connections. You can either monitor the active connections in real-time or browse historical logs. The program shows extensive information about each connection: remote host IP, remote host name (if available), amounts of incoming and outgoing traffic through this connection, timestamps of the first and last activity of this connection, name of the process that initiated or accepted this connection, full path to the application the process belongs to, etc. The traffic summary indicator shows an upload and download speed graph and traffic totals. In addition it draws pie chart diagrams that illustrate the percentage of certain hosts in the total incoming and outgoing traffic.

Screenshots

These days it’s not enough to have software that detects spyware, adware, viruses, and other suspicious activities. There’s always a chance that a brand new, unknown piece of malware can sneak into your network and wreak havoc. To be absolutely certain that everything in your network is hunky dory, you need to be able to analyze the volume and direction of Internet traffic, in real time.

IP Traffic Monitor helps you to accurately observe all network activity to easily identify which processes are generating the most traffic, providing a powerful indicator of possible viral infection or illegal activity. Network activity logs are generated daily, and you always have the option of reviewing past logs in your search for suspicious patterns.

IP Traffic Monitor features a streamlined interface complete with colorful charts and intuitive displays. At a glance, you’ll be able to see all of the processes that are currently running, and how much data has been uploaded and downloaded by each process. Visual charts show you exactly how much bandwidth is consumed by each process. If a remote host is involved, IP Traffic Monitor will show you its IP address and resolved name!

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

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

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

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

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

... Этот адрес называется IP . ... Но что такое IP-адрес? ... IP-адрес - 4-байтовое (32-разрядное) число, задающее уникальный номер компьютеру пользователя в Интернете. ... Если брандмауэр опознаёт пакет данных и его IP-адрес, то он позволяет этим данным «пройти». ... Брандмауэр просматривает весь трафик на наличие вирусов любого вида: - spyware (шпионящее ПО); - вредоносного программного...

... Брандмауэр с поддержкой режима обследования осмотрит каждое состояние соединения, обеспечив более высокую производительность и понизив злоумышленный трафик . ... В основном, беспроводной маршрутизатор используется для распределения сетевого трафика между сетью и Интернетом. ... Проверьте также URL, IP и МАК адреса в опциях фильтра.

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

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

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