Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Защита от "вероломных" Java-приложений

Грегори Йеркса


Рис. 1. Обеспечение безопасности JVM с помощью Security Manager

С самого момента рождения технологии Java злоумышленники научились находить недостатки в ее системе безопасности и использовать их в своих целях. Защита пользователей от подобного рода действий сегодня стала одной из основных проблем сетевой безопасности. Усовершенствования, внесенные фирмой Sun в виртуальную Java-машину (Java Virtual Machine - JVM) и инструментальный набор разработчика Java-приложений (Java Development Kit - JDK), а также новые Web-браузеры закрыли многие известные "дыры", но тем не менее сетевые администраторы не должны расслабляться в деле защиты своих сетей от нападений.

Сетевые программные компоненты (applets) и приложения Java предназначены для выполнения множества различных функций - от надежных транзакций до рекламных и информационных сообщений.

С точки же зрения пользователя, почти невозможно чувствовать себя в полной безопасности при наличии огромного количества скверно написанных или - еще хуже - специально ориентированных на совершение злонамеренных действий Java-приложений. Несмотря на то что новые браузеры, такие, как Internet Explorer 4.0 фирмы Microsoft, позволяют пользователям устанавливать защиту, основываясь на источнике происхождения Java-компонента, на них нельзя полагаться и тем более разрешать им самостоятельно определять уровень защиты своих рабочих станций.

В последнее время некоторые фирмы начали производить продукты, обеспечивающие защиту на стороне клиента независимо от используемого браузера, но, для того чтобы предотвратить возможные атаки, администраторам нужно придерживаться достаточно жесткой политики безопасности в масштабе всей корпоративной сети. Различные аспекты безопасности и имеющиеся в Java функции защиты мы исследовали в лаборатории журнала Network Computing в Университете Висконсин-Мэдисон.

Рубежи обороны

Java придает дополнительные полезные возможности как Всемирной паутине в целом, так и каждой настольной системе. С самого начала для его создателей главными приоритетами были безопасность и совместимость. Язык программирования Java, поддерживающий принцип "написано однажды - работает везде" (Write Once/Run Anywhere - WORA), требует использования мощных механизмов защиты, которые реализованы как в среде разработки программного компонента или приложения, так и в виртуальной Java-машине.

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

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

Компании Netscape Communications, Microsoft и Sun Microsystems имеют свои реализации JVM, обладающие целым рядом отличий одна от другой. Например, продукт Applet Viewer фирмы Sun для обеспечения боўльшей свободы "доверенным" программным компонентам Java использует списки контроля доступа. Браузер Internet Explorer 4.0 фирмы Microsoft идет еще дальше: предоставляет Java-компонентам доступ к системным ресурсам.

Возьмите ведерко и совок

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

Виртуальная Java-машина состоит из трех частей: Class Loader (CL), Byte-Code Verifier (BCV) и Security Manager (SM). Каждая из них добавляет свой уровень защиты в процесс исполнения Java-приложений и сетевых программных компонентов. Например, при обращении к HTML-странице, содержащей Java-компонент, JVM загружает его и создает "песочницу". После верификации байт-кода CL загружает все необходимые классы. Локальные Java-приложения не вызывают CL, поскольку их байт-коды формируются посредством компиляции. Байт-код же сетевого программного компонента, напротив, должен пройти через стадию загрузки классов с целью проверки правильности Java-кода и его соответствия спецификациям языка.

BCV со своей стороны гарантирует, что байт-код соответствует спецификациям языка Java. Через BCV должны пройти все байт-коды Java независимо от источника происхождения программы или компонента. Однако сетевые Java-компоненты - это прекомпилированный байт-код (а не созданный браузером). Таким образом, злоумышленник, обойдя встроенные механизмы защиты среды разработки, может создать байт-код вручную. BCV предотвращает такой тип вторжений, проверяя байт-код и определяя потенциальную угрозу безопасности и нарушения синтаксиса языка. Кроме того, BCV контролирует пространство имен и обращения, способные нарушить систему защиты Java.

Наиболее важная часть JVM - это SM, который на самом деле представляет собой Java-класс. За SM остается последнее слово в определении всех потенциально опасных действий со стороны Java-приложений. Он осуществляет контроль за доступом к файлам, системным вводом-выводом, сетевым вводом-выводом, созданием экземпляров классов посредством Class Loader, созданием процессов/потоков и за доступом к объектам. При выполнении сетевым Java-компонентом одного из перечисленных выше действий он сначала обращается к SM за "одобрением". Руководствуясь источником происхождения приложения или Java-компонента, SM "решает", допустимо ли то или иное действие. Всякий раз, когда Java-компонент или приложение вызывают потенциально опасную функцию, SM разрешает или запрещает доступ к определенным ресурсам, руководствуясь источником происхождения этого приложения или компонента.

Это тот, кого вы знаете

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

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

Вторжение в вашу сеть

В большинстве случаев система безопасности Java сама способна определить негодные Java-компоненты и приложения до того, как они успеют нанести вред. Но не стоит слишком успокаиваться, потому что с большинством опасностей пользователи и системные администраторы еще не знакомы. Плохо написанные или созданные со злым умыслом Java-компоненты можно сгруппировать в три категории: программы, вызывающие непроизводительный расход ресурсов (denial of service - отказ в обслуживании); так называемые "троянские кони" и программы, предназначенные для получения доступа к конфиденциальной информации, а в некоторых случаях и для порчи данных.

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

Источники опасности

В настоящее время основная угроза со стороны Java-программ связана с ошибками в организации системы безопасности Java. Просмотрев документ "Хронология ошибок, связанных с защитой" фирмы Sun (по адресу: java.sun.com/sfaq/chronology.html), вы найдете, что там указано гораздо больше ошибок, относящихся к реализации, нежели являющихся результатом недостатков самой модели защиты Java.

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

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

Java-технология обеспечивает возможность аутентификации программного компонента при его загрузке из сети посредством цифровой подписи. В JDK версии 1.1 и более поздних имеются такие средства, как электронная подпись AuthentiCode, сертификаты X.509 версии 3, а также JavaKey, собственное средство Java для подписи файлов JAR (Java Archive - единый файл, содержащий все классы, изображения и ресурсы).

Установка границ

Лучшей альтернативой защите от перечисленных в статье Java-компонентов на клиентской стороне является обеспечение безопасности в точках входа в вашу сеть. В большинстве корпоративных сетей для этих целей используются Firewall-системы (межсетевые экраны). Однако один только межсетевой экран не защитит вас от программных Java-компонентов, предназначенных для порчи информации или других недобрых целей. Только оснащенная дополнительным ПО Firewall-система сможет проверять содержимое Java-компонентов, попадающих в вашу сеть. Конкретная же стратегия зависит от поставщика Firewall-системы и конфигурации вашей сети.

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

Ряд программных продуктов третьих фирм способны генерировать цифровые подписи на основе общедоступных знаний о байт-коде Java. Однако, несмотря на то что эти подписи указывают на источник происхождения программы, они могут ввести в заблуждение. Проекты типа Kimera усиливают защиту Java путем создания более совершенных программ для проверки байт-кода. В свою очередь, такие производители, как Finjan, создают продукты, которые используют байт-код Java-компонентов для создания БД безопасности. Записи, хранящиеся в такой БД, помогают определять степень угрозы для безопасности сети со стороны любого Java-компонента при его первом входе в нее. SurfinGate, продукт фирмы Finjan, выполняет это путем проверки байт-кода Java и записи результатов для последующего использования. Конечно, проверка всего байт-кода Java, проходящего через вашу сеть, замедляет передачу информации на настольные системы. Возможности, имеющиеся в продукте SurfinGate, позволяют исключить просмотр байт-кода, если в этом нет необходимости.

Цифровая подпись также позволяет реализовать активную защиту вашей сети. Однако продукты, подобные SurfinGate, не могут правильно интерпретировать все Java-компоненты. Базы данных, которые используют эти продукты, могут устареть и перестать отражать новые виды опасностей и атак. Другие продукты, такие, как Cage фирмы Digitivity, защищают конечных пользователей посредством "изоляции" исполняемых Java-программ.

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


Суббота жк кто знает в эту субботу.




  
6 '1998
СОДЕРЖАНИЕ

колонка редактора

• Cеть напрокат

локальные сети

• Сегментирующие концентраторы для рабочих групп

• Сопряжение сетей Ethernet и Fast Ethernet

• NDPS - решение проблем сетевой печати?

• Рост рынка волоконной оптики

• Можно ли Windows NT доверять секреты?

• Системы микроклимата

• Тестируем переключатели KVM

корпоративные сети

• На переднем крае IP-коммутации

• Исследуем связующее ПО

• Как выбрать коммутатор АТМ

услуги сетей связи

• Практические аспекты построения корпоративных сетей Frame Relay (часть II)

• Связь в Сургуте: слагаемые успеха

• Интеллектуальные сети и услуги

• Куда шагает Frame Relay

системы учрежденческой связи

• Системы микросотовой связи стандарта DECT

• Принципы выбора УПАТС (часть II)

• Документальная телеконференция: недостающее звено между аудио- и видеоконференц-связью

интернет и интрасети

• Border Manager - служба безопасности от Novell

• Кто ищет, тот всегда найдет

защита данных

• Защита от "вероломных" Java-приложений

• Серверы-посредники Socks

• CeBIT'98: технологии информационной безопасности

новые продукты

• Новые сетевые принтеры на Comtek'98, Не хочу отдавать обратно OfficeConnect Dual Analog, С возвращением, LANNET!; Мультисервисный концентратор доступа MC3810 фирмы Cisco, Пополнение семейства Vanguard, Кластер серверов от INPRO Computer Systems

только на сервере

• Система S.W.I.F.T. и информационная безопасность

• Экспертиза, проектирование и реинжиниринг



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх