Коммуникационный канал и процессор связи




НазваниеКоммуникационный канал и процессор связи
страница26/29
Дата конвертации08.01.2013
Размер3.44 Mb.
ТипДокументы
1   ...   21   22   23   24   25   26   27   28   29

Сетезависимые протоколы


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

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

Три верхних уровня сеансовый, уровень представления и прикладной ориентированы на приложения и мало зависят от технических особенностей построения сети. На протоколы этих уровней не влияют никакие изменения в топологии сети, замена оборудования или переход на другую сетевую технологию. Так, переход от Ethernet на высокоскоростную технологию 100VG-AnyLAN не потребует никаких изменений в программных средствах, реализующих функции прикладного, представительного и сеансового уровней.

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

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

  • либо только на физическом уровне (повторитель);

  • либо на физическом и канальном уровнях (мост);

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

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


2. Почтовые протоколы Internet: POP3, SMTP, и IMAP.


Пересылка писем

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


SMTP — простой протокол электронной почты

В Интернете для доставки электронной почты машина-источник устанавливает TCP-соединение с портом 25 машины-приемника. Этот порт прослушивается поч­товым демоном, и их общение происходит с помощью протокола SMTP (Simple Mail Transfer Protocol — простой протокол электронной почты). Этот демон при­нимает входящие соединения и копирует сообщения из них в соответствующие почтовые ящики. Если письмо невозможно доставить, отправителю возвращает­ся сообщение об ошибке, содержащее первую часть этого письма.

Протокол SMTP представляет собой простой ASCII-протокол. Установив TCP-соединение с портом 25, передающая машина, выступающая в роли кли­ента, ждет запроса принимающей машины, работающей в режиме сервера. Сер­вер начинает диалог с того, что посылает текстовую строку, содержащую его идентификатор и сообщающую о его готовности (или неготовности) к приему почты. Если сервер не готов, клиент разрывает соединение и повторяет попыт­ку позднее.

Если сервер готов принимать почту, клиент объявляет, от кого поступила поч­та и кому она предназначается. Если получатель почты существует, сервер дает клиенту добро на пересылку сообщения. Затем клиент посылает сообщение, а сервер подтверждает его получение. Контрольные суммы не проверяются, так как транспортный протокол TCP обеспечивает надежный байтовый поток. Если у отправителя есть еще почта, она также отправляется. После передачи всей поч­ты в обоих направлениях соединение разрывается. Пример диалога клиента и сервера при передаче сообщения из листинга 7.2 показан в листинге 7.3. Строки, посланные клиентом, помечены буквой С; а посланные сервером — S:.


Листинг 7.3. Передача сообщения от elinor@abc.com для carolyn@xyz.com

S: 220 xyz.com служба SMTP готова

С: HELO abc.com

S: 250 xyz.com приветствует abc.com

С: MAIL FROM:

S: 250 подтверждаю отправителя

С: RCPT TO:

S: 250 подтверждаю получателя

С: DATA

S: 354 Отправляйте письмо; конец письма обозначается строкой, состоящей из символа "."

С: From: elinor@abc.com

С: То: carolyn@xyz.com

С: MIME-Version: 1.0

С: Message-Id: <0704760941.AA00747@abc.com>

С: Content-Type: multipart/alternative; boundary=qwertyuiopasdfghjklzxcvbnm

С: Subject: Земля обошла вокруг Солнца целое число раз

С:

С: Это преамбула. Пользовательский агент игнорирует ее. Ку-ку.

С:

С: --qwertyuiopasdfghjklzxcvbnm

С: Content-Type: text/richtext

C:

С: Happy birthday to you

С: Happy birthday to you

C: Happy birthday dear Carolyn

C: Happy birthday to you

C:

C: --qwertyuiopasdfghjklzxcvbnm

C: Content-Type: message/external-body;

С: access-type= "anon-ftp" :

С: site= "bicycle.abc.com":

С: directory="pub";

С: name="birthday.snd"

С:

С: content-type: audio/basic

С: content-transfer-encoding: base64

C: --qwertyuiopasdfghjklzxcvbnm

C:

S: 250 сообщение принято

С: QUIT

S: 221 xyz.com разрываю соединение


Несколько комментариев к листингу 7.3. Сначала клиент, естественно, посы­лает приветствие серверу. Таким образом, первая команда клиента выглядит как HELO, что представляет собой наиболее удачный из двух вариантов сокращения слова HELLO до четырех символов. Зачем все эти команды было нужно сокра­щать до четырех букв, сейчас уже никто не помнит.

В нашем примере сообщение должно быть послано только одному получателю, поэтому используется только одна команда RCPT (сокращение от слова recipi­ent — получатель). Использование этой команды несколько раз позволяет посы­лать одно сообщение нескольким получателям. Каждое из них подтверждается или отвергается индивидуально. Несмотря на то, что попытки пересылки сооб­щения некоторым получателям оказываются неудачными (например, из-за от­сутствия адресатов), это сообщение все равно может быть доставлено остальным адресатам, числящимся в списке рассылки.

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

Чтобы лучше понять, как работают SMTP и другие рассмотренные в этой гла­ве протоколы, попробуйте сами поработать с ними. В любом случае, для начала найдите машину, подключенную к Интернету. В системе UNIX наберите в ко­мандной строке:


telnet mail.isp.com 25


подставив вместо mail.isp.com DNS-имя почтового сервера провайдера. В системе Windows щелкните на кнопке Пуск, затем на кнопке Выполнить и наберите коман­ду в диалоговом окне. В результате выполнения этой команды будет установлено telnet-соединение (то есть соединение TCP) с портом 25 данной машины. Как было показано в табл. 6.3, порт 25 является SMTP-портом. В ответ на введенную команду вы получите что-то вроде этого:


Trying 192.30.200.66...

Connected to mail.isp.com

Escape character is

220 mail.isp.com Smail #74 ready at Thu, 25 Sept 2002 13:26 +0200


Первые три строки посылаются telnet и поясняют для вас происходящее. По­следняя строка посылается сервером SMTP удаленной машины и сообщает о готовности к общению с вашей машиной и приему почты. Чтобы узнать о доступ­ных командах, наберите


HELP


Начиная с этого момента, возможен обмен последовательностями команд, по­казанными в листинге 7.3. Начинаться общение должно с команды клиента HELO.

Стоит отметить, что использование строк ASCII-текста в качестве команд не случайно. Большинство протоколов Интернета работают именно таким образом. Применение ASCII-текста упрощает тестирование и отладку протоколов. Тести­рование можно производить, набирая команды вручную, как было показано ра­нее. Легко читаются выведенные в ответ сообщения.

Несмотря на то, что протокол SMTP определен довольно четко, все же могут возникать определенные проблемы. Одна из них связана с длиной сообщений. Некоторые старые реализации не поддерживали сообщения длиннее 64 Кбайт. Еще одна проблема связана с тайм-аутами. Если таймеры клиента и сервера на­строены на разное время ожидания, один из них может внезапно разорвать со­единение, в то время как противоположная сторона будет продолжать передачу. Наконец, иногда могут возникать бесконечные «почтовые штормы». Например, если хост 1 хранит список рассылки А, а хост 2 — список рассылки В и они со­держат записи друг о друге, то письмо, посланное по одному из списков, будет создавать бесконечный объем трафика, пока кто-нибудь не заметит это.

Для решения некоторых из этих проблем был разработан расширенный про­токол SMTP, ESMTP. Он описан в RFC 2821. Клиенты, желающие использовать его, должны начинать сессию связи с посылки приветствия EHLO вместо HELO. Ес­ли команда не принимается сервером, значит, сервер поддерживает только обыч­ный протокол SMTP и клиенту следует работать в обычном режиме. Если же EHLO принято, значит, установлена сессия ESMTP и возможна работа с новыми параметрами и командами.


Доставка сообщений

До сих пор мы предполагали, что все пользователи работают на машинах, способ­ных посылать и получать электронную почту. Как мы уже знаем, электронная почта доставляется, когда отправитель устанавливает TCP-соединение с получа­телем и посылает по нему сообщения. Такая модель прекрасно работала тогда, когда все хосты сети ARPANET (а позднее — Интернет) были, по сути, постоянно на линии и могли принимать ТСР-соединения.

Однако с появлением пользователей, связывающихся с провайдерами с помо­щью модема, такой подход перестал оправдывать себя. Проблема вот в чем: что будет, если Элинор захочет отправить письмо Кэролайн, а та в данный момент не работает в Интернете? Получается, что Элинор не сможет установить ТСР-соединение с Кэролайн, следовательно, невозможно будет запустить протокол SMTP, и Кэролайн так и не получит поздравление с днем рождения.

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


РОРЗ

К сожалению, такое решение создает новую проблему: как пользователю забрать свою почту у агента передачи сообщений провайдера? Ответ таков: следует соз­дать специальный протокол, который позволил бы пользовательскому агенту (на машине клиента) соединиться с агентом передачи сообщений провайдера (на ма­шине провайдера) и скопировать хранящуюся для него почту. Одним из таких протоколов является РОРЗ (Post Office Protocol v. 3 — почтовый протокол, 3-я версия), определенный в документе RFC 1939.

Ситуация, при которой доставка осуществляется в условиях постоянного со­единения с Интернетом отправителя и получателя, показана на рис. 7.5, а. Ил­люстрация ситуации, в которой отправитель находится в текущий момент на ли­нии, а приемник — нет, приведена на рис. 7.5, б.





Рис. 7.5. Отправка и прием почты, когда приемник постоянно

находится в подключенном состоянии и пользовательский агент

работает на одной машине с агентом передачи сообщений (а);

прием почты при модемном соединении получателя

с провайдером (б)


Протокол РОРЗ начинает свою работу, когда пользователь запускает почто­вый редактор. Последний дозванивается до провайдера (если только машина уже не находится в подключенном состоянии) и устанавливает TCP-соединение с аген­том передачи сообщений с использованием порта 110. После установки соедине­ния протокол РОРЗ проходит три последовательных состояния.

1. Авторизация.

2. Транзакции.

3. Обновление.

Авторизация связана с процессом входа пользователя в систему. В состоянии транзакций пользователь забирает свою почту и может пометить ее для удале­ния из почтового ящика. В состоянии обновления происходит удаление поме­ченной корреспонденции.

Можно посмотреть, как все это происходит, набрав команду вида


telnet mail.isp.com 110,


где mail.isp.com следует заменить на DNS-имя почтового сервера провайдера. Telnet устанавливает TCP-соединение с портом 110, прослушиваемым РОРЗ-сервером. После установки TCP-соединения сервер посылает ASCII-сообщение, объявляя о своем присутствии. Обычно оно начинается с +0К, затем следует комментарий. Возможный сценарий после установки TCP-соединения показан в листинге 7.4. Как и раньше, строки, начинающиеся с С:, говорят о том, что данная команда ис­ходит от клиента (пользователя), а начинающиеся с S: — что это сообщения сер­вера (агента передачи сообщений на машине провайдера).


Листинг 7.4. Получение трех сообщений по протоколу РОРЗ

S: +0K РОРЗ-сервер готов

С: USER carolyn

S: +0K

С: PASS vegetables

S: OK вход в систему произведен

С: LIST

S: 1 2505

S: 2 14302

S: 3 8122

S: .

C: RETR 1

S: (отправляет сообщение 1)

С: DELE 1

С: RETR 2

S: (отправляет сообщение 2)

С: DELE 2

С: RETR 3

S: (отправляет сообщение 3)

С: DELE 3

С: QUIT

S: +0K Конец соединения с РОРЗ-сервером

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

После этого пользователь может запросить сообщения командой RETR и поме­тить их для удаления командой DELE. После получения (и, возможно, установки меток удаления) всех писем пользователь посылает команду QUIT для заверше­ния состояния транзакций и входа в состояние обновления. После удаления сер­вером всех сообщений он посылает ответ и разрывает ТСР-соединение.

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

Теперь подведем небольшие итоги того, как происходит работа с электронной почтой клиентов провайдера. Элинор создает сообщение для Кэролайн с помо­щью редактора электронной почты (то есть пользовательского агента) и щелкает на значке, чтобы отослать его. Программа передает письмо агенту передачи сообще­ний на хосте Элинор. Агент передачи сообщений видит, что письмо адресова­но carolyn@xyz.com, и использует DNS для поиска записи MX для xyz.com (где xyz.com — провайдер Кэролайн). В ответ на запрос возвращается DNS-имя поч­тового сервера xyz.com. Агент передачи сообщений после этого снова обращается к DNS (например, используя gethostbyname): на этот раз ему нужно найти IP-ад­рес этой машины. Затем с помощью порта 25 найденной машины устанавливает­ся TCP-соединение с SMTP-сервером. Передавая команды SMTP, аналогичные показанным в листинге 7.3, агент пересылает сообщение в почтовый ящик для Кэролайн и разрывает ТСР-соединение.

Через некоторое время Кэролайн загружает свой компьютер, соединяется с провайдером и запускает программу электронной почты. Та устанавливает ТСР-соединение через порт ПО РОРЗ-сервера, работающего на машине провайдера. Имя DNS или IP-адрес этой машины обычно указывается при установке про­граммы электронной почты либо его получают у провайдера. После установки TCP-соединения почтовая программа Кэролайн запускает протокол РОРЗ для копирования содержимого почтового ящика на локальный жесткий диск. При этом происходит обмен командами, аналогичными показанным в листинге 7.4. По окончании передачи электронной почты ТСР-соединение разрывается. На самом деле в тот же момент можно разорвать и соединение с провайдером, по­скольку вся почта уже находится на жестком диске у Кэролайн. Конечно, чтобы отправить ответ на письма, Кэролайн придется снова соединяться с провайде­ром, поэтому не всегда пользователи разрывают соединение сразу после загруз­ки почты.

IMAP

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

Это неудобство привело к созданию альтернативного протокола доставки со­общений, IMAP (Interactive Mail Access Protocol — протокол интерактивного доступа к электронной почте), определенного в RFC 2060. В отличие от протоко­ла РОРЗ, который подразумевает, что пользователь будет очищать почтовый ящик после каждого контакта с провайдером и будет работать с почтой в отклю­ченном режиме, протокол ШАР предполагает, что вся почта будет оставаться в почтовых ящиках на сервере неограниченно долго. IMAP обладает широким на­бором механизмов для чтения сообщений или даже частей сообщений. Такое свой­ство полезно при использовании медленных модемов, поскольку можно про­честь только текстовую часть письма, к которому приложены большие видео- и аудиофрагменты. Поскольку основное предположение состоит в том, что пользо­ватель не будет копировать на свой компьютер письма, в ШАР входят также ин­струменты для создания, удаления и других видов управления почтовыми ящика­ми, размещающимися на сервере. Таким образом, пользователь может завести собственный почтовый ящик для каждого лица, с которым ведется переписка, и переносить сообщения из почтового ящика для всех входящих писем в эти пер­сональные ящики.

Протокол ШАР обладает разнообразными возможностями, например, способ­ностью упорядочивать почту не по порядку ее поступления, как показано в табл. 7.3, а по атрибутам писем (например, «сначала дайте мне письмо от Бобби»). В отли­чие от РОРЗ, IMAP может заниматься как доставкой исходящей почты от поль­зователя в направлении места назначения, так и доставлять входящую почту пользователя.

В целом стиль протокола ШАР подобен РОРЗ, пример работы, которого по­казан в листинге 7.4. Различаются они количеством команд — в ШАР их десят­ки. Сервер ШАР прослушивает порт 143. Сравнение протоколов РОРЗ и ШАР приведено в табл. 7.8. Следует заметить, что не все провайдеры и не все програм­мы работы с электронной почтой поддерживают оба протокола. Поэтому, выби­рая программу и провайдера, следует выяснить, могут ли они работать хоть с од­ним из этих протоколов, и если да, то с какими именно протоколами.


Тема 23

Обеспечение безопасности и защиты информации.

2 часа




Основные меры по обеспечению безопасности.

Брэндмауэры.

Технологии шифрования.


Защита соединений


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

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


IPsec


Проблемная группа IETF в течение многих лет мирилась с отсутствием безопас­ности в Интернете. Обеспечить ее было действительно непросто, и прежде всего потому, что разгорелись жаркие споры вокруг того, какую часть Интернета сле­дует, собственно, защищать. Большинство экспертов по вопросам безопасности уверены в том, что по-настоящему надежная система должна выполнять сквоз­ную шифрацию и сквозное обеспечение целостности данных (то есть все это долж­но быть сделано на прикладном уровне). Это означает, что процесс-источник шифрует и/или ставит защиту целостности данных и отправляет их процессу-приемнику, который, соответственно, дешифрует данные и проверяет их целост­ность. Тогда можно будет заметить любые попытки взлома (даже на уровне опе­рационной системы на любой из сторон). Беда такого подхода в том, что для обес­печения безопасности требуется вносить изменения во все приложения. Это означает, что необходимо «спустить» шифрацию на транспортный уровень или организовать новый специализированный подуровень между прикладным и транс­портным уровнями. Он должен быть сквозным, но в то же время не требующим внесения изменений в приложения.

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

Результатом всех этих дискуссий было создание стандарта IРsес (IР sесuritу —IР-безопасность), описанного в КРС 2401, 2402, 2406 и др. Не всем поль­зователям требуется шифрация соединений (выполнение соответствующих про­цедур может занимать существенную часть вычислительных ресурсов). Однако вместо того чтобы делать шифрацию необязательной, пользователю предлагает­ся в случае необходимости выбирать пустой алгоритм. В RFС 2410 расписы­ваются такие достоинства пустого алгоритма, как простота, легкость реализации и высокая скорость.

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

Для чего нужен целый набор алгоритмов? Дело в том, что считающийся сего­дня надежным алгоритм завтра может быть сломан. Если сделать IРsес незави­симым от конкретного алгоритма, стандарт выживет даже в случае взлома одно­го из алгоритмов.

Для чего нужны разные модули? Для того чтобы можно было защищать и од­но ТСР-соединение, и весь трафик между парой хостов, и весь трафик между па­рой защищенных хостов, и т. д.

Несколько удивительно, что IРsес ориентирован на соединение, несмотря на его присутствие, на уровне IР. На самом деле, это не так странно, как кажется. Ведь безопасность можно обеспечить только созданием ключа и использованием его в течение какого-то времени. А это, по сути дела, разновидность соединения. К тому же все соединения погашают расходы на их установление за счет переда­чи большого количества пакетов. «Соединение» в контексте IРsес называется за­щищающей связью (sесuritу соnnесtiоп). Защищающая связь — это симплексное соединение между двумя конечными точками, с которым связан специальный идентификатор защиты. Если требуется передача защищенных данных в обоих направлениях, понадобятся две защищающие связи. Идентификаторы защиты передаются в пакетах, следующих по этим надежным соединениям, и используются по прибытии защищенных пакетов для поиска ключей и другой важной ин­формации.

Технически IРsес состоит из двух основных частей. Первая описывает два но­вых заголовка, которые можно добавлять к пакету для передачи идентификатора защиты, данных контроля целостности и другой информации. Вторая часть, ISАКМР (Intегnеt sесuritу аnd Кеу Мanаgеmеnt Ргоtосоl — интернет-безопасность и протокол управления ключами), предназначена для создания ключей. Мы не станем вдаваться в подробности устройства ISАКМР, потому что, во-первых, это очень сложная тема и, во-вторых, основной протокол IKE (Intегnеt Кеу Ехchаngе — обмен ключами в Интернете) работает очень некорректно и требует за­мены (Реrlmаn и Каufmаn, 2000).

IРsес может работать в двух режимах. В транспортном режиме заголовок IРsес вставляется сразу за заголовком IР. Поле Рrоtосо1 заголовка IР изменяется таким образом, чтобы было понятно, что далее следует заголовок IРsес (перед заголовком ТСР). В заголовке IРsес содержится информация, касающаяся безо­пасности, — в частности, идентификатор защищающей связи, новый порядковый номер и, возможно, проверка целостности поля полезной нагрузки.

В режиме туннелирования весь IР-пакет вместе с заголовком вставляется внутрь нового IР-пакета с совершенно новым заголовком. Этот режим хорош то­гда, когда туннель заканчивается где-нибудь вне конечного пункта. В некоторых случаях концом туннеля является шлюз, обеспечивающий безопасность, напри­мер, корпоративный брандмауэр. В этом режиме брандмауэр вставляет и извле­кает пакеты, проходящие через него в разные стороны. При такой организации машины ЛВС компании гарантированно будут обслужены по стандарту IРsес. Об этом совершенно не приходится беспокоиться: все заботы берет на себя бранд­мауэр.

Еще режим туннелирования полезен, когда несколько ТСР-соединений объе­диняются вместе и обрабатываются в виде единого шифрованного потока, по­скольку в данном случае взломщик не может узнать, кто и кому передает пакеты, а также в каком количестве. А ведь иногда даже объем трафика, передаваемого одним лицом другому, является ценной информацией. Например, если во время военного кризиса трафик между Пентагоном и Белым домом резко снижается и при этом так же резко растет трафик между Пентагоном и какой-нибудь воен­ной базой в Колорадо, перехватчик может сделать из этого далеко идущие выводы.

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

Первый из новых заголовков называется заголовком идентификации (АН — Аuthеntication Неаdег). С его помощью проверяется целостность данных и вы­полняется защита от взлома путем повторной передачи. Однако он не имеет ни­какого отношения к секретности (то есть шифрации данных). Применение АН в транспортном режиме показано на рис. 1. В стандарте IРv4 он располагается между заголовком IР (вместе со всеми необязательными полями) и заголовком ТСР. В IРv6 это просто еще один дополнительный заголовок. Так он и воспри­нимается. Формат АН действительно очень близок к формату дополнительного заголовка IРv6. К полезной нагрузке иногда добавляют заполнение, чтобы дос­тичь определенной длины, необходимой алгоритму идентификации. Это показа­но на рисунке.



Рис. 1. Заголовок идентификации IРsес в транспортном режиме для IРv4


Рассмотрим заголовок АН. Поле Следующий заголовок хранит предыдущее значение, которое в поле Протокол заголовка IР ранее было заменено на 51, что­бы показать, что далее следует заголовок АН. Обычно здесь встречается код для ТСР (6). Поле Длина полезной нагрузки хранит количество 32-разрядных слов заголовка АН минус 2.

Поле Указатель параметров безопасности — это идентификатор соединения. Он вставляется отправителем и ссылается на конкретную запись в базе данных у получателя. В этой записи содержится общий ключ и другая информация данно­го соединения. Если бы этот протокол был придуман ITU, а не IETF, это поле, скорее всего, называлось бы Номером виртуального канала.

Поле Порядковый номер применяется для нумерации всех пакетов, посылае­мых по защищенной связи. Все пакеты получают уникальные номера, даже если они посылаются повторно. Имеется в виду, что повторно передаваемый пакет имеет номер, отличный от номера оригинального пакета (даже если порядковый номер ТСР тот же самый). Это поле служит для предотвращения взлома путем повторной передачи. Порядковые номера никогда не повторяются. Если же ока­жутся использованными все 232 номера, для продолжения общения устанавлива­ется новая защищающая связь.

Наконец, поле переменной длины Данные идентификации содержит цифро­вую подпись, вычисляемую относительно полезной нагрузки. При установке за­щищающей связи стороны договариваются об используемом алгоритме генера­ции подписей. Чаще всего здесь не применяется шифрование с открытыми ключами, так как все известные алгоритмы этого типа работают слишком мед­ленно, а пакеты необходимо обрабатывать с очень большой скоростью. Протокол IРsес основан на шифровании с симметричными ключами, поэтому перед установкой защищающей связи отправитель и получатель должны договориться о значении общего ключа, применяемого при вычислении подписи. Один из про­стейших способов заключается в вычислении хэш-функции для пакета и общего ключа. Отдельно общий ключ, конечно, не передается. Подобная схема называ­ется НМАС (Наshed Меssagе Аuthеntication Соdе — код идентификации хэшированного сообщения). Вычисление этого кода выполняется гораздо быстрее, чем последовательный запуск SНА-1 и RSА.

Заголовок АН не позволяет шифровать данные. Его основная польза выявля­ется, когда важна проверка целостности, но не нужна секретность. Стоит отме­тить, что при проверке целостности при помощи АН охватываются некоторые поля заголовка IР, в частности, те из них, которые не изменяются при прохожде­нии пакета от маршрутизатора к маршрутизатору. Поле Время жизни, например, меняется при каждой пересылке через маршрутизатор, поэтому его нельзя охва­тить при проверке целостности. Однако IР-адрес источника охватывается, тем самым предотвращается возможность его подмены взломщиком.

Альтернативой заголовку IРsес служит заголовок ЕSР (Еncapsulating Securitу Рауload — инкапсулированная защищенная полезная нагрузка). Как показа­но на рис. 2, этот заголовок может применяться как в транспортном режиме, так и в режиме туннелирования.



Рис. 2. ЕSР в транспортном режиме (а); ЕSР в режиме туннелирования (б)


Заголовок ЕSР состоит из двух 32-разрядных слов: Указателя параметров безопасности и Порядкового номера. Мы их уже встречали в заголовке АН. Третье слово, которое обычно следует за ними, однако технически не является частью заголовка, — это Вектор инициализации (если только не применяется пустой алгоритм шифрования, тогда это поле опускается).

ЕSР, как и АН, обеспечивает проверку целостности при помощи НМАС, од­нако вместо того, чтобы включать хэш в заголовок, его вставляют после поля по­лезной нагрузки. Это видно на рис. 2. Такое расположение полей дает преиму­щество при аппаратной реализации метода. Оно заключается в том, что НМАС может подсчитываться во время передачи битов полезной нагрузки по сети и до­бавляться к ним в конец. Именно поэтому в Еthernet и других стандартах ло­кальных сетей циклический контроль избыточности вставляется в концевик, а не в заголовок. При применении заголовка АН пакет приходится буферизировать и вычислять подпись, только после его можно отправлять. Это потенциально приводит к уменьшению числа пакетов, которые можно передать за единицу времени.

Казалось бы, если ЕSР умеет делать все то же самое, что и АН, и даже больше, причем он еще и гораздо эффективнее, тогда зачем мучиться с АН? Причины этого в основном исторические. Изначально заголовок АН обеспечивал только проверку целостности, а ЕSР — только секретность. Позднее ЕSР научили использовать для проверки целостности, но разработчики АН не хотели, чтобы он канул в Лету после всей той работы, которую они проделали. Единственный аргумент в пользу АН заключается в том, что с его помощью можно частично про­верять заголовок IР, чего не умеет ЕSР. И все же это аргумент довольно слабый. Еще один сомнительный аргумент состоит в том, что система, поддерживающая АН, но не поддерживающая ЕSР, возможно, будет иметь меньше проблем при получении лицензии на экспорт, поскольку этот заголовок не имеет отношения к секретности и шифрованию. Похоже, что АН со временем все-таки исчезнет с го­ризонта.


Брандмауэры


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

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

Таким образом, требуются специальные средства, удерживающие «доброка­чественную» информацию внутри, а «вредную» — снаружи. Один из способов состоит в применении IРsес. Этот метод защищает данные при их пересылке. Однако шифрование не спасает от вирусов и хакеров, способных проникнуть в локальную сеть. Помочь защитить сети от нежелательного проникновения сна­ружи может установка брандмауэров, к рассмотрению которых мы сейчас обратимся.

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





Рис. 3. Брандмауэр, состоящий из двух пакетных фильтров и шлюза прикладного уровня

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


1   ...   21   22   23   24   25   26   27   28   29

Похожие:

Коммуникационный канал и процессор связи icon4. Метрологическое обеспечение бескабельных телеизмерительных систем
Обзор отечественных и зарубежных забойных телесистем. Акустический канал связи. Телесистемы с гидравлическим каналом связи. Электромагнитный...

Коммуникационный канал и процессор связи iconМетодические указания к практическим занятиям, самостоятельной подготовке по дисциплине «Коммуникационный менеджмент»
«Коммуникационный менеджмент» для студентов IV курса специальности 0306 02 «Связи с общественностью» дневной формы обучения

Коммуникационный канал и процессор связи icon«Коммуникационный менеджмент»
Учебника, в полной мере отвечающего потребностям курса «Коммуникационный менеджмент в политике и экономике», в настоящее время нет....

Коммуникационный канал и процессор связи iconПрограмма дисциплины «Коммуникационный менеджмент в политике и экономике» Для направления 030200. 68
Учебника, в полной мере отвечающего потребностям курса «Коммуникационный менеджмент в политике и экономике», в настоящее время нет....

Коммуникационный канал и процессор связи iconИсходный файл "Новости", Первый канал "Новости", Первый канал, 11. 06. 2011
Площадь природных пожаров в Сибири за минувшие сутки достигла 37,5 тысяч гектаров

Коммуникационный канал и процессор связи iconИсходный файл "Новости", Первый канал "Новости", Первый канал, 07. 09. 2011
Сотрудники российского подразделения Интерпола нашли в сибирской тайге молодую латиноамериканку

Коммуникационный канал и процессор связи iconПравительство Российской Федерации Государственное образовательное бюджетное учреждение высшего профессионального образования
Курс «Коммуникационный консалтинг» является дисциплиной по выбору и предназначен для студентов 4 курса факультета прикладной политологии,...

Коммуникационный канал и процессор связи iconРоссийской Федерации Кузнецкий институт информационных и управленческих технологий (филиал пгу) Лабораторный практикум по информатике
Согласно требованиям «Государственных образовательных стандартов» для технических специальностей в лабораторный практикум включены:...

Коммуникационный канал и процессор связи iconУчебно-методический комплекс по дисциплине «Коммуникационный менеджмент» составлен в соответствии с требованиями Государственного образовательного стандарта высшего профессионального образования по специальности 030602 Связи с общественностью.
Дисциплина входит в федеральный компонент цикла общепрофессиональных дисциплин и является обязательной для изучения

Коммуникационный канал и процессор связи iconРабочая программа по курсу «Коммуникационный менеджмент»
Государственного образовательного стандарта высшего профессионального образования по специальности «Связи с общественностью» (030602)....


Разместите кнопку на своём сайте:
lib.convdocs.org


База данных защищена авторским правом ©lib.convdocs.org 2012
обратиться к администрации
lib.convdocs.org
Главная страница