Санкт-петербургский государственный политехнический
жүктеу/скачать 454 Kb.
|
- Бұл бет үшін навигация:
- Заголовки ответа HTTP
- Общие заголовки
- Заголовки объекта
- 1.2.1.2 FTP — протокол передачи файлов
- 1.2.1.3 SMTP (и электронная почта)
- Заголовок SMTP
- 1.2.2 Особенности построения современных протоколов и возможности их гибкой фильтрации
- 1.2.2.2 Структура и фильтрация BitTorrent.
- 1.2.2.3 Структура и фильтрация Skype.
HTTP ответНачальная строка ответа называется Далее могут следовать заголовки ответа и тело ответа. Строка статуса имеет следующий формат:
или
<Версия><Код><Пояснение> Версия в настоящее время может принимать значения HTTP/1.0 или HTTP/1.1. Код — возвращаемый код состояния и Пояснение. Элемент код состояния (Status-Code) - это целочисленный трехразрядный код результата понимания и удовлетворения запроса. Пояснение (Reason-Phrase) предназначено для короткого текстового описания кода состояния. Код состояния (Status-Code) предназначен для использования автоматами, а поясняющая фраза предназначена для живых пользователей. От клиента не требуется исследовать или отображать поясняющую фразу (Reason-Phrase). Первая цифра кода состояния определяет класс ответа. Последние две цифры не имеют определенной роли в классификации. Имеется 5 значений первой цифры: 1xx: Информационные коды – запрос получен, продолжается обработка. 2xx: Успешные коды – действие было успешно получено, понято и обработано. 3xx: Коды перенаправления – для выполнения запроса должны быть предприняты дальнейшие действия. 4xx: Коды ошибок клиента – запрос имеет плохой синтаксис или не может быть выполнен. 5xx: Коды ошибок сервера – сервер не в состоянии выполнить допустимый запрос. Заголовки ответа HTTPЗаголовки ответа могут фигурировать только в сообщениях-ответах. В последней версии протокола HTTP/1.1 тринадцать заголовков ответа. Заголовки имеют формат: Параметр: значение. Для простоты восприятия удобно разбить заголовки ответа на четыре класса:
Location Переадресация на указанный URL 2. Дополнительная информация Server Идентификация сервера Retry-After Величина задержки перед повторной попыткой запроса Accept-Ranges Частичный запрос Alternates Альтернативные способы представления ресурса Set-Cookie Содержимое Сookies для записи на стороне клиента Public Список доступных методов для всего сервера Keep-Alive Поддержание TCP соединения 3. Безопасность www-Authenticate Запрос информации для аутентификации Proxy-Authenticate Запрос информации для аутентификации прокси-сервером
ETag Проверка непрозрачности Age Время с момента создания ответа Vary Выбор варианта ресурса Полный перечень значений параметров для каждого заголовка приведен в RFC 2616 [ 6] Кроме описанных заголовков запросов и ответов существуют так называемые общие заголовки, они могут идти до заголовков запросов и ответови применяются как для сообщений запросов, так и для сообщений ответов. Эти поля заголовка применяются только к передаваемому сообщению, то есть могут присутствовать только при наличии тела сообщения. Общие заголовкиDate Дата/время создания сообщения Pragma Директива сообщения Cache-Control Директива кэширования Connection Упр-е соединением при промежуточных передачах Trailer Список заголовков в конце сообщения Transfer-Encoding Преобразование тела сообщения Upgrade Переход на другие протоколы Via Информация о промежуточных серверах Warning Уведомление об ошибке Полный перечень значений параметров для каждого заголовка приведен в RFC 2616 [6]. Сообщения запросов и ответов могут передать тело сообщения (объект), если иное не установлено методом запроса или кодом состояния ответа. Объект состоит из полей заголовка объекта (entity-header) и тела объекта (entity-body), хотя некоторые ответы могут включать только заголовки объекта (entity-headers).
Content-Encoding Кодирование содержания, примененное к телу содержимого Content-Length Длина тела содержимого Content-Type Тип тела содержимого Expires Продолжительность актуальности тела содержимого Last-Modified Время последней модификации ресурса Content-Language Язык содержимого Content-Location Альтернативный адрес ресурса Content-Range Положение диапазона в теле содержимого Например, Content-Type ("тип содержимого") – содержит обозначение типа содержимого ответа. В зависимости от значения Content-Type браузер воспринимает ответ как HTML-страницу, картинку gif или jpeg, как файл, который надо сохранить на диске, или как что-либо еще и предпринимает соответствующие действия. Значение Content-Type для браузера аналогично значению расширения файла для Windows. Некоторые типы содержимого: text/html - текст в формате HTML (веб-страница); text/plain - простой текст; image/jpeg - картинка в формате JPEG; image/gif - то же, в формате GIF; application/octet-stream - поток "октетов" (т.е. просто байт) для записи на диск. Полный перечень значений параметров для каждого заголовка приведен в RFC 2616 [6]. Все указанные особенности протокола HTTP (методы, заголовки и их значения, URL) можно использовать для «тонкой» фильтрации трафика протокола HTTP. Это требует точного понимания подробностей и тонкостей использования HTTP при сетевом взаимодействии и может быть достигнуто только практическим исследованием реального HTTP трафика. Нужно отметить, что в современных сетях роль протокола HTTP шире, чем просто обеспечение получения информации с WEB серверов. На его базе работают так называемые WEB службы (Web Services- WS), используя HTTP как транспорт для передачи своих сообщений (например SOAP - Simple Object Access Protocol чаще всего используется поверх HTTP).
Протокол FTP обеспечивает вход на сервер с авторизацией, то есть запрашивается логин и пароль. После аутентификации сервер разрешает доступ к своей файловой системе с заранее определёнными правами доступа. Естественно, что на сервере должна быть заранее создана соответствующая учётная запись. Анонимный FTP (anonymous FTP) – это вариант обычного FTP с той разницей, что он не требует идентификации пользователя. Это прекрасный способ для предоставления доступа к файловому серверу заранее неизвестным (анонимным) пользователям. В этом случае сервер настраивается так, что в качестве логина нужно указать слово anonymous (или ftp), а в качестве пароля – адрес электронной почты. Пароль не проверяется, а просто записывается в файл протокола доступа. Пользователь anonymous не имеет никаких прав на сервере, кроме чтения файлов из строго определенных каталогов. Особенностью протокола FTP является использование двух каналов — управляющего (command connection) и информационного (data transfer connectiot). Оба канала используют протокол TCP. Сначала по запросу клиента формируется канал управления (управляющее соединение), который в дальнейшем используется для передачи команд от клиента и откликов от сервера. Сервер осуществляет пассивное открытие на заранее известный порт FTP (21) и ожидает запроса на соединение от клиента. Клиент осуществляет активное открытие на TCP порт 21, чтобы установить управляющее соединение. Со стороны клиента стандартным образом выбирается «клиентский» порт > 1024. Информационный канал формируется сервером по команде клиента, он не должен существовать постоянно на протяжении всей FTP-сессии и может формироваться и ликвидироваться по мере необходимости. Канал управления может быть закрыт только после завершения информационного обмена, т.е. завершения FTP-сессии. Сервер FTP имеет два режима работы, "активный" (обычный) и "пассивный". Эти слова характеризуют поведение сервера. Инициатором выбора режима является клиент. В активном режиме клиент подключается к порту 21 на сервере и регистрируется. Когда требуется передача данных, клиент выделяет динамический порт с номером большим или равным 1024, информирует сервер о том, какой порт открыт, а затем сервер открывает новое подключение к этому порту. Это "активная" роль сервера: он активно устанавливает новые подключения к клиентам. В пассивном режиме, подключение к порту 21 выполняется аналогично. Когда требуется передача данных, СЕРВЕР выделяет динамический порт с номером, начиная с 1024, информирует клиента о том, какой порт открыт, а затем КЛИЕНТ открывает новое подключение к этому порту. Это "пассивная" роль сервера: он ждет установки клиентом второго подключения (для передачи данных). Схема работы FTP в двух режимах приведена на рисунках 2.a и 2.b 
Рис. 2.а. Активный режим
Рис. 2.b. Пассивный режим
С точки зрения фильтрации с использованием пакетного МЭ, FTP протокол является весьма неудобным, так как в этом случае нужно решить четыре проблемы: 1. Поддержка FTP-сервера в активном режиме Необходимо разрешить серверу открывать новые подключения во внешний мир через порты с номерами от 1024 и выше. 2. Поддержка FTP-сервера в пассивном режиме Необходимо разрешить подключения извне к портам с номерами от 1024 и выше на вашем сервере. Явно нежелательно с точки зрения безопасности. 3. Поддержка FTP-клиентов в активном режиме Необходимо разрешить подключения извне к портам с номерами от 1024 и выше на клиентских машинах. Явно нежелательно с точки зрения безопасности. 4. Поддержка FTP-клиентов в пассивном режиме Необходимо разрешить клиентам открывать новые подключения во внешний мир через порты с номерами от 1024 и выше. Было бы желательно, что бы МЭ «понимал» протокол FTP, определял режим его работы и открывал бы только необходимые порты, а не весь диапазон. Анализ FTP на межсетевом экране не представляет особых трудностей, так как все команды и данные передаются в открытом виде. Команды состоят из заглавных ASCII символов, некоторые с необязательными аргументами. Команды управления, которыми обмениваются клиент и сервер отличаются от команд, доступных пользователю. Они делятся на три группы:
Рассмотрим несколько наиболее характерных команд из каждой группы Среди команд управления доступом к системе следует отметить следующие: USER. Как правило, эта команда открывает сессию FTP между клиентом и сервером. Аргументом команды является имя (идентификатор) пользователя для работы с файловой системой. Эта команда может подаваться не только в начале, но и в середине сессии, если, например, пользователь желает изменить идентификатор, от имени которого будут проводиться действия. При этом все переменные, относящиеся к старому идентификатору, освобождаются. Если во время изменения идентификатора происходит обмен данными, обмен завершается со старым идентификатором пользователя. PASS. Данная команда подается после ввода идентификатора пользователя и, в качестве аргумента содержит пароль пользователя. Напомним, что данные аутентификации FTP передаются по сети открытым текстом, поэтому для обеспечения защищенности канала пользователю необходимо предпринимать дополнительные меры. CWD. Команда позволяет пользователям работать с различными каталогами удаленной файловой системы. Аргументом команды является строка, указывающая путь каталога удаленной файловой системы, в котором желает работать пользователь. REIN. Команда реинициализации. Эта команда очищает все переменные текущего пользователя, сбрасывает параметры соединения. Если в момент подачи команды происходит передача данных, передача продолжается и завершается с прежними параметрами. QUIT. Команда закрывает управляющий канал. Если в момент подачи команды происходит передача данных, канал закрывается после окончания передачи данных. Команды управления потоком устанавливают параметры передачи данных. Все параметры, описываемые этими командами имеют значение по умолчанию, поэтому команды управления потоком используются только тогда, когда необходимо изменить значение параметров передачи, используемых по умолчанию. Команды управления потоком могут подаваться в любом порядке, но все они должны предшествовать командам FTP-сервиса. Из команд управления потоком данных следует выделить следующие: PORT. Команда назначает адрес и порт хоста, который будет использоваться как активный участник соединения по каналу передачи данных. Аргументами команды являются 32-битный IP адрес и 16-битный номер порта соединения. Эти значения разбиты на шесть 8-битных полей и представлены в десятичном виде: h1, h2, h3, h4, p1, p2, где hN - байты адреса (от старшего к младшему), а pN - байты порта (от старшего к младшему). PASV. Эта команда отправляется модулю, который будет играть пассивную роль в передаче данных (“слушать” соединение). Ответом на данную команду должна быть строка, содержащая адрес и порт хоста, находящиеся в режиме ожидания соединения в формате команды PORT — “h1, h2, h3, h4, p1, p2”. Команды TYPE, STRU, MODE определяют, соответственно, тип передаваемых данных (ASCII, Image и другие), структуру или формат передачи данных (File, Record, Page), способ передачи (Stream, Block и другие). Использование этих команд очень важно при построении взаимодействия в гетерогенных средах и весьма отличающихся операционных и файловых систем взаимодействующих хостов. Команды FTP-сервиса определяют действия, которые необходимо произвести с указанными файлами. Как правило, аргументом команд этой группы является путь к файлу. Синтаксис указанного пути должен удовлетворять требованиям формата файловой системы обработчика команды. Из команд FTP-сервиса можно выделить следующие: RETR. Эта команда указывает модулю “Программа передачи данных сервера” передать копию файла, заданного параметром этой команды, модулю передачи данных на другом конце соединения. STOR. Команда указывает модулю “Программа передачи данных сервера” принять данные по каналу передачи данных и сохранить их как файл, имя которого задано параметром этой команды. Если такой файл уже существует, он будет замещен новым, если нет, будет создан новый. Команды RNFR и RNTO должны следовать одна за другой. Первая команда содержит в качестве аргумента старое имя файла, вторая – новое. Последовательное применение этих команд переименовывает файл. ABOR. Команда предписывает серверу прервать выполнение предшествующей сервисной команды (например, передачу файла) и закрыть канал передачи данных. Команда DELE удаляет указанный файл. Команды MKD и RMD, соответственно, создают и удаляют указанный в аргументе каталог. При помощи команд LIST и NLST можно получить список файлов в указанном каталоге. Все команды FTP-протокола отправляются “Интерпретатором протокола пользователя” в текстовом виде - по одной команде в строке. Каждая строка команды – идентификатор и аргументы – заканчиваются символами Эти команды могут использоваться для «тонкой» фильтрации трафика протокола FTP.
Несмотря на очевидные проблемы, связанные со SPAM (не затребованная, мусорная массовая реклама, часто содержащая вирусы), доля которого в общем объёме почты составляет около 80%, электронная почта в Интернет продолжает оставаться достаточно популярным и востребованным сервисом. Рассмотрим основные принципы работы электронной почты. Адрес электронной почты выглядит так: почтовый_ящик@почтовый.домен, где почтовый.домен – некое доменное имя, а почтовый_ящик – имя-идентификатор корреспондента. Почтовый ящик может соответствовать одному человеку, группе людей, официальному почтовому адресу, автомату-обработчику и т.д. – форма адреса от этого не зависит, зависит только обработка. Для простоты будем считать, что почтовые ящики соответствуют конкретному человеку, то есть являются персональными. Почтовый домен – это доменное имя, для которого в системе DNS существует запись типа MX, либо запись типа A, если MX отсутствует. Компьютер, на который указывает запись MX, является почтовым сервером для данного почтового домена. Вся почта, направленная на адреса в данном почтовом домене, поступает на этот сервер, которые принимает решение о том, как дальше поступить с этой почтой. Базовая структура сообщения электронной почты определена в RFC-822. Оно состоит из «внешней части» – заголовков протокола SMTP и самого письма. Заголовок SMTPЗаголовок SMTP содержит в себе следующую информацию:
Эти поля обычно не доступны конечным пользователям и существуют только при обмене между SMTP серверами. Письмо (в терминологии протокола SMTP— 'DATA'), в свою очередь, состоит из заголовков и тела письма.
К сожалению, эта информация может быть легко подделана отправителем, что в реальности часто используется при рассылке SPAM. Поэтому использовать её в качестве признака фильтрации не представляется целесообразным. Тело письма. В теле письма находится, собственно, текст письма. Согласно стандарту, в теле письма могут находиться только символы ASCII. Поэтому при использовании национальных кодировок или различных форм представления информации (HTML, RTF, бинарные файлы) текст письма должен кодироваться по стандарту MIME (см. ниже). Как уже указывалось, основой для передачи почтовых сообщений служит протокол SMTP. Изначально SMTP содержал 14 команд, наиболее используемыми являются: HELO hostname (может использоваться EHLO) - первая команда сеанса, hostname – доменное имя вызывающего хоста (клиента). MAIL FROM: email_адрес_от_кого - обратный адрес. RCPT TO: email_адрес_кому - адрес получателя (в случае нескольких адресатов команда повторяется для каждого адресата). DATA - начало ввода текста сообщения; сервер посылает промежуточный положительный отклик 354 и рассматривает все последующие строки в качестве текста (тела) сообщения; конец ввода – строка состоящая из одной точки. При необходимости, перед текстом сообщения вводятся поля заголовка, обычно это делает почтовая программа. Каждое поле заголовка должно начинаться с новой строки. Между заголовком и текстом сообщения должна быть одна пустая строка. QUIT - конец связи. Далее появился так называемый расширенный SMTP(ESMTP). Не все серверы поддерживают команды ESMTP и каждый сервер может поддерживать какое-то свое подмножество ESMTP-команд, в том числе нестандартных. Для того, чтобы выяснить, какие дополнительный команды поддерживаются, следует вместо HELO подать команду EHLO. Конкретный перечень дополнительных команд согласовывается при установлении соединения между серверами. На первом этапе пользователь готовит письмо, используя так называемого пользовательского агента. Пользовательский агент является клиентской программой пользователя для работы с электронной почтой, его функции:
На сервере работает так называемый транспортный агент, его задача (упрощенно) выглядит так:
Сервер-отправитель связывается с сервером получателем по протоколу SMTP (сервер-отправитель играет при этом роль клиента), используя TCP, порт 25 и пытается передать ему почтовое отправление. Сервер-получатель проверяет наличие у себя соответствующего адресата, объем передаваемого сообщения, наличие места в почтовом ящике адресата, ряд проверок, связанных с борьбой со SPAM, и помещает письмо в почтовый ящик пользователя. На этом роль SMTP протокола завершена. Это сильно упрощённая модель доставки электронной почты. Она рассматривается в основном с точки зрения возможной фильтрации трафика электронной почты. Далее адресат каким-то образом должен получить письмо из своего почтового ящика. Для получения сообщений с почтового сервера и чтения писем пользователи обычно применяют почтовые клиентские программы, использующие протоколы POP3 или IMAP4. Они также используют в качестве транспортного протокол TCP, работают по технологии “клиент- сервер”. При подключении естественно требуется аутентификация пользователя, обычно с помощью ввода логина (имени пользователя) и соответствующего пароля. POP3 (Post Office Protocol - Version 3, RFC-1939). POP3-сервер прослушивает TCP-порт 110. Если клиент хочет воспользоваться услугами POP3-сервера, то устанавливает с ним TCP связь. По установлении связи POP3-сервер посылает клиенту уведомление (например, +OK POP3 server ready) и сессия переходит в фазу авторизации (см. также RFC-1734, -1957). После этого может производиться обмен командами и откликами. Команды POP3 состоят из ключевых слов (3-4 символа), за которыми могут следовать аргументы. Каждая команда завершается парой символов CR-LF. Как ключевые слова, так и аргументы могут содержать только печатаемые ASCII-символы. В качестве разделителя используются символы пробела. Каждый аргумент может содержать до 40 символов. Для целей разграничения доступа из команд POP3 можно использовать USER name, где name – характеризует почтовый ящик сервера; PASS string (string – пароль для доступа к почтовому серверу). Вся информация передаётся в открытом виде и может использоваться при фильтрации. IMAP4(Internet Message Access Protocol, Version 4, RFC-2060) IMAP4-сервер прослушивает TCP-порт 143. Это достаточно сложный протокол, он обслуживает более 20 различных команд клиента по управлению состоянием своей почты. Подробное описание всех команд и ответов IМАР4-сервера можно найти в RFC-2060. Команда LOGIN идентифицирует клиента серверу и передает пароль пользователя открытым текстом. Эта информация также может быть использована для фильтрации. Основное отличие POP3 и IMAP4 состоит в том, что POP3 ориентирован на хранение и обработку почтовых сообщений на клиентской машине. Он позволяет скачать с сервера все вновь пришедшие письма (с возможностью оставить копии на сервере). Почтовая клиентская программа позволяет сортировать письма, раскладывать по папкам, удалять и так далее. IMAP4 ориентирован на хранение и обработку почтовых сообщений непосредственно на сервере. IMAP4 позволяет управлять каталогами (папками) удаленных сообщений так же, как если бы они располагались на локальном компьютере. IMAP4 позволяет клиенту создавать, удалять и переименовывать почтовые ящики, проверять наличие новых сообщений и удалять старые. До сих пор речь шла о протоколах передачи и чтения почтовых сообщений и, соответственно, о передаваемых командах и служебной информации (заголовках почтовых сообщений). В тоже время большой интерес представляет и возможность фильтрации по признакам внутри самого письма. Изначально, в соответствии с RFC 822, в теле письма, то есть в самом тексте можно было использовать только символы US-ASCII (латинские буквы, цифры, знаки препинания, некоторые специальные символы, всего 128). Их сочетания легко можно было использовать в качестве признака фильтрации. В дальнейшем появилась так называемая расширенная таблица (еще 128 символов) и на её базе появились различные кодировки кириллического алфавита. Среди них наиболее популярной были KOI8-R, CP1251 (Windows-1251). Не останавливаясь на их особенностях, можно только сказать, что использование в качестве фильтрующих признаков русских букв (и слов соответственно) не давало хорошего результата с учетом возможности различной кодировки. По мере развития электронной почты появилась потребность передавать в почтовых сообщениях данные различных типов:
Для этих целей был предложен стандарт MIME (Multipurpose Internet Mail Extention, RFC-2045-49). Многоцелевое расширение интернет-почты (MIME) — дополняющий протокол, позволяющий передавать сообщения, используя SMTP-данные, которые не имеют вид ASCII. Расширение MIME — не почтовый протокол и не отменяет SMTP; оно только его расширяет. Модуль MIME преобразовывает данные, отличающиеся от ASCII, к виду ASCII и доставляет их SMTP-клиенту через Интернет. Сервер SMTP на приемной стороне получает данные в виде ASCII и доставляет к MIME, чтобы преобразовать данные в первоначальный вид. Можно упрощенно сказать, что MIME — это набор программного обеспечения, который преобразует данные, не представленные в ASCII, в данные ASCII и, соответственно, наоборот. MIME определяет пять заголовков, которые могут быть дополнены к исходной секции заголовков SMTP для определения параметров преобразования: MIME – Version (MIME – Версия). Content – Type (Содержание – Тип). Content — Transfer – Encoding (Содержание – Передача – Кодирование). Content – Id (Содержание – Идентификатор). Content – Description (Содержание — Описание). Заголовок "MIME-Version: 1.0". Он указывает версию MIME (в настоящий момент 1.0) и используется для обозначения того, что настоящее сообщение является не простым email-сообщением согласно RFC-822, а составлено по спецификации MIME. Наиболее интересным и полезным является дополнительный заголовок "Content-Type:", который определяет соответственно тип данных, содержащихся в сообщении (разделе сообщения) Он имеет формат:
Стандартные типы и подтипы данных можно найти по адресу http://www.iana.org/assignments/media-types/index.html Примеры text
Текстовые данные (в том числе восьмибитные); наиболее распространенные подтипы: plain (обычный текст) и html. Возможный параметр: "charset=название_кодировки_символов"; наличие параметра необязательно. (Примеры кодировок символов: us-ascii [текст в узком смысле, только семибитные символы], кириллица: koi8-r, windows-1251, iso8859-5.) Если не указан charset, считается, что это us-ascii. Пример заголовка: Content-Type: text/plain; charset=koi8-r Если заголовок "Content-Type:" отсутствует, то считается, что это Content-Type: text/plain; charset=us-ascii image Неподвижные изображения; примеры подтипов: jpeg, gif. Пример заголовка (параметры необязательны): Content-Type: image/jpeg; name="portrait.jpg" audio
Звук; примеры подтипов: mpeg, x-realaudio. Пример заголовка (параметры необязательны): Content-Type: audio/x-realaudio; name="song.ra" video Видео; примеры подтипов: mpeg, quicktime. Пример заголовка (параметры необязательны): Content-Type: video/mpeg; name="movie.mpeg" application Двоичные данные (поток байт), в общем случае предназначенные для какой-то прикладной программы и не попадающие в вышеперечисленные категории. Подтип позволяет определить, для какой именно программы предназначены данные. Определено большое число различных подтипов (например, postscipt, msword, zip, x-javascript). Если неизвестно, как интерпретировать данные, используется общий подтип octet-stream. Пример заголовка (параметры необязательны): Content-Type: application/msword; name="my_file.doc" Очевидно, что использование указанных заголовков, типов, подтипов и параметров может сделать фильтрацию более гибкой и эффективной. Нужно заметить, что многие пользователи используют популярные бесплатные почтовые службы, такие как mail.ru, yandex.ru, gmail.com и им подобные. Интерфейс таких служб строится на базе WEB сервера, доступ к которому производится стандартным образом по протоколу http (описанному ранее). Следовательно, в этом случае для фильтрации пользовательских запросов (как на отсылку, так и на чтение почты), можно использовать все приведенные выше рекомендации.
OSCAR – (Open System for Communication in Realtime) – прикладной протокол программ мгновенного обмена сообщениями в реальном времени (instant messengers). Протокол обеспечивает передачу текстовых и мультимедийных сообщений для систем ICQ и AIM. Он был создан в 1999 году компанией AOL (America Online, Inc.) в качестве альтернативы и дополнения существовавшего на тот момент протокола icq, разработанного в 1996 для первой версии ICQ-клиента израильскими программистами компании Mirabilis. Протокол способен работать со старыми и новыми ICQ-серверами вне зависимости от типа выбранного клиента. Популярными альтернативными программами-клиентами, использующими OSCAR для общения в сети ICQ являются QIP, Miranda IM, R&Q и др. На сегодняшний день не существует полной и достоверной официальной спецификации этого протокола. Для идентификации пользователей служба ICQ использует UIN (Universal Identification Number) — уникальный для каждой учётной записи номер, состоящий из 5-9 арабских цифр. Этот номер присваивается учётной записи при первичной регистрации пользователя в системе, после чего, в паре с паролем, может использоваться для аутентификации в системе. С каждой учётной записью ассоциирован статус присутствия, являющийся индикатором того, подключён пользователь к сети или нет, и готов ли он в данный момент отвечать на сообщения. После успешной авторизации клиент ICQ загружает с сервера список контактов пользователя. Контакты в списке могут быть распределены по группам, имена и количество которых изменяются пользователем. В ICQ реализована передача файлов по технологии P2P, минуя сервер. Передача файлов возможна только тогда, когда статус у получателя «В сети». Подобный способ передачи файлов может быть опасен тем, что отправитель узнает IP получателя (или наоборот) или отправит ему вредоносное программное обеспечение. Начиная же с ICQ 5, появилась возможность передавать файлы через сам сервер ICQ, который играет посредническую роль. Это необходимо в том случае, если клиент ICQ определил, что P2P-соединение установить невозможно (закрытые порты в межсетевых экранах, отсутствие персонального внешнего IP и др.). Серверную часть IM составляют следующие серверы:
Пользователь может одновременно использовать несколько клиентов на основе одного или различных движков. По идее, все сообщения и уведомления о друзьях должны отправляться на все клиенты, хотя есть некоторые правила пересылки сообщений, в соответствии с которыми пользователи, имеющие статус away или idle, могут не получить сообщения. Любое клиентское приложение IM использует протокол OSCAR для взаимодействия с выходными буферами IM для того, чтобы, например, получать списки контактов, посылать и получать сообщения. Протокол OSCAR – бинарный, то есть он использует побайтный способ передачи информации. Описание структуры состоит из основных уровней передачи – главного функционального уровня FLAP (Frame Layer Protocol), и следующего за ним уровня SNAC (Simple Network Atomic Communication), отвечающего за передачу специальных сообщений, обеспечивающих работу клиента с сервером. В рамках SNAС существуют его отдельные подгруппы – Errors, OSERVICE (группа базовых операций и типов данных, являющихся общими для множества групп и различных серверов), Permit/Deny (для изменения одноимённых установок и настроек передачи трафика, не входящего в группу сообщений) и ICBM (группа, описывающая протокольные сообщения, для взаимодействия между клиентами, организацию каналов связи и пр.) (см. рис. 1.1). Число этих подгрупп постоянно увеличивается, а сами они подвергаются существенным изменениям со стороны разработчиков с выходом каждой новой версии клиента. Многие из серверных соединений поддерживают TLS между уровнями FLAP и TCP, если требуется однократное шифрование. В большинстве случаев, бинарный поток данных формируется с использованием вышеперечисленных элементов в указанном порядке без добавочного дополнения нулевыми битами. Р Таким образом, контроль отдельных типов FLAP и SNAC может сделать фильтрацию эффективней. Разрешая или запрещая передачу данных по отдельным заголовкам этиx субпротоколов, мы можем управлять отдельными функциями или режимами работа ICQ-клиента. Протокол использует некоторые базовые типы данных, описанные ниже; это «строительные блоки» для остальных типов данных и SNACs. При шифровании или дешифровании этих типов необходимо помнить про порядок пересылки байтов (см. табл. 1.1). Таблица 1.1. Основные типы данных протокола OSCAR.
Строковые типы не заканчиваются значением NULL и хранятся в кодировке UTF8. Строка считается сжатой, если все пробелы удалены, а все буквы верхнего регистра преобразованы в нижний (см. табл. 1.2). Таблица 1.2 Строковые типы данных протокола OSCAR.
Тип данных TLV – широко распространенные структуры в протоколе OSCAR, используемые для представления динамически вводимых данных (см. табл. 1.3). Синтаксические анализаторы (также называемые парсерами) должны всегда игнорировать незнакомые тэги, чтобы не вызвать ошибку в устаревших клиентах после добавления в протокол новых элементов. Возможные значения тэгов определяются тем, где именно в протоколе находится TVL, эти возможные значения принадлежат классу TVL. Вообще говоря, термины «тип» и «тэг» часто используются как синонимы, но в данном документе под словом «тэг» подразумевается целочисленное значение, связанное с TVL, а под словом «тип» - тип данных, соответствующий этому значению. Таблица 1.3. Тип данных TVL
TLV обычно используются в массивах структур TVL, позволяя легко расширять протокол. Использование только одной TLV без массива не приносит большой выгоды, т.к. это позволяет описать только один элемент. Есть два общих метода добавления массива TLV к типам данных и SNACs. Также существует дополнительный метод добавления массива TLV к SNACs. Наиболее часто встречающийся – tlvBlock, который представляет из себя число TLV типа u16, за которым следуют сами TLV (см. табл. 1.4). Менее распространенный – tlvBlock, который вместо числа TLV представляет собой суммарный размер всех TLV. Третий (возможный только в SNACs) – tlvRestBlock, который сообщает, что все последующие байты в SNAC – TLV. Таблица 1.4. tlvBlock
Несколько углубимся в то, как реализована передача данных в протоколе OSCAR. Вся информация, которой обмениваются клиент и сервер, упаковывается в, так называемые, FLAP-пакеты. Каждый из них имеет обязательные поля: Command Start, Channel ID, Sequence Number, Data Length и Data. Command Start имеет длину один байт – это заголовок пакета. Channel ID – идентификатор канала, который обозначает разные виды каналов, к которым может относиться пакет, будь то канал соединения или канал данных и т.д. Чаще всего это именно канал данных. Длина этого поля также один байт. Sequence Number – это анахронизм, оставшийся от UDP, когда порядковый номер пакета с каждым следующим посланным пакетом увеличивался на единицу для обеспечения целостности передаваемых данных, что сегодня делает TCP. Data Length – длина поля данных. Data – это просто передаваемые данные, длина произвольная, но ограниченная двумя байтами. Обычно процесс работы с ICQ начинается с подключения к серверу login.icq.com через порт 5190. Сервер принимает UIN и пароль, передавая FLAP-пакет со значением Data, равным единице. В ICQ используется формат записи данных TLV. TLV является аббревиатурой от Type, Length, Value. В TLV упаковываются почти все данные, включая сами сообщения, однако напрямую эти пакеты используются редко. Обычно они упакованы в еще один вид пакетов – SNAC. SNAC-пакеты используются исключительно в канале данных. Внутри этого пакета есть следующие поля: FamilyId (тип Word) – идентификатор типа данных, SubtypeId (Word) – идентификатор подтипа, Flags[0] и Flags[1] (byte) – служебные флаги, RequestId (dword) – идентификатор запроса и SNAC Data (произвольная длина) – сами данные. Следовательно, SNAC-пакет записывается в поле Data FLAP-пакета, а TLV-пакет – в поле Data SNAC-пакета. Структура данных, передаваемых по протоколу OSCAR, не является примитивной. Более глубокое описание этой структуры гораздо сложнее: каждой возможной комбинации FamilyID и SubTypeID для SNAC-пакетов соответствуют разнообразные вложенные TLV-пакеты, которые могут быть разными даже для одинаковых SNAC`ов. Все данные, которые были получены в ходе экспериментов, в том числе: основные идеи использования различных типов данных в протоколе OSCAR, распределение UIN, структура возникающих ошибок, доскональное описание FLAP и SNAC уровней, а также описание наиболее значимых групп SNAC не были включены в данное пособие, чтобы избежать излишней информативности этих подробностей, т.к. они не являются определяющими в дальнейшем направлении работы. Задача фильтрации трафика подобного протокола не представляется элементарной. Зависимость расположения типов байт от динамики развития общения неоднозначна. Значительную помеху для осуществления фильтрации представляют широко используемые данные типа TLV, которые не имеют регулярной структуры. Однако, обобщая данные, полученные в результате эксперимента, приходим к выводу, что общая схема пакета, используемого протоколом такова (см. табл. 1.5.): Таблица 1.5. Общая схема пакета протокола OSCAR
В указанной схеме, достаточно много TLV полей, имеющих нерегулярную структуру и отличающихся непостоянными смещениями относительно заголовков. Размер включённой в пакет «полезной нагрузки», смысловых данных, напрямую зависит от значения поля Length: Size = ({Lenth}+4) байта. Помещённые за полем Length данные располагаются в строгом порядке следования, однако их размеры нельзя определить заранее. Для осуществления гибкой (эффективной) фильтрации сообщений данного протокола с указанием известных смещений необходимо уметь считывать значение поля Length, а также значения полей Length всех используемых структур TLV пакета. Таким образом, в общем случае, для всех полей, кроме полей FLAP заголовка, мы не можем получить конкретное значение смещения от начала прикладных данных.
BitTorrent – система совместной передачи файлов на основе пиринговой сети, разработанная в 2001 году Брэмом Коэном. Доля интернет-трафика, приходящаяся на BitTorrent, крупнейшая среди долей прочих протоколов общемирового трафика. Система функционирует за счёт совокупной работы нескольких протоколов, главным из которых является одноимённый протокол BitTorrent (bittorrent protocol). Принцип работы BitTorrent таков: нагрузка на распространителя файла уменьшается благодаря тому, что клиенты начинают обмениваться данными сразу же, даже если файл не докачен ими до конца. Основными преимуществами использования данной сети являются:
Однако использование сети BitTorrent кроет за собой и ряд существенных недостатков:
В торрент-среде распространена своя специфическая терминология:
Можно условно выделить четыре основных сегмента функционирования BitTorrent приложений, которые необходимо рассматривать отдельно – это:
Перед началом скачивания клиент подсоединяется к трекеру, сообщает ему свой адрес и хеш-сумму запрашиваемого файла, на что в ответ клиент получает адреса других клиентов, скачивающих или раздающих этот же файл. Далее клиент периодически информирует трекер о ходе процесса и получает обновлённый список адресов. Клиенты соединяются друг с другом и обмениваются сегментами (блоками) файлов без непосредственного участия трекера, который лишь регулярно обновляет информацию о подключившихся к обмену клиентах и другую статистическую информацию. Для эффективной работы сети BitTorrent необходимо, чтобы как можно больше клиентов были способны принимать входящие соединения. Неправильная настройка NAT или сетевого экрана могут этому помешать. При соединении клиенты сразу обмениваются информацией об имеющихся у них сегментах. Клиент, желающий скачать сегмент, посылает запрос и, если второй клиент готов отдавать, получает этот сегмент. После этого клиент проверяет контрольную сумму сегмента и оповещает всех присоединённых пиров о наличии у него этого сегмента. Каждый клиент имеет возможность временно блокировать отдачу другому клиенту (choke). Это делается для более эффективного использования канала отдачи. Кроме того, при выборе — кого разблокировать, предпочтение отдаётся пирам, которые сами передали этому клиенту много сегментов. Обмен сегментами ведётся по этому принципу симметрично в двух направлениях и в случайном порядке. Клиенты периодически сообщают друг другу об имеющихся у них сегментах. Обмен данными начинается, когда обе стороны в нём заинтересованы, то есть каждая из сторон имеет сегменты, которых нет у другой. Количество переданных сегментов подсчитывается, и если одна из сторон обнаруживает, что передаёт в среднем больше, чем принимает, она блокирует (choke) отдачу. Таким образом, в протокол заложена защита от личеров. При получении полного файла клиент переходит в специальный режим работы, в котором он только отдаёт данные (становится сидом). Клиенты периодически информируют трекер об изменениях в состоянии закачек и обновляют списки IP-адресов. По умолчанию клиенты соединяются с трекером по протоколу TCP. Входящий порт трекера: 6969. Клиенты соединяются друг с другом, используя протоколы TCP или UDP. Входящие порты клиентов: 6881—6889. Номера портов не фиксированы в спецификации протокола и могут изменяться при необходимости. Более того, большинство трекеров используют обычный для http порт 80, а среди клиентов чаще выбирается случайный входящий порт. В торрент-системе активно используются DHT (Distributed Hash Table — «распределённая хэш-таблица») — это класс децентрализованных распределённых систем, которые обеспечивают поисковый сервис, похожий по принципу работы на таблицу хэшей, и имеют структуру ассоциативного массива: (ключ, значение), хранящиеся в DHT, а каждый участвующий узел может рационально искать значение, ассоциированное с данным именем. Ответственность за поддержку связи между именем и значением распределяется между узлами, таким образом изменение набора участников является причиной минимального количества разрывов. Это позволяет легко масштабировать DHT и постоянно отслеживать добавление/удаление узлов и ошибки в их работе. DHT-сеть в BitTorrent-клиентах использует протокол UDP. Кроме того, протокол UDP используется UDP-трекерами для соединения клиентов друг с другом через UDP NAT Traversal. Таким образом, простейшие методы блокирования портов здесь совершенно не применимы, и фильтрация, если и может быть осуществлена, то только по конкретным сигнатурам протокола. Для каждого распространяемого файла создаётся файл метаданных с расширением .torrent, который содержит следующую информацию:
Файл метаданных является хэш-таблицей в Bencode формате. Файлы метаданных могут распространяться через любые каналы связи: они (или ссылки на них) могут выкладываться на веб-серверах, размещаться на домашних страницах пользователей сети, рассылаться по электронной почте, публиковаться в блогах или новостных лентах RSS. Получив каким-либо образом файл с метаданными, клиент может начинать скачивание. Существует огромное количество различных версий клиентов, работающих с BitTorrent, каждая из которых в разной степени отличается друг от друга. Традиционно BitTorrent, как и большинство P2P-приложений использовало протокол TCP для обмена данными. Однако новые torrent-клиенты, начиная с 2010 года, стали использовать новый протокол uTP, основанный на UDP. μTP (Micro Transport Protocol) — переимплементация (переопределение) TCP на основе протокола UDP с изменённым контролем за переполнением, который реагирует быстрее, чем соответствующий алгоритм в TCP. Таким образом, при увеличении загрузки канала μTP первым замедляется и отдаёт канал другим приложениям. Передача файлов в торрент-сетях (а это более 50% мирового трафика) постепенно перешла с протокола TCP на протокол UDP. В версии BitTorrent 2.0 впервые появилась поддержка UDP-трекеров. Для трекера в целом TCP избыточен и требует много лишних ресурсов, поэтому для открытых трекеров переход на UDP обоснован. Например, с начала 2010 года трекер anirena плохо работает по TCP и отвечает далеко не с первого раза, использование DHT запрещёно, а UDP-трекер прекрасно работает. Однако для закрытых трекеров он не подходит, т.к. не позволяет послать passkey, чтобы идентифицировать таким образом качающего. Здесь подразумевается UDP для трекера, а не UDP для обмена данными между пирами (это абсолютно разные вещи, никак друг с другом не связанные). Также в этой версии протокола впервые появился метод обхода некоторых NAT (STUN), что помогло присоединяться большему числу NAT-пользователей. Основная часть информации в протоколе передаётся в формате Bencode, это способ используется для хранения и передачи данных в сжатом формате. Он поддерживает следующие типы: байтовые строки (byte strings), целые числа (integers), списки (lists) и хэш-таблицы (словари) (dictionaries). Байтовые строки кодируются следующим образом: <длина строки, кодируемая в десятичной ASCII, в которой есть только символы цифр>:<строковые данные>. Стоит отметить, что здесь не используются фиксированные начальный и конечный разделители. Целые числа кодируются следующим образом: i<целое число, закодированное в десятичной ASCII>e. Начальный символ i и конечный е - начальный и конечный разделители соответственно. Встречаются закодированные отрицательные числа, такие как i-3e. Целому числу не всегда может предшествовать префикс, состоящий из нулей, как например i04e. Вместе с тем, i0e – это используется в качестве нуля. Списки кодируются следующим образом: l Хэш-таблицы (словари) кодируются следующим образом: d Организация гибкой (эффективной) фильтрации BitTorrent подразумевает контроль этой системы по её отдельных элементам, а именно:
Результаты исследований выявили три различных направления для реализации подобной фильтрации включающей в себя фильтрацию на основе контроля метаданных, фильтрацию сообщений протоколов работающих с торрент-трекером и фильтрацию собственно BitTorrent протокола, основанную на обмене сообщениями между пирами. Для фильтрации на основе контроля метаданных существуют простейшие разработки, сформулированы основные критерии и предпосылки. Важнейшим преимуществом такого подхода стало большое число контролируемых функций и режимов работы BitTorrent. Однако данная система на данный момент требует более детальной проверки и тщательного анализа результатов, так как работает до момента получения метаданных и совершенно неэффективна для уже работающей bittorrent-сети. Фильтрация протоколов системы BitTorrent на основе http признана устаревшей, однако для неё существуют некоторые перспективы. Это либо контроль генерации случайных составляющих некоторых параметров приложения, либо (что более реально, но более трудоёмко) проведение детального дизассемблирования элементов всех протоколов. Система фильтрации собственно bittorrent protocol более надёжна, однако на данный момент она охватывает достаточно небольшое число функций и не охватывает все особенности функционирования клиента. Для неё необходимо проводить серию дизассемблирований, а также изучать особенности поведения и частоты возникновения конкретных полей и заголовков в пакетах. Существуют гипотетические предпосылки, указывающие на зависимость появления некоторых элементов протокола от таких параметров, как количество пиров, участвующих в обмене и скорости работы клиента. Поведение трафика в системе BitTorrent представляет собой достаточно упорядоченный процесс со сложной структурой контроля и высокой степенью устойчивостью к каким-либо изменениям и высокой степенью живучести. Сложностью для осуществления фильтрации также представляется тот факт, что система `паразитирует` на стандартных протоколах, подведя их возможности под свои собственные нужды. И закрывая отдельные элементы торрент-сетей, мы невольно запрещаем работу всего остального.
Skype – бесплатная проприетарная система обеспечения шифрованной голосовой связи и видео-связи через компьютерные сети (VoIP), поддерживающая платные услуги связи с абонентами традиционных телефонных сетей. Программа Skype поддерживает многопользовательский чат без поддержки именованных каналов (в отличии от ICQ или IRC). Официально для обеспечения качественной голосовой связи требуется широкополосное Интернет-соединение, однако на практике достаточно использовать мобильное соединение edge-уровня при полностью свободном канале. Неофициальных Skype-клиентов на данный момент не существует в связи с его закрытостью. В отличие от многих других программ IP-телефонии, для передачи данных Skype первоначально использовал P2P-архитектуру. Каталог пользователей Skype распределён по компьютерам пользователей сети Skype, что позволяет сети легко масштабироваться до очень больших размеров (в данный момент более 100 миллионов пользователей, 10-15 миллионов онлайн) без дорогой инфраструктуры централизованных серверов. Кроме того, Skype может маршрутизировать звонки через компьютеры других пользователей. Это позволяет соединяться друг с другом пользователям, находящимися за NAT или межсетевым экраном, однако создаёт дополнительную нагрузку на компьютеры и каналы пользователей, подключённых к Интернет напрямую. Единственным центральным элементом для Skype является сервер идентификации, на котором хранятся учётные записи пользователей и резервные копии их списков контактов. Центральный сервер нужен только для установки связи. После того, как связь установлена, компьютеры пересылают голосовые данные напрямую друг другу (если между ними есть прямая связь), или через Skype-посредник (суперузел — компьютер, у которого есть внешний IP-адрес и открыт TCP-порт для Skype). В частности, если два компьютера, находящиеся внутри одной локальной сети, установили между собой Skype-соединение, то связь с Интернетом можно прервать, и разговор будет продолжаться вплоть до его завершения пользователями или какого-либо сбоя связи внутри локальной сети. Однако, вследствие неоднократных проблем с надёжностью сети, Microsoft без уведомления пользователей перевел все суперузлы на собственные серверы (стать им стало невозможно), так что от концепции Р2Р на данный момент система перешла к архитектуре более близкой к клиент-серверной. Система Skype является чрезвычайно устойчивой к различным внешним воздействиям. Даже при полном запрете протокола UDP эта программа функционирует в особом режиме схожем с работой вредоносных троянских программ. Skype проходит через межсетевые экрана используя специальные протоколы (STUN и TURN). Однако, на самом деле Skype — обычный VoIP-клиент с поддержкой усовершенствованного STUN-подобного протокола. При установке соединения между узлами данные шифруются при помощи AES-256, для передачи ключа которого, в свою очередь, используется 1024-битный ключ RSA. Открытые ключи пользователей сертифицируются центральным сервером Skype при входе в систему с использованием 1536 или 2048-битных сертификатов RSA. Также Skype прекрасно работает через TOR, систему анонимных сетевых маршрутизаций, защищённых от прослушивания. А в дополнении к внутреннему закрытому шифрованию Skype может запускаться через сверхустойчивую анонимную оверлейную I2P-сеть, где дополнительно будет зашифрован четырёхуровневым шифрованием самой сети. Подобная закрытость является предметом обсуждения среди спецслужб в связи с невозможность его прослушивания и перехвата разговоров. Единственные известные случаи перехватов осуществлялись с помощью троянских программ, берущих звук непосредственно с микрофонов до использования внутреннего шифрования. Взлом исполняемого файла Skype с целью получения информации о его функционировании для последующего контроля представляет собой чрезвычайно сложную задачу. Он содержит ряд средств и механизмов, противодействующих анализу с использованием различных инструментальных средств, таких как отладчики, дамперы, дизассемблеры и т.д.). Требуемые для его анализа временные и технические ресурсы весьма велики. Первые сложности возникают при работе с исходным двоичным файлом, который целиком зашифрован и расшифровывается по мере загрузки в память. Любое несанкционированное воздействие, распознанное внутренними механизмами Skype, приводит к сбросу исполняемого кода до начального состояния и полной очистки результатов его выполнения. Все прикладные функции вызываются по мере процесса распаковки. Многие функции проверки и вызова исполняемых элементов задаются случайно, на основе данных от внутренних генераторов, и выполняются при использовании различных криптографических сигнатур, полученных с полиморфных генераторов, генерирующих и смешивающих случайные команды (в том числе и пустые) со значимыми. Каждый вызов функции осуществляется через динамически генерируемый указатель адреса, обработанный обфусцирующим блоком для усложнения кода. Основным приёмом передачи управления для Skype являются структурные исключения. В этих случаях система модифицирует регистры памяти, выходит на исключение (фактически, прерывание) и переходит на выполнения кода с прерванного сегмента или передаёт его в случайное место. Это стратегическое преимущество велико, но может быть снято путём подбора корректных отладчиков. Протокол взаимодействия между Skype-клиентами полностью недокументирован, поэтому все известные данные о нем были получены эмпирическими методами: дизассемблирования Skype-клиентов, анализа перехваченного сетевого трафика и т.д. Поскольку существует огромное множество версий Skype-клиентов, существенно отличающихся между собой, то описание протокола может содержать неточности для различных версий. При запуске Skype-клиент открывает TCP и UDP порты, номера которых случайным образом задаются при инсталляции и могут быть в любой момент изменены через диалог конфигурации, что затрудняет блокирование Skype-трафика на межсетевом экране. Помимо этого, Skype открывает 80 (HTTP) и 443 (HTTP-over-TLS) порты, однако их блокировка не сказывается на полноценном функционировании системы. Поиск функциональных сигнатур в трафике Skype осложняется использованием различных встроенных технологий шифрования и обфускации, подвергающихся постоянным модификациям. Идентификация и гибкая (эффективная) фильтрация трафика Skype на сегодняшний день серьёзно затруднена из-за всех вышеперечисленных технологий, используемых в этой системе. Доступных, универсальных и актуальных способов контроля Skype неизвестно. Разработчики Skype предостерегают администраторов от попыток выявления и блокирования его трафика. Можно перечислить ряд решений, в той или иной степени решающих проблему фильтрации Skype, по большей степени основанных на использовании известных незашифрованных данных. Например, каждое UDP-соединение Skype использует открытый протокол для получения публичных IP-адресов super-узлов, что свободно определяется анализатором трафика. А TCP-соединение использует один и тот же RC4 поток дважды, что позволяет восстанавливать первые 10 байт ключа, расшифровав часть постоянных полей заголовков протокола Skype. Распознать и заблокировать UDP-трафик гораздо проще: каждый фрейм начинается с двухбайтового идентификационного номера (ID) и типа пакета (payload). В UDP пакет вложен обфусцированный 39-байтный NAck-пакет, содержащий следующие данные:
Таким образом, чтобы заблокировать UDP-трафик, генерируемый Skype, достаточно запретить такой тип пакетов. Вторым шагом к полному запрету Skype является блокировка протокола TCP. Заголовки входящих IP-пакетов, относящиеся к протоколу обмена SSL-ключами (SSL key-exchange packets) содержат нехарактерный для обычных приложений идентификатор 170301h, возвращаемый в ответ на запрос с идентификатором 160301h (стандартный SSL версии 3.1). Таким образом, блокирование всех входящих пакетов, содержащих в заголовке 170301h серьёзно скажется на Skype и текущие версии потеряют работоспособность. жүктеу/скачать 454 Kb. Достарыңызбен бөлісу:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
