Обеспечение информационной безопасности в сетях IP

Введение
Угрозы информационной безопасности и необходимость защиты информации
  В наше время главной ценностью на планете считается информация, следовательно её, как и всякую другую ценность, человек старается сохранить от посторонних рук и глаз. А так как сейчас уже 21 век, и понятие информации неразрывно связано с компьютерными технологиями, системами и сетями связи, то становится очевидной важность вопроса защиты информации в них. Изобретение  компьютера и дальнейшее бурное развитие информационных технологий во второй половине 20 века сделали проблему защиты информации настолько актуальной и острой, насколько актуальна сегодня информатизация для всего общества. Особенно актуально стоит этот вопрос в области секретной информации государства и частной коммерческой информации.
  В бизнесе добросовестная конкуренция предполагает соперничество, основанное на соблюдении законодательства и общепризнанных норм морали. Однако нередко предприниматели, конкурируя между собой, стремятся с помощью противоправных действий получить информацию в ущерб интересам другой стороны и использовать ее для достижения преимущества на рынке. Криминализация общества и недостаточная эффективность государственной системы охраны правопорядка заставляет предста¬вителей бизнеса самим принимать меры для адекватного противостояния имеющим место негативным процессам, наносящим ущерб конфиденциальной информации фирмы.
Причин активизации компьютерных преступлений и связанных с ними финансовых потерь достаточно много, существенными из них являются:
 переход от традиционной "бумажной" технологии хранения и передачи сведений на электронную и недостаточное при этом развитие технологии защиты информации в таких технологиях;
 объединение вычислительных систем, создание глобальных сетей и расширение доступа к информационным ресурсам;
 увеличение сложности программных cредств.
Следовательно главная тенденция, характеризующая развитие современных информационных технологий - рост числа компьютерных преступлений и связанных с ними хищений конфиденциальной и иной информации, а также материальных потерь.
 Мы все чаще слышим в СМИ слова "информационная безопасность", "произведена новая атака на компьютеры", "создан новый вирус", "ущерб от атаки составил ... " и далее приводятся все более ошеломляющие цифры.... Все эти проблемы связаны с низким и недостаточным уровнем обеспечения безопасности в информационных системах. Значит, необходимо обеспечивать безопасность тех данных, которые хранятся в наших компьютерах и передаются в сетях.
Содержание
 1.   Краткая историческая справка появления всемирной сети………………………..................ст 4.
2. IP телефония – краткое описание……………………………………….....................................ст5.
3 Удаленные атаки на распределенные вычислительные системы …………………….............ст9.
3.1 Классификация удаленных атак на РВС …………………………………….........ст9.
3.2 Характеристика и механизмы реализации типовых удаленных атак ………….ст15.
4 Причины успеха удаленных атак на РВС …………………………………………….............ст26.
5 Принципы создания защищенных систем связи в распределенных вычислительных
системах …………………………………………………………………………………..…….ст33.
5.1 Выделенный канал связи между объектами распределенной ВС …………….......ст34.
5.2 Виртуальный канал как средство обеспечения дополнительной идентификации/аутентификации объектов в распределенной ВС …………..........ст36.
5.3 Контроль за маршрутом сообщения в распределенной ВС ………………….........ст38.
5.4 Контроль за виртуальными соединениями в распределенной ВС …………..........ст39.
5.5 Проектирование распределенной ВС с полностью определенной
информацией о ее объектах с целью исключения алгоритмов
удаленного поиска …………………………………………..............................……..ст41.
6 Конкретные примеры атак на TCP/IP …………………………………………………............ст43.
6.1 Пассивные атаки на уровне TCP ……………………………………………….……ст44.
6.1.1 Подслушивание ……………………………………………….....................................ст44.
6.2 Активные атаки на уровне TCP …………………………………………...................ст44.
6.2.1 Предсказание порядкового номера TCP ……………………….................................ст45.
6.2.2 IP Hijacking - Нападение на IP ……………………………………………............ст48.
6.2.3 Пассивное сканирование …………………………………………………………ст 51.
6.2.4 Затопление ICMP-пакетами ………………………………………………………ст51.
6.2.5 Локальная буря ……………………………………………………………………ст52.
6.2.6 Затопление SYN-пакетами ………………………………………………………..ст53.
7 Решения на программном уровне ……………………………………………………………..ст54.
7.1 SSL – Secure Sockets Layer - протокол защищенных сокетов ………………………ст54.
7.2 IPSec - протокол защиты сетевого трафика на IP-уровне …………………………..ст58.
7.3 FireWall-1 Интернет-технологии FireWall (Межсетевые экраны …………….…….ст67
7.4 Check Point FireWall-1 технология проверки с учетом состояния протокола (Stateful Inspection Technology) …………………………………………………………………ст70.
7.5 Недостатки МСЭ ………………………………………………………………………ст77.
8 Решения на аппаратном уровне ……………………………………………………………….ст81.
9 Заключение……………………………………………………………………………………...ст84.
10 Список использованных источников …………………………………………………………ст85.
1. Краткая историческая справка появления всемирной сети
 Сеть управления перспективных исследовательских программ ARPANet (Advanced Research Project Agency network) была создана в конце шестидесятых годов американским агентством перспективных исследований в обороне DARPA. Первоначально сеть была экспериментальной и целью ее создания была организация системы, состоящей из нескольких узлов, при повреждении одного из которых сеть продолжала бы функционировать. В семидесятых годах ARPANet стала считаться действующей сетью США, и через эту сеть можно было получить доступ к ведущим университетским и научным центрам США. В начале восьмидесятых годов началась стандартизация языков программирования, а затем и протоколов взаимодействия сетей. Результатом этой работы стала разработка семиуровневой модели сетевого взаимодействия ISO/OSI и семейства протоколов TCP/IP, которое стало основой для построения как локальных, так и глобальных сетей.
 Базовые механизмы информационного обмена в сетях TCP/IP были в целом сформированы в начале восьмидесятых годов, и были направлены прежде всего на обеспечение доставки пакетов данных между различными операционными системами с использованием разнородных каналов связи. Несмотря на то, что идея создания сети ARPANet (впоследствии превратившейся в современный Интернет) принадлежала правительственной оборонной организации, фактически сеть зародилась в исследовательском мире, и наследовала традиции открытости академического сообщества. Ещё до коммерциализации Интернета (которая произошла в середине девяностых годов) многие авторитетные исследователи отмечали проблемы, связанные с безопасностью стека протоколов TCP/IP. Основные концепции протоколов TCP/IP не полностью удовлетворяют (а в ряде случаев и противоречат) современным представлениям о компьютерной безопасности.
 До недавнего времени сеть Интернет использовалась в основном для обработки информации по относительно простым протоколам: электронная почта, передача файлов, удалённый доступ. Сегодня, благодаря широкому распространению технологий WWW (World Wide Web), всё активнее применяются средства распределённой обработки мультимедийной информации. Одновременно с этим растёт объём данных, обрабатываемых в средах клиент/сервер и предназначенных для одновременного коллективного доступа большого числа абонентов. Разработано несколько протоколов прикладного уровня, обеспечивающих информационную безопасность таких приложений, как электронная почта (PEM - Privacy Enhanced Mail, почта повышенной секретности; PGP - Pretty Good Privacy, набор алгоритмов и программ для высоконадежного шифрования сообщений с использованием открытых ключей, и т.п.), WWW (Secure HTTP , SSL2 и т.п.), сетевое управление (SNMPv2 и т.п.). Однако наличие средств обеспечения безопасности в базовых протоколах семейства TCP/IP позволит осуществлять информационный обмен между широким спектром различных приложений и сервисных служб.
2.  IP телефония – краткое описание
 До недавнего времени сети с коммутацией каналов (телефонные сети) и сети с коммутацией пакетов (IP-сети) существовали практически независимо друг от друга и использовались для различных целей. Телефонные сети использовались только для передачи голосовой информации, а IP-сети - для передачи данных. IP-телефония - это технология, которая связывает два абсолютно разных мира - мир телефонии и мир интернет посредством устройства, называемого шлюз или gateway. Шлюз представляет собой устройство, в которое с одной стороны включаются телефонные линии, а с другой стороны - IP-сеть (например, Интернет).
Что такое IP протокол? 
 Протокол IP осуществляет передачу информации от узла к узлу сети в виде дискретных блоков - пакетов. При этом IP не несет ответственности за надежность доставки информации, целостность или сохранение порядка потока пакетов и, таким образом, не решает с необходимым для приложений качеством задачу передачи информации. Эту задачу решают два других протокола – TCP (Transfer Control Protocol, протокол управления передачей данных) и UDP (User Datagram Protocol, дейтаграммный протокол передачи данных) - которые, как говорят, "лежат" над IP (т. е. используют процедуры протокола IP для передачи информации, добавляя к ним свою дополнительную функциональность)..
Варианты построения IP-телефонных систем.
Известны и практически реализуются две базовые схемы IP-телефонии.
1. Для пользователей персональных компьютеров: данная схема связана с организацией телефонных переговоров между пользователями персональных компьютеров, оснащенных мультимедийным оборудованием и (или) специальными программными (программно-аппаратными) средствами, обеспечивающим ведение дуплексных телефонных переговоров, необходимый сервис и контроль. Пользовательские компьютеры могут входить в состав локальной сети, иметь персональный IP-адрес или подключаться к сети Интернет при помощи модема. 
2. Для пользователей телефонной сети: Данная схема предусматривает использование специальных многофункциональных устройств - шлюзов. Шлюз предназначен для преобразования аналоговых речевых и служебных сигналов в цифровую последовательность, организации из этой последовательности пакетов глобальной сети Интернет и передачи их в сеть, прием пакетов и восстановление цифровой последовательности - цифровых речевых и служебных сигналов и их преобразование в аналоговую форму, а так же решение большого перечня задач ,связанных с организацией интерфейсов, генерированием и детектированием сигналов абонентской сигнализации, управлением режимами телефонных переговоров и многое другое.  Однако главные задачи шлюза - обеспечение качественного дуплексного телефонного общения абонентов в режиме пакетной передачи и коммутации цифровых сигналов. 
 
Рис. 1. Структурная схема организации телефонной связи через сеть Интернет с использованием шлюзов.
Протокол IP
 Краеугольный камень сети Интернет - Internet Protocol (IP). Как уже отмечалось протокол Internet создан для использования в объединенных системах компьютерных коммуникационных сетей с коммутацией пакетов. Это протокол сетевого уровня, который обеспечивает маршрутизацию пакетов в сети. Однако он не гарантирует надежную доставку пакетов. Таким образом, пакеты могут искажаться, задерживаться, передаваться по различным маршрутам (а значит иметь различное время передачи) и т. д. На основе IP работают протоколы транспортного уровня Transport Control Protocol (TCP) и User Datagram Protocol (UDP). 
Протокол Internet выполняет две главные функции: адресацию и фрагментацию.
 Адресация: Выбор пути передачи называется маршрутизацией. Модули Internet используют адреса, помещенные в заголовок Internet, для передачи Internet датаграмм их получателям.
 Фрагментация: Модули Internet используют поля в заголовке Internet для фрагментации и восстановления датаграмм Internet, когда это необходимо для их передачи через сети с малым размером пакетов.
Связь с другими протоколами
 Следующая диаграмма иллюстрирует место протокола Internet в иерархии протоколов.
 
Рис. 2 Взаимодействие протоколов
Telnet - сетевой теледоступ (протокол виртуального терминала в наборе протоколов Internet; позволяет пользователям одного хоста подключаться к другому удаленному хосту и работать с ним как через обычный терминал ).
FTP - File Transfer Protocol протокол передачи файлов (используемый в Internet протокол передачи файлов между хост-компьютерами ).
TFTP - Trivial File Transfer Protocol простейший протокол передачи данных, являющийся упрощенным вариантом протокола FTP; поддерживает простую передачу данных между двумя системами без аутентификации.
ICMP- Internet Control Message Protocol - протокол управляющих сообщений в сети Internet (один из четырех протоколов межсетевого уровня семейства TCP/IP, обеспечивающий восстановление связи при сбойных ситуациях в передаче пользовательских пакетов).
 Протокол Internet взаимодействует с одной стороны с протоколами передачи информации между хост-компьютерами, а с другой - с протоколами локальной компьютерной сети. При этом локальная сеть может являться малой компьютерной сетью, участвующей в создании большой сети, такой как ARPANET - Advanced Research Project Agency network сеть Управления перспективных исследовательских программ ( сеть с коммутацией пакетов, организованная в начале 70-х годов; явилась прообразом сегодняшней сети Internet, была расформирована в июне 1990 ).
 В данной работе мы с Вами рассмотрим условия возникновения угроз хранению информации, передаче её по сетям и системам связи, предпосылки их возникновения, методы предупреждения и некоторые способы противодействия.
3. Удаленные атаки на распределенные вычислительные системы
 Основной особенностью любой распределенной системы является то, что ее компоненты распределены в пространстве и связь между ними физически осуществляется при помощи сетевых соединений и программно при помощи механизма сообщений. При этом все управляющие сообщения и данные, пересылаемые между объектами распределенной ВС, передаются по сетевым соединениям в виде пакетов обмена. Эта особенность и является основной для рассматриваемых в этой главе удаленных атак на инфраструктуру и протоколы IP-сетей.
3.1 Классификация удаленных атак на распределенные вычислительные системы
 Следущая классификация приводиться  для точного описания удаленных атак на распределенные вычислительные системы.
Удаленные атаки можно классифицировать по следующим  признакам:
а) По характеру воздействия
 пассивное воздействие;
 активное  воздействие.
 Пассивное воздействие на распределенную вычислительную систему это воздействие, которое не оказывает непосредственного влияния на работу системы, но может нарушать ее политику безопасности. Именно отсутствие непосредственного влияния на работу распределенной ВС приводит к тому, что пассивное удаленное воздействие практически невозможно обнаружить. Примером пассивного типового удаленного воздействия в РВС служит прослушивание канала связи в сети.
 Под активным воздействием на распределенную ВС будем понимать воздействие, оказывающее непосредственное влияние на работу системы (изменение конфигурации РВС, нарушение работоспособности и т. д.) и нарушающее принятую в ней политику безопасности. Практически все типы удаленных атак являются активными воздействиями. Это связано с тем, что в самой природе разрушающего воздействия содержится активное начало. Очевидной особенностью активного воздействия по сравнению с пассивным является принципиальная возможность его обнаружения (естественно, с большей или меньшей степенью сложности), так как в результате его осуществления в системе происходят определенные изменения. В отличие от активного, при пассивном воздействии не остается никаких следов (от того, что атакующий просмотрит чужое сообщение в системе, в тот же момент ничего не изменится).
б) По цели воздействия
 нарушение конфиденциальности информации либо ресурсов системы
 нарушение целостности информации
 нарушение работоспособности (доступности) системы
 Угрозы нарушения конфиденциальности направлены на разглашение конфиденциальной или секретной информации. При реализации этих угроз информация становится известной лицам, которые не должны иметь к ней доступ.
  Угрозы нарушения целостности информации ,хранящейся в компьютерной системе или передаваемой по каналу связи, направлены на её изменение или искажение, приводящее к нарушению её качества или полному уничтожению. Целостность информации может быть нарушена умышленно злоумышленником, а также в результате объективных воздействий со стороны среды, окружающей систему. Эта угроза особенно актуальна для систем передачи информации - компьютерных сетей и систем телекоммуникации.
 Угрозы нарушения работоспособности (отказ в обслуживании) направлены на создание таких ситуаций, когда определённые преднамеренные действия либо снижают работоспособность АСОИ, либо блокируют доступ к некоторым её ресурсам. В этом случае не предполагается получение атакующим несанкционированного доступа к информации. Его основная цель - добиться, чтобы операционная система на атакуемом объекте вышла из строя и для всех остальных объектов системы доступ к ресурсам атакованного объекта был бы невозможен. Примером удаленной атаки, целью которой является нарушение работоспособности системы, может служить типовая УА "Отказ в обслуживании".
 Этот классификационный признак является прямой проекцией трех основных типов угроз - раскрытия, целостности и отказа в обслуживании.
Основная цель практически любой атаки - получить несанкционированный доступ к информации. Существуют две принципиальные возможности доступа к информации:
 перехват
 искажение.
 Возможность перехвата информации означает получение к ней доступа, но невозможность ее модификации. Следовательно, перехват информации ведет к нарушению ее конфиденциальности. Примером перехвата информации может служить анализ сетевого трафика в сети. В этом случае имеется несанкционированный доступ к информации без возможности ее искажения. Очевидно также, что нарушение конфиденциальности информации является пассивным воздействием.
 Возможность искажения информации означает либо полный контроль над  информационным потоком между объектами системы, либо возможность передачи сообщений от имени другого объекта. Таким образом, очевидно, что искажение информации ведет к нарушению ее целостности. Данное информационное разрушающее воздействие представляет собой яркий пример активного воздействия. Примером удаленной атаки, цель которой нарушение целостности информации, может служить типовая удаленная атака (УА) "Ложный объект РВС".
  Опасные воздействия можно разделить на случайные и преднамеренные
  Причины случайных воздействий:
 аварийные ситуации из-за стихийных бедствий и отключения электроэнергии;
 отказы и сбои аппаратуры;
 ошибки в программном обеспечении;
 ошибки в работе обслуживающего персонала и пользователей;
 помехи в линии связи из-за воздействия внешней среды.
в)  По условию начала осуществления воздействия
 Удаленное воздействие, также как и любое другое, может начать осуществляться только при определенных условиях. В распределенных ВС существуют три вида условий начала осуществления удаленной атаки:
 Атака по запросу от атакуемого объекта 
 В этом случае атакующий ожидает передачи от потенциальной цели атаки запроса определенного типа, который и будет условием начала осуществления воздействия. Примером подобных запросов в ОС Novell NetWare  может служить SAP -запрос, а в сети Internet - DNS - и ARP-запросы . Важно отметить, что данный тип удаленных атак наиболее характерен для распределенных ВС.
 Атака по наступлению ожидаемого события на атакуемом объекте 
 В этом случае атакующий осуществляет постоянное наблюдение за состоянием операционной системы удаленной цели атаки и при возникновении определенного события в этой системе начинает воздействие. Как и в предыдущем случае, инициатором осуществления начала атаки выступает сам атакуемый объект. Примером такого события может быть прерывание сеанса работы пользователя с сервером в ОС Novell NetWare без выдачи команды LOGOUT.
 Безусловная атака
 В этом случае начало осуществления атаки безусловно по отношению к цели атаки, то есть атака осуществляется немедленно и безотносительно к состоянию системы и атакуемого объекта. Следовательно, в этом случае атакующий является инициатором начала осуществления атаки.
г) По наличию обратной связи с атакуемым объектом
 с обратной связью
 без обратной связи (однонаправленная атака)
 Удаленная атака, осуществляемая при наличии обратной связи с атакуемым объектом, характеризуется тем, что на некоторые запросы, переданные на атакуемый объект, атакующему требуется получить ответ, а, следовательно, между атакующим и целью атаки существует обратная связь, которая позволяет атакующему адекватно реагировать на все изменения, происходящие на атакуемом объекте. Подобные удаленные атаки наиболее характерны для распределенных ВС.
 В отличие от атак с обратной связью удаленным атакам без обратной связи не требуется реагировать на какие-либо изменения, происходящие на атакуемом объекте. Атаки данного вида обычно осуществляются передачей на атакуемый объект одиночных запросов, ответы на которые атакующему не нужны. Подобную УА можно называть однонаправленной удаленной атакой. Примером однонаправленных атак является типовая УА "Отказ в обслуживании".
д)  По расположению субъекта атаки относительно атакуемого объекта
1. внутрисегментное
2. межсегментное
Рассмотрим ряд определений:
Субъект атаки (или источник атаки) - это атакующая программа или оператор, непосредственно осуществляющие воздействие.
Хост (host) - сетевой компьютер.
Маршрутизатор (router) - устройство, обеспечивающее маршрутизацию пакетов обмена в глобальной сети.
Подсеть (subnetwork) (в терминологии Internet) - совокупность хостов, являющихся частью глобальной сети, для которых маршрутизатором выделен одинаковый номер подсети. Подсеть - логическое объединение хостов маршрутизатором. Хосты внутри одной подсети могут взаимодействовать между собой непосредственно, минуя маршрутизатор.
Сегмент сети - физическое объединение хостов. Например, сегмент сети образуют совокупность хостов, подключенных к серверу по схеме "общая шина" . При такой схеме подключения каждый хост имеет возможность подвергать анализу любой пакет в своем сегменте.
 С точки зрения удаленной атаки чрезвычайно важно, как по отношению друг к другу располагаются субъект и объект атаки, то есть в одном или в разных сегментах они находятся. В случае внутрисегментной атаки, как следует из названия, субъект и объект атаки находятся в одном сегменте. При межсегментной атаке субъект и объект атаки находятся в разных сегментах.
Данный классификационный признак позволяет судить о так называемой "степени удаленности" атаки.
 В дальнейшем будет показано, что на практике межсегментную атаку осуществить значительно труднее, чем внутрисегментную. Важно отметить, что межсегментная удаленная атака представляет гораздо большую опасность, чем внутрисегментная. Это связано с тем, что в случае межсегментной атаки объект её и непосредственно атакующий могут находиться на расстоянии многих тысяч километров друг от друга, что может существенно воспрепятствовать мерам по отражению атаки.  
В общем виде все атаки делятся на:
 внутренние атаки
 внешние атаки
Внутренние атаки инициируются персоналом объекта, на котором установлена система, содержащая КИ. Из-за неудовлетворительной зарплаты или отношения руководства, отдельные сотрудники с высоким уровнем самооценки могут предпринять действия по выдаче информации лицам, заинтересованным в её получении.
 Внешние атаки возникают благодаря непосредственной деятельности недобросовестных конкурентов, преступных элементов, иностранных разведывательных служб, из-за неумелой постановки взаимоотношений с представителями государственных структур, общественных организаций, средств массовой информации. Действия извне могут быть направлены на пассивные носители информации следующими способами:
1. похищение или снятие копий с различных носителей информации;
2. снятие информации в процессе коммуникации;
3. снятие информации в процессе её передачи по сети связи;
4. уничтожение информации или повреждение ее носителей;
5. случайное или преднамеренное доведение до сведения конку¬рентов документов и материалов, содержащих секретную ин¬формацию.
   Действия извне могут быть также направлены на персонал ком¬пании и выражаться в формах:
 подкупа,
 угроз,
 шантажа,
 выведывания с целью получения информации,
 переманивания ведущих специалистов на конкурирующую фир¬му и т. п.
 Внешние угрозы (в случае коммерческой информации), как правило, выступают в форме промыш¬ленного шпионажа. В ходе конкурентной борьбы использование про¬мышленного шпионажа нельзя отнести к этическим видам деловых взаимоотношений предпринимателей. Однако любая предпринима¬тельская деятельность, как показывает зарубежная практика, без него немыслима. Самый благоприятный общественно-экономический климат для развития предпринимательства не сможет предотвра¬тить банкротства, если в результате удачной шпионской акции бу¬дут похищены секретные для фирмы сведения.
е) По уровню эталонной модели ISO/OSI, на котором осуществляется воздействие
1. физический
2. канальный
3. сетевой
4. транспортный
5. сеансовый
6. представительный 
7. прикладной 
 Международная Организация по Стандартизации (ISO) приняла стандарт ISO 7498, описывающий взаимодействие открытых систем (OSI). Распределенные ВС также являются открытыми системами. Любой сетевой протокол обмена, как и любую сетевую программу, можно с той или иной степенью точности спроецировать на эталонную семиуровневую модель OSI. Такая многоуровневая проекция позволит описать в терминах модели OSI функции, заложенные в сетевой протокол или программу. Удаленная атака также является сетевой программой. В связи с этим представляется логичным рассматривать удаленные атаки на распределенные ВС, проецируя их на эталонную модель ISO/OSI.
На рисунке 3 показана обобщённая схема классификации удаленных атак на РВС:
 
Рис. 3. Классификация типовых удаленных атак
3.2 Характеристика и механизмы реализации типовых удаленных атак
Понятие типовой удаленной атаки
 Исследования и анализ информационной безопасности различных распределенных ВС, проводимые авторами в течение последних лет, наглядно продемонстрировали тот факт, что, независимо от используемых сетевых протоколов, топологии, инфраструктуры исследуемых распределенных ВС, механизмы реализации удаленных воздействий на РВС инвариантны по отношению к особенностям конкретной системы. Это объясняется тем, что распределенные ВС проектируются на основе одних и тех же принципов, а, следовательно, имеют практически одинаковые проблемы безопасности; Поэтому оказывается, что причины успеха удаленных атак на различные РВС одинаковы. Таким образом, появляется возможность ввести понятие типовой удаленной атаки. Типовая удаленная атака - это удаленное информационное разрушающее воздействие, программно осуществляемое по каналам связи и характерное для любой распределенной ВС. Введение этого понятия в совокупности с описанием механизмов реализации типовых УА позволяет предложить методику исследования безопасности, инвариантную по отношению к виду распределенной ВС. Методика заключается в последовательном осуществлении всех типовых удаленных воздействий в соответствии с предложенным далее их описанием и характеристиками. При этом основным элементом исследования безопасности РВС является анализ сетевого трафика. Как пояснение последнего утверждения рассмотрим следующую аналогию: отладчик - основное средство для хакера, соответственно анализатор сетевого трафика - основное средство для сетевого хакера. Анализатор сетевого трафика по своей сути является сетевым отладчиком. Итак, в качестве методики исследования информационной безопасности распределенной ВС предлагается выполнение ряда тестовых задач, оценивающих защищенность системы по отношению к типовым удаленным воздействиям.
Рассмотрим в следующих пунктах типовые удаленные атаки и механизмы их реализации.
Анализ сетевого трафика
Атака - Анализ сетевого трафика
 Анализ сетевого трафика является одним из способов получения паролей и идентификаторов пользователей в сети Internet. Сетевой анализ осуществляется с помощью специальной пpогpаммы - анализатоpа пакетов (sniffer), перехватывающей все пакеты, передаваемые по сегменту сети, и выделяющей среди них те, в которых передаются идентификатор пользователя и его пароль.
 Во многих протоколах данные передаются в открытом, незашифрованном виде. Анализ сетевого трафика позволяет перехватывать данные, передаваемые по протоколам FTP и TELNET (пароли и идентификаторы пользователей), HTTP (Hypertext Transfer Protocol - протокол передачи гипертекстовых файлов - передача гипертекста между WEB-сервером и браузером, в том числе и вводимые пользователем в формы на web-страницах данные), SMTP  , POP3  , IMAP , NNTP  (электронная почта и конференции) и IRC -Internet Relay Chat (online-разговоры, chat). Так могут быть перехвачены пароли для доступа к почтовым системам с web-интерфейсом, номера кредитных карт при работе с системами электронной коммерции и различная информация личного характера, разглашение которой нежелательно.
 В настоящее время разработаны различные протоколы обмена, позволяющие защитить сетевое соединение и зашифровать трафик . К сожалению, они ещё не сменили старые протоколы и не стали стандартом для каждого пользователя. В определённой степени их распространению помешали существующие в ряде стран ограничения на экспорт средств сильной криптографии. Из-за этого реализации данных протоколов либо не встраивались в программное обеспечение, либо значительно ослаблялись (ограничивалась максимальная длина ключа), что приводило к практической бесполезности их, так как шифры могли быть вскрыты за приемлемое время.
Анализ сетевого трафика позволяет:
1.  Во-первых, изучить логику работы распределенной ВС, то есть получить взаимно однозначное соответствие событий, происходящих в системе, и команд, пересылаемых друг другу ее объектами, в момент появления этих событий (если проводить дальнейшую аналогию с инструментарием хакера, то анализ трафика в этом случае заменяет и трассировщик). Это достигается путем перехвата и анализа пакетов обмена на канальном уровне. Знание логики работы распределенной ВС позволяет на практике моделировать и осуществлять типовые удаленные атаки, рассмотренные в следующих пунктах на примере конкретных распределенных ВС.
2.  Во-вторых, анализ сетевого трафика позволяет перехватить поток данных, которыми обмениваются объекты распределенной ВС. Таким образом, удаленная атака данного типа заключается в получении на удаленном объекте несанкционированного доступа к информации, которой обмениваются два сетевых абонента. Отметим, что при этом отсутствует возможность модификации трафика и сам анализ возможен только внутри одного сегмента сети. Примером перехваченной при помощи данной типовой удаленной атаки информации могут служить имя и пароль пользователя, пересылаемые в незашифрованном виде по сети (п. 4.1).
 По характеру воздействия анализ сетевого трафика является пассивным воздействием Осуществление данной атаки без обратной связи ведет к нарушению конфиденциальности информации внутри одного сегмента сети на канальном уровне OSI При этом начало осуществления атаки безусловно по отношению к цели атаки.
Анализ сетевого трафика – средство выявления атаки
 Анализ сетевого трафика можно также успешно использовать в противоположных целях, для выявления сетевых атак.
 Существует два не исключающих друг друга подхода к выявлению сетевых атак: анализ сетевого трафика и анализ контента. В первом случае анализируются только заголовки сетевых пакетов, во втором — их содержимое.
 Конечно, наиболее полный контроль информационных взаимодействий может быть обеспечен только путем анализа всего содержимого сетевых пакетов, включая их заголовки и области данных. Однако с практической точки зрения эта задача является трудновыполнимой из-за огромного объема данных, которые приходилось бы анализировать. Современные системы выявления атак IDS (Intrusion-Detection System) начинают испытывать серьезные проблемы с производительностью уже в 100 Мб/с сетях. Поэтому в большинстве случаев целесообразно использовать для выявления атак методы анализа сетевого трафика, в некоторых случаях сочетая их с анализом контента.
 Сигнатура сетевой атаки концептуально практически не отличается от сигнатуры вируса. Она представляет собой набор признаков, позволяющих отличить сетевую атаку от других видов сетевого трафика. Например, перечисленные ниже признаки могут рассматриваться в качестве сигнатур атак:
Примеры сигнатур атак, используемых при анализе трафика (заголовков сетевых пакетов):
 В заголовке TCP пакета установлен порт назначения 139 и флаг OOB (Out of Band - внеполосный). Это является признаком атаки аля WinNuke.
 Установлены одновременно противоречащие друг другу флаги TCP пакета: SYN и FIN. Данная комбинация флагов используется во многих атакующих программах для обхода фильтров и мониторов, проверяющих только установку одиночного SYN флага.
 Методы анализа контента имеют еще один существенный недостаток. Они не работают, когда атакующие программы (DDoS, trojans) используют методы шифрования трафика. Например, Back Orifice trojan или Barbwire DDoS осуществляют шифрование команд, передаваемых между клиентом и сервером, (менеджером и агентом), с использованием алгоритма blowfish. Методы выявления такого рода атак ограничиваются анализом заголовков сетевых пакетов.
Подмена доверенного объекта или субъекта распределенной ВС
 Одной из проблем безопасности распределенной ВС является недостаточная идентификация и аутентификация ее удаленных друг от друга объектов. Основная трудность заключается в осуществлении однозначной идентификации сообщений, передаваемых между субъектами и объектами взаимодействия. Обычно в распределенных ВС эта проблема решается следующим образом: в процессе создания виртуального канала объекты РВС обмениваются определенной информацией, уникально идентифицирующей данный канал. Такой обмен обычно называется "рукопожатием" (handshake). Однако, отметим, что не всегда для связи двух удаленных объектов в РВС создается виртуальный канал. Практика показывает, что зачастую, особенно для служебных сообщений (например, от маршрутизаторов) используется передача одиночных сообщений, не требующих подтверждения.
 Как известно, для адресации сообщений в распределенных ВС используется сетевой адрес, который уникален для каждого объекта системы (на канальном уровне модели OSI - это аппаратный адрес сетевого адаптера, на сетевом уровне - адрес определяется в зависимости от используемого протокола сетевого уровня (например, IP-адрес). Сетевой адрес также может использоваться для идентификации объектов распределенной ВС. Однако сетевой адрес достаточно просто подделывается и поэтому использовать его в качестве единственного средства идентификации объектов недопустимо.
 В том случае, когда распределенная ВС использует нестойкие алгоритмы идентификации удаленных объектов, то оказывается возможной типовая удаленная атака, заключающаяся в передаче по каналам связи сообщений от имени произвольного объекта или субъекта РВС. При этом существуют две разновидности данной типовой удаленной атаки:
 атака при установленном виртуальном канале,
 атака без установленного виртуального канала.
 В случае установленного виртуального соединения атака будет заключаться в присвоении прав доверенного субъекта взаимодействия, легально подключившегося к объекту системы, что позволит атакующему вести сеанс работы с объектом распределенной системы от имени доверенного субъекта. Реализация удаленных атак данного типа обычно состоит в передаче пакетов обмена с атакующего объекта на цель атаки от имени доверенного субъекта взаимодействия (при этом переданные сообщения будут восприняты системой как корректные). Для осуществления атаки данного типа необходимо преодолеть систему идентификации и аутентификации сообщений, которая, в принципе, может использовать контрольную сумму, вычисляемую с помощью открытого ключа, динамически выработанного при установлении канала, случайные многобитные счетчики пакетов и сетевые адреса станций. Однако на практике, например, в ОС Novell NetWare 3.12-4.1 для идентификации пакетов обмена используются два 8-битных счетчика - номер канала и номер пакета; в протоколе TCP для идентификации используются два 32-битных счетчика.
 Как было замечено выше, для служебных сообщений в распределенных ВС часто используется передача одиночных сообщений, не требующих подтверждения, то есть не требуется создание виртуального соединения. Атака без установленного виртуального соединения заключается в передаче служебных сообщений от имени сетевых управляющих устройств, например, от имени маршрутизаторов.
 Очевидно, что в этом случае для идентификации пакетов возможно лишь использование статических ключей, определенных заранее, что довольно неудобно и требует сложной системы управления ключами. Однако, при отказе от такой системы идентификация пакетов без установленного виртуального канала будет возможна лишь по сетевому адресу отправителя, который легко подделать.
 Посылка ложных управляющих сообщений может привести к серьезным нарушениям работы распределенной ВС (например, к изменению ее конфигурации). Рассмотренная типовая удаленная атака, использующая навязывание ложного маршрута, основана на описанной идее.
 Подмена доверенного объекта РВС является активным воздействием, совершаемым с целью нарушения конфиденциальности  и целостности информации, по наступлению на атакуемом объекте определенного события Данная удаленная атака может являться как внутрисегментной, так и межсегментной, как с обратной связью так и без обратной связи с атакуемым объектом и осуществляется на сетевом и транспортном уровнях модели OSI.
Ложный объект распределенной ВС
 В том случае, если в распределенной ВС недостаточно надежно решены проблемы идентификации сетевых управляющих устройств (например, маршрутизаторов), возникающие при взаимодействии последних с объектами системы, то подобная распределенная система может подвергнуться типовой удаленной атаке, связанной с изменением маршрутизации и внедрением в систему ложного объекта. В том случае, если инфраструктура сети такова, что для взаимодействия объектов необходимо использование алгоритмов удаленного поиска, то это также позволяет внедрить в систему ложный объект. Итак, существуют две принципиально разные причины, обуславливающие появление типовой удаленной атаки "Ложный объект РВС" .
Внедрение в распределенную ВС ложного объекта путем навязывания ложного маршрута
 Современные глобальные сети представляют собой совокупность сегментов сети, связанных между собой через сетевые узлы. При этом маршрутом называется последовательность узлов сети, по которой данные передаются от источника к приемнику. Каждый маршрутизатор имеет специальную таблицу, называемую таблицей маршрутизации, в которой для каждого адресата указывается оптимальный маршрут. Отметим, что таблицы маршрутизации существуют не только у маршрутизаторов, но и у любых хостов в глобальной сети. Для обеспечения эффективной и оптимальной маршрутизации в распределенных ВС применяются специальные управляющие протоколы, позволяющие маршрутизаторам обмениваться информацией друг с другом (RIP  , OSPF  ), уведомлять хосты о новом маршруте - ICMP (Internet Control Message Protocol ), удаленно управлять маршрутизаторами (SNMP ). Важно отметить, что все описанные выше протоколы позволяют удаленно изменять маршрутизацию в сети Internet, то есть являются протоколами управления сетью.
 Поэтому абсолютно очевидно, что маршрутизация в глобальных сетях играет важнейшую роль и, как следствие этого, может подвергаться атаке. Основная цель атаки, связанной с навязыванием ложного маршрута, состоит в том, чтобы изменить исходную маршрутизацию на объекте распределенной ВС так, чтобы новый маршрут проходил через ложный объект - хост атакующего.
 Реализация данной типовой удаленной атаки состоит в несанкционированном использовании протоколов управления сетью для изменения исходных таблиц маршрутизации.
 Для изменения маршрутизации атакующему необходимо послать по сети определенные данными протоколами управления сетью специальные служебные сообщения от имени сетевых управляющих устройств (например, маршрутизаторов). В результате успешного изменения маршрута атакующий получит полный контроль над потоком информации, которой обмениваются два объекта распределенной ВС, и атака перейдет во вторую стадию, связанную с приемом, анализом и передачей сообщений, получаемых от дезинформированных объектов РВС.
 Навязывание объекту РВС ложного маршрута - активное воздействие, совершаемое с любой из целей нарушения конфиденциальности, целостности и работоспособности, безусловно по отношению к цели атаки. Данная типовая удаленная атака может осуществляться как внутри одного сегмента, так и межсегментно, как с обратной связью, так и без обратной связи с атакуемым объектом  на транспортном и прикладном уровне модели OSI.
Внедрение в распределенную ВС ложного объекта путем использования недостатков алгоритмов удаленного поиска
 В распределенной ВС часто оказывается, что ее удаленные объекты изначально не имеют достаточно информации, необходимой для адресации сообщений. Обычно такой информацией являются аппаратные (адрес сетевого адаптера) и логические (IP-адрес, например) адреса объектов РВС. Для получения подобной информации в распределенных ВС используются различные алгоритмы удаленного поиска, заключающиеся в передаче по сети специального вида поисковых запросов, и в ожидании ответов на запрос с искомой информацией. После получения ответа на запрос, запросивший субъект РВС обладает всеми необходимыми данными для адресации. Руководствуясь полученными из ответа сведениями об искомом объекте, запросивший субъект РВС начинает адресоваться к нему. Примером подобных запросов, на которых базируются алгоритмы удаленного поиска, могут служить SAP-запрос в ОС Novell NetWare, ARP- и DNS-запрос в сети Internet.
 В случае использования распределенной ВС механизмов удаленного поиска существует возможность на атакующем объекте перехватить посланный запрос и послать на него ложный ответ, где указать данные, использование которых приведет к адресации на атакующий ложный объект. В дальнейшем весь поток информации между субъектом и объектом взаимодействия будет проходить через ложный объект РВС.
 Другой вариант внедрения в РВС ложного объекта использует недостатки алгоритма удаленного поиска и состоит в периодической передаче на атакуемый объект заранее подготовленного ложного ответа без приема поискового запроса. В самом деле, атакующему для того, чтобы послать ложный ответ, не всегда обязательно дожидаться приема запроса (он может, в принципе, не иметь подобной возможности перехвата запроса). При этом атакующий может спровоцировать атакуемый объект на передачу поискового запроса, и тогда его ложный ответ будет немедленно иметь успех. Данная типовая удаленная атака чрезвычайно характерна для глобальных сетей, когда у атакующего из-за нахождения его в другом сегменте относительно цели атаки просто нет возможности перехватить поисковый запрос.
 Ложный объект РВС - активное воздействие, совершаемое с целью нарушения конфиденциальности и целостности информации, которое может являться атакой по запросу от атакуемого объекта а также безусловной атакой. Данная удаленная атака является как внутрисегментной, так и межсегментной, имеет обратную связь с атакуемым объектом и осуществляется на канальном и прикладном уровнях модели OSI.
Использование ложного объекта для организации удаленной атаки на распределенную ВС
 Получив контроль над проходящим потоком информации между объектами, ложный объект РВС может применять различные методы воздействия на перехваченную информацию. В связи с тем, что внедрение в распределенную ВС ложного объекта является целью многих удаленных атак и представляет серьезную угрозу безопасности РВС в целом, то в следующих пунктах будут подробно рассмотрены методы воздействия на информацию, перехваченную ложным объектом.
Селекция потока информации и сохранение ее на ложном объекте РВС
 Одной из атак, которую может осуществлять ложный объект РВС, является перехват передаваемой между субъектом и объектом взаимодействия информации. Важно отметить, что факт перехвата информации (файлов, например) возможен из-за того, что при выполнении некоторых операций над файлами (чтение, копирование и т. д.) содержимое этих файлов передается по сети, а, значит, поступает на ложный объект. Простейший способ реализации перехвата - это сохранение в файле всех получаемых ложным объектом пакетов обмена.
 Тем не менее, данный способ перехвата информации оказывается недостаточно информативным. Это происходит вследствие того, что в пакетах обмена кроме полей данных существуют служебные поля, не представляющие в данном случае для атакующего непосредственного интереса. Следовательно, для того, чтобы получить непосредственно передаваемый файл, необходимо проводить на ложном объекте динамический семантический анализ потока информации для его селекции.
Модификация информации
 Одной из особенностей любой системы воздействия, построенной по принципу ложного объекта, является то, что она способна модифицировать перехваченную информацию. Следует особо отметить, что это один из способов, позволяющих программно модифицировать поток информации между объектами РВС с другого объекта. Ведь для реализации перехвата информации в сети необязательно атаковать распределенную ВС по схеме "ложный объект" . Эффективней будет атака, осуществляющая анализ сетевого трафика, позволяющая получать все пакеты, проходящие по каналу связи, но, в отличие от удаленной атаки по схеме "ложный объект" , она не способна к модификации информации.
Далее рассмотрим два вида модификации информации:
 модификация передаваемых данных;
 модификация передаваемого кода.
 Одной из функций, которой может обладать система воздействия, построенная по принципу "ложный объект" , является модификация передаваемых данных. В результате селекции потока перехваченной информации и его анализа система может распознавать тип передаваемых файлов (исполняемый или текстовый). Соответственно, в случае обнаружения текстового файла или файла данных появляется возможность модифицировать проходящие через ложный объект данные. Особую угрозу эта функция представляет для сетей обработки конфиденциальной информации.
 Другим видом модификации может быть модификация передаваемого кода. Ложный объект, проводя семантический анализ проходящей через него информации, может выделять из потока данных исполняемый код. Известный принцип неймановской архитектуры гласит, что не существует различий между данными и командами. Следовательно, для того, чтобы определить, что передается по сети - код или данные, необходимо использовать определенные особенности, свойственные реализации сетевого обмена в конкретной распределенной ВС или некоторые особенности, присущие конкретным типам исполняемых файлов в данной локальной ОС.
Представляется возможным выделить два различных по цели вида модификации кода:
 внедрение РПС (разрушающих программных средств);
 изменение логики работы исполняемого файла. В первом случае при внедрении РПС исполняемый файл модифицируется по вирусной технологии: к исполняемому файлу одним из известных способов дописывается тело РПС ,а также одним из известных способов изменяется точка входа так, чтобы она указывала на начало внедренного кода РПС. Описанный способ, в прин-ципе, ничем не отличается от стандартного заражения исполняемого файла вирусом, за исключением того, что файл оказался поражен вирусом или РПС в момент передачи его по сети! Такое возможно лишь при использовании системы воздействия, построенной по принципу "ложный объект" . Конкретный вид РПС, его цели и задачи в данном случае не имеют значения, но можно рассмотреть, например, вариант использования ложного объекта для создания сетевого червя - наиболее сложного на практике удаленного воздействия в сетях, или в качестве РПС использовать сетевые шпионы.
 Во втором случае происходит модификация исполняемого кода с целью изменения логики его работы. Данное воздействие требует предварительного исследования работы исполняемого файла и, в случае его проведения, может принести самые неожиданные результаты. Например, при запуске на сервере (например, в ОС Novell NetWare) программы идентификации пользователей распределенной базы данных ложный объект может так модифицировать код этой программы, что появится возможность беспарольного входа с наивысшими привилегиями в базу данных.
Подмена информации
 Ложный объект позволяет не только модифицировать, но и подменять перехваченную им информацию. Если модификация информации приводит к ее частичному искажению, то подмена - к ее полному изменению.
 При возникновении в сети определенного контролируемого ложным объектом события одному из участников обмена посылается заранее подготовленная дезинформация. При этом такая дезинформация в зависимости от контролируемого события может быть воспри-нята либо как исполняемый код, либо как данные. Рассмотрим пример подобного рода дезинформации.
 Предположим, что ложный объект контролирует событие, которое состоит в подключении пользователя к серверу. В этом случае он ожидает, например, запуска соответствующей программы входа в систему. В случае, если эта программа находится на сервере, то при ее запуске исполняемый файл передается на рабочую станцию. Вместо того, чтобы выполнить данное действие, ложный объект передает на рабочую станцию код заранее написанной специальной программы - захватчика паролей. Эта программа выполняет визуально те же действия, что и настоящая программа входа в систему, например, запрашивая имя и пароль пользователя, после чего полученные сведения посылаются на ложный объект, а пользователю выводится сообщение об ошибке. При этом пользователь, посчитав, что он неправильно ввел пароль (пароль обычно не отображается на экране) снова запустит программу подключения к системе (на этот раз настоящую) и со второго раза получит доступ. Результат такой атаки - имя и пароль пользователя, сохраненные на ложном объекте.
Отказ в обслуживании
 Одной из основных задач, возлагаемых на сетевую ОС, функционирующую на каждом из объектов распределенной ВС, является обеспечение надежного удаленного доступа с любого объекта сети к данному объекту. В общем случае в распределенной ВС каждый субъект системы должен иметь возможность подключиться к любому объекту РВС и получить в соответствии со своими правами удаленный доступ к его ресурсам. Обычно в вычислительных сетях возможность предоставления удаленного доступа реализуется следующим образом: на объекте РВС в сетевой ОС запускаются на выполнение ряд программ-серверов (например, FTP-сервер, WWW-сервер и т.п.), предоставляющих удаленный доступ к ресурсам данного объекта. Данные программы-серверы входят в состав телекоммуникационных служб предоставления удаленного доступа. Задача сервера состоит в том, чтобы, находясь в памяти операционной системы объекта РВС, постоянно ожидать получения запроса на подключение от удаленного объекта. В случае получения подобного запроса сервер должен по возможности передать на запросивший объект ответ, в котором либо разрешить подключение, либо нет (под-ключение к серверу специально описано очень схематично, так как подробности в данный момент не имеют значения). По аналогичной схеме происходит создание виртуального канала связи, по которому обычно взаимодействуют объекты РВС. В этом случае непосредственно ядро сетевой ОС обрабатывает приходящие извне запросы на создание виртуального канала (ВК) и передает их в соответствии с идентификатором запроса (порт или сокет) прикладному процессу, которым является соответствующий сервер.
 Очевидно, что сетевая операционная система способна иметь только ограниченное число открытых виртуальных соединений и отвечать лишь на ограниченное число запросов. Эти ограничения зависят от различных параметров системы в целом, основными из которых являются быстродействие ЭВМ, объем оперативной памяти и пропускная способность канала связи (чем она выше, тем больше число возможных запросов в единицу времени).
 Основная проблема состоит в том, что при отсутствии статической ключевой информации в РВС идентификация запроса возможна только по адресу его отправителя. Если в распределенной ВС не предусмотрено средств аутентификации адреса отправителя, то есть инфраструктура РВС позволяет с одного объекта системы передавать на другой атакуемый объект бесконечное число анонимных запросов на подключение от имени других объектов, то в этом случае будет иметь успех типовая удаленная атака "Отказ в обслуживании". Результат применения этой удаленной атаки - нарушение на атакованном объекте работоспособности соответствующей службы предоставления удаленного доступа, то есть невозможность получения удаленного доступа с других объектов РВС - отказ в обслуживании!
 Вторая разновидность этой типовой удаленной атаки состоит в передаче с одного адреса такого количества запросов на атакуемый объект, какое позволит трафик (направленный "шторм" запросов). В этом случае, если в системе не предусмотрены правила, ограничивающие число принимаемых запросов с одного объекта (адреса) в единицу времени, то результатом этой атаки может являться как переполнение очереди запросов и отказа одной из телекоммуникационных служб, так и полная остановка компьютера из-за невозможности системы заниматься ничем другим, кроме обработки запросов.
 И последней, третьей разновидностью атаки "Отказ в обслуживании" является передача на атакуемый объект некорректного, специально подобранного запроса. В этом случае при наличии ошибок в удаленной системе возможно зацикливание процедуры обработки запроса, переполнение буфера с последующим зависанием системы и т. п.
 Типовая удаленная атака "Отказ в обслуживании" является активным воздействием, осуществляемым с целью нарушения работоспособности системы безусловно относительно цели атаки. Данная УА является однонаправленным воздействием как межсегментным, так и внутрисегментным, осуществляемым на транспортном и прикладном (7) уровнях модели OSI.
В таблице приведена схема классификации типовых удаленных атак на РВС
 
Табл. 1. Классификация типовых удаленных атак на распределенные ВС

4. Причины успеха удаленных атак на распределенные вычислительные системы
 В предыдущей главе было показано, что общие принципы построения распределенных ВС позволяют выделить в отдельный класс угрозы, характеризующие только распределенные системы. Было введено такое понятие, как типовая удаленная атака, и были предложены механизмы реализации удаленных атак (УА) всех типов. Понятие типовой УА позволило классифицировать угрозы безопасности распределенным ВС вообще, поскольку типовые УА инвариантны по отношению к конкретному типу РВС. Инвариантность типовых УА основана на том, что они направлены на основополагающие принципы построения, заложенные в инфраструктуру любой распределенной системы.
 Предложенные в этой работе описание, характеристика и классификация основных типов УА позволяют говорить о практической методике исследования безопасности РВС. Основой этой методики является последовательное осуществление УА всех типов; при этом основным средством анализа безопасности сетевого взаимодействия объектов распределенной системы будет являться сетевой анализ (анализ сетевого трафика).
 Итак, в данной главе будут подробно рассмотрены основные причины, из-за которых возможны удаленные атаки. Наша цель состоит в том, чтобы сформулировать те принципы и требования, которые ликвидировали бы причины успеха УА и, руководствуясь которыми, было бы возможно построение распределенной ВС с защищенным сетевым взаимодействием ее удаленных компонентов.
 Основные вопросы, на которые попытается дать ответы данная глава, это: "почему возможны удаленные атаки" и "в чем причины их успеха"? Анализ механизмов реализации типовых УА позволяет сформулировать причины, по которым данные удаленные атаки оказались возможными. Особо отметим, что рассматриваемые ниже причины основываются на базовых принципах построения сетевого взаимодействия объектов распределенной ВС.
 В этой главе мы разберем только причины успеха УА на инфраструктуру и базовые протоколы сети, а не УА на телекоммуникационные службы. Для устранения причин атак первого типа зачастую необходимо либо отказаться от определенных служб (DNS, например), либо изменить конфигурацию системы (наличие широковещательной среды приводит к возможности прослушивания канала, осуществляемого программным образом), либо изменить систему в целом. Все дело в том, что причины успеха удаленных атак данного типа кроются в инфраструктуре распределенной ВС, поэтому создание таксономии причин их успеха представляется весьма важной задачей, решение которой позволит выработать принципы построения защищенного взаимодействия в РВС.
 Итак, рассмотрим возможные причины успеха УА на инфраструктуру и базовые протоколы распределенных ВС.
1. Отсутствие выделенного канала связи между объектами РВС
2. Недостаточная идентификация и аутентификация объектов и субъектов РВС
3. Взаимодействие объектов без установления виртуального канала
4. Использование нестойких алгоритмов идентификации объектов при создании виртуального канала
5. Отсутствие контроля за виртуальными каналами связи между объектами РВС
6. Отсутствие в РВС возможности контроля за маршрутом сообщений
7. Отсутствие в РВС полной информации о ее объектах
8. Отсутствие в РВС криптозащиты сообщений
1. Отсутствие выделенного канала связи между объектами РВС
 В предыдущих главах была рассмотрена типовая УА "Анализ сетевого трафика". Кратко напомним, что данная атака заключается в прослушивании канала передачи сообщений в сети. Результат этой атаки во-первых, выяснение логики работы распределенной ВС и, во-вторых, перехват потока информации, которой обмениваются объекты системы. Такая атака программно возможна только в случае, если атакующий находится в сети с физически широковещательной средой передачи данных как, например, всем известная и получившая широкое распространение среда Ethernet  (в отличие от Token Ring , которая не является широковещательной, но и не имеет достаточного распространения). Очевидно, что данная УА была бы программно невозможна, если бы у каждого объекта системы существовал для связи с любым другим объектом выделенный канал (вариант физического прослушивания выделенного канала не рассматривается, так как без специфических аппаратных средств подключение к выделенному каналу невозможно).
Следовательно, причина успеха данной типовой УА - наличие широковещательной среды передачи данных или отсутствие выделенного канала связи между объектами РВС.
2. Недостаточная идентификация и аутентификация объектов и субъектов РВС
 Как уже подчеркивалось в предыдущих главах, проблема идентификации и аутентификации субъектов и объектов РВС имеет чрезвычайно важное значение. От успеха ее решения зависит безопасность распределенной ВС в целом. Примеры успешно осуществленных удаленных атак, рассмотренные в предыдущих главах, доказывают, что отсутствие у разработчиков определенной заранее выработанной концепции и принципов идентификации объектов РВС в целом оставляют атакующему потенциальные возможности для компрометации объектов системы. Стандартными способами компрометации субъектов и объектов РВС являются:
 выдача себя за определенный объект или субъект с присвоением его прав и полномочий для доступа в систему (например, типовая УА "Подмена доверенного субъекта или объекта РВС");
 внедрение в систему ложного объекта, выдающего себя за доверенный объект системы (например, типовая УА "Ложный объект РВС").
3. Взаимодействие объектов без установления виртуального канала
 Одним из важнейших вопросов, на который необходимо ответить, говоря об идентификации/аутентификации объектов/субъектов РВС, является вопрос о видах взаимодействия между субъектами и объектами в распределенной ВС. Как отмечалось ранее, взаимодействие между субъектами и объектами РВС бывает двух видов:
 с использованием виртуального канала,
 без использования виртуального канала.
 Практика показывает, что 99% взаимодействия между объектами в сети Internet проходит с установлением ВК (при любом FTP-, TELNET-, HTTP- и т. п. подключении используется протокол TCP, а, следовательно, создается ВК). Это происходит из-за того, что взаимодействие по виртуальному каналу является единственным динамическим способом защиты сетевого соединения объектов РВС. Дело в том, что в процессе создания ВК объекты РВС обмениваются динамически вырабатываемой ключевой информацией, позволяющей уникально идентифицировать канал. В противном случае для идентификации объектов распределенной системы пришлось бы использовать массив статической идентификационной информации, уникальной для каждого объекта в системе. А это означает, что мы получаем стандартную проблему статического распределения ключей (матрица NхN), которая решается только на ограниченном подмножестве объектов. Очевидно, что задача статического распределения ключей на сегодняшний день в принципе не может быть решена в сети Internet, да этого и не требуется.
 Итак, мы показали, что идентификация объектов РВС, при отсутствии статической ключевой информации, возможна только при взаимодействии объектов с использованием виртуального канала. Это, в свою очередь, означает, что взаимодействие объектов без установления ВК является одной из возможных причин успеха удаленных атак на РВС.
 Но ошибочно считать распределенную вычислительную систему безопасной, даже если все взаимодействие объектов происходит с созданием ВК. Об этом речь пойдет в следующем пункте.
4. Использование нестойких алгоритмов идентификации объектов при создании виртуального канала
 Ошибочно считать взаимодействие объектов по виртуальному каналу в распределенной ВС панацеей от всех проблем, связанных с идентификацией объектов РВС. ВК является необходимым, но не достаточным условием безо-пасного взаимодействия. Чрезвычайно важным в данном случае становится выбор алгоритма идентификации при создании ВК. Основное требование, которое следует предъявлять к данным алгоритмам, состоит в следующем: перехват ключевой информации, которой обмениваются объекты РВС при создании ВК не должен позволить атакующему получить итоговые идентификаторы канала и объектов. Это требование по сути очевидно. Оно должно предъявляться к алгоритмам идентификации исходя из принципиальной возможности прослушивания атакующим канала передачи. Однако в большинстве существующих сетевых ОС в базовых алгоритмах идентификации, используемых при создании ВК, этим требованием разработчики практически пренебрегают. Так, например, в ОС Novell NetWare 3.12- 4.1 идентификатор канала - это число в диапазоне 0-FFh, идентификатор объекта (рабочей станции или файл-сервера) - также число от 0 до FFh; в протоколе TCP идентификаторами канала и объектов являются два 32-битных числа, формируемых в процессе создания TCP-соединения.
 Из всего сказанного ясно, что создание виртуального канала с использованием нестойкого алгоритма идентификации не позволяет надежно обезопасить РВС от подмены объектов взаимодействия и выступает одной из причин успеха удаленных атак на распределенные вычислительные системы.
5. Отсутствие контроля за виртуальными каналами связи между объектами РВС
 Как было показано ранее, объекты распределенной ВС, взаимодействующие по виртуальным каналам, могут подвергаться типовой УА "Отказ в обслуживании" . Особенность этой атаки состоит в том, что, действуя абсолютно легальными средствами системы, можно удаленно добиться нарушения ее работоспособности. Напомним, что, данная УА реализуется передачей множественных запросов на создание соединения (виртуального канала), в результате чего либо переполняется число возможных соединений, либо система, занятая обработкой ответов на запросы, вообще перестает функционировать. В чем причина успеха данной УА? В предыдущем пункте было показано, что взаимодействие объектов РВС по виртуальным каналам позволяет единственным способом обеспечить защиту соединения в глобальной сети. Однако в использовании ВК есть как несомненные плюсы, так и очевидные минусы. К минусам относится необходимость контроля над соединением. При этом задача контроля распадается на две подзадачи:
 контроль за созданием соединения;
 контроль за использованием соединения.
 Если вторая задача решается довольно просто (обычно соединение разрывается по тайм-ауту, определенному системой - так сделано во всех известных сетевых ОС), то решение задачи контроля за созданием соединения представляется нетривиальным. Именно отсутствие приемлемого решения этой задачи является основной причиной успеха типовой УА "Отказ в обслуживании" . Сложность контроля над созданием ВК состоит в том, что в системе, в которой отсутствует статическая ключевая информация о всех ее объектах, невозможно отделить ложные запросы на создание соединения от настоящих. Очевидно также, что если один субъект сетевого взаимодействия будет иметь возможность анонимно занимать неограниченное число каналов связи с удаленным объектом, то подобная система может быть полностью парализована данным субъектом (пример - существующая сеть Internet в стандарте IPv4)! Поэтому, если любой объект в распределенной системе может анонимно послать сообщение от имени любого другого объекта (например, в Internet маршрутизаторы не проверяют IP-адрес источника отправления), то в подобной распределенной ВС в принципе невозможен контроль за созданием виртуальных соединений. Поэтому основная причина, по которой возможна типовая УА "Отказ в обслуживании" и ей подобные - это отсутствие в РВС возможности контроля за маршрутом сообщений.
6. Отсутствие в РВС возможности контроля за маршрутом сообщений
 В распределенных ВС в качестве начальной идентифицирующей объект информации обычно выступает его адрес. Под адресом в РВС понимается определенная системой уникальная информация, которой он наделяется при внесении в систему. Теперь все сообщения от других объектов РВС, адресованные на этот адрес, поступят на данный объект. Путь, или, как принято говорить, маршрут сообщения определяется топологией РВС и проходит через совокупность узлов-маршрутизаторов. Следовательно, в каждом приходящем на объект РВС пакете может быть полностью отмечен его маршрут - список адресов маршрутизаторов, пройденных на пути к адресату. Этот отмеченный в пакете маршрут станет информацией, аутентифицирующей (подтверждающей) с точностью до подсети, подлинность адреса субъекта, отославшего сообщение. Другой вариант аутентификации адреса отправителя - фильтрация маршрутизатором пакетов с неверным адресом отправителя.
 Если в РВС не предусмотреть подобных возможностей контроля за маршрутом сообщения, то адрес отправителя сообщения оказывается ничем не подтвержден. Таким образом, в системе будет существовать возможность отправки сообщения от имени любого объекта системы, а именно путем указания в заголовке сообщения чужого адреса отправителя. Также в подобной РВС будет невозможно определить, откуда на самом деле пришло сообщение, а, следовательно, вычислить координаты атакующего (в сети Internet невозможно доступным способом вычислить инициатора однонаправленной удаленной атаки).
 Таким образом, мы убеждаемся, что отсутствие в распределенной ВС возможности контроля за маршрутом сообщений порождает, во-первых, невозможность контроля за созданием соединений, и, во-вторых, возможность анонимной отправки сообщения, следовательно является причиной успеха удаленных атак на РВС.
7. Отсутствие в РВС полной информации о ее объектах
 В распределенной системе с разветвленной структурой, состоящей из большого числа объектов, может возникнуть ситуация, когда для доступа к определенному объекту системы у субъекта взаимодействия может не оказаться необходимой информации об интересующем объекте. Обычно такой недостающей информацией об объекте является его адрес. Такая ситуация характерна и вполне объяснима для сетей с разветвленной структурой.
 Объясним это на простом примере. Предположим, что пользователь сети Internet решил подключиться, например, к WWW-серверу фирмы Novell. Он знает ее название, но не имеет информации об IP-адресе или имени ее сервера. В этом случае пользователь может послать широковещательный запрос всем хостам в сети с надеждой, что запрос дойдет до интересующего его сервера, и тот в ответ пришлет столь нужный для пользователя адрес. Очевидно, что в глобальной сети использование данной схемы по меньшей мере неразумно. Поэтому для подобных целей пользователь может подключиться к ближайшему известному ему поисковому серверу (Altavista, например) и послать запрос на поиск адреса интересующей его фирмы в базе данных информационного сервера.
 Рассмотренный выше пример наглядно описывает возможные алгоритмы удаленного поиска (см. соотв. пункт), которые используют объекты РВС. В первом случае, когда поиск осуществляется внутри сегмента сети, субъект системы посылает широковещательный запрос, который получают все объекты РВС, и тот из них, для кого предназначался запрос, передает в ответ необходимую для адресации информацию. Во втором случае, когда необходимо осуществить глобальный поиск, субъект распределенной системы посылает запрос на ближайший информационно-поисковый сервер, который, просканировав свою базу данных в поисках адреса запрашиваемого ресурса, либо отошлет в ответ на запрос найденный адрес, либо обратится к следующему в системе поисково-информационному серверу. Таким образом, если в распределенной ВС существуют объекты, информация о которых не определена, то для обеспечения ее нормального функционирования необходимо использование описанных выше алгоритмов удаленного поиска.
 Примером РВС с заложенной неопределенностью является сеть Internet, в которой, во-первых, у хостов, находящихся в одном сегменте, может не быть информации об аппаратных адресах друг друга, и, во-вторых, применяются непригодные для непосредственной адресации мнемонические имена хостов, используемые для удобства пользователей при обращении к удаленным системам.
 На наш взгляд, очевиден тот факт, что в системе с заложенной в нее неопределенностью существуют потенциальные возможности внесения в систему ложного объекта и выдачи одного объекта системы за другой. Этот факт объясняется тем, что, являясь следствием неопределенности системы, алгоритмы удаленного поиска несут в себе потенциальную угрозу, состоящую в том, что на посланный запрос может прийти ложный ответ, в котором вместо информации о запрашиваемом объекте будет информация о ложном объекте. Вследствие этого распределенная ВС с заложенной неопределенностью является потенциально опасной системой и может подвергаться удаленным атакам.
8. Отсутствие в РВС криптозащиты сообщений
 В распределенных ВС связь между объектами системы осуществляется по каналам связи. Поэтому всегда существует принципиальная возможность для атакующего прослушать канал и получить несанкционированный доступ к информации, которой обмениваются по сети ее абоненты. В том случае, если проходящая по каналу информация не зашифрована и атакующий каким-либо образом получает доступ к каналу, то УА "Анализ сетевого трафика" является наиболее эффективным способом получения информации. Очевидна и причина, делающая эту атаку столь эффективной. Эта причина - передача по сети незашифрованной информации.
 Использование криптостойких алгоритмов шифрования пакетов обмена между объектами РВС на канальном, прикладном уровнях делает анализ сетевого трафика практически бессмысленным. В случае канального шифрования, которое обычно выполняется аппаратно, по сети передаются полностью зашифрованные пакеты. В том случае, если в сети используются алгоритмы шифрования пакетов на сетевом - прикладном уровнях, то шифрация применяется только к полям данных пакетов соответствующих уровней, то есть заголовки пакетов, содержащие служебную информацию, не являются зашифрованными, поэтому атакующий имеет возможность, перехватив пакет, подвергнуть анализу данную служебную информацию.
5. Принципы создания защищенных систем связи в распределенных вычислительных системах
 В предыдущей главе были рассмотрены основные причины нарушения информационной безопасности распределенных вычислительных систем по каналам связи. Описанные выше причины успеха удаленных атак на распределенные системы наглядно продемонстрировали, что несоблюдение требований безопасности к защищенным системам связи удаленных объектов РВС приводит к нарушению безопасности системы в целом. Поэтому данная глава и будет посвящена выработке требований защищенного взаимодействия в распределенной ВС. Основной вопрос, на который мы постараемся здесь ответить, это - из каких принципов необходимо исходить при построении защищенной системы связи удаленных объектов распределенной ВС. Итак, далее речь пойдет о технологии создания защищенных систем связи объектов в РВС.
 Очевидно, что при построении защищенных систем следует бороться не с угрозами, являющимися следствием недостатков системы, а с причинами возможного успеха атак. Ясно, что для того, чтобы победить следствие, надо устранить причину. Поэтому, чтобы ликвидировать угрозы (удаленные атаки), осуществляемые по каналам связи, необходимо ликвидировать причины, их порождающие. Это основной принцип, руководствуясь которым, далее мы и сформулируем требования к защищенным системам связи в распределенных ВС.
5.1 Выделенный канал связи между объектами распределенной ВС
 Все объекты распределенной ВС взаимодействуют между собой по каналам связи. В пред. главе (см. "Отсутствие выделенного канала связи")рассматривалась причина успеха УА, состоящая в использовании в РВС для связи между объектами широковещательной среды передачи которое означает, что все объекты распределенной ВС подключаются к одной общей шине. Это приводит к тому, что сообщение, предназначенное (адресованное) только одному объекту системы, будет получено всеми ее объектами. Однако только объект, адрес которого указан в заголовке сообщения как адрес назначения, будет считаться тем объектом, кому это сообщение непосредственно направлялось. Очевидно, что в РВС с топологией "общая шина" необходимо использовать специальные методы идентификации объектов (см. "Виртуальный канал как средство обеспечения дополнительной идентификации объектов РВС"), так как идентификация на канальном уровне возможна только в случае использования сетевых криптокарт.
 Также очевидно, что идеальной с точки зрения безопасности будет взаимодействие объектов распределенной ВС по выделенным каналам. Существуют два возможных способа организации топологии распределенной ВС с выделенными каналами. В первом случае каждый объект связывается физическими линиями связи со всеми объектами системы. Во втором случае в системе может использоваться сетевой концентратор, через который осуществляется связь между объектами (топология "звезда").
 Плюсы распределенной ВС с выделенными каналами связи между объектами состоят в следующем:
 передача сообщений осуществляется напрямую между источником и приемником, минуя остальные объекты системы. В такой системе в случае отсутствия доступа к объектам, через которые осуществляется передача сообщения, не существует программной возможности для анализа сетевого трафика;
 имеется возможность идентифицировать объекты распределенной системы на канальном уровне по их адресам без использования специальных криптоалгоритмов шифрования трафика. Это оказывается, поскольку система построена так, что по данному выделенному каналу осуществима связь только с одним определенным объектом. Появление в такой распределенной системе ложного объекта невозможно без аппаратного вмешательства (подключение дополнительного устройства к каналу связи);
 система с выделенными каналами связи - это система, в которой отсутствует неопределенность с информацией о ее объектах. Каждый объект в такой системе изначально однозначно идентифицируется и обладает полной информацией о других объектах системы.
К минусам РВС с выделенными каналами относятся:
 сложность реализации и высокие затраты на создание системы;
 ограниченное число объектов системы (зависит от числа входов у концентратора);
 сложность внесения в систему нового объекта.
  Очевидно также, что создание глобальной РВС с выделенными каналами потребует колоссальных затрат и возможно на сегодняшний день.
Анализируя все плюсы и минусы использования выделенных каналов для построения защищенных систем связи между объектами РВС, можно сделать вывод, что создание распределенных систем только с использованием широковещательной среды передачи или только с выделенными каналами неэффективно. Поэтому представляется правильным при построении распределенных вычислительных систем с разветвленной топологией и большим числом объектов использовать комбинированные варианты соединений объектов. Для обеспечения связи между объектами большой степени значимости можно использовать выделенный канал. Связь менее значимых объектов системы может осуществляться с использованием комбинации общая шина-выделенный канал.
 В данном пункте были рассмотрены варианты сетевых топологий с выделенными каналами связи. При этом рассматривались только физические каналы связи и предлагались более или менее безопасные способы взаимодействия объектов системы по этим каналам. Однако выбор безопасной топологии РВС является необходимым, но отнюдь не достаточным условием для создания защищенных систем связи между объектами распределенных ВС.
Итак, в завершение данного пункта сформулируем первый принцип создания защищенных средств связи объектов в РВС:
Утверждение 1.
Наилучшее с точки зрения безопасности взаимодействие объектов в распределенной ВС возможно только по физически выделенному каналу.
5.2 Виртуальный канал как средство обеспечения дополнительной идентификации/аутентификации объектов в распределенной ВС
 В предыдущем пункте рассматривались возможные наиболее безопасные варианты физического построения сети: как в РВС необходимо соединять объекты для обеспечения наиболее безопасного взаимодействия. Однако, для создания защищенного взаимодействия удаленных объектов подобных мер явно недостаточно, так как, во-первых, на практике обеспечить взаимодействие всех объектов по выделенному каналу достаточно сложно и, во-вторых, нельзя не предусмотреть вариант физического подключения к каналу. Следовательно, разработчик защищенной системы связи в распределенной ВС должен исходить из следующего принципа:
Утверждение 2.
При построении защищенной системы связи в распределенной ВС необходимо исходить из того, что все сообщения, передаваемые по каналу связи, могут быть перехвачены, но это не должно повлечь за собой нарушения безопасности системы в целом.
 Таким образом, данное утверждение накладывает на разработчика следующие требования: необходимость введения дополнительных средств идентификации объектов в распределенной ВС и криптозащита передаваемых по каналу связи сообщений.
 В пред. главе доказывалось, что идентификация объектов РВС, в отсутствие статической ключевой информации, возможна только при взаимодействии объектов с использованием виртуального канала (заметим, что в дальнейшем рассматривается только распределенная ВС, у объектов которой отсутствует ключевая информация для связи друг с другом - в подобной системе решить задачу безопасного взаимодействия несколько сложнее). Следовательно, для того, чтобы ликвидировать причину успеха удаленных атак, описанную в пред. главе, а также, исходя из Утверждения 2, необходимо руководствоваться следующим правилом:
Утверждение 3.
Любое взаимодействие двух объектов в распределенной ВС должно проходить по виртуальному каналу связи.
 Рассмотрим, как в распределенной ВС виртуальный канал (ВК) связи может использоваться для надежной, независимой от топологии и физической организации системы, идентификации ее удаленных объектов.
 Для этого при создании ВК могут использоваться криптоалгоритмы с открытым ключом (например, в Internet принят подобный стандарт защиты ВК, называемый Secure Socket Layer - SSL). Данные криптоалгоритмы основаны на результатах исследований, полученных в 70-х годах У. Диффи. Он ввел понятие односторонней функции с потайным входом. Это не просто вычисляемая в одну сторону функция, обращение которой невозможно, она содержит потайной вход (trapdoor), который позволяет вычислять обратную функцию лицу, знающему секретный ключ. Сущность криптографии с открытым ключом (или двухключевой криптографии) в том, что ключи, имеющиеся в криптосистеме, входят в нее парами и каждая пара удовлетворяет следующим двум свойствам:
 текст, зашифрованный на одном ключе, может быть дешифрован на другом;
 знание одного ключа не позволяет вычислить другой.
 Поэтому один из ключей может быть опубликован. При опубликованном (открытом) ключе шифрования и секретном ключе дешифрования получается система шифрования с открытым ключом. Каждый пользователь сети связи может зашифровать сообщение при помощи открытого ключа, а расшифровать его сможет только владелец секретного ключа. При опубликовании ключа дешифрования получается система цифровой подписи. Здесь только владелец секретного ключа создания подписи может правильно зашифровать текст (т.е. подписать его), а проверить подпись (дешифровать текст) может любой на основании опубликованного ключа проверки подписи.
 В 1976 г. У. Диффи и М. Хеллман предложили следующий метод открытого распределения ключей. Пусть два объекта A и B условились о выборе в качестве общей начальной информации большого простого числа p и примитивного корня степени p - 1 из 1 в поле вычетов по модулю p. Тогда эти пользователи действуют в соответствии с протоколом (рис. 1):
A вырабатывает случайное число x, вычисляет число ax (mod p) и посылает его B;
B вырабатывает случайное число y, вычисляет число ay (mod p) и посылает его A;
затем A и B возводят полученное число в степень со своим показателем и получают число axy (mod p).

Рис. 4. Алгоритм У. Диффи и М. Хеллмана открытого распределения ключей
 Это число и является сеансовым ключом для одноключевого алгоритма, например, DES. Для раскрытия этого ключа криптоаналитику необходимо по известным ax (mod p), ay (mod p) найти axy (mod p) , т.е. найти x или y. Нахождение числа x по его экспоненте ax (mod p) называется задачей дискретного логарифмирования в простом поле. Эта задача является труднорешаемой, и поэтому полученный ключ, в принципе, может быть стойким.
 Особенность данного криптоалгоритма состоит в том, что перехват по каналу связи пересылаемых в процессе создания виртуального канала сообщений ax (mod p) и ay (mod p) не позволит атакующему получить конечный ключ шифрования axy (mod p). Этот ключ далее должен использоваться, во-первых, для цифровой подписи сообщений и, во-вторых, для их криптозащиты. Цифровая подпись сообщений позволяет надежно идентифицировать объект распределенной ВС и виртуальный канал. Шифрование сообщений необходимо для соблюдения Утверждения 2. В заключении к данному пункту сформулируем следующее требование к созданию защищенных систем связи в распределенных ВС и два следствия из него:
Утверждение 4.
Для обеспечения надежной идентификации объектов распределенной ВС при создании виртуального канала необходимо использовать криптоалгоритмы с открытым ключом.
Следствие 4.1.
Необходимо обеспечить цифровую подпись сообщений.
Следствие 4.2.
Необходимо обеспечить возможность шифрования сообщений.
5.3 Контроль за маршрутом сообщения в распределенной ВС
 Как известно, каждый объект распределенной ВС должен обладать адресом, уникально его идентифицирующим. Для того, чтобы сообщение от одного объекта было передано на другой объект системы, оно должно пройти через цепь маршрутизаторов, задача которых - проанализировав адрес назначения, указанный в сообщении, выбрать оптимальный маршрут и, исходя из него, переправить пакет или на следующий маршрутизатор или непосредственно абоненту, если он напрямую подключен к данному узлу. Таким образом, маршрут до объекта определяется цепочкой узлов, пройденных сообщением. Как было показано ранее, маршрут сообщения может являться информацией, аутентифицирующей с точностью до подсети подлинность адреса субъекта, отославшего сообщение. Очевидно, что перед любой системой связи объектов в РВС встает стандартная проблема проверки подлинности адреса сообщения, пришедшего на объект. Эту задачу, с одной стороны, можно решить, введя дополнительную идентификацию сообщений на другом, более высоком уровне OSI. Так, адресация осуществляется на сетевом уровне, а дополнительная идентификация, например, на транспортном. Однако подобное решение не позволит избежать проблемы контроля за созданием соединений, так как дополнительная идентификация абонентов будет возможна только после создания соединения. Поэтому разработчикам распределенной ВС можно предложить следующие пути решения проблемы.
 В первом случае функцию проверки подлинности адреса отправителя можно возложить на маршрутизатор. Это несложно сделать, так как маршрутизатор может отследить, откуда к нему пришел пакет (от другого маршрутизатора или от подключенного к нему хоста из подсетей, напрямую подключенных к данному маршрутизатору). Маршрутизатор может проверять соответствие адреса отправителя с адресом соответствующей подсети, откуда пришло сообщение. В случае совпадения сообщение пересылается далее, а в противном случае - отфильтровывается. Этот способ позволит на начальной стадии отбросить пакеты с неверными адресами отправителя.
 Другой вариант решения может состоять в создании в заголовке пакета специальных полей, куда каждый маршрутизатор, через который проходит пакет, заносит маршрутную информацию (часть своего адреса, например). При этом первый маршрутизатор, на который поступил пакет, заносит также информацию о классе сети (A, B, C), откуда пришел пакет. Тем не менее, внесение в пакет адресов всех пройденных по пути маршрутизаторов будет неоптимальным решением, так как в этом случае сложно заранее определить максимальный размер заголовка пакета.
 Когда сообщение дойдет до конечного адресата, в его заголовке будет полностью отмечен пройденный маршрут. По этому маршруту, вне зависимости от указанного в пакете сетевого адреса отправителя, можно, во-первых, с точностью до подсети идентифицировать подлинность адреса и, во-вторых, определить с точностью до подсети истинный адрес отправителя. Итак, получив подобное сообщение с указанным маршрутом, сетевая операционная система анализирует маршрут и проверяет подлинность адреса отправителя. В случае его недостоверности пакет отбрасывается.
 Из всего вышесказанного следует следующее требование к созданию защищенных систем связи в распределенных ВС:
Утверждение 5.
В распределенной ВС необходимо обеспечить на сетевом уровне контроль за маршрутом сообщений для аутентификации адреса отправителя.
5.4 Контроль за виртуальными соединениями в распределенной ВС
 В предыдущей главе было показано, что взаимодействие объектов РВС по виртуальному каналу позволяет надежно защитить соединение от возможных информационно-разрушающих воздействий по каналам связи. Однако взаимодействие по ВК имеет свои минусы. К минусам относится необходимость контроля за соединением. Если в системе связи удаленных объектов РВС не предусмотреть использование надежных алгоритмов контроля за соединением, то, избавившись от одного типа удаленных атак на соединение ("Подмена доверенного объекта"), можно подставить систему под другую типовую УА - "Отказ в обслуживании". Поэтому для обеспечения надежного функционирования и работоспособности (доступности) каждого объекта распределенной ВС необходимо прежде всего контролировать процесс создания соединения. Как уже говорилось ранее, задача контроля за ВК распадается на две подзадачи:
 контроль за созданием соединения;
 контроль за использованием соединения.
 Решение второй задачи лежит на поверхности: так как сетевая операционная система не может одновременно иметь бесконечное число открытых ВК, то в том случае, если ВК простаивает в течение определенного системой тайм-аута, происходит его закрытие.
 Далее рассмотрим возможный алгоритм, позволяющий обеспечить контроль за созданием соединения в РВС.
 Основная задача, которую необходимо решить в данном случае, состоит в том, чтобы не позволить одному субъекту взаимодействия занять все виртуальные каналы системы. Напомним, что при создании ВК полученный системой запрос на создание соединения ставится в очередь запросов, и, когда до него дойдет время, система выработает ответ на запрос и отошлет его обратно отправителю запроса. Задача контроля за созданием соединения заключается как раз в том, чтобы определить те правила, исходя из которых система могла бы либо поставить запрос в очередь, либо нет. Если все пришедшие запросы автоматически ставятся системой в очередь (так построены все сетевые ОС, поддерживающие протокол TCP/IP), то это в случае атаки ведет к переполнению очереди и к отказу в обслуживании всех остальных легальных запросов. Такое происходит из-за того, что атакующий посылает в секунду столько запросов, сколько позволит трафик (тысячи запросов в секунду), а обычный пользователь с легальным запросом на подключение может послать лишь несколько запросов в минуту! Следовательно, вероятность подключения втакой ситуации, при условии переполнения очереди, один к миллиону в лучшем случае. Поэтому необходимо ввести ограничения на постановку в очередь запросов от одного объекта. Однако, если в РВС любой объект системы может послать запрос от имени (с адреса) любого другого объекта системы, то, как отмечалось ранее, решить задачу контроля не представляется возможным. Поэтому для обеспечения этой возможности было введено Утверждение 5, исходя из которого в каждом пришедшем на объект пакете должен быть указан пройденный им маршрут, позволяющий с точностью до подсети подтвердить подлинность адреса отправителя. Учитывая данный факт, позволяющий отсеять все пакеты с неверным адресом отправителя, можно предложить следующее условие постановки запроса в очередь: в системе вводится ограничение на число обрабатываемых в секунду запросов из одной подсети.
 Это максимальное число ставящихся в очередь запросов в секунду определяется непосредственно операционной системой и зависит от следующих параметров сетевой ОС: быстродействия, объема виртуальной памяти, числа одновременно обслуживаемых виртуальных каналов, длины очереди и т.д. Вводимое ограничение не позволит атакующему переполнить очередь, так как только первые несколько его запросов будут поставлены в очередь на обслуживание, а остальные будут игнорироваться. Первый же запрос легального пользователя из другой подсети будет также сразу поставлен в очередь.
 К минусам этого способа решения проблемы контроля за созданием соединения можно отнести тот факт, что, так как адрес отправителя можно аутентифицировать с точностью только до подсети, то атакующий может посылать запросы от имени любого объекта данной подсети. Следовательно, в случае атаки все остальные объекты из подсети атакующего будут лишены возможности подключения к атакуемому объекту. Однако, так как, во-первых, атакующего по указанному в пакете маршруту можно будет вычислить с точностью до его подсети и, во-вторых, не произойдет нарушения работоспособности цели атаки, то такая атака вряд ли будет иметь смысл.
 Итак, в завершение очередное требование к защищенным системам связи в распределенных ВС.
Утверждение 6.
Для обеспечения доступности ресурсов распределенной ВС необходим контроль за виртуальными соединениями между ее объектами.
Следствие 6.1.
Необходимо обеспечить контроль за созданием соединения, введя ограничение на число обрабатываемых в секунду запросов из одной подсети.
Следствие 6.2.
Необходимо обеспечить контроль за использованием соединения, разрывая его по тайм-ауту в случае отсутствия сообщений.
5.5 Проектирование распределенной ВС с полностью определенной информацией о ее объектах с целью исключения алгоритмов удаленного поиска
 Одной из особенностей распределенной ВС является возможное отсутствие информации, необходимой для доступа к ее удаленным объектам. Поэтому в РВС возникает необходимость использования потенциально опасных с точки зрения безопасности алгоритмов удаленного поиска. Следовательно, для того, чтобы в РВС не возникало необходимости в использовании данных алгоритмов, требуется на начальном этапе спроектировать систему так, чтобы информация о ее объектах была изначально полностью определена. Это позволит, в свою очередь, ликвидировать одну из причин успеха удаленных атак, связанных с использованием в распределенной ВС алгоритмов удаленного поиска.
 Однако в РВС с неопределенным и достаточно большим числом объектов (например, Internet) спроектировать систему с отсутствием неопределенности практически невозможно. В этом случае отказаться от алгоритмов удаленного поиска не представляется возможным.
 Существуют два типа данных алгоритмов. Первый типовой алгоритм удаленного поиска - с использованием информационно-поискового сервера, второй - с использованием широковещательных запросов. Применение в РВС алгоритма удаленного поиска с использованием широковещательных запросов в принципе не позволяет защитить систему от внедрения в нее ложного объекта, а, следовательно, использование данного алгоритма в защищенной системе недопустимо. Применение в распределенной ВС алгоритма удаленного поиска с использованием информационно-поискового сервера позволяет обезопасить систему от внедрения в нее ложного объекта только в том случае, если, во-первых, взаимодействие объектов системы с сервером происходит только с созданием виртуального канала и, во-вторых, у объектов, подключенных к данному серверу, и у сервера существует заранее определенная статическая ключевая информация, используемая при создании виртуального канала. Выполнение этих условий сделает невозможным в распределенной ВС передачу в ответ на запрос с объекта ложного ответа и, следовательно, внедрения в систему ложного объекта.
 Поясним последнее утверждение. В том случае, если виртуальный канал с информационно-поисковым сервером создается с использованием только динамически вырабатываемой ключевой информации, например, по схеме открытого распределения ключей, то ничто не мешает атакующему - в том случае, если он может перехватить первоначальный запрос на создание ВК с объекта системы - послать ложный ответ и создать виртуальный канал от имени настоящего сервера. Именно поэтому на всех объектах системы необходима начальная ключевая информация для создания ВК с информационно-поисковым сервером.
 В заключение предлагаются следующие требования, которыми необходимо руководствоваться при создании защищенных систем связи в распределенных ВС.
Утверждение 7.
Наиболее безопасной распределенной ВС является та система, в которой информация о ее объектах изначально полностью определена и в которой не используются алгоритмы удаленного поиска.
Утверждение 8.
В том случае, если выполненить требование 7 невозможно, необходимо в распределенной ВС использовать только алгоритм удаленного поиска с выделенным информационно-поисковым сервером, и при этом взаимодействие объектов системы с данным сервером должно осуществляться только по виртуальному каналу с применением надежных алгоритмов защиты соединения с обязательным использованием статической ключевой информации.
Следствие 8.1.
В распределенной ВС для обеспечения безопасности необходимо отказаться от алгоритмов удаленного поиска с использованием широковещательных запросов.
 Заключая эту главу, хотелось бы обратить внимание читателя на то, что, как он, наверное, уже понял, в сети Internet в стандарте IPv4 практически ни одно из сформулированных требований к построению безопасных систем связи между удаленными объектами распределенных ВС не выполняется. Учтя собственные ошибки в разработке стандарта IPv4, группы разработчиков уже завершили проект создания нового более защищенного стандарта сети Internet - IPv6, где учтены некоторые из вышеизложенных требований.
6. Конкретные примеры атак на TCP/IP
6.1 Пассивные атаки на уровне TCP
 При данном типе атак крэкеры  никаким образом не обнаруживают себя и не вступают напрямую во взаимодействие с другими системами. Фактически все сводиться к наблюдению за доступными данными или сессиями связи.
6.1.1 Подслушивание
 Атака заключаются в перехвате сетевого потока и его анализе (Англоязычные термин - "sniffing")
 Для осуществления подслушивания крэкеру необходимо иметь доступ к машине, расположенной на пути сетевого потока, который необходимо анализировать; например, к маршрутизатору или PPP -серверу на базе UNIX . Если крэкеру удастся получить достаточные права на этой машине, то с помощью специального программного обеспечения сможет просматривать весь трафик, проходящий через заданные интерфейс.
 Второй вариант - крэкер получает доступ к машине, которая расположена в одном сегменте сети с системой, которой имеет доступ к сетевому потоку. Например, в сети "тонкий ethernet" сетевая карта может быть переведена в режим, в котором она будет получать все пакеты, циркулирующие по сети, а не только адресованной ей конкретно. В данном случае крэкеру не требуется доступ к UNIX - достаточно иметь PC с DOS или Windows (частая ситуация в университетских сетях)
 Поскольку TCP/IP-трафик, как правило, не шифруется (мы рассмотрим исключения ниже), крэкер, используя соответствующий инструментарий, может перехватывать TCP/IP-пакеты, например, telnet-сессий и извлекать из них имена пользователей и их пароли.
 Следует заметить, что данный тип атаки невозможно отследить, не обладая доступом к системе крэкера, поскольку сетевой поток не изменяется. Единственная надежная защита от подслушивания -- шифрование TCP/IP-потока (например, secure shell – защищенная оболочка) или использование одноразовых паролей (например, S/KEY)
 Другое вариант решения - использование интеллектуальных свитчей и UTP, в результате чего каждая машина получает только тот трафик, что адресован ей.  
 У каждой палки два конца. Естественно, подслушивание может быть и полезно. Так, данный метод используется большим количеством программ, помогающих администраторам в анализе работы сети (ее загруженности, работоспособности и т.д.). Один из ярких примеров - общеизвестный tcpdump
6.2 Активные атаки на уровне TCP
 При данном типе атак крэкер взаимодействует с получателем информации, отправителем и/или промежуточными системами, возможно, модифицируя и/или фильтруя содержимое TCP/IP-пакетов. Данные типы атак часто кажутся технически сложными в реализации, однако для хорошего программиста не составляет труда реализовать соотвествующий инструментарий. К сожалению, сейчас такие программы стали доступны широким массам пользователей (например, см. SYN-затопление).
 Активные атаки можно разделить на две части. В первом случае крэкер предпринимает определенные шаги для перехвата и модификации сетевого потока или попыток "притвориться" другой системой. Во втором случае протокол TCP/IP используется для того, чтобы привести систему-жертву в нерабочее состоянии.
 Обладая достаточными привилегиями в Unix (или попросту используя DOS или Windows, не имеющие системы ограничений пользователей), крэкер может вручную формировать IP-пакеты и передавать их по сети. Естественно, поля заголовка пакета могут быть сформированы произвольным образом. Получив такой пакет, невозможно выяснить откуда реально он был получен, поскольку пакеты не содержат пути их прохождения. Конечно, при установке обратного адреса не совпадающим с текущим IP-адресом, крэкер никогда не получит ответ на отосланный пакет. Однако, как мы увидим, часто это и не требуется.
 Возможность формирования произвольных IP-пакетов является ключевым пунктом для осуществления активных атак.
6.2.1 Предсказание порядкового номера TCP
Данная атака была описана еще Робертом Моррисом (Robert T. Morris) в A Weakness in the 4.2BSD Unix TCP/IP Software. Англоязычный термин - IP-spoofing . В данном случае цель крэкера - притвориться другой системой, которой, например, "доверяет" система-жертва (в случае использования протокола rlogin/rsh для беспарольного входа). Метод также используется для других целей - например, для использования SMTP жертвы для посылки поддельных писем.
Описание
Вспомним, что установка TCP-соединения происходит в три стадии (3-way handshake): клиент выбирает и передает серверу порядковый номер (назовем его C-SYN), в ответ на это сервер высылает клиенту пакет данных, содержащий подтверждение (C-ACK) и собственный порядковый номер сервера (S-SYN). Теперь уже клиент должен выслать подтверждение (S-ACK). Схематично это можно представить так:
 
Рис.5. Установка TCP-соединения
 После этого соединение считается установленным и начинается обмен данными. При этом каждый пакет имеет в заголовке поле для порядкового номера и номера подтверждения. Данные числа увеличиваются при обмене данными и позволяют контролировать корректность передачи.
 Предположим, что крэкер может предсказать, какой порядковый номер (S-SYN по схеме) будет выслан сервером. Это возможно сделать на основе знаний о конкретной реализации TCP/IP. Например, в 4.3BSD значение порядкового номера, которое будет использовано при установке следующего значения, каждую секунду увеличивается на 125000. Таким образом, послав один пакет серверу, крэкер получит ответ и сможет (возможно, с нескольких попыткок и с поправкой на скорость соединения) предсказать порядковый номер для следующего соединения.
 Если реализация TCP/IP использует специальный алгоритм для определения порядкового номера, то он может быть выяснен с помощью посылки нескольких десятков пакетов серверу и анализа его ответов.
 Итак, предположим, что система A доверяет системе B, так, что пользователь системы B может сделать "rlogin A"  и оказаться на A, не вводя пароля. Предположим, что крэкер расположен на системе C. Система A выступает в роли сервера, системы B и C - в роли клиентов.
 Первая задача крэкера - ввести систему B в состояние, когда она не сможет отвечать на сетевые запросы. Это может быть сделано несколькими способами, в простейшем случае нужно просто дождаться перезагрузки системы B. Нескольких минут, в течении которых она будет неработоспособна, должно хватить. Другой вариант - использование описанными в следующих разделах методов.
 После этого крэкер может попробовать притвориться системой B, для того, что бы получить доступ к системе A (хотя бы кратковременный).
 Крэкер высылает несколько IP-пакетов, инициирующих соединение, системе A, для выяснения текущего состояния порядкового номера сервера.
 Крэкер высылает IP-пакет, в котором в качестве обратного адреса указан уже адрес системы B.
 Система A отвечает пакетом с порядковым номером, который направляется системе B. Однако система B никогда не получит его (она выведена из строя), как, впрочем, и крэкер. Но он на основе предыдущего анализа догадывается, какой порядковый номер был выслан системе B
 Крэкер подтверждает "получение" пакета от A, выслав от имени B пакет с предполагаемым S-ACK (заметим, что если системы располагаются в одном сегменте, крэкеру для выяснения порядкового номера достаточно перехватить пакет, посланный системой A). После этого, если крэкеру повезло и порядковый номер сервера был угадан верно, соединение считается установленным.
 Теперь крэкер может выслать очередной фальшивый IP-пакет, который будет уже содержать данные. Например, если атака была направлена на rsh, он может содержать команды создания файла .rhosts или отправки /etc/passwd крэкеру по электронной почте.
Представим это в виде схемы:
 
Рис. 6 IP-spoofing
Детектирование и защита
 Простейшим сигналом IP-spoofing будут служить пакеты с внутренними адресами, пришедшие из внешнего мира. Программное обеспечение маршрутизатора может предупредить об этом администратора. Однако не стоит обольщаться - атака может быть и изнутри Вашей сети.
 В случае использования более интеллектуальных средств контроля за сетью администратор может отслеживать (в автоматическом режиме) пакеты от систем, которые находятся в недоступном состоянии. Впрочем, что мешает крэкеру имитировать работу системы B ответом на ICMP-пакеты?
 Какие способы существуют для защиты от IP-spoofing? Во-первых, можно усложнить или сделать невозможным угадывание порядкового номера (ключевой элемент атаки). Например, можно увеличить скорость изменения порядкового номера на сервере или выбирать коэффициент увеличения порядкового номера случайно (желательно, используя для генерации случайных чисел криптографически стойкий алгоритм).
 Если сеть использует межсетевой экран firewall (или другой фильтр IP-пакетов), следует добавить ему правила, по которым все пакеты, пришедшие извне и имеющие обратными адресами из нашего адресного пространства, не должны пропускаться внутрь сети. Кроме того, следует минимизировать доверие машин друг другу. В идеале не должны существовать способа, напрямую попасть на соседнюю машину сети, получив права суперпользователя на одной из них. Конечно, это не спасет от использования сервисов, не требующих авторизации, например, IRC – чат (крэкер может притвориться произвольной машиной Internet и передать набор команд для входа на канал IRC, выдачи произвольных сообщений и т.д.).
 Шифрование TCP/IP-потока решает в общем случае проблему IP-спуфинга (при условии, что используются криптографически стойкие алгоритмы).
 Для того, чтобы уменьший число таких атак, рекомендуется также настроить firewall для фильтрации пакетов, посланных нашей сетью наружу, но имеющих адреса, не принадлежащие нашему адресному пространству. Это защитит мир от атак из внутренней сети, кроме того, детектирование подобных пакетов будет означать нарушение внутренней безопасности и может помочь администратору в работе.
6.2.2 IP Hijacking – Нападение на IP
 Если в предыдущем случае крэкер инициировал новое соединение, то в данном случае он перехватывает весь сетевой поток, модифицируя его и фильтруя произвольным образом. Метод является комбинацией 'подслушивания' и IP-спуфинга.
Описание
 Необходимые условия - крэкер должен иметь доступ к машине, находящейся на пути сетевого потока и обладать достаточными правами на ней для генерации и перехвата IP-пакетов.
Напомним, что при передаче данных постоянно используются порядковый номер и номер подтверждения (оба поля находятся в IP-заголовке). Исходя из их значения, сервер и клиент проверяют корректность передачи пакетов.
 Существует возможность ввести соединение в "десинхронизированное состояние", когда присылаемые сервером порядковый номер и номер подтверждения не будут совпадать с ожидаемым значениеми клиента, и наоборот. В данном случае крэкер, "прослушивая" линию, может взять на себя функции посредника, генерируя корректные пакеты для клиента и сервера и перехватывая их ответы.
 Метод позволяет полностью обойти такие системы защиты, как, например, одноразовые пароли, поскольку крэкер начинает работу уже после того, как произойдет авторизация пользователя.
Есть два способа рассинхронизировать соединение
 Ранняя десинхронизация
 Соединение десинхронизируется на стадии его установки.
Крэкер прослушивает сегмент сети, по которому будут проходить пакеты интересующей его сессии
 Дождавшись пакета S-SYN от сервера, крэкер высылает серверу пакет типа RST (сброс), конечно, с корректным порядковым номером, и, немедленно, вслед за ним фальшивый C-SYN-пакет от имени клиента
 Сервер сбрасывает первую сессию и открывает новую, на том же порту, но уже с новым порядковым номером, после чего посылает клиенту новый S-SYN-пакет.
 Клиент игнорирует S-SYN-пакет, однако крэкер, прослушивающий линию, высылает серверу S-ACK-пакет от имени клиента.
 Итак, клиент и сервер находятся в установленом состоянии ESTABLISHED (установлено), однако сессия десинхронизирована.
Представим это в виде схемы:
 
Рис.7. Ранняя десинхронизация
 Естественно, 100% срабатывания у этой схемы нет, например, она не застрахована от того, что по дороге не потеряются какие-то пакеты, посланные крэкером. Для корректной обработки этих ситуаций программа должна быть усложнена.
 Десинхронизация нулевыми данными
 В данном случае крэкер прослушивает сессию и в какой-то момент посылает серверу пакет с "нулевыми" данными, т.е. такими, которые фактически будут проигнорированы на уровне прикладной программы и не видны клиенту. Аналогичный пакет посылается клиенту. Очевидно, что после этого сессия переходит в десинхронизированное состояние.
ACK-буря
 Одна из проблем IP Hijacking заключается в том, что любой пакет, высланный в момент, когда сессия находится в десинхронизированном состоянии вызывает так называемый ACK-бурю. Например, пакет выслан сервером, и для клиента он является неприемлимым, поэтому тот отвечает ACK-пакетом. В ответ на этот неприемлимый уже для сервера пакет клиент вновь получает ответ... И так до бесконечности.
 К счастью (или к сожалению?) современные сети строятся по технологиям, когда допускается потеря отдельных пакетов. Поскольку ACK-пакеты не несут данных, повторных передачи не происходит и "буря стихает".
 Как показали опыты, чем сильнее ACK-буря, тем быстрее она "утихомиривает" себя - на 10MB ethernet это происходит за доли секунды. На ненадежных соединениях типа SLIP  - ненамного больше.
Детектирование и защита
 Есть несколько путей. Например, можно реализовать TCP/IP-стэк, которые будут контролировать переход в десинхронизированное состояние, обмениваясь информацией о порядковом номере/номере подтверждения. Однако в данному случае мы не застрахованы от крэкера, меняющего и эти значения.
 Поэтому более надежным способом является анализ загруженности сети, отслеживание возникающих ACK-бурь. Это можно реализовать при помощи конкретных средств контроля за сетью.
 Если крэкер не потрудиться поддерживать десинхронизированное соединение до его закрытия или не станет фильтровать вывод своих команд, это также будет сразу замечено пользователем. К сожалению, подавляющее большинство просто откруют новую сессию, не обращаясь к администратору.
 Стопроцентную защиту от данной атаки обеспечивает, как всегда, шифрование TCP/IP-трафика (на уровне приложений - secure shell) или на уровн протокола - IPsec). Это исключает возможность модификации сетевого потока. Для защиты почтовых сообщений может применяться PGP.
 Следует заметить, что метод также не срабатывает на некоторых конкретных реализациях TCP/IP. Так, некоторые системы генерируют встречный RST-пакет. Это делает невозможным раннюю десинхронизацию.
6.2.3 Пассивное сканирование
 Сканирование часто применяется крэкерами для того, чтобы выяснить, на каких TCP-портах работают демоны, отвечающие на запросы из сети. Обычная программа-сканер последовательно открывает соединения с различными портами. В случае, когда соединение устанавливается, программа сбрасывает его, сообщая номер порта крэкеру.
 Данный способ легко детектируются по сообщениям демонов, удивленных мгновенно прерваным после установки соединением, или с помощью использования специальных программ. Лучшие из таких программ обладают некоторыми попытками внести элементы искуственного элемента в отслеживание попыток соединения с различными портами.
 Однако крэкер может воспользоваться другим методом - пассивным сканированием (английский термин "passive scan"). При его использовании крэкер посылает TCP/IP SYN-пакет на все порты подряд (или по какому-то заданному алгоритму). Для TCP-портов, принимающих соединения извне, будет возвращен SYN/ACK-пакет, как приглашение продолжить 3-way handshake. Остальные вернут RST-пакеты. Проанализировав данные ответ, крэкер может быстро понять, на каких портах работают программа. В ответ на SYN/ACK-пакеты он может также ответить RST-пакетами (cброс), показывая, что процесс установки соединения продолжен не будет (в общем случае RST-пакетами автоматический ответит TCP/IP-реализация крэкера, если он не предпримет специальных мер).
 Метод не детектируется предыдущими способами, поскольку реальное TCP/IP-соединение не устанавливается. Однако (в зависимости от поведения крэкера) можно отслеживать
 резко возросшее количество сессий, находящихся в состоянии SYN_RECEIVED. (SIN пакет принят) при условии, что крэкер не посылает в ответ RST)
 прием от клиента RST-пакета в ответ на SYN/ACK.
 К сожалению, при достаточно умном поведении крэкера (например, сканирование с низкой скоростью или проверка лишь конкретных портов) детектировать пассивное сканирование невозможно, поскольку оно ничем не отличается от обычных попыток установить соединение.
В качестве защиты можно лишь посоветовать закрыть на firewall все сервисы, доступ к которым не требуется извне.
6.2.4 Затопление ICMP-пакетами 
 Традиционный англоязычный термин - "ping flood". Появился он потому, что программа "ping", предназначенная для оценки качества линии, имеет ключ для "агрессивного" тестирования. В этом режиме запросы посылаются с максимально возможной скоростью и программа позволяет оценить, как работает сеть при максимальной нагрузке. Данная атака требует от крэкера доступа к быстрым каналам в Интернет.
Вспомним, как работает ping. Программа посылает ICMP-пакет типа ECHO REQUEST (запрос отклика ICMP), выставляя в нем время и его идентификатор. Ядро машины-получателя отвечает на подобный запрос пакетом ICMP ECHO REPLY (ответ на отклик ICMP) . Получив его ping выдает скорость прохождения пакета.
 При стандартном режиме работы пакеты выслаются через некоторые промежутки времени, практически не нагружая сеть. Но в "агрессивном" режиме поток ICMP echo request/reply-пакетов может вызвать перегрузку небольшой линии, лишив ее способности передавать полезную информацию.
 Естественно, случай с ping является частным случаем более общей ситуации, связанный с перегрузкой каналов. Например, крэкер может посылать множество UDP-пакетов  на 19-й порт машины-жертвы, и горе ей, если она, следуя общепринятым правилам, имеет на 19-м UDP-порту знакогенератор, отвечающий на пакеты строчками по 80 байт.
 Заметим, что крэкер может также подделывать обратный адрес подобных пакетов, затрудняя его обнаружение. Отследить его поможет разве что скоординированная работа специалистов на промежуточных маршрутизаторах, что практически нереально.
 Одной из вариантов атаки - посылать ICMP echo request-пакеты с исходным адресом, указывающем на жертву, на широковещательные-адреса крупных сетей. В результате каждая из машин ответит на этот фальшивый запрос, и машина-отправитель получит больше количество ответов. Посылка множество echo requests от имени "жертвы" на широковещательные-адреса крупных сетей, можно вызвать резкой заполненение канала "жертвы".
 Приметы затопления - резко возросшая нагрузка на сеть (или канал) и повышение количество специфических пакетов (таких, как ICMP).
 В качестве защиты можно порекомендовать настройку маршрутизаторов, при которых они будут фильтровать тот же ICMP трафик, превышающие некоторую заданную заранее величину (пакетов/ед. времени). Для того, чтобы убедиться, что Ваши машины не могут служить источником ping flood'а, ограничьте доступ к ping.
6.2.5 Локальная буря
 Сделаем небольшое отступление в сторону реализации TCP/IP и рассмотрим "локальные бури" на пример UDP-бури. Как правило, по умолчанию системы поддерживают работу таких UDP-портов, как 7 ("эхо", полученный пакет отсылается назад), 19 ("знакогенератор", в ответ на полученный пакет отправителю выслается строка знакогенератора) и других.
 В данном случае крэкер может послать единственный UDP-пакет, где в качестве исходного порта будет указан 7, в качестве получателя - 19-й, а в качестве адреса получателя и отправителя будут указаны, к примеру, две машины вашей сети (или даже 127.0.0.1). Получив пакет, 19-й порт отвечает строкой, которая попадает на порт 7. Седьмой порт дублирует ее и вновь отсылает на 19.. и так до бесконечности.
 Бесконечный цикл съедает ресурсы машин и добавляет на канал бессмысленную нагрузку. Конечно, при первом потерянном UDP-пакете буря прекратиться. Как недавно стало известно, данная атака временно выводит из строя (до перезагрузки) некоторые старые модели маршрутизаторов.
 Очевидно, что в бесконечный разговор могут быть вовлечены многие демоны (в случае TCP/IP может быть применен TCP/IP spoofing, в случае UDP/ICMP достаточно пары фальшивых пакетов)
 В качестве защиты стоит еще раз порекомендовать не пропускать в сети пакеты с внутренними адресам, но пришедшие извне. Также рекомендуется закрыть на firewall использование большинства сервисов.
6.2.6 Затопление SYN-пакетами
 Пожалуй, затопление SYN-пакетами ("SYN flooding") - самый известный способ нападения, с того времени, как хакерский электронный журнал "2600" опубликовал исходные тексты программы, позволяющие занятьсе этим даже неквалифицированным пользователям. Следует заметить, что впервые эта атака была упомянута еще в 1986 году все тем же Робертом Т. Моррисом.
 Вспомним, как работает TCP/IP в случае входящих соединений. Система отвечает на пришедший C-SYN-пакет S-SYN/C-ACK-пакетом, переводит сессию в состояние SYN_RECEIVED (SYN пакет принят) и заносит ее в очередь. Если в течении заданного времени от клиента не придет S-ACK, соединение удаляется из очереди, в противном случае соединение переводится в установленное состояние ESTABLISHED. 
 Рассмотрим случай, когда очередь входных соединений уже заполнена, а система получает SYN-пакет, приглашающий к установке соединения. По RFC  он будет молча проигнорирован.
 Затопление SYN-пакетами основано на переполнении очереди сервера, после чего сервер перестает отвечать на запросы пользователей. Самая известная атака такого рода - атака на Panix, нью-йоркского провайдера. Panix не работал в течении 2-х недель.
 В различных системах работа с очередью реализована по разному. Так, в BSD -системах, каждый порт имеет свою собственную очередь размером в 16 элементов. В системах SunOS, напротив, такого разделения и нет и система просто располагает большой общей очередью. Соответственно, для того, что бы заблокировать, к примеру, WWW-порт на BSD достаточно 16 SYN-пакетов, а для Solaris 2.5 их количество будет гораздо больше.
 После истечение некоторого времени (зависит от реализации) система удаляет запросы из очереди. Однако ничего не мешает крэкеру послать новую порцию запросов. Таким образом, даже находясь на соединение 2400 bps, крэкер может посылать каждые полторы минуты по 20-30 пакетов на FreeBSD-сервер, поддерживая его в нерабочем состоянии (естественно, эта ошибка была скорректирована в последних версиях FreeBSD)
 Как обычно, крэкер может воспользоваться случайными обратными IP-адресами при формировании пакетов, что затрудняет его обнаружение и фильтрацию его трафика.
 Детектирование несложно -- большое количество соединений в состоянии SYN_RECEIVED (SYN пакет принят) , игнорирование попыток соединится с данным портом. В качестве защиты можно порекомендовать патчи, которые реализуют автоматическое "прорежение" очереди. Для того, что бы узнать, если к Вашей системе защита от SYN-затопления, обратитесь к поставщику системы.
 Другой вариант защиты – настроить cетевой экран firewall так, что бы все входящие TCP/IP-соединения устанавливал он сам, и только после этого перебрасывал их внутрь сети на заданную машину. Это позволит Вам ограничить syn-затопление и не пропустить его внутрь сети.
7. Решения на программном уровне
7.1 SSL – Secure Socket Layer – протокол защищенных сокетов
 Протокол SSL (Secure Socket Layer) был разработан фирмой Netscape, как протокол обеспечивающий защиту данных между сервисными протоколами (такими как HTTP, NNTP, FTP и т.д.) и транспортными протоколами (TCP/IP). Часто для него используется аббревиатура HTTPS. Именно эта латинская буква "s" превращает обычный, не защищенный канал передачи данных в Интернете по протоколу HTTP, в засекреченный или защищенный,
 Протокол SSL предоставляет "безопасный канал", который имеет три основные свойства:
 Канал является частным. Шифрование используется для всех сообщений после простого диалога, который служит для определения секретного ключа.
 Канал аутентифицирован. Серверная сторона диалога всегда аутентифицируется, в то время как клиентская - аутентифицируется опционно.
 Канал надежен. Транспортировка сообщений включает в себя проверку целостности (с привлечением MAC).
 SSL не только обеспечивает защиту данных в Интернете, но так же производит опознание сервера и клиента (server/client authentication). В данный момент протокол SSL принят W3 консорциумом (W3 Consortium) на рассмотрение, как основной защитный протокол для клиентов и серверов (WWW browsers and servers) в сети Интернет.
Использование SSL
 Чаще всего, этот протокол используется в составе любого Интернет-ресурса, осуществляющего манипуляции с личными или финансовыми данными посещающих его пользователей Интернета. Чаще всего, это банки, Интернет-магазины или любые другие виртуальные места, в которых приходящие по своим делам пользователи, вынуждены передавать свои личные, и зачастую, секретные данные. Этого может потребовать и простая регистрация, и процедура оплаты какого-либо товара, или любая другая процедура, при которой пользователи вынуждены честно выдавать свои паспортные данные, PIN-ы и пароли. Появляются два довольно веских довода, первый, передаваемую информацию надо шифровать, и второй, мы должны быть уверены, что передаем информацию именно туда, куда нужно. Именно для решения этих двух вопросов и используется SSL.
HTTP и HTTPS
 Попытки разработать универсальный сетевой протокол, способный обеспечить надлежащий уровень безопасности при работе в Интернет, предпринимались достаточно давно, и достаточно большим количеством различных фирм и организаций. HTTP протокол предлагал достаточно простой, парольный способ идентификации того или иного пользователя. В момент соединения с сервером, пользователь вводил пароль, пароль передавался серверу в открытом, не зашифрованном виде, и далее, проверив соответствие пароля и имени пользователя, сервер открывал или не открывал затребованное соединение. Далее, по мере развития Интернета, было создано несколько различных безопасных протоколов. Официальный протокол, разработку которого спонсировала IETF, назывался Secure HTTP (SHTTP), Помимо него, разрабатывались, и были созданы, еще несколько не официальных проектов, один из которых, под названием SSL (Secure Sockets Layer), созданный Netscape, получил большую популярность и широкое распространение. Правда, не смотря на свою популярность, SSL не является официальным Интернет стандартом.
SSL в действии
 Главным назначением SSL-протокола, является обеспечение приватного и надежного способа обмена информацией между двумя удаленно взаимодействующими приложениями. Протокол реализуется в виде двухслойной (многослойной) среды, специально предназначенной для безопасного переноса секретной информации, через не засекреченные каналы связи. В качестве первого слоя, в такой среде используется некоторый надежный транспортный протокол; TCP к примеру. По слову "транспортный", не трудно догадаться, что TCP берет на себя функции "несущей", и в дальнейшем, становится извозчиком, для всех лежащих выше слоев (протоколов). Вторым по счету слоем, накладываемым на TCP, является SSL Record Protocol. Вместе, эти два слоя, TCP и SSL Record Protocol, формируют своеобразное ядро SSL. В дальнейшем, это ядро становится первичной герметизирующей оболочкой, для всех последующих более сложных протокольных инфраструктур. В качестве одной из таких структур, используется SSL Handshake Protocol (Протокол «рукопожатия»)- позволяющий серверу и клиенту идентифицировать друг друга и согласовывать криптографические алгоритмы и ключи, перед тем как приложения, работающие на серверной и клиентской стороне, смогут начать передачу или прием информационных байтов в защищенном режиме.
 Одним из не мало важных преимуществ SSL, является его полная программно-платформенная независимость. Протокол разработан на принципах переносимости, и идеология его построения, не зависит, от тех приложений, в составе которых он используется. Помимо этого, важно и то, что поверх протокола SSL, могут прозрачно накладываться и другие протоколы; либо для еще большего увеличения степени защиты целевых информационных потоков, либо, для адаптации криптографических способностей SSL под какую-нибудь другую, вполне определенную задачу.
 Вы начинаете использовать SSL в тот момент, когда вводите в адресной строке своего браузера URL начинающийся с аббревиатуры HTTPS, В результате, вы подключаетесь к порту за номером 443, который для SSL обычно используется по умолчанию; для стандартного HTTP соединения, чаще всего используется порт 80. В процессе подключения, браузер пользователя (в дальнейшем клиент), посылает серверу приветственное сообщение (hello message). В свою очередь сервер, также должен посылать клиенту свое приветственное сообщение. Приветственные сообщения, являются первичными, инициализирующими сообщениями и содержат информацию, используемую при дальнейшей настройке открываемого секретного канала. В общем случае, приветственное сообщение устанавливает четыре основных параметра: версия протокола, идентификатор сессии, способ шифрования, метод компрессии, а также, два специально сгенерированных случайных числа; и сервер, и клиент, генерируют такие числа независимо друг от друга, а затем, просто обмениваются ими друг с другом.
 После получения приветственного сообщения от клиента, сервер отсылает свой сертификат, если таковой у него имеется. Также, при необходимости, сервер может послать и некое ключевое сообщение, например в случае отсутствии сертификата. Если сервер авторизирован (т.е. имеет соответствующий сертификат), он может потребовать и клиентский сертификат, если того потребует выбранный способ шифрования данных. После этого, производится еще ряд промежуточных обменных операций, в процессе которых, производится окончательное уточнение выбранного алгоритма шифрования, ключей и секретов, и далее, сервер посылает клиенту некое финальное сообщение, после чего обе стороны приступают к обмену зашифрованной информации.
Ложка дегтя
 SSL как таковой, теоретически, может обеспечить практически полную защиту любого Интернет соединения. Но для успешного функционирования SSL, кроме него самого, необходимы также и чисто программные средства, претворяющие технологию SSL в жизнь. Программы, так или иначе использующие SSL протокол, как ни странно, является порой самым уязвимым местом этой технологии. Именно из-за ошибок в этих программах, возможна почти полная потеря, всех, достигнутых после использования SSL щитов и заслонов. К таким программным инструментам, прежде всего, относятся активно используемые нами Интернет-браузеры.
 Одним из самых показательных критериев уровня защиты, является размер используемых ключей. Чем больше этот размер, тем соответственно надежнее защита. Браузеры в основном используют три размера: 40, 56 и 128 бит, соответственно. Причем, 40-а битный вариант ключа недостаточно надежен. Таким образом, предпочтительнее использовать именно 128-ми битные ключи. Применительно к Internet Explorer-у от Microsoft, это означает загрузку дополнительного пакета (security pack). Так как интернациональные версии этого браузера, всегда снабжаются исключительно 40-а или 56-и битной защитой, а 128-ми битная защита, ставится только на североамериканские версии этого браузера (США, Канада). Для того чтобы установить, какой именно размер ключа используется в вашем браузере, в Netscape Navigator вам достаточно открыть подменю "Options/Security Preferences", а в Internet Explorer, подменю "Help/About".
 Но размер ключа, не будет играть решающий роли, если в защите браузера имеется внутренняя брешь. Сообщения об открытии таких брешей, в тех или иных браузерах, появляются с регулярными интервалами. Такая брешь напоминает открытую форточку в протапливаемой комнате - все тепло мгновенно выветривается. По этому поводу, уместно вспомнить случай произошедший с Netscape Navigator, в мае 2000 года. Тогда, один корейский студент обнаружил такую, довольно не приятную особенность, этого браузера. При попытке соединения с сервером, обладающим не годным сертификатом, с дальнейшим отказом от продолжения такого соединения, происходило следующее. Netscape, по ошибке, помещал этот сертификат в список годных, и соответственно, при последующем подключение уже не выдавал пользователю ни каких предупреждающих сообщений, спокойно подключаясь к этому, не вполне надежному, серверу
 Но все эти и им подобные прорехи, не идут ни в какое сравнение с той угрозой, которую могут представлять для пользователя вовремя не отозванные сертификаты. Дело в том, что браузеры обычно поставляются с неким, вполне определенным набором действительных сертификатов, но автоматического механизма проверки этой годности по прошествию некоторого времени - не существует. Таким образом, возможно, что действие, того или иного, используемого вашим браузером сертификата, уже, давно кончилось; мог истечь срок годности, мог быть потерян контроль над личным ключом соответствующим этому сертификату и.т.д. В любом из этих случаев, сертификат автоматически отзывается, и помещается в специальный, так называемый revocation list, или список не годных сертификатов, создаваемый и обновляемый тем или иным сертификационным сообществом (CA). Теперь, если не удалить такой сертификат из вашего браузера, он по прежнему будет числиться как годный, со всеми вытекающими отсюда последствиями.
 Следует заметить, что идея, заложенная в протоколе SSL безусловно, хороша. Хотя у нее есть и свои плюсы, и свои минусы, но в целом, этот протокол можно назвать одним из наиболее удачных решений проблемы защиты пользовательских данных при их распространении "открытым" каналом. Этот протокол вполне бы мог стать некой сетевой панацеей. Но, к сожалению, практика, показывает что идея это еще не решение. Без соответствующей практической составляющей, идея так и остается идеей, а потому, пользователи безусловно, должны помнить, что символ замка, появляющийся в строке состояния их Интернет-браузеров, еще не гарантия того, что все наши секреты и тайны находятся под действительно надежной защитой
Реализации SSL
 Теперь несколько слов о реализации SSL. Наиболее распространенным пакетом программ для поддержки SSL является SSLeay. Последняя версия (SSLeay v. 0.8.0) поддерживает SSLv3. Эта версия доступна в исходных текстах. Этот пакет предназначен для создания и управления различного рода сертификатами. Так же в его состав входит и библиотека для поддержки SSL различными программами. Эта библиотека необходима, например, для модуля SSL в распространенном HTTP сервере Apache. Если Вы устанавливаете версию, вне США, то особых проблем с алгоритмом RSA быть не должно. Но только накладывается ограничение на длину ключа в 40 бит. Действеут это ограничение и на другой пакет от фирмы Netscape - SSLRef. А вот если компьютер с SSLeay находится на территории США, то за использование алгоритма RSA необходимо заплатить. Но об этом нужно разговаривать с самой фирмой RSA Data Security Inc.
7.2 IPSec - протокол защиты сетевого трафика на IP-уровне
Краткая историческая справка появления протокола
 В 1994 году Совет по архитектуре Интернет (IAB ) выпустил отчет "Безопасность архитектуры Интернет". В этом документе описывались основные области применения дополнительных средств безопасности в сети Интернет, а именно защита от несанкционированного мониторинга, подмены пакетов и управления потоками данных. В числе первоочередных и наиболее важных защитных мер указывалась необходимость разработки концепции и основных механизмов обеспечения целостности и конфиденциальности потоков данных. Поскольку изменение базовых протоколов семейства TCP/IP вызвало бы полную перестройку сети Интернет, была поставлена задача обеспечения безопасности информационного обмена в открытых телекоммуникационных сетях на базе существующих протоколов. Таким образом, начала создаваться спецификация Secure IP – Защищенный IP, дополнительная по отношению к протоколам IPv4 и IPv6.
Архитектура IPSec
 IP Security - это комплект протоколов, касающихся вопросов шифрования, аутентификации и обеспечения защиты при транспортировке IP-пакетов; в его состав входят около 20 предложений по стандартам и 18 RFC.
 Спецификация IP Security (известная сегодня как IPsec) разрабатывается IETF (Internet Engineering Task Force - проблемная группа проектирования Internet) В настоящее время IPsec включает 3 алгоритмо-независимые базовые спецификации, опубликованные в качестве RFC-документов "Архитектура безопасности IP", "Аутентифицирующий заголовок (AH)", "Инкапсуляция зашифрованных данных (ESP)". Необходимо заметить, что в марте 1998 года Рабочая группа IP Security Protocol предложила новые версии этих спецификаций, имеющие в настоящее время статус предварительных стандартов. Кроме этого, существуют несколько алгоритмо-зависимых спецификаций, использующих протоколы MD5, SHA, DES.
 
Рис. 8 Архитектура IPSec
 Рабочая группа IP Security Protocol разрабатывает также и протоколы управления ключевой информацией. В задачу этой группы входит разработка протокола  IKMP (Internet Key Management Protocol), протокола управления ключами прикладного уровня, не зависящего от используемых протоколов обеспечения безопасности. В настоящее время рассматриваются концепции управления ключами с использованием спецификации ISAKMP (Internet Security Association and Key Management Protocol) и протокола Oakley установления ключа (Oakley Key Determination Protocol). Спецификация ISAKMP описывает механизмы согласования атрибутов используемых протоколов, в то время как протокол Oakley позволяет устанавливать сессионные ключи на компьютеры сети Интернет. Рассматриваются также возможности использования механизмов управления ключами протокола SKIP . Создаваемые стандарты управления
ключевой информацией, возможно, будут поддерживать Центры распределения ключей, аналогичные используемым в системе Kerberos.
 Гарантии целостности и конфиденциальности данных в спецификации IPsec обеспечиваются за счет использования механизмов аутентификации и шифрования соответственно. Последние, в свою очередь, основаны на предварительном согласовании сторонами информационного обмена т.н. "контекста безопасности" - применяемых криптографических алгоритмов, алгоритмов управления ключевой информацией и их параметров. Спецификация IPsec предусматривает возможность поддержки сторонами информационного обмена различных протоколов и параметров аутентификации и шифрования пакетов данных, а также различных схем распределения ключей. При этом результатом согласования контекста безопасности является установление индекса параметров безопасности (SPI), представляющего собой указатель на определенный элемент внутренней структуры стороны информационного обмена, описывающей возможные наборы параметров безопасности.
 По сути, IPSec, работает на третьем уровне, т. е. на сетевом уровне. В результате передаваемые IP-пакеты защищены прозрачным для сетевых приложений и инфраструктуры образом. В отличие от SSL (Secure Socket Layer), который работает на четвертом (т. е. транспортном) уровне и теснее связан с более высокими уровнями модели OSI, IPSec призван обеспечить низкоуровневую защиту.
 
Рис. 9 Модель OSI/ISO
 К IP-данным, готовым к передаче по виртуальной частной сети, IPSec добавляет заголовок для идентификации защищенных пакетов. Перед передачей по Internet эти пакеты инкапсулируются в другие IP-пакеты. IPSec поддерживает несколько типов шифрования, в том числе DES  и MD5 – дайджест сообщения.
 Чтобы установить защищенное соединение, оба участника сеанса должны иметь возможность быстро согласовать параметры защиты, такие как алгоритмы аутентификации и ключи. IPSec поддерживает два типа схем управления ключами, с помощью которых участники могут согласовать параметры сеанса. Эта двойная поддержка вызвала определенные трения в рабочей группе IETF.
 С текущей версией IP, IPv4, могут быть использованы или Internet Secure Association Key Management Protocol (ISAKMP), или Simple Key Management for Internet Protocol. !!!! С новой версией IP, IPv6, придется использовать ISAKMP, известный сейчас как ISAKMP/Oakley. К сожалению, две вышеописанные схемы управления ключами во многом несовместимы, а значит, гарантировать интероперабельность из конца в конец вряд ли возможно.
Заголовок AH
 Аутентифицирующий заголовок (AH) является обычным опциональным заголовком и, как правило, располагается между основным заголовком пакета IP и полем данных. Наличие AH никак не влияет на процесс передачи информации транспортного и более высокого уровней. Основным и единственным назначением AH является обеспечение защиты от атак, связанных с несанкционированным изменением содержимого пакета, и в том числе от подмены исходного адреса сетевого уровня. Протоколы более высокого уровня должны быть модифицированы в целях осуществления проверки аутентичности полученных данных.
 Формат AH достаточно прост и состоит из 96-битового заголовка и данных переменной длины, состоящих из 32-битовых слов. Названия полей достаточно ясно отражают их содержимое: Next Header указывает на следующий заголовок, Payload Len представляет длину пакета, SPI является указателем на контекст безопасности и Sequence Number Field содержит последовательный номер пакета.
 
Рис. 10Формат заголовка AH
 Последовательный номер пакета был введен в AH в 1997 году в ходе процесса пересмотра спецификации IPsec. Значение этого поля формируется отправителем и служит для защиты от атак, связанных с повторным использованием данных процесса аутентификации. Поскольку сеть Интернет не гарантирует порядок доставки пакетов, получатель должен хранить информацию о максимальном последовательном номере пакета, прошедшего успешную аутентификацию, и о получении некоторого числа пакетов, содержащих предыдущие последовательные номера (обычно это число равно 64).
 В отличие от алгоритмов вычисления контрольной суммы, применяемых в протоколах передачи информации по коммутируемым линиям связи или по каналам локальных сетей и ориентированных на исправление случайных ошибок среды передачи, механизмы обеспечения целостности данных в открытых телекоммуникационных сетях должны иметь средства защиты от внесения целенаправленных изменений. Одним из таких механизмов является специальное применение алгоритма MD5: в процессе формирования AH последовательно вычисляется хэш-функция от объединения самого пакета и некоторого предварительно согласованного ключа, а затем от объединения полученного результата и преобразованного ключа. Данный механизм применяется по умолчанию в целях обеспечения всех реализаций IPv6, по крайней мере, одним общим алгоритмом, не подверженным экспортным ограничениям.
Заголовок ESP - Инкапсуляция зашифрованных данных
 В случае использования инкапсуляции зашифрованных данных заголовок ESP является последним в ряду опциональных заголовков, "видимых" в пакете. Поскольку основной целью ESP является обеспечение конфиденциальности данных, разные виды информации могут требовать применения существенно различных алгоритмов шифрования. Следовательно, формат ESP может претерпевать значительные изменения в зависимости от используемых криптографических алгоритмов. Тем не менее, можно выделить следующие обязательные поля: SPI , указывающее на контекст безопасности, поле порядкового номера, содержащее последовательный номер пакета, и контрольная сумма, предназначенная для защиты от атак на целостность зашифрованных данных. Кроме этого, как правило, в теле ESP присутствуют параметры ( например, режим использования) и данные (например, вектор инициализации) применяемого алгоритма шифрования. Часть ESP заголовка может быть зашифрована на открытом ключе получателя или на совместном ключе пары отправитель-получатель. Получатель пакета ESP расшифровывает ESP заголовок и использует параметры и данные применяемого алгоритма шифрования для декодирования информации транспортного уровня.
 
Рис. 11Формат заголовка ESP
Различают два режима применения ESP - транспортный и тоннельный.
Транспортный режим
 Транспортный режим используется для шифрования поля данных IP пакета, содержащего протоколы транспортного уровня (TCP, UDP, ICMP), которое, в свою очередь, содержит информацию прикладных служб. Примером применения транспортного режима является передача электронной почты. Все промежуточные узлы на маршруте пакета от отправителя к получателю используют только открытую информацию сетевого уровня и, возможно, некоторые опциональные заголовки пакета (в IPv6). Недостатком транспортного режима является отсутствие механизмов скрытия конкретных отправителя и получателя пакета, а также возможность проведения анализа трафика. Результатом такого анализа может стать информация об объемах и направлениях передачи информации, области интересов абонентов, расположение руководителей.
Тоннельный режим
 Тоннельный режим предполагает шифрование всего пакета, включая заголовок сетевого уровня. Тоннельный режим применяется в случае необходимости скрытия информационного обмена организации с внешним миром. При этом, адресные поля заголовка сетевого уровня пакета, использующего тоннельный режим, заполняются межсетевым экраном организации и не содержат информации о конкретном отправителе пакета. При передаче информации из внешнего мира в локальную сеть организации в качестве адреса назначения используется сетевой адрес межсетевого экрана. После дешифрования межсетевым экраном начального заголовка сетевого уровня пакет направляется получателю.
SA - Security Associations
 Security Association (SA) - это соединение, которое предоставляет службы обеспечения безопасности трафика, который передаётся через него. Два компьютера на каждой стороне SA хранят режим, протокол, алгоритмы и ключи, используемые в SA. Каждый SA используется только в одном направлении. Для двунаправленной связи требуется два SA. Каждый SA реализует один режим и протокол; таким образом, если для одного пакета необходимо использовать два протокола (как например AH и ESP), то требуется два SA.
Политика безопасности
 Политика безопасности хранится в SPD (Security Policy Database - База данных политики безопасности). SPD может указать для пакета данных одно из трёх действий: отбросить пакет, не обрабатывать пакет с помощью IPSec, обработать пакет с помощью IPSec. В последнем случае SPD также указывает, какой SA необходимо использовать (если, конечно, подходящий SA уже был создан) или указывает, с какими параметрами должен быть создан новый SA.
SPD является очень гибким механизмом управления, который допускает очень хорошее управление обработкой каждого пакета. Пакеты классифицируются по большому числу полей, и SPD может проверять некоторые или все поля для того, чтобы определить соответствующее действие. Это может привести к тому, что весь трафик между двумя машинами будет передаваться при помощи одного SA, либо отдельные SA будут использоваться для каждого приложения, или даже для каждого TCP соединения.
ISAKMP/Oakley
 Протокол ISAKMP определяет общую структуру протоколов, которые используются для установления SA и для выполнения других функций управления ключами. ISAKMP поддерживает несколько Областей Интерпретации (DOI), одной из которых является IPSec-DOI. ISAKMP не определяет законченный протокол, а предоставляет "строительные блоки" для различных DOI и протоколов обмена ключами.
 Протокол Oakley - это протокол определения ключа, использующий алгоритм замены ключа Диффи-Хеллмана. Протокол Oakley поддерживает идеальную прямую безопасность (Perfect Forward Secrecy - PFS), при реализации которой разрешается доступ к данным, защищенным только одним ключом, когда сомнение вызывает единственный ключ. При этом для вычисления значений дополнительных ключей этот ключ защиты повторно никогда не используется; кроме того, для этого не используется и исходный материал, послуживший для вычисления данного ключа защиты.
IKE
 IKE - протокол обмена ключами по умолчанию для ISAKMP, на данный момент являющийся единственным. IKE находится на вершине ISAKMP и выполняет, собственно, установление как ISAKMP SA, так и IPSec SA. IKE поддерживает набор различных примитивных функций для использования в протоколах. Среди них можно выделить хэш-функцию и псевдослучайную функцию (PRF).
Атаки на AH, ESP и IKE.
Все виды атак на компоненты IPSec можно разделить на следующие группы:
• атаки, эксплуатирующие конечность ресурсов системы (типичный пример - атака "Отказ в обслуживании", Denial-of-service или DOS-атака)
• атаки, использующие особенности и ошибки конкретной реализации IPSec
• атаки, основанные на слабостях самих протоколов AH и ESP
 Чисто криптографические атаки можно не рассматривать - оба протокола определяют понятие "трансформ", куда скрывают всю криптографию. Если используемый криптоалгоритм стоек, а определенный с ним трансформ не вносит дополнительных слабостей (это не всегда так, поэтому правильнее рассматривать стойкость всей системы - Протокол-Трансформ-Алгоритм), то с этой стороны все нормально.
 Что остается? Replay Attack – воспроизвести атаку - нивелируется за счет использования Порядкового номера (в одном единственном случае это не работает - при использовании ESP без аутентификации и без AH). Далее, порядок выполнения действий (сначала шифрация, потом аутентификация) гарантирует быструю отбраковку "плохих" пакетов (более того, согласно последним исследованиям в мире криптографии, именно такой порядок действий наиболее безопасен, обратный порядок в некоторых, правда очень частных случаях, может привести к потенциальным дырам в безопасности; к счастью, ни SSL, ни IKE, ни другие распространенные протоколы с порядком действий "сначала аутентифицировать, потом зашифровать", к этим частным случаям не относятся, и, стало быть, этих дыр не имеют).
 Остается атака Denial-Of-Service (отказ в обслуживании). Как известно, это атака, от которой не существует полной защиты. Тем не менее, быстрая отбраковка плохих пакетов и отсутствие какой-либо внешней реакции на них (согласно RFC) позволяют более-менее хорошо справляться с этой атакой. В принципе, большинству (если не всем) известным сетевым атакам (sniffing, spoofing, hijacking и т.п.) AH и ESP при правильном их применении успешно противостоят. С IKE несколько сложнее. Протокол очень сложный, тяжел для анализа. Кроме того, в силу опечаток (в формуле вычисления HASH_R) при его написании и не совсем удачных решений (тот же HASH_R и HASH_I) он содержит несколько потенциальных "дыр" (в частности, в первой фазе не все Payload в сообщении аутентифицируются), впрочем, они не очень серьезные и ведут, максимум, к отказу в установлении соединения. От атак типа replay, spoofing, sniffing, hijacking IKE более-менее успешно защищается. С криптографией несколько сложнее, - она не вынесена, как в AH и ESP, отдельно, а реализована в самом протоколе. Тем не менее, при использовании стойких алгоритмов и примитивов (PRF), проблем быть не должно. В какой-то степени можно рассматривать как слабость IPsec то, что в качестве единственного обязательного к реализации криптоалгоритма в нынешних спецификациях указывается DES (это справедливо и для ESP, и для IKE), 56 бит ключа которого уже не считаются достаточными. Тем не менее, это чисто формальная слабость - сами спецификации являются алгоритмо-независимыми, и практически все известные вендоры давно реализовали 3DES (а некоторые уже и AES).Таким образом, при правильной реализации, наиболее "опасной" атакой остается отказ в обслуживании.
Оценка протокола
 Протокол IPSec получил неоднозначную оценку со стороны специалистов. С одной стороны, отмечается, что протокол IPSec является лучшим среди всех других протоколов защиты передаваемых по сети данных, разработанных ранее (включая разработанный Microsoft PPTP ). С другой стороны, присутствует чрезмерная сложность и избыточность протокола. По мнению аналитиков, протокол является слишком сложным, чтобы быть безопасным. В частности, Niels Ferguson и Bruce Schneier в своей работе "A Cryptographic Evaluation of IPsec – Криптографическое вычисление IPsec” отмечают, что они обнаружили серьёзные проблемы безопасности практически во всех главных компонентах IPsec. Авторы также отмечают, что набор протоколов требует серьёзной доработки для того, чтобы он обеспечивал хороший уровень безопасности. Они также приводят описание ряда атак, использующих как слабости общей схемы обработки данных, так и слабости криптографических алгоритмов.
 В этой главе мы рассмотрели некоторые основные моменты, касающиеся протокола сетевой безопасности IPsec. Не лишним будет отметить, что протокол IPsec реализован в операционной системе Windows2000 компании Microsoft. В заключение главы приводится таблица, в которой производится сравнение IPSec и широко распространённого сейчас SSL.

Особенности IPSec SSL
Аппаратная независимость Да Да
Код Не требуется изменений для приложений. Может потребовать доступ к исходному коду стека TCP/IP. Требуются изменения в приложениях. Могут потребоваться новые DLL или доступ к исходному коду приложений.
Защита IP пакет целиком. Включает защиту для протоколов высших уровней. Только уровень приложений.
Фильтрация пакетов Основана на аутентифицированных заголовках, адресах отправителя и получателя, и т.п. Простая и дешёвая. Подходит для роутеров. Основана на содержимом и семантике высокого уровня. Более интеллектуальная и более сложная.
Производительность Меньшее число переключений контекста и перемещения данных. Большее число переключений контекста и перемещения данных. Большие блоки данных могут ускорить криптографические операции и обеспечить лучшее сжатие.
Платформы Любые системы, включая роутеры В основном, конечные системы (клиенты/серверы), также firewalls.
Firewall/VPN Весь трафик защищён. Защищён только трафик уровня приложений. ICMP, RSVP, QoS и т.п. могут быть незащищены.
Прозрачность Для пользователей и приложений. Только для пользователей.
Текущий статус Появляющийся стандарт. Широко используется WWW браузерами, также используется некоторыми другими продуктами.

Табл. 2. Классификация типовых удаленных атак на распределенные ВС
7.3 FireWall
Интернет-технологии FireWall (Межсетевые экраны)
Обзор
 Когда Вы соединяете Вашу сеть с Internet или с другой сетью, фактор обеспечения безопасности доступа в Вашу сеть имеет критическое значение. Наиболее эффективный способ защиты при связи с Internet предполагает размещение межсетевого экрана FireWall между Вашей локальной сетью и Internet. Межсетевые экраны реализуют механизмы контроля доступа из внешней сети к внутренней путем фильтрации всего входящего и исходящего трафика, пропуская только авторизованные данные.
 Существует три основных типа межсетевых экранов - пакетный фильтр (packet filtering), шлюз на сеансовом уровне (circuit-level gateway) и шлюз на прикладном уровне (application-level gateway). Очень немногие существующие межсетевые экраны могут быть однозначно отнесены к одному из названных типов. Как правило, МСЭ совмещает в себе функции двух или трех типов.
 Как уже отмечалось, для того, чтобы эффективно обеспечивать безопасность сети, firewall обязан отслеживать и управлять всем потоком, проходящим через него. Для принятия управляющих решений для TCP/IP-сервисов (то есть передавать, блокировать или отмечать в журнале попытки установления соединений), firewall должен получать, запоминать, выбирать и обрабатывать информацию, полученную от всех коммуникационных уровней и от других приложений.
 Недостаточно просто проверять пакеты по отдельности. Информация о состоянии соединения, полученная из инспекции соединений в прошлом и других приложений - главный фактор в принятии управляющего решения при попытке установления нового соединения. Для принятия решения могут учитываться как состояние соединения (полученное из прошлого потока данных), так и состояние приложения (полученное из других приложений).
 Итак, управляющие решения требуют чтобы firewall имел доступ, возможность анализа и использования следующих вещей:
1. Информация о соединениях - информация от всех семи уровней в пакете.
2. История соединений - информация, полученная от предыдущих соединений. Например, исходящая команда PORT сессии FTP должна быть сохранена для того, чтобы в дальнейшем с его помощью можно было проверить входящее соединение FTP data.
3. Состояния уровня приложения - информация о состоянии, полученная из других приложений. Например, аутентифицированному до настоящего момента пользователю можно предоставить доступ через firewall только для авторизованных видов сервиса.
4. Манипулирование информацией - вычисление разнообразных выражений, основанных на всех вышеперечисленных факторах.
Сравнение альтернатив
 В этом разделе описаны границы, в которых доступные технологии firewall обеспечивают эти четыре своих основных свойства.
Маршрутизаторы
 Маршрутизаторы действуют на сетевом уровне и их очевидным недостатком является неспособность обеспечивать безопасность даже для наиболее известных сервисов и протоколов. Маршрутизаторы не являются устройствами обеспечения безопасности, так как они не имеют основных возможностей firewall:
1. Информация о соединении - маршрутизаторы имеют доступ лишь к ограниченной части заголовка пакетов.
2. Наследуемая информация о соединении и приложении - маршрутизаторы не поддерживают хранение информации о истории соединения или приложения.
3. Действия над информацией - маршрутизаторы имеют очень ограниченные возможности по действиям над информацией.
 К тому же, маршрутизаторы трудно конфигурировать, следить за их состоянием и управлять. Они не обеспечивают должного уровня журналирования событий и механизмов оповещения.
Proxy
 Proxy являются попыткой реализовать firewall на уровне приложения. Их основное преимущество - поддержка полной информации о приложениях. Proxy обеспечивают частичную информацию об истории соединений, полную информацию о приложении и частичную информацию о текущем соединении. Proxy также имеют возможность обработки и действий над информацией.
Однако, имеются очевидные трудности в использовании proxy на уровне приложения в качестве firewall, включая :
1. Ограничения на соединения - каждый сервис требует наличия своего собственного proxy, так что число доступных сервисов и их масштабируемость ограничены.
2. Ограничения технологии – шлюзы прикладного уровня не могут обеспечить proxy для UDP, RPC2 и других сервисов общих семейств протоколов.
3. Производительность - реализация на уровне приложения имеет значительные потери в производительности.
 В добавление, proxy беззащитны к ошибкам в приложениях и ОС, неверной информации в нижних уровнях протоколов и в случае традиционных proxy очень редко являются прозрачными.
Исторически proxy уровня приложений удовлетворяли применению общему их применению и нуждам Internet. Однако, по мере превращения Internet в постоянно меняющуюся динамичную среду, постоянно предлагающую новые протоколы, сервисы и приложения, proxy более не способны обработать различные типы взаимодейстывий в Internet или отвечать новым нуждам бизнеса, высоким требованиям к пропускной способности и безопасности сетей.
7.4 Check Point FireWall-1 технология проверки с учетом состояния протокола (Stateful Inspection Technology)
Технология FireWall-1
 В отличие от описанных альтернатив, FireWall-1 вводит передовую архитектуру, названную технологией проверки с учетом состояния протокола, которая реализует все необходимые возможности firewall на сетевом уровне.
 Предлагая проверку с учетом состояния протокола, FireWall-1 модуль инспекции имеет доступ и анализирует данные, полученные от всех уровней коммуникаций. Эти данные о "состоянии" и "контексте" запоминаются и обновляются динамически, обеспечивая виртуальную информацию о сессии для отслеживания протоколов без установки соединений (таких как RPC и приложений основанных на UDP). Данные, собранные из состояний соединений и приложений, конфигурации сети и правил безопасности, используются для генерации соответствующего действия и либо принятия, либо отвержения, либо шифрации канала связи. Любой трафик, который намеренно не разрешен правилами безопасности блокируется по умолчанию и одновременно в реальном времени генерируются сигналы оповещения, обеспечивая системного администратора полной информацией о состоянии сети.
Табл. 3. Сравнение технологий
Свойство firewall Маршрутизаторы Proxy Проверка с учетом состояния протокола
Информация о канале связи Частично Частично Да
Информация об истории соединений Нет Частично Да
Информация о состоянии приложения Нет Да Да
Действия над информацией Частично Да Да
 
 Итак, FireWall-1 совмещает прозрачность на сетевом уровне, полноту, надежность и высокую производительность с гибкостью на уровне приложений, обеспечивая тем самым превосходное решение для обеспечения безопасности, которое значительно превосходит возможности предыдущих решений.
Политика безопасности
 Политика безопасности FireWall-1 выражается в виде базы правил и свойств. База правил - это упорядоченный набор правил, с помощью которых проверяется каждое соединение. Если источник соединения, назначение и тип сервиса соответствуют правилу, с соединением будет выполнено действие, описанное в правиле (Accept - принять, Encrypt-зашифровать, Reject-отклонить, Drop-оставить). Если соединение не соответствует ни одному из правил, оно блокируется, в соответствии с принципом "Что специально не разрешено, всегда запрещено".
Модуль проверки FireWall-1
 Модуль проверки FireWall-1 динамически загружается в ядро операционной системы, между уровнем Data Link – каналом передачи данных  и сетью (уровни 2 и 3). Когда приходит первый пакет нового соединения, модуль проверки FireWall-1 проверяет базу правил для определения должно ли быть разрешено это соединение. Как только соединение установлено, FireWall-1 добавляет его во внутреннюю таблицу соединений. Из соображений эффективности, последующие пакеты соединения проверяются по таблице соединений, а не по базе правил. Пакету разрешается быть переданным только, если соединение имеется в таблице соединений.
В таком соединении как здесь, соединение полностью ведется модулем проверки FireWall-1 (рис. 9).
 
Рис.12 Соединение управляется модулем проверки FireWall-1
Примеры
UDP
 Из информации в заголовке TCP/UDP, FireWall-1, используя свои уникальные способности, моделирует состояние коммуникационного протокола, на основе чего отслеживает и управляет соединениями UDP.
FTP
 Для отслеживания обратного соединения FTP-data, FireWall-1 извлекает информацию из области приложения в пакете. Такая уникальная способность использования информации из всех уровней позволяет FireWall-1 моделировать состояние протокола, на основе чего обратное соединение может быть установлено ("Исходящие соединения FTP").
RPC
 FireWall-1 использует все описанные выше возможности, включая информацию о состоянии, полученную из приложения для отслеживания динамического переназначения номеров программ и портов этого сложного протокола ("RPC (Remote Procedure Call)").
Аутентификация на сервере безопасности и безопасность содержания
 FireWall-1 позволяет администратору определять политику безопасности для каждого пользователя, где не только источник соединения, назначения и сервис проверяются, но и каждый пользователь должен быть аутентифицирован. Более того, соединения могут быть разрешены или запрещены исходя из их содержания. К примеру, почта для или от определенных адресов может быть запрещена или перенаправлена, доступ может быть запрещен к заданным URL , и включена анти-вирусная проверка над передаваемыми файлами.
 Аутентификация и проверка содержимого обеспечиваются набором серверов безопасности FireWall-1, работающих на уровне приложения (Рис. 10).
 
Рис. 13 Соеднение через сервер безопасности FireWall-1
 
 Когда работает сервер безопасности FireWall-1, модуль проверки перенаправляет все пакеты соединения к серверу безопасности, который выполняет требуемую аутентификацию и/или проверку содержимого.
Существуют пять серверов безопасности FireWall-1, как показано в Таблице 4.
Табл. 4. Серверы безопасности FireWall-1 - свойства
Сервер Аутентификация Проверка содержимого
TELNET Да Нет
RLOGIN Да Нет
FTP Да Да
HTTP Да Да
SMTP Нет Да

Распределение нагрузки
 FireWall-1 позволяет распределить вычислительную нагрузку на любое число серверов. Рис. 11 показывает конфигурацию, в которой сервисы FTP и HTTP обслуживаются несколькими серверами.
 
Рис. 14 Распределение нагрузки по нескольким серверам
 Все HTTP серверы способны дать клиенту одинаковые сервисы (однако не все HTTP серверы позади защищенного моста). Таким же образом, все FTP серверы обеспечивают клиентов одинаковым сервисом.
 Системному администратору важно, чтобы загрузка по обслуживанию была распределена между серверами. Клиент не будет подозревать о наличии нескольких разных серверов. С точки зрения клиента, есть только один HTTP и один FTP сервер. Когда запрос на обслуживание достигает FireWall, FireWall-1 определяет какой из серверов будет обслуживать данный запрос, основываясь на алгоритме балансирования загрузки, заданном системным администратором.
Алгоритм распределения нагрузки
 Доступны следующие алгоритмы распределения :
1. По загрузке сервера. FireWall-1 запрашивает серверы чтобы определить, который из них лучше всего способен обслужить новое соединение.
2. По времени ответа на ping (round trip). FireWall-1 использует ping для определения времени прохождения пакета между FireWall-1 и каждым из серверов и выбирает сервер с наименьшим временем ответа.
3. По кругу. FireWall-1 просто назначает следующий сервер в списке.
4. Случайный. FireWall-1 назначает сервер в случайном порядке.
5. По доменному имени. FireWall-1 назначает "ближайший" сервер, основываясь на доменных именах.
Аутентификация
 FireWall-1 обеспечивает при вида аутентификации:
1. Аутентификация пользователя, которая позволяет администратору давать каждому пользователю свои привилегии доступа. Аутентификация пользователя включает сервер безопасности HTTP FireWall-1, который предоставляет механизм для аутентификации пользователей сервиса HTTP, как входящего так и исходящего.
2. Аутентификация клиентов дает механизм для аутентификации пользователя любого приложения, стандартного или собственной разработки.
3. Аутентификация сессий, дающая прозрачную аутентификацию каждой сессии, что может быть интегрировано с любым приложением.
Табл. 5. Сравнение типов аутентификации

  Пользователь Клиент Сессия
Сервисы TELNET, FTP, RLOGIN, HTTP Все сервисы Все сервисы
Аутентификация выполняется один раз на … Сессию Адрес IP (много сессий) в отдельной непрозрачной сессии аутентификации Сессии
Прозрачность (пользователь инициирует сессию непосредственно к серверу)? Да Да, только после непрозрачной сессии аутентификации Да
 
 Обратите внимание: аутентификация клиента и сессии обеспечиваются не серверами безопасности, а другими механизмами, описанными в "Аутентификация клиента" и "Аутентификация сессии".
FireWall-1 поддерживает следующие схемы аутентификации для каждого пользователя:
1. S/Key - Пользователю требуется ввести значения S/Key для данной итерации.
2. SecurID - Пользователю требуется ввести номер, показанный на SecurID карте Security Dynamics (безопасная динамика).
3. По паролю - от пользователя требуют ввести его (или ее) пароль OС.
4. Внутренняя - пользователь должен ввести его (или ее) внутренний пароль FireWall-1 на мосте.
5. RADIUS - пользователь должен ввести ответ на запрос сервера RADIUS.
6. AssureNet Pathways - пользователь должен ввести ответ на запрос сервера AssureNet Pathway (обеспечение сетевого пути).
Проверка потока данных
 Возможность проверки содержания расширяет набор возможностей по проверке данных до протоколов самого верхнего уровня. Эта возможность позволяет максимально гибко управлять доступом к сетевым ресурсам.
FireWall-1 обеспечивает проверку содержания для HTTP, SMTP и FTP с использованием серверов безопасности FireWall-1. Для каждого соединения, установленного через сервер безопасности FireWall-1, администратор может управлять доступом в соответствии с различными параметрами протокола данного сервиса: URL, именами файлов, командами FTP PUT/GET, типами запросов и так далее.
 Наиболее важное применение проверки содержания - анти-вирусная проверка передаваемых файлов. Анти-вирусная поддержка полностью интегрирована с FireWall-1.
Проверка содержания реализуется через тип обьекта FireWall-1 Resource. Определение обьекта Resource задает ряд составляющих, которые могут быть доступны через определенный протокол. Вы можете задавать FireWall-1 Resource на основе протоколов HTTP, FTP и SMTP.
 Например, вы можете задать URI ресурс, чьими атрибутами будет список URL и схем HTTP и FTP. Ресурс может быть использован в базе правил точно таким же образом, как и любой другой тип сервиса, и для него также могут быть определены стандартные процедуры записи события в журнал и оповещения администратора системы для обеспечения возможности наблюдения за использованием данного ресурса.
HTTP
 Ресурсы URI могут определять схемы (HTTP, FTP, GOPHER и т.д.), методы (GET,PUT, и т.д.), машины (например, "*.com"), пути и запросы. Также может быть задан файл, содержащий список IP адресов и серверов.
SMTP
 Протокол SMTP, разработанный для обеспечения наиболее удобного общения между людьми через Internet, и расширенный для поддержки не только e-mail, но и передачи файлов, предоставляет выбор системному администратору, который хочет одновременно поддерживая прозрачность соединений, не позволять нарушителям проникнуть внутрь сети.
FireWall-1 предлагает сервер SMTP, который обеспечивает максимально детальный контроль над соединениями SMTP. Определяя SMTP ресурсы, администратор безопасности имеет возможности:
 спрятать в исходящей почте адрес From под стандартным общим адресом, закрыв тем самым внутреннюю архитектуру сети и реальные имена пользователей.
 перенаправить почту, посланную на данный адрес To (например для root) на другой почтовый адрес.
 уничтожать всю почту от заданного адреса.
 обрезать все прикрепленные к письмам файлы.
 убирать поля Received из исходящей почты для закрытия внутренней структуры сети.
 уничтожать все письма размера более заданного.
FTP
 Сервер безопасности FTP обеспечивает аутентификацию и проверку содержимого, основываясь на командах FTP (PUT/GET), ограничениях на имена файлов и анти-вирусной проверке файлов.
Анти-вирус
 Анти-вирусная проверка является составной частью такого свойства FireWall-1, как проверка содержимого потоков данных и значительно снижает уязвимость защищенных машин.
Проверка всех передаваемых файлов проводится с использованием встроенного анти-вирусного модуля. Конфигурация этого механизма (какие файлы проверять, что делать с зараженными файлами) полностью интегрирована в политику безопасности (базу правил). Все инструменты управления и проверки FireWall-1 доступны для журналирования и оповещения о случаях нахождения зараженных файлов.
7.5 Недостатки межсетевых экранов
Отсутствие защиты от авторизованных пользователей
Проблема:
 Невозможность защиты от пользователей, знающих идентификатор и пароль для доступа в защищаемый сегмент корпоративной сети.
 Межсетевой экран может ограничить доступ посторонних лиц к ресурсам, но он не может запретить авторизованному пользователю скопировать ценную информацию или изменить какие-либо параметры финансовых документов, к которым этот пользователь имеет доступ.
Решение:
 Для устранения этого недостатка нужны новые подходы и технологии. Например, использование систем обнаружения атак (intrusion detection systems). RealSecure, обнаруживают и блокируют несанкционированную деятельность в сети независимо от того, кто ее реализует - авторизованный пользователь (в т.ч. и администратор) или злоумышленник.
Отсутствие защиты новых сетевых сервисов
Проблема:
 Невозможность защиты новых сетевых сервисов. Как правило, МСЭ разграничивают доступ по широко распространенным протоколам, таким как HTTP, Telnet, SMTP, FTP и ряд других. Реализуется это при помощи при помощи механизма "посредников" (proxy), обеспечивающих контроль трафика, передаваемого по этим протоколам или при помощи указанных сервисов. И хотя число таких "посредников" достаточно велико, они существуют не для всех новых протоколов и сервисов.
Решение:
 Многие производители межсетевых экранов пытаются решить указанную проблему, но удается это далеко не всем. Некоторые производители создают proxy для новых протоколов и сервисов, но всегда существует временной интервал от нескольких дней до нескольких месяцев между появлением протокола и соответствующего ему proxy. Другие разработчики межсетевых экранов предлагают средства для написания своих proxy
 В этом случае необходима высокая квалификация и время для написания эффективного proxy, учитывающего специфику нового сервиса и протокола. Аналогичная возможность существует и у межсетевого экрана CheckPoint Firewall-1, который включает в себя мощный язык INSPECT, позволяющий описывать различные правила фильтрации трафика.
Ограничение функциональности сетевых сервисов
Проблема:
 Некоторые корпоративные сети используют топологию, которая трудно "уживается" с межсетевым экраном, или используют некоторые сервисы (например, NFS ) таким образом, что применение МСЭ требует существенной перестройки всей сетевой инфраструктуры.
 В такой ситуации относительные затраты на приобретение и настройку межсетевого экрана могут быть сравнимы с ущербом, связанным с отсутствием МСЭ.
Решение:
 Решить данную проблему можно только путем правильного проектирования топологии сети на начальном этапе создания корпоративной информационной системы.
Потенциальная опасность обхода межсетевого экрана
Проблема:
 Межсетевые экраны не могут защитить ресурсы корпоративной сети в случае неконтролируемого использования в ней модемов. Доступ в сеть через модем по протоколам SLIP(межсетевой протокол для последовательного канала) или PPP(ротокол двухточечного соединения) в обход межсетевого экрана делает сеть практически незащищенной.
Решение:
 Для решения этой задачи необходимо строго контролировать все имеющиеся в корпоративной сети модемы и программное обеспечение удаленного доступа. Для этих целей возможно применение как организационных, так и технических мер. Например, использование систем разграничения доступа, в т.ч. и к COM-портам (например, Secret Net) или систем анализа защищенности (например, Internet Scanner и System Scanner).
Потенциально опасные возможности
Проблема:
 Новые возможности, которые появились недавно, и которые облегчают жизнь пользователям Internet, разрабатывались практически без учета требований безопасности. Например, WWW, Java, ActiveX  и другие сервисы, ориентированные на работу с данными. Они являются потенциально опасными, так как могут содержать в себе враждебные инструкции, нарушающие установленную политику безопасности.
Решение:
 Защита от таких полезных, но потенциально опасных возможностей должна решаться в каждом конкретном случае по-своему. Можно проанализировать необходимость использования новой возможности и совсем отказаться от нее; а можно использовать специализированные защитные средства, например, систему SurfinShield компании Finjan или SafeGate компании Security-7 Software, обеспечивающие безопасность сети от враждебного "мобильного" кода.
Вирусы и атаки
Проблема:
 Практически ни один межсетевой экран не имеет встроенных механизмов защиты от вирусов и, в общем случае, от атак. Как правило, эта возможность реализуется путем присоединения к МСЭ дополнительных модулей или программ третьих разработчиков (например, система антивирусной защиты ViruSafe для МСЭ CyberGuard Firewall или система обнаружения атак RealSecure для МСЭ CheckPoint Firewall-1). Использование нестандартных архиваторов или форматов передаваемых данных, а также шифрование трафика, сводит всю антивирусную защиту "на нет". Как можно защититься от вирусов или атак, если они проходят через межсетевой экран в зашифрованном виде и расшифровываются только на оконечных устройствах клиентов?
Решение:
В таком случае лучше перестраховаться и запретить прохождение через межсетевой экран данных в неизвестном формате.
Снижение производительности
Проблема:
 Несмотря на то, что подсоединение к сетям общего пользования или выход из корпоративной сети осуществляется по низкоскоростным каналам (как правило, при помощи dialup-доступа на скорости до 56 Кбит или использование выделенных линий до 256 Кбит), встречаются варианты подключения по каналам с пропускной способностью в несколько сотен мегабит и выше (ATM , T1, E3 и т.п.). В таких случаях межсетевые экраны являются самым узким местом сети, снижая ее пропускную способность. В некоторых случаях приходится анализировать не только заголовок (как это делают пакетные фильтры), но и содержание каждого пакета ("proxy"), а это существенно снижает производительность межсетевого экрана. Для сетей с напряженным трафиком использование межсетевых экранов становится нецелесообразным.
Решение:
 В таких случаях на первое место надо ставить обнаружение атак и реагирование на них, а блокировать трафик необходимо только в случае возникновения непосредственной угрозы.
Отсутствие контроля своей конфигурации
Проблема:
 Даже если все описанные выше проблемы решены, остается опасность, что межсетевой экран неправильно сконфигурирован.
Решение:
 В этом случае помогут средства анализа защищенности. Средства анализа защищенности могут тестировать межсетевой экран как на сетевом уровне (например, подверженность атакам типа "отказ в обслуживании"), так и на уровне операционной системы (например, права доступа к конфигурационным файлам межсетевого экрана). Кроме того, при сканировании возможна реализация атак типа "подбор пароля", позволяющие обнаружить "слабые" пароли или пароли, установленные производителем по умолчанию. К средствам, проводящим такие проверки, можно отнести, например, систему Internet Scanner американской компании Internet Security Systems (ISS).
 Ознакомившись с описанными проблемами, многие могут сделать вывод, что межсетевые экраны не могут обеспечить защиту корпоративной сети от несанкционированного вмешательства. Это не так. Межсетевые экраны являются необходимым, но явно недостаточным средством обеспечения информационной безопасности. Они обеспечивают лишь первую линию обороны. Не стоит покупать межсетевой экран только потому, что он признан лучшим по результатам независимых испытаний. При выборе и приобретении межсетевых экранов необходимо тщательно все продумать и проанализировать. В некоторых случаях достаточно установить простейший пакетный фильтр, свободно распространяемый в сети Internet или поставляемый вместе с операционной системой, например squid. В других случаях межсетевой экран необходим, но применять его надо совместно с другими средствами обеспечения
8. Решения на аппаратном уровне
 Большинство сетевых бизнес-коммуникаций происходит между сервером и рабочими станциями клиентов, и между рабочими станциями в группе. Здесь же находится самая большая внутренняя угроза безопасности данных. Идентификация, целостность и шифрование данных, реализованные в сетевых адаптерах могли бы гарантировать защиту передаваемых данных в локальных сетях
 Традиционно большинство компаний и предприятий строят свои межсетевые экраны и парольную защиту своей сети от несанкционированного доступа извне. Однако исследования показывают, что большинство нарушений защит было произведено внутри самих компаний, а не извне (71% против 25%), и их число продолжает увеличиваться. Вследствие интеллектуального воровства предприятия несут огромные убытки, и помимо внешней защиты появляется необходимость создавать защиту локальных сетей. Для эффективной безопасности передачи данных внутри локальных сетей может быть использован Internet Protocol Security (IPSec), который доступен уже сейчас, как протокол защиты локальных сетей.
IPSec решения
 Корпорация Intel предлагает первое семейство сетевых адаптеров с встроенной защитой данных - Intel® PRO/100 S Desktop, Server и Mobile Adapters. Эти адаптеры оптимизированы для аппаратной обработки IPSec в Windows* 2000, и для расширения возможностей Windows NT* 4.0 и Windows 98 используя Intel® Packet Protect software. Реализованная в адаптерах технология переносит операции кодирования/декодирования на контроллер Intel® 82550 адаптера, который имеет интегрированный сопроцессор кодирования. Это решение позволяет освободить центральный процессор сервера или ПК для выполнения других задач и, таким образом не влияет на пропускную способность сетевого соединения.
 IPSec обеспечивает превосходную защиту локальной сети, однако процесс кодирования/декодирования требует от ЦП интенсивных вычислений. Если обработка этих процессов производится на сервере, то это требует настолько много вычислительной мощности ЦП, что эффективная пропускная способность сервера может снизиться с 100 Мбит/с до 20 Мбит/с. При этом эффективность работы сервера и ПК пользователя может снижаться, в то время как утилизация ЦП возрастает, потому что процессоры сосредоточены на кодировании, вместо других функций, требуемых пользователям.
 Разгрузка ЦП особенно важна для работы сервера, потому что серверы получают зашифрованные пакеты от многих рабочих станций и должны тратить больше времени на обработку, чем рабочая станция. Для этого IPSec адаптер устанавливается на каждый сервер и пользовательские рабочие станции, которые будут частью защищенной локальной сети.
 IPSec выполняется на 3 уровне протокольного стека, в результате этого он прозрачен для приложений, в отличии от технологий защиты, которые выполняются на других уровнях. Это означает, что применение протокола IPSec относительно недорого и не требует изменения приложений и повторного обучения пользователей.
Три уровня развертывания защиты
 На первом этапе развертывания защиты локальной сети адаптеры Intel® PRO/100 S должны быть устанавлены на ПК пользователей, которым нужна защищенная связь и на серверы, которые используются этими пользователями. После того, как адаптеры установлены согласно правилам IPSec, при установлении связи компьютер предложит использовать протокол IPSec и если оба компьютера допускают использование протокола IPSec, то передаваемые ими данные будут зашифрованы. Если сервер или клиентская рабочая станция не поддерживает протокол IPSec, то последует открытая передача данных. Благодаря этому все передаваемые данные между выбранными клиентами и серверами будут зашифрованы, и информация не может быть перехвачена другими пользователями внутри локальной сети предприятия. Для идентификации пользователя используются предварительно распределенные ключи.

 На следующем этапе должны определяться различные уровни кодирования и идентификации для каждого пользователя в зависимости от роли ПК и исходя из трафика проходящего через него. Для усиления защиты локальной сети создаются две рабочие группы. Одна рабочая группа - эксклюзивная, она использует индивидуальную политику защиты, кроме того, эта рабочая группа входит и в общую политику защиты. Это позволяет надежно дифференцировать сообщения между эксклюзивной рабочей группой и основной сетью. При этом выделенная рабочая группа может посылать кодированные сообщения доступные для всех пользователей или только для определенных клиентов внутри самой группы.
 Третий этап – авторские полномочия. Как только политика защиты для выделенной рабочей группы построена и хорошо работает, они могут быть сгруппированы вместе, и развертывание IPSec может быть расширенно на других членов группы. Таким образом, модель выделенной рабочей группы может быть расширена на часть или на всю компанию. На определенном этапе этого процесса предприятие может решить, что ему необходима более строгая защита. Хотя предварительно распределенные ключи обеспечивают превосходную идентификацию для начального этапа защиты локальной сети, но это не самый строгий уровень, который возможен. Строгий уровень идентификации можно обеспечить, используя стандарт X.509 дл цифровых удостоверений, которые проверяются авторскими полномочиями. В решениях Intel используется Entrust* - один из наиболее уважаемых видов авторских полномочий. В рассмотренном примере, при выдачи цифровых удостоверений, возможно, уникально идентифицировать каждого пользователя выделенной группы. Это позволяет системному администратору дифференцировать запросы сделанные разными по приоритету пользователями.

Ключи защиты
 Процесс аутентификации IPSec требует уникального идентификатора или ключа для каждого привлеченного компьютера. Распределение и обслуживание этих ключей может быть произведено одним из двух способов:
 Предварительно распределенные ключи
 В этом случае сетевой администратор сам распределяет ключи. Преимущества предварительно распределенных ключей в том, что они просты в конфигурировании и не требуют специального программного обеспечения. Предварительно распределенные ключи подходят для рабочей группы среднего размера, с умеренными потребностями защиты.
 Авторские полномочия
 В этом случае третье лицо выпускает цифровые удостоверения. Авторские полномочия гарантируют, что пользователь предоставляя уникальный сертификат, будет определен, кто он есть и каковы его полномочия. Наиболее широко применяется промышленный стандарт для определения цифровых удостоверений – Х.509. Обычно, метод авторских полномочий применяется в финансовых учреждениях или других организациях, где необходимо подтверждение своих полномочий.
IPSec в сетевых адаптерах Intel
 Сетевая безопасность является одной из основных проблем, связанных с развитием сетей и Internet. В локальных сетях защита данных особенно важна при быстром росте деловой среды, где безопасность – основное беспокойство пользователя. Сетевые адаптеры Intel, использующие IPSec, разгружают ЦП и обеспечивают безопасную соединение клиент – сервер. Применение адаптеров, реализующих IPSec, является экономичным, легко устанавливаемым и масштабируемым решением для защиты данных в локальных сетях. Сетевые адаптеры Intel, реализующие IPSec:
 Intel PRO/100 S Desktop Adapter
 Intel PRO/100 S Server Adapter
 Intel PRO/100+ Dual Port S Server Adapter
 Intel PRO/100 SR CardBus II Mobile Adapter
 Intel PRO/100 SR LAN+Modem56 CardBus II Mobile Adapter
 Intel PRO/100 SR Mobile Adapter (RealPort Type III)
 Intel PRO/100 SR LAN+Modem56 Mobile Adapter (RealPort Type III)
9. Заключение
Как уже было отмечено в одной из первых глав,  главной целью создания сети Интернет было обеспечение функциональности при выходе из строя одного или нескольких ее узлов, цель совсем состояла в обеспечение безопасности, исходно сеть создавалась как незащищенная открытая система, предназначенная для информационного общения все возрастающего числа пользователей. При этом подключение новых пользователей должно было быть максимально простым, а доступ к информации - наиболее удобным. Все это явно противоречит принципам создания защищенной системы, безопасность которой должна быть описана на всех стадиях ее создания и эксплуатации, а пользователи - наделены четкими полномочиями.
Internet создавался как незащищенная система, не предназначенная для хранения и обработки конфиденциальной информации. Следовательно, протоколы используемые в этой сети также не обеспечивают должного контроля безопасности и целосности информационных ресурсов.
На мой взгляд, в Сети не должна находиться информация, раскрытие которой приведет к серьезным последствиям.. Наоборот, в Сети необходимо размещать информацию, распространение которой желательно ее владельцу. При этом всегда необходимо учитывать тот факт, что в любой момент эта информация может быть перехвачена, искажена или может стать недоступной. Следовательно, речь должна идти не о защищенности Internet, а об обеспечении разумной достаточности информационной безопасности Сети.
Конечно, это не отменяет необходимости ознакомления пользователя с богатым и все время возрастающим арсеналом программных и аппаратных средств обеспечения информационной безопасности сети. Тем не менее стоит отметить, что они не в состоянии превратить сеть в защищенную среду, что означило бы изменение ее природы.
10. Список использованных источников
1.  Прикладная криптография. /Б. Шнайер. - М.: Издательство ТРИУМФ,2002.
2. Основы криптографии: Учебное пособие. /Алферов А.П., Зубов А.Ю., Кузьмин А.С. Черемушкин А.В. - М.: Гелиос, 2001.
3. Атака через INTERNET / Медведовский И.Д., Семьянов П.В., Платонов В.В.; Под ред. проф. Зегжды П.Д. - СПб: Мир и семья-95, 1998. - 296с.: ил.
4. Защита информации в компьютерных системах и сетях / Романец Ю.В., Тимофеев П.А., Шаньгин В.Ф.; Под ред. В.Ф.Шаньгина. - М.: Радио и связь, 1999. - 328с.
5. http://www.knurr.ru/chkpf/archive/wp_v3_0/
6. http://www.lnt.ru/solutions.asp?r=20
7. http://sky.net.ua/review/index.php?review_id=109
8. http://www.microsoft.com/rus/windows2000/library/security/w2k_IPSecurity.asp

9. http://developer.netscape.com/docs/manuals/security/sslin/contents.htm
10. http://nsa.by.ru/docs/security/s23.html
11. http://book.itep.ru
12. http://oradb1.jinr.dubna.su/Netscape/MISC/SSL.htm
13. http://www.unixoid.spb.ru/Security/ssl2.html
14. http://www.nestor.minsk.by/sr/sr0006/sr00607.html
15. http://www.citforum.ru/internet/securities/tcpip.shtml
16. http://www.ixbt.com/comm/ipsecure.shtml
Конец формы
Конец формы