2015-01-30
1003
Очевидно, что при построении защищенных систем следует бороться не с угрозами, являющимися следствием недостатков системы, а с причинами возможного успеха атак. Ясно, что для того, чтобы победить следствие, надо устранить причину. Поэтому, чтобы ликвидировать угрозы (удаленные атаки), осуществляемые по каналам связи, необходимо ликвидировать причины, их порождающие. Это основной принцип, руководствуясь которым, далее мы и сформулируем требования к защищенным системам связи в распределенных ВС.
Выделенный канал связи между объектами распределенной ВС
Утверждение 1.
Наилучшее с точки зрения безопасности взаимодействие объектов в распределенной ВС возможно только по физически выделенному каналу.
Виртуальный канал как средство обеспечения дополнительной
дентификации/аутентификации объектов в распределенной ВС
В предыдущем пункте рассматривались возможные наиболее безопасные варианты физического построения сети: как в РВС необходимо соединять объекты для обеспечения наиболее безопасного взаимодействия. Однако, для создания защищенного взаимодействия удаленных объектов подобных мер явно недостаточно, так как, во-первых, на практике обеспечить взаимодействие всех объектов по выделенному каналу достаточно сложно и, во-вторых, нельзя не предусмотреть вариант физического подключения к каналу. Следовательно, разработчик защищенной системы связи в распределенной ВС должен исходить из следующего принципа:
Утверждение 2.
При построении защищенной системы связи в распределенной ВС необходимо исходить из того, что все сообщения, передаваемые по каналу связи, могут быть перехвачены, но это не должно повлечь за собой нарушения безопасности системы в целом.
Таким образом, данное утверждение накладывает на разработчика следующие требования: необходимость введения дополнительных средств идентификации объектов в распределенной ВС и криптозащита передаваемых по каналу связи сообщений.
В п. 5.1.2 доказывалось, что идентификация объектов РВС, в отсутствие статической ключевой информации, возможна только при взаимодействии объектов с использованием виртуального канала (заметим, что в дальнейшем рассматривается только распределенная ВС, у объектов которой отсутствует ключевая информация для связи друг с другом - в подобной системе решить задачу безопасного взаимодействия несколько сложнее). Следовательно, для того, чтобы ликвидировать причину успеха удаленных атак, описанную в п. 5.1.2.1, а также, исходя из Утверждения 2, необходимо руководствоваться следующим правилом:
Утверждение 3.
Любое взаимодействие двух объектов в распределенной ВС должно проходить по виртуальному каналу связи.
Рассмотрим, как в распределенной ВС виртуальный канал (ВК) связи может использоваться для надежной, независимой от топологии и физической организации системы, идентификации ее удаленных объектов.
Для этого при создании ВК могут использоваться криптоалгоритмы с открытым ключом (например, недавно в Internet принят подобный стандарт защиты ВК, называемый Secret Socket Layer - SSL). Данные криптоалгоритмы основаны на результатах исследований, полученных в 70-х годах У. Диффи. Он ввел понятие односторонней функции с потайным входом. Это не просто вычисляемая в одну сторону функция, обращение которой невозможно, она содержит потайной вход (trapdoor), который позволяет вычислять обратную функцию лицу, знающему секретный ключ. Сущность криптографии с открытым ключом (или двухключевой криптографии) в том, что ключи, имеющиеся в криптосистеме, входят в нее парами и каждая пара удовлетворяет следующим двум свойствам:
текст, зашифрованный на одном ключе, может быть дешифрован на другом;
знание одного ключа не позволяет вычислить другой.
Поэтому один из ключей может быть опубликован. При опубликованном (открытом) ключе шифрования и секретном ключе дешифрования получается система шифрования с открытым ключом. Каждый пользователь сети связи может зашифровать сообщение при помощи открытого ключа, а расшифровать его сможет только владелец секретного ключа. При опубликовании ключа дешифрования получается система цифровой подписи. Здесь только владелец секретного ключа создания подписи может правильно зашифровать текст (т.е. подписать его), а проверить подпись (дешифровать текст) может любой на основании опубликованного ключа проверки подписи.
В 1976 г. У. Диффи и М. Хеллман предложили следующий метод открытого распределения ключей. Пусть два объекта A и B условились о выборе в качестве общей начальной информации большого простого числа p и примитивного корня степени p - 1 из 1 в поле вычетов по модулю p. Тогда эти пользователи действуют в соответствии с протоколом (рис. 6.4):
A вырабатывает случайное число x, вычисляет число a x (mod p) и посылает его B;
B вырабатывает случайное число y, вычисляет число a y (mod p) и посылает его A;
 |
затем A и B возводят полученное число в степень со своим показателем и получают число a xy (mod p).
Рис. 6.4. Алгоритм У. Диффи и М. Хеллмана открытого распределения ключей
Это число и является сеансовым ключом для одноключевого алгоритма, например, DES. Для раскрытия этого ключа криптоаналитику необходимо по известным a x (mod p), a y (mod p) найти a xy (mod p), т.е. найти x или y. Нахождение числа x по его экспоненте a x (mod p) называется задачей дискретного логарифмирования в простом поле. Эта задача является труднорешаемой, и поэтому полученный ключ, в принципе, может быть стойким [11].
Особенность данного криптоалгоритма состоит в том, что перехват по каналу связи пересылаемых в процессе создания виртуального канала сообщений a x (mod p) и a y (mod p) не позволит атакующему получить конечный ключ шифрования a xy (mod p). Этот ключ далее должен использоваться, во-первых, для цифровой подписи сообщений и, во-вторых, для их криптозащиты. Цифровая подпись сообщений позволяет надежно идентифицировать объект распределенной ВС и виртуальный канал. Шифрование сообщений необходимо для соблюдения Утверждения 2. В заключении к данному пункту сформулируем следующее требование к созданию защищенных систем связи в распределенных ВС и два следствия из него:
Утверждение 4.
Для обеспечения надежной идентификации объектов распределенной ВС при создании виртуального канала необходимо использовать криптоалгоритмы с открытым ключом.
Следствие 4.1.
Необходимо обеспечить цифровую подпись сообщений.
Следствие 4.2.
Необходимо обеспечить возможность шифрования сообщений.
Контроль за маршрутом сообщения в распределенной ВС
Как известно, каждый объект распределенной ВС должен обладать адресом, уникально его идентифицирующим. Для того, чтобы сообщение от одного объекта было передано на другой объект системы, оно должно пройти через цепь маршрутизаторов, задача которых- проанализировав адрес назначения, указанный в сообщении, выбрать оптимальный маршрут и, исходя из него, переправить пакет или на следующий маршрутизатор или непосредственно абоненту, если он напрямую подключен к данному узлу. Таким образом, маршрут до объекта определяется цепочкой узлов, пройденных сообщением. Как было показано в п. 5.1.4, маршрут сообщения может являться информацией, аутентифицирующей с точностью до подсети подлинность адреса субъекта, отославшего сообщение. Очевидно, что перед любой системой связи объектов в РВС встает стандартная проблема проверки подлинности адреса сообщения, пришедшего на объект. Эту задачу, с одной стороны, можно решить, введя дополнительную идентификацию сообщений на другом, более высоком уровне OSI. Так, адресация осуществляется на сетевом уровне, а дополнительная идентификация, например, на транспортном. Однако подобное решение не позволит избежать проблемы контроля за созданием соединений (п. 5.1.3), так как дополнительная идентификация абонентов будет возможна только после создания соединения. Поэтому разработчикам распределенной ВС можно предложить следующие пути решения проблемы.
В первом случае функцию проверки подлинности адреса отправителя можно возложить на маршрутизатор. Это несложно сделать, так как маршрутизатор может отследить, откуда к нему пришел пакет (от другого маршрутизатора или от подключенного к нему хоста из подсетей, напрямую подключенных к данному маршрутизатору). Маршрутизатор может проверять соответствие адреса отправителя с адресом соответствующей подсети, откуда пришло сообщение. В случае совпадения сообщение пересылается далее, а в противном случае - отфильтровывается. Этот способ позволит на начальной стадии отбросить пакеты с неверными адресами отправителя.
Другой вариант решения может состоять в создании в заголовке пакета специальных полей, куда каждый маршрутизатор, через который проходит пакет, заносит маршрутную информацию (часть своего адреса, например). При этом первый маршрутизатор, на который поступил пакет, заносит также информацию о классе сети (A, B, C), откуда пришел пакет. Тем не менее, внесение в пакет адресов всех пройденных по пути маршрутизаторов будет неоптимальным решением, так как в этом случае сложно заранее определить максимальный размер заголовка пакета.
Когда сообщение дойдет до конечного адресата, в его заголовке будет полностью отмечен пройденный маршрут. По этому маршруту, вне зависимости от указанного в пакете сетевого адреса отправителя, можно, во-первых, с точностью до подсети идентифицировать подлинность адреса и, во-вторых, определить с точностью до подсети истинный адрес отправителя. Итак, получив подобное сообщение с указанным маршрутом, сетевая операционная система анализирует маршрут и проверяет подлинность адреса отправителя. В случае его недостоверности пакет отбрасывается.
Из всего вышесказанного следует следующее требование к созданию защищенных систем связи в распределенных ВС:
Утверждение 5.
В распределенной ВС необходимо обеспечить на сетевом уровне контроль за маршрутом сообщений для аутентификации адреса отправителя.
Контроль за виртуальными соединениями в распределенной ВС
В предыдущей главе было показано, что взаимодействие объектов РВС по виртуальному каналу позволяет надежно защитить соединение от возможных информационно-разрушающих воздействий по каналам связи. Однако, как это отмечалось в п. 5.1.3, взаимодействие по ВК имеет свои минусы. К минусам относится необходимость контроля за соединением. Если в системе связи удаленных объектов РВС не предусмотреть использование надежных алгоритмов контроля за соединением, то, избавившись от одного типа удаленных атак на соединение ("Подмена доверенного объекта" - см. п. 3.2.2), можно подставить систему под другую типовую УА - "Отказ в обслуживании" (п. 3.2.4). Поэтому для обеспечения надежного функционирования и работоспособности (доступности) каждого объекта распределенной ВС необходимо прежде всего контролировать процесс создания соединения. Как уже говорилось в п. 5.1.3, задача контроля за ВК распадается на две подзадачи:
контроль за созданием соединения;
контроль за использованием соединения.
Решение второй задачи лежит на поверхности: так как сетевая операционная система не может одновременно иметь бесконечное число открытых ВК, то в том случае, если ВК простаивает в течение определенного системой тайм-аута, происходит его закрытие.
Далее рассмотрим возможный алгоритм, позволяющий обеспечить контроль за созданием соединения в РВС.
Основная задача, которую необходимо решить в данном случае, состоит в том, чтобы не позволить одному субъекту взаимодействия занять все виртуальные каналы системы. Процесс создания ВК был рассмотрен в п. 3.2.4. Напомним, что при создании ВК полученный системой запрос на создание соединения ставится в очередь запросов, и, когда до него дойдет время, система выработает ответ на запрос и отошлет его обратно отправителю запроса. Задача контроля за созданием соединения заключается как раз в том, чтобы определить те правила, исходя из которых система могла бы либо поставить запрос в очередь, либо нет. Если все пришедшие запросы автоматически ставятся системой в очередь (так построены все сетевые ОС, поддерживающие протокол TCP/IP), то это в случае атаки ведет к переполнению очереди и к отказу в обслуживании всех остальных легальных запросов. Такое происходит из-за того, что атакующий посылает в секунду столько запросов, сколько позволит трафик (тысячи запросов в секунду), а обычный пользователь с легальным запросом на подключение может послать лишь несколько запросов в минуту! Следовательно, вероятность подключения втакой ситуации, при условии переполнения очереди, один к миллиону в лучшем случае. Поэтому необходимо ввести ограничения на постановку в очередь запросов от одного объекта. Однако, если в РВС любой объект системы может послать запрос от имени (с адреса) любого другого объекта системы, то, как отмечалось ранее, решить задачу контроля не представляется возможным. Поэтому для обеспечения этой возможности было введено Утверждение 5, исходя из которого в каждом пришедшем на объект пакете должен быть указан пройденный им маршрут, позволяющий с точностью до подсети подтвердить подлинность адреса отправителя. Учитывая данный факт, позволяющий отсеять все пакеты с неверным адресом отправителя, можно предложить следующее условие постановки запроса в очередь: в системе вводится ограничение на число обрабатываемых в секунду запросов из одной подсети.
Это максимальное число ставящихся в очередь запросов в секунду определяется непосредственно операционной системой и зависит от следующих параметров сетевой ОС: быстродействия, объема виртуальной памяти, числа одновременно обслуживаемых виртуальных каналов, длины очереди и т.д. Вводимое ограничение не позволит атакующему переполнить очередь, так как только первые несколько его запросов будут поставлены в очередь на обслуживание, а остальные будут игнорироваться. Первый же запрос легального пользователя из другой подсети будет также сразу поставлен в очередь.
К минусам этого способа решения проблемы контроля за созданием соединения можно отнести тот факт, что, так как адрес отправителя можно аутентифицировать с точностью только до подсети, то атакующий может посылать запросы от имени любого объекта данной подсети. Следовательно, в случае атаки все остальные объекты из подсети атакующего будут лишены возможности подключения к атакуемому объекту. Однако, так как, во-первых, атакующего по указанному в пакете маршруту можно будет вычислить с точностью до его подсети и, во-вторых, не произойдет нарушения работоспособности цели атаки, то такая атака вряд ли будет иметь смысл.
Итак, в завершение очередное требование к защищенным системам связи в распределенных ВС.
Утверждение 6.
Для обеспечения доступности ресурсов распределенной ВС необходим контроль за виртуальными соединениями между ее объектами.
Следствие 6.1.
Необходимо обеспечить контроль за созданием соединения, введя ограничение на число обрабатываемых в секунду запросов из одной подсети.
Следствие 6.2.
Необходимо обеспечить контроль за использованием соединения, разрывая его по тайм-ауту в случае отсутствия сообщений.
Проектирование распределенной ВС с полностью определенной информацией о ее объектах с целью исключения алгоритмов удаленного поиска
Одной из особенностей распределенной ВС является возможное отсутствие информации, необходимой для доступа к ее удаленным объектам. Поэтому в РВС возникает необходимость использования потенциально опасных с точки зрения безопасности алгоритмов удаленного поиска (п. 3.2.3.2 и 5.1.5). Следовательно, для того, чтобы в РВС не возникало необходимости в использовании данных алгоритмов, требуется на начальном этапе спроектировать систему так, чтобы информация о ее объектах была изначально полностью определена. Это позволит, в свою очередь, ликвидировать одну из причин успеха удаленных атак, связанных с использованием в распределенной ВС алгоритмов удаленного поиска.
Однако в РВС с неопределенным и достаточно большим числом объектов (например, Internet) спроектировать систему с отсутствием неопределенности практически невозможно. В этом случае отказаться от алгоритмов удаленного поиска не представляется возможным.
Существуют два типа данных алгоритмов. Первый типовой алгоритм удаленного поиска - с использованием информационно-поискового сервера, второй - с использованием широковещательных запросов (п. 5.1.5). Применение в РВС алгоритма удаленного поиска с использованием широковещательных запросов в принципе не позволяет защитить систему от внедрения в нее ложного объекта (п. 3.2.3), а, следовательно, использование данного алгоритма в защищенной системе недопустимо. Применение в распределенной ВС алгоритма удаленного поиска с использованием информационно-поискового сервера позволяет обезопасить систему от внедрения в нее ложного объекта только в том случае, если, во-первых, взаимодействие объектов системы с сервером происходит только с созданием виртуального канала и, во-вторых, у объектов, подключенных к данному серверу, и у сервера существует заранее определенная статическая ключевая информация, используемая при создании виртуального канала. Выполнение этих условий сделает невозможным в распределенной ВС передачу в ответ на запрос с объекта ложного ответа и, следовательно, внедрения в систему ложного объекта.
Поясним последнее утверждение. В том случае, если виртуальный канал с информационно-поисковым сервером создается с использованием только динамически вырабатываемой ключевой информации, например, по схеме открытого распределения ключей, то ничто не мешает атакующему - в том случае, если он может перехватить первоначальный запрос на создание ВК с объекта системы - послать ложный ответ и создать виртуальный канал от имени настоящего сервера (п. 3.2.3.2). Именно поэтому на всех объектах системы необходима начальная ключевая информация для создания ВК с информационно-поисковым сервером.
В заключение предлагаются следующие требования, которыми необходимо руководствоваться при создании защищенных систем связи в распределенных ВС.
Утверждение 7.
Наиболее безопасной распределенной ВС является та система, в которой информация о ее объектах изначально полностью определена и в которой не используются алгоритмы удаленного поиска.
Утверждение 8.
В том случае, если выполненить требование 7 невозможно, необходимо в распределенной ВС использовать только алгоритм удаленного поиска с выделенным информационно-поисковым сервером, и при этом взаимодействие объектов системы с данным сервером должно осуществляться только по виртуальному каналу с применением надежных алгоритмов защиты соединения с обязательным использованием статической ключевой информации.
Следствие 8.1.
В распределенной ВС для обеспечения безопасности необходимо отказаться от алгоритмов удаленного поиска с использованием широковещательных запросов.
Заключая эту главу, хотелось бы обратить внимание читателя на то, что, как он, наверное, уже понял, в сети Internet в стандарте IPv4 практически ни одно из сформулированных требований к построению безопасных систем связи между удаленными объектами распределенных ВС не выполняется. Поэтому авторы позволили себе привести свои требования, по которым должна строиться распределенная ВС. Кстати, учтя собственные ошибки в разработке стандарта IPv4, группы разработчиков уже заканчивают проект создания нового более защищенного стандарта сети Internet - IPv6, где будут, по-видимому, учтены некоторые из вышеизложенных требований. Однако разговор о том, насколько будет безопасна сеть Internet в новом стандарте, несколько преждевременен, и его необходимо отложить до окончательного выхода стандарта в свет.
Программно-аппаратные методы защиты от удаленных атак в сети Internet
К программно-аппаратным средствам обеспечения информационной безопасности средств связи в вычислительных сетях относятся:
аппаратные шифраторы сетевого трафика;
методика Firewall, реализуемая на базе программно-аппаратных средств;
защищенные сетевые криптопротоколы;
программно-аппаратные анализаторы сетевого трафика;
защищенные сетевые ОС.
Существует огромное количество литературы, посвященной этим средствам защиты, предназначенным для использования в сети Internet (за последние два года практически в каждом номере любого компьютерного журнала можно найти статьи на эту тему).
Далее мы, по возможности кратко, чтобы не повторять всем хорошо известную информацию, опишем данные средства защиты, применяемые в Internet. При этом мы преследуем следующие цели: во-первых, еще раз вернемся к мифу об "абсолютной защите", которую якобы обеспечивают системы Firewall, очевидно, благодаря стараниям их продавцов; во-вторых, сравним существующие версии криптопротоколов, применяемых в Internet, и дадим оценку, по сути, критическому положению в этой области; и, в-третьих, ознакомим читателей с возможностью защиты с помощью сетевого монитора безопасности, предназначенного для осуществления динамического контроля за возникающими в защищаемом сегменте IP-сети ситуациями, свидетельствующими об осуществлении на данный сегмент одной из описанных в 4 главе удаленных атак.
7.2.1. Методика Firewall как основное программно-аппаратное средство осуществления сетевой политики безопасности в выделенном сегменте IP-сети
В общем случае методика Firewall реализует следующие основные три функции:
1. Многоуровневая фильтрация сетевого трафика.
Фильтрация обычно осуществляется на трех уровнях OSI:
сетевом (IP);
транспортном (TCP, UDP);
прикладном (FTP, TELNET, HTTP, SMTP и т. д.).
Фильтрация сетевого трафика является основной функцией систем Firewall и позволяет администратору безопасности сети централизованно осуществлять необходимую сетевую политику безопасности в выделенном сегменте IP-сети, то есть, настроив соответствующим образом Firewall, можно разрешить или запретить пользователям как доступ из внешней сети к соответствующим службам хостов или к хостам, находящихся в защищаемом сегменте, так и доступ пользователей из внутренней сети к соответствующим ресурсам внешней сети. Можно провести аналогию с администратором локальной ОС, который для осуществления политики безопасности в системе назначает необходимым образом соответствующие отношения между субъектами (пользователями) и объектами системы (файлами, например), что позволяет разграничить доступ субъектов системы к ее объектам в соответствии с заданными администратором правами доступа. Те же рассуждения применимы к Firewall-фильтрации: в качестве субъектов взаимодействия будут выступать IP-адреса хостов пользователей, а в качестве объектов, доступ к которым необходимо разграничить, - IP-адреса хостов, используемые транспортные протоколы и службы предоставления удаленного доступа.
2. Proxy-схема с дополнительной идентификацией и аутентификацией пользователей на Firewall-хосте.
Proxy-схема позволяет, во-первых, при доступе к защищенному Firewall сегменту сети осуществить на нем дополнительную идентификацию и аутентификацию удаленного пользователя и, во-вторых, является основой для создания приватных сетей с виртуальными IP-адресами. Смысл proxy-схемы состоит в создании соединения с конечным адресатом через промежуточный proxy-сервер (proxy от англ. полномочный) на хосте Firewall. На этом proxy-сервере и может осуществляться дополнительная идентификация абонента.
3. Создание приватных сетей (Private Virtual Network - PVN) с "виртуальными" IP-адресами (NAT - Network Address Translation).
В том случае, если администратор безопасности сети считает целесообразным скрыть истинную топологию своей внутренней IP-сети, то ему можно порекомендовать использовать системы Firewall для создания приватной сети (PVN-сеть). Хостам в PVN-сети назначаются любые "виртуальные" IP-адреса. Для адресации во внешнюю сеть (через Firewall) необходимо либо использование на хосте Firewall описанных выше proxy-серверов, либо применение специальных систем роутинга (маршрутизации), только через которые и возможна внешняя адресация. Это происходит из-за того, что используемый во внутренней PVN-сети виртуальный IP-адрес, очевидно, не пригоден для внешней адресации (внешняя адресация - это адресация к абонентам, находящимся за пределами PVN-сети). Поэтому proxy-сервер или средство роутинга должно осуществлять связь с абонентами из внешней сети со своего настоящего IP-адреса. Кстати, эта схема удобна в том случае, если вам для создания IP-сети выделили недостаточное количество IP-адресов (в стандарте IPv4 это случается сплошь и рядом, поэтому для создания полноценной IP-сети с использованием proxy-схемы достаточно только одного выделенного IP-адреса для proxy-сервера).
Итак, любое устройство, реализующее хотя бы одну из этих функций Firewall-методики, и является Firewall-устройством. Например, ничто не мешает вам использовать в качестве Firewall-хоста компьютер с обычной ОС FreeBSD или Linux, у которой соответствующим образом необходимо скомпилировать ядро ОС. Firewall такого типа будет обеспечивать только многоуровневую фильтрацию IP-трафика. Другое дело, предлагаемые на рынке мощные Firewall-комплексы, сделанные на базе ЭВМ или мини-ЭВМ, обычно реализуют все функции Firewall-мето-дики и являются полнофункциональными системами Firewall. На следующем рисунке изображен сегмент сети, отделенный от внешней сети полнофункциональным Firewall-хостом.
 |
Рис. 7.1. Обобщенная схема полнофункционального хоста Firewall.
Однако администраторам IP-сетей, поддавшись на рекламу систем Firewall, не стоит заблуждаться на тот счет, что Firewall это гарантия абсолютной защиты от удаленных атак в сети Internet. Firewall - не столько средство обеспечения безопасности, сколько возможность централизованно осуществлять сетевую политику разграничения удаленного доступа к доступным ресурсам вашей сети. Да, в том случае, если, например, к данному хосту запрещен удаленный TELNET-доступ, то Firewall однозначно предотвратит возможность данного доступа. Но дело в том, что большинство удаленных атак имеют совершенно другие цели (бессмысленно пытаться получить определенный вид доступа, если он запрещен системой Firewall). Действительно, зададим себе вопрос, а какие из рассмотренных в 4 главе удаленных атак может предотвратить Firewall? Анализ сетевого трафика (п. 4.1)? Очевидно, нет! Ложный ARP-сервер (п. 4.2)? И да, и нет (для защиты вовсе не обязательно использовать Firewall). Ложный DNS-сервер (п. 4.3)? Нет, к сожалению, Firewall вам тут не помощник. Навязывание ложного маршрута при помощи протокола ICMP (п. 4.4)? Да, эту атаку путем фильтрации ICMP-сообщений Firewall легко отразит (хотя достаточно будет фильтрующего маршрутизатора, например Cisco). Подмена одного из субъектов TCP-соединения (п. 4.5)? Ответ отрицательный; Firewall тут абсолютно не при чем. Нарушение работоспособности хоста путем создания направленного шторма ложных запросов или переполнения очереди запросов (п. 4.6)? В этом случае применение Firewall только ухудшит все дело. Атакующему для того, чтобы вывести из строя (отрезать от внешнего мира) все хосты внутри защищенного Firewall-системой сегмента, достаточно атаковать только один Firewall, а не несколько хостов (это легко объясняется тем, что связь внутренних хостов с внешним миром возможна только через Firewall).
Из всего вышесказанного отнюдь не следует, что использование систем Firewall абсолютно бессмысленно. Нет, на данный момент этой методике (именно как методике!) нет альтернативы. Однако надо четко понимать и помнить ее основное назначение. Нам представляется, что применение методики Firewall для обеспечения сетевой безопасности является необходимым, но отнюдь не достаточным условием, и не нужно считать, что, поставив Firewall, вы разом решите все проблемы с сетевой безопасностью и избавитесь от всех возможных удаленных атак из сети Internet. Прогнившую с точки зрения безопасности сеть Internet никаким отдельно взятым Firewall'ом не защитишь!
7.2.2. Программные методы защиты, применяемые в сети Internet
К программным методам защиты в сети Internet можно отнести прежде всего защищенные криптопротоколы, с использованием которых появляется возможность надежной защиты соединения. В следующем пункте пойдет речь о существующих на сегодняшний день в Internet подходах и основных, уже разработанных, криптопротоколах.
К иному классу программных методов защиты от удаленных атак относятся существующие на сегодняшний день программы, основная цель которых - анализ сетевого трафика на предмет наличия одного из известных активных удаленных воздействий. Об этом пункт 7.2.2.2.
7.2.2.1. SKIP-технология и криптопротоколы SSL, S-HTTP как основное средство защиты соединения и передаваемых данных в сети Internet
Прочитав 4 и 5 главы, читатель, очевидно, уяснил, что одна из основных причин успеха удаленных атак на распределенные ВС кроется в использовании сетевых протоколов обмена, которые не могут надежно идентифицировать удаленные объекты, защитить соединение и передаваемые по нему данные. Поэтому совершенно естественно, что в процессе функционирования Internet были созданы различные защищенные сетевые протоколы, использующие криптографию как с закрытым, так и с открытым ключом. Классическая криптография с симметричными криптоалгоритмами предполагает наличие у передающей и принимающей стороны симметричных (одинаковых) ключей для шифрования и дешифрирования сообщений. Эти ключи предполагается распределить заранее между конечным числом абонентов, что в криптографии называется стандартной проблемой статического распределения ключей. Очевидно, что применение классической криптографии с симметричными ключами возможно лишь на ограниченном множестве объектов. В сети Internet для всех ее пользователей решить проблему статического распределения ключей, очевидно, не представляется возможным. Однако одним из первых защищенных протоколов обмена в Internet был протокол Kerberos, основанный именно на статическом распределении ключей для конечного числа абонентов. Таким же путем, используя классическую симметричную криптографию, вынуждены идти наши спецслужбы, разрабатывающие свои защищенные криптопротоколы для сети Internet. Это объясняется тем, что почему-то до сих пор нет гостированного криптоалгоритма с открытым ключом. Везде в мире подобные стандарты шифрования давно приняты и сертифицированы, а мы, видимо, опять идем другим путем!
Итак, понятно, что для того, чтобы дать возможность защититься всему множеству пользователей сети Internet, а не ограниченному его подмножеству, необходимо использовать динамически вырабатываемые в процессе создания виртуального соединения ключи при использовании криптографии с открытым ключом (п. 6.2 и подробно в [11]). Далее мы рассмотрим основные на сегодняшний день подходы и протоколы, обеспечивающие защиту соединения.
SKIP (Secure Key Internet Protocol)-технологией называется стандарт инкапсуляции IP-пакетов, позволяющий в существующем стандарте IPv4 на сетевом уровне обеспечить защиту соединения и передаваемых по нему данных. Это достигается следующим образом: SKIP-пакет представляет собой обычный IP-пакет, поле данных которого представляет из себя SKIP-заголовок определенного спецификацией формата и криптограмму (зашифрованные данные). Такая структура SKIP-пакета позволяет беспрепятственно направлять его любому хосту в сети Internet (межсетевая адресация происходит по обычному IP-заголовку в SKIP-пакете). Конечный получатель SKIP-пакета по заранее определенному разработчиками алгоритму расшифровывает криптограмму и формирует обычный TCP- или UDP-пакет, который и передает соответствующему обычному модулю (TCP или UDP) ядра операционной системы. В принципе, ничто не мешает разработчику формировать по данной схеме свой оригинальный заголовок, отличный от SKIP-заголовка.
S-HTTP (Secure HTTP) - это разработанный компанией Enterprise Integration Technologies (EIT) специально для Web защищенный HTTP-протокол. Протокол S-HTTP позволяет обеспечить надежную криптозащиту только HTTP-документов Web-севера и функционирует на прикладном уровне модели OSI. Эта особенность протокола S-HTTP делает его абсолютно специализированным средством защиты соединения, и, как следствие, невозможное его применение для защиты всех остальных прикладных протоколов (FTP, TELNET, SMTP и др.). Кроме того, ни один из существующих на сегодняшний день основных Web-броузеров (ни Netscape Navigator 3.0, ни Microsoft Explorer 3.0) не поддерживают данный протокол.
SSL (Secure Socket Layer) - разработка компании Netscape - универсальный протокол защиты соединения, функционирующий на сеансовом уровне OSI. Этот протокол, использующий криптографию с открытым ключом, на сегодняшний день, по нашему мнению, является единственным универсальным средством, позволяющим динамически защитить любое соединение с использованием любого прикладного протокола (DNS, FTP, TELNET, SMTP и т. д.). Это связано с тем, что SSL, в отличие от S-HTTP, функционирует на промежуточном сеансовом уровне OSI (между транспортным - TCP, UDP, - и прикладным - FTP, TELNET и т. д.). При этом процесс создания виртуального SSL-соединения происходит по схеме Диффи и Хеллмана (п. 6.2), которая позволяет выработать криптостойкий сеансовый ключ, используемый в дальнейшем абонентами SSL-соединения для шифрования передаваемых сообщений. Протокол SSL сегодня уже практически оформился в качестве официального стандарта защиты для HTTP-соединений, то есть для защиты Web-серверов. Его поддерживают, естественно, Netscape Navigator 3.0 и, как ни странно, Microsoft Explorer 3.0 (вспомним ту ожесточенную войну броузеров между компаниями Netscape и Microsoft). Конечно, для установления SSL-соединения с Web-сервером еще необходимо и наличие Web-сервера, поддерживающего SSL. Такие версии Web-серверов уже существуют (SSL-Apachе, например). В заключении разговора о протоколе SSL нельзя не отметить следующий факт: законами США до недавнего времени был запрещен экспорт криптосистем с длиной ключа более 40 бит (недавно он был увеличен до 56 бит). Поэтому в существующих версиях броузеров используются именно 40-битные ключи. Криптоаналитиками путем экспериментов было выяснено, что в имеющейся версии протокола SSL шифрование с использованием 40-битного ключа не является надежной защитой для передаваемых по сети сообщений, так как путем простого перебора (240 комбинаций) этот ключ подбирается за время от 1,5 (на суперЭВМ Silicon Graphics) до 7 суток (в процессе вычислений использовалось 120 рабочих станций и несколько мини ЭВМ).
Итак, очевидно, что повсеместное применение этих защищенных протоколов обмена, особенно SSL (конечно, с длиной ключа более 40 бит), поставит надежный барьер на пути всевозможных удаленных атак и серьезно усложнит жизнь кракеров всего мира. Однако весь трагизм сегодняшней ситуации с обеспечением безопасности в Internet состоит в том, что пока ни один из существующих криптопротоколов (а их уже немало) не оформился в качестве единого стандарта защиты соединения, который поддерживался бы всеми производителями сетевых ОС! Протокол SSL, из имеющихся на сегодня, подходит на эту роль наилучшим образом. Если бы его поддерживали все сетевые ОС, то не потребовалось бы создание специальных прикладных SSL-совместимых серверов (DNS, FTP, TELNET, WWW и др.). Если не договориться о принятии единого стандарта на защищенный протокол сеансового уровня, то тогда потребуется принятие многих стандартов на защиту каждой отдельной прикладной службы. Например, уже разработан экспериментальный, никем не поддерживаемый протокол Secure DNS. Также существуют экспериментальные SSL-совместимые Secure FTP- и TELNET-серверы. Но все это без принятия единого поддерживаемого всеми производителями стандарта на защищенный протокол не имеет абсолютно никакого смысла. А на сегодняшний день производители сетевых ОС не могут договориться о единой позиции на эту тему и, тем самым, перекладывают решение этих проблем непосредственно на пользователей Internet и предлагают им решать свои проблемы с информационной безопасностью так, как тем заблагорассудится!
7.2.2.2. Сетевой монитор безопасности IP Alert-1
Практические и теоретические изыскания авторов, по направлению, связанному с исследованием безопасности распределенных ВС, в том числе и сети Internet (два полярных направления исследования: нарушение и обеспечение информационной безопасности), навели на следующую мысль: в сети Internet, как и в других сетях (например, Novell NetWare, Windows NT), ощущается серьезная нехватка программного средства защиты, осуществляющего комплексный контроль (мониторинг) на канальном уровне за всем потоком передаваемой по сети информации с целью обнаружения всех типов удаленных воздействий, описанных в 4 главе. Исследование рынка программного обеспечения сетевых средств защиты для Internet выявило тот факт, что подобных комплексных средств обнаружения удаленных воздействий по нашим сведениям не существует, а те, что имеются, предназначены для обнаружения воздействий одного конкретного типа (например, ICMP Redirect (п. 4.4) или ARP (п. 4.2)). Поэтому и была начата разработка средства контроля сегмента IP-сети, предназначенного для использования в сети Internet и получившее следующее название: сетевой монитор безопасности IP Alert-1. Основная задача этого средства, программно анализирующего сетевой трафик в канале передачи, состоит не в отражении осуществляемых по каналу связи удаленных атак, а в их обнаружении, протоколировании (ведении файла аудита с протоколированием в удобной для последующего визуального анализа форме всех событий, связанных с удаленными атаками на данный сегмент сети) и незамедлительным сигнализировании администратору безопасности в случае обнаружения удаленной атаки. Основной задачей сетевого монитора безопасности IP Alert-1 является осуществление контроля за безопасностью соответствующего сегмента сети Internet.
Сетевой монитор безопасности IP Alert-1 обладает следующими функциональными возможностями и позволяет, путем сетевого анализа, обнаружить следующие удаленные атаки на контролируемый им сегмент сети Internet.
Функциональные возможности сетевого монитора безопасности IP Alert-1
1. Контроль за соответствием IP- и Ethernet-адресов в пакетах, передаваемых хостами, находящимися внутри контролируемого сегмента сети.
На хосте IP Alert-1 администратор безопасности создает статическую ARP-таблицу, куда заносит сведения о соответствующих IP- и Ethernet-адресах хостов, находящихся внутри контролируемого сегмента сети.
Данная функция позволяет обнаружить несанкционированное изменение IP-адреса или его подмену (IP Spoofing).
2. Контроль за корректным использованием механизма удаленного ARP-поиска.
Эта функция позволяет, используя статическую ARP-таблицу, определить удаленную атаку "Ложный ARP-сервер" (п. 4.2).
3. Контроль за корректным использованием механизма удаленного DNS-поиска.
Эта функция позволяет определить все возможные виды удаленных атак на службу DNS (атаки в п. 4.3. 1- 4.3.3).
4. Контроль на наличие ICMP Redirect сообщения.
Данная функция оповещает об обнаружении ICMP Redirect сообщения и соответствующей удаленной атаки, описанной в п. 4.4
5. Контроль за корректностью попыток удаленного подключения путем анализа передаваемых запросов.
Эта функция позволяет обнаружить, во-первых, попытку исследования закона изменения начального значения идентификатора TCP-соединения - ISN (п. 4.5.1), во-вторых, удаленную атаку "отказ в обслуживании", осуществляемую путем переполнения очереди запросов на подключение (п. 4.6), и, в-третьих, направленный "шторм" ложных запросов на подключение (как TCP, так и UDP), приводящий также к отказу в обслуживании (п. 4.6).
Таким образом, сетевой монитор безопасности IP Alert-1 позволяет обнаружить, оповестить и запротоколировать все виды удаленных атак, описанных в 4 главе! При этом данная программа никоим образом не является конкурентом системам Firewall. IP Alert-1, используя описанные и систематизированные в 4 главе особенности удаленных атак на сеть Internet, служит необходимым дополнением - кстати, несравнимо более дешевым, - к системам Firewall. Без монитора безопасности большинство попыток осуществления удаленных атак на ваш сегмент сети останется скрыто от ваших глаз. Ни один из известных авторам файрволов не занимается подобным интеллектуальным анализом проходящих по сети сообщений на предмет выявления различного рода удаленных атак, ограничиваясь, в лучшем случае, ведением журнала, в который заносятся сведения о попытках подбора паролей для TELNET и FTP, о сканировании портов и о сканировании сети с использованием знаменитой программы удаленного поиска известных уязвимостей сетевых ОС - SATAN (п. 8.9.1). Поэтому, если администратор IP-сети не желает оставаться безучастным и довольствоваться ролью простого статиста при удаленных атаках на его сеть, то ему желательно использовать сетевой монитор безопасности IP Alert-1. Кстати, напомним, что Цутому Шимомура смог запротоколировать атаку Кевина Митника (п. 4.5.2), во многом, видимо, благодаря программе tcpdump - простейшему анализатору IP-трафика.
