Безопасность — это процесс. Часть 1
Безопасность — это процесс. Часть 1
Поводом для написания данной статьи послужили новые уязвимости операционной системы Windows, которые совсем недавно были использованы семейством интернет-червей LoveSan/Blaster, вызвавших в середине августа одну из крупнейших эпидемий в вирусной истории.
Однако эпидемия вроде бы отшумела, а вопросы остались. Мы поговорим о технологиях Microsoft, которые оказались под ударом, чтобы лучше уяснить суть происходящего, поскольку я уверен, что подавляющее большинство пользователей и системных администраторов весьма посредственно ориентируются в сути вопроса. А наша практическая часть все-таки будет больше ориентирована на простых пользователей, потому что системные администраторы обязаны все это знать по определению.
Скажу сразу, что я весьма далек от той части публики, которая, не разобравшись, кричит "виндовс — мастдай". События последних лет, статистика красноречиво показывают, какие системы подвергаются взломам чаще всего. А тех, кто думает, что сможет на коленке написать безглючную СуперОС или даже просто 100 строк кода, я отошлю к Ф.Бруксу, вернее, к его труду "Мифический человеко-месяц (или как создаются программные системы)": "Время от времени можно прочесть в газете о том, как в переоборудованном гараже пара программистов сделала замечательную программу, оставившую позади разработки больших команд. И каждый программист охотно верит в эти сказки, поскольку знает, что может создать любую программу со скоростью, значительно превышающей те 1000 операторов в год, которые, по сообщениям, пишут программисты в промышленных бригадах. Почему же до сих пор все профессиональные бригады программистов не заменены одержимыми дуэтами из гаражей?"
Итак, вернемся на главную дорогу и начнем наше неспешное повествование. Согласно исследованиям университета Карнеги-Меллона ( http://www.sei.cmu.edu ) и ФБР ( http://www.fbi.gov ), 98% инцидентов возникает из-за проблемы, о которой ответственные сотрудники IT-отдела уже знали, но не приняли адекватных мер к устранению. Эксперты Gartner ( http://www.gartner.com ) считают, что эта цифра — около 90%. Аналитики координационного центра по безопасности CERT ( http://www.cert.org ) утверждают, что 95% инцидентов, о которых им сообщают, используют известные дыры.
Можно заметить печальную общую тенденцию: около 90% всех проблем с компьютерной безопасностью происходит по причине невнимательности со стороны системных администраторов, одной из задач которых и является своевременная защита постоянно появляющихся дыр в корпоративной сети.
Далее. Компания Qualys представила интересную статистику, касающуюся ликвидации дыр в программном обеспечении корпоративными пользователями. Эта статистика была получена на основе данных сканирования на предмет уязвимостей 1,5 млн. компьютерных систем. По данным Qualys, процесс ликвидации уязвимостей идет недостаточно быстро. В частности, в течение первых 30 дней после появления информации о критических дырах патчи устанавливают менее половины компаний. На устранение менее серьезных уязвимостей уходит, в среднем, на 60 дней больше, чем на борьбу с критическими дырами. За это время хакеры и специалисты по безопасности в 80% случаев успевают создать программы, использующие эти дыры. Именно поэтому существует опасность повторения атак с использованием уже, казалось бы, давно обезвреженных уязвимостей.
"Переполнение буфера RPC", "уязвимое место в системе безопасности интерфейса DCOM" — такими фразами пестрели сообщения об опасности еще вчера. Попытаемся разобраться, что скрывается за этими понятиями, ибо "практика без теории слепа".
DCOM
Microsoft Distributed COM (DCOM) — это расширение модели COM для поддержки связей объектов для разных компьютеров, находящихся в локальной сети (LAN), глобальной сети (WAN) или Интернет. Используя DCOM, ваше приложение может быть распределенным, т.е. может работать на нескольких компьютерах как на одном.
Общающиеся посредством COM/DCOM программы называются клиентом и сервером. Клиент является инициатором общения. Он обращается к одной из служб сервера для получения некоторых данных или для выполнения некоторой работы над данными, которые передаются серверу. Службы сервера реализуются в виде одного или нескольких входящих в его состав объектов COM. Один объект может содержать произвольное количество служб.
Component Object Model (COM) разработан для того, чтобы позволить клиентам прозрачно связываться с объектами, независимо от того, где объекты выполняются: в том же самом процессе, на той же самой машине или на разных машинах. Это обеспечивает единую модель программирования для всех типов объектов: и для клиентов, и для серверов.
Поскольку DCOM развивает объектную модель COM, вы можете использовать существующие приложения, компоненты и инструментальные средства на базе COM для продвижения в мир распределенных вычислений. DCOM берет на себя обработку нижнего уровня сетевых протоколов, так что вы можете сосредоточиться на решении ваших задач.
Архитектура DCOM
Объектная модель компонентов (COM) является краеугольной технологией MS Windows, она определяет взаимодействие компонентов и их клиентов таким образом, что клиент и компонент могут соединиться напрямую без какого-либо посредника в лице системного компонента. Клиент вызывает методы в компоненте без использования каких бы то ни было надстроек.
Рис.1. Компоненты COM в том же самом процессе.
В современных операционных системах процессы защищены друг от друга. Клиент, который должен связаться с компонентом в другом процессе, не может вызвать компонент непосредственно, он должен использовать некоторую форму взаимодействия процессов, обеспечиваемую операционной системой. COM обеспечивает эту связь полностью прозрачным способом: перехватывает запросы от клиента и посылает их компоненту, находящемуся в другом процессе. Рисунок 2 иллюстрирует, как библиотеки времени выполнения COM/DCOM обеспечивают связь между клиентом и компонентом.
Рис. 2. Компоненты COM в разных процессах. LPC — local procedure call. RPC — remote procedure call. DCE — distributed computing environment.
Когда клиент и компонент находятся на различных машинах, DCOM просто заменяет местное взаимодействие процессов сетевым протоколом. Ни клиент, ни компонент не знают, что провод, который их соединяет, становится немного длиннее.
DCOM может использовать любой транспортный протокол, включая TCP/IP, UDP, IPX/SPX и NetBIOS. Это также кросс-платформенный стандарт. Существуют реализации для Mac, UNIX, Linux. Сетевой протокол DCOM основан на Distributed Computing Environment (DCE) RPC. DCE RPC определяет стандарт для преобразования структур данных и параметров в сетевые пакеты.
Конкурирующий с DCOM стандарт — CORBA.
Рисунок 3 показывает DCOM архитектуру: COM во время выполнения обеспечивает объектно-ориентированные услуги клиентам и компонентам и использует RPC и провайдера защиты, чтобы генерировать стандартные сетевые пакеты, которые соответствуют стандарту DCOM.
Рис. 3. DCOM: компоненты COM на разных машинах.
Свойства DCOM можно конфигурировать с помощью DCOMCNFG.EXE.
При использовании операционной системы Windows 2000 к модели COM добавляется концепция центрального хранилища классов COM. Вся информация о компоненте, связанная с активацией, может быть опционально сохранена в Active Directory на контроллере домена так же, как сервисы входа в систему и идентификации сохраняют пользовательские мандаты на контроллере домена. Библиотеки COM в прозрачном режиме получат информацию для активации из Active Directory. Изменения информации о конфигурации компонентов в Active Directory автоматически размножатся всем клиентам, связанным с этой частью AD.
Защита DCOM
DCOM использует расширенную структуру защиты Windows NT. Windows NT обеспечивает набор встроенных провайдеров защиты, которые поддерживают множественные идентифицирующие и опознавательные механизмы: от традиционных моделей защиты на базе доверительных доменов до защиты на основе публичных ключей. Центральная часть структуры защиты — пользовательский каталог, в котором хранится необходимая информация: имя пользователя, пароль, публичный ключ. Большинство DCOM, реализованных на платформах, отличных от Windows NT, обеспечивают подобный или идентичный механизм.
Что такое RPC
RPC — Remote Procedure Call — стандарт сетевого программирования, определяющий мощную технологию для того, чтобы создавать распределенные программы клиент/сервер.
RPC заглушки (stub) и библиотеки времени выполнения (run-time library) управляют большинством процессов, касающихся сетевых протоколов и связи. Это дает возможность разработчику программного обеспечения сосредоточиться на разработке приложения, а не на особенностях сетевых протоколов. Вы можете конфигурировать RPC, чтобы использовать один или более транспортов, один или более сервисов имен и один или более серверов защиты. Стандарт RPC разработан в начале 1980-ых годов организацией Open Software Foundation (OSF). Реализация RPC от Microsoft совместима со стандартом OSF. В природе существует еще один стандарт — SunRPC.
Как работает RPC
Средства RPC предоставляют возможность пользователям посредством клиента вызвать процедуру, расположенную в удаленной серверной программе. Клиент и сервер имеют собственные адресные пространства, то есть каждый имеет свой собственный ресурс памяти для используемых данных. Следующий рисунок иллюстрирует архитектуру RPC.
Как показано на рисунке, приложение-клиент вызывает локальную заглушку (stub) вместо фактического кода процедуры. Заглушки откомпилированы и связаны с приложением-клиентом. Вместо того, чтобы содержать в себе полный код удаленной процедуры, клиентская заглушка:
• получает нужные параметры из адресного пространства на клиенте.
• транслирует параметры в стандартный формат (NDR) для передачи по сети.
• вызывает RPC-функции клиентской библиотеки времени выполнения (run-time library) для того, чтобы послать запрос и необходимые параметры на сервер.
Сервер выполняет следующие действия:
• серверные RPC-функции библиотеки времени выполнения принимают запрос и вызывают серверную заглушку.
• серверная заглушка получает параметры из сетевого буфера и конвертирует данные из сетевого формата в формат серверного приложения.
• серверная заглушка вызывает фактическую процедуру на сервере.
Удаленная процедура выполняется. При этом, возможно, генерируя выходные параметры и возвращаемое значение. Когда выполнение удаленной процедуры заканчивается, следующая последовательность шагов возвращает данные клиенту:
• удаленная процедура возвращает данные серверной заглушке.
• серверная заглушка преобразовывает выходные параметры к формату, требуемому для передачи по сети, и возвращает их в RPC-функцию библиотеки времени выполнения.
• серверные RPC-функции библиотеки времени выполнения передают данные по сети на клиентский компьютер.
Клиент завершает процесс, принимая данные по сети и возвращая их запрашивающей функции:
• клиентская RPC-функция библиотеки времени выполнения получает возвращаемые удаленной процедурой значения и передает их клиентской заглушке.
• клиентская заглушка преобразовывает данные из NDR до формата, используемого клиентским компьютером.
• заглушка пишет данные в клиентскую память и возвращает результат запрашивающей программе на клиенте.
Запрашивающая программа продолжает выполняться, как будто вызов функции произошел на том же компьютере.
Продолжение следует
Юрий Трофимов, mr.Root@tut.by
Поводом для написания данной статьи послужили новые уязвимости операционной системы Windows, которые совсем недавно были использованы семейством интернет-червей LoveSan/Blaster, вызвавших в середине августа одну из крупнейших эпидемий в вирусной истории.
Однако эпидемия вроде бы отшумела, а вопросы остались. Мы поговорим о технологиях Microsoft, которые оказались под ударом, чтобы лучше уяснить суть происходящего, поскольку я уверен, что подавляющее большинство пользователей и системных администраторов весьма посредственно ориентируются в сути вопроса. А наша практическая часть все-таки будет больше ориентирована на простых пользователей, потому что системные администраторы обязаны все это знать по определению.
Скажу сразу, что я весьма далек от той части публики, которая, не разобравшись, кричит "виндовс — мастдай". События последних лет, статистика красноречиво показывают, какие системы подвергаются взломам чаще всего. А тех, кто думает, что сможет на коленке написать безглючную СуперОС или даже просто 100 строк кода, я отошлю к Ф.Бруксу, вернее, к его труду "Мифический человеко-месяц (или как создаются программные системы)": "Время от времени можно прочесть в газете о том, как в переоборудованном гараже пара программистов сделала замечательную программу, оставившую позади разработки больших команд. И каждый программист охотно верит в эти сказки, поскольку знает, что может создать любую программу со скоростью, значительно превышающей те 1000 операторов в год, которые, по сообщениям, пишут программисты в промышленных бригадах. Почему же до сих пор все профессиональные бригады программистов не заменены одержимыми дуэтами из гаражей?"
Итак, вернемся на главную дорогу и начнем наше неспешное повествование. Согласно исследованиям университета Карнеги-Меллона ( http://www.sei.cmu.edu ) и ФБР ( http://www.fbi.gov ), 98% инцидентов возникает из-за проблемы, о которой ответственные сотрудники IT-отдела уже знали, но не приняли адекватных мер к устранению. Эксперты Gartner ( http://www.gartner.com ) считают, что эта цифра — около 90%. Аналитики координационного центра по безопасности CERT ( http://www.cert.org ) утверждают, что 95% инцидентов, о которых им сообщают, используют известные дыры.
Можно заметить печальную общую тенденцию: около 90% всех проблем с компьютерной безопасностью происходит по причине невнимательности со стороны системных администраторов, одной из задач которых и является своевременная защита постоянно появляющихся дыр в корпоративной сети.
Далее. Компания Qualys представила интересную статистику, касающуюся ликвидации дыр в программном обеспечении корпоративными пользователями. Эта статистика была получена на основе данных сканирования на предмет уязвимостей 1,5 млн. компьютерных систем. По данным Qualys, процесс ликвидации уязвимостей идет недостаточно быстро. В частности, в течение первых 30 дней после появления информации о критических дырах патчи устанавливают менее половины компаний. На устранение менее серьезных уязвимостей уходит, в среднем, на 60 дней больше, чем на борьбу с критическими дырами. За это время хакеры и специалисты по безопасности в 80% случаев успевают создать программы, использующие эти дыры. Именно поэтому существует опасность повторения атак с использованием уже, казалось бы, давно обезвреженных уязвимостей.
"Переполнение буфера RPC", "уязвимое место в системе безопасности интерфейса DCOM" — такими фразами пестрели сообщения об опасности еще вчера. Попытаемся разобраться, что скрывается за этими понятиями, ибо "практика без теории слепа".
DCOM
Microsoft Distributed COM (DCOM) — это расширение модели COM для поддержки связей объектов для разных компьютеров, находящихся в локальной сети (LAN), глобальной сети (WAN) или Интернет. Используя DCOM, ваше приложение может быть распределенным, т.е. может работать на нескольких компьютерах как на одном.
Общающиеся посредством COM/DCOM программы называются клиентом и сервером. Клиент является инициатором общения. Он обращается к одной из служб сервера для получения некоторых данных или для выполнения некоторой работы над данными, которые передаются серверу. Службы сервера реализуются в виде одного или нескольких входящих в его состав объектов COM. Один объект может содержать произвольное количество служб.
Component Object Model (COM) разработан для того, чтобы позволить клиентам прозрачно связываться с объектами, независимо от того, где объекты выполняются: в том же самом процессе, на той же самой машине или на разных машинах. Это обеспечивает единую модель программирования для всех типов объектов: и для клиентов, и для серверов.
Поскольку DCOM развивает объектную модель COM, вы можете использовать существующие приложения, компоненты и инструментальные средства на базе COM для продвижения в мир распределенных вычислений. DCOM берет на себя обработку нижнего уровня сетевых протоколов, так что вы можете сосредоточиться на решении ваших задач.
Архитектура DCOM
Объектная модель компонентов (COM) является краеугольной технологией MS Windows, она определяет взаимодействие компонентов и их клиентов таким образом, что клиент и компонент могут соединиться напрямую без какого-либо посредника в лице системного компонента. Клиент вызывает методы в компоненте без использования каких бы то ни было надстроек.
Рис.1. Компоненты COM в том же самом процессе.
В современных операционных системах процессы защищены друг от друга. Клиент, который должен связаться с компонентом в другом процессе, не может вызвать компонент непосредственно, он должен использовать некоторую форму взаимодействия процессов, обеспечиваемую операционной системой. COM обеспечивает эту связь полностью прозрачным способом: перехватывает запросы от клиента и посылает их компоненту, находящемуся в другом процессе. Рисунок 2 иллюстрирует, как библиотеки времени выполнения COM/DCOM обеспечивают связь между клиентом и компонентом.
Рис. 2. Компоненты COM в разных процессах. LPC — local procedure call. RPC — remote procedure call. DCE — distributed computing environment.
Когда клиент и компонент находятся на различных машинах, DCOM просто заменяет местное взаимодействие процессов сетевым протоколом. Ни клиент, ни компонент не знают, что провод, который их соединяет, становится немного длиннее.
DCOM может использовать любой транспортный протокол, включая TCP/IP, UDP, IPX/SPX и NetBIOS. Это также кросс-платформенный стандарт. Существуют реализации для Mac, UNIX, Linux. Сетевой протокол DCOM основан на Distributed Computing Environment (DCE) RPC. DCE RPC определяет стандарт для преобразования структур данных и параметров в сетевые пакеты.
Конкурирующий с DCOM стандарт — CORBA.
Рисунок 3 показывает DCOM архитектуру: COM во время выполнения обеспечивает объектно-ориентированные услуги клиентам и компонентам и использует RPC и провайдера защиты, чтобы генерировать стандартные сетевые пакеты, которые соответствуют стандарту DCOM.
Рис. 3. DCOM: компоненты COM на разных машинах.
Свойства DCOM можно конфигурировать с помощью DCOMCNFG.EXE.
При использовании операционной системы Windows 2000 к модели COM добавляется концепция центрального хранилища классов COM. Вся информация о компоненте, связанная с активацией, может быть опционально сохранена в Active Directory на контроллере домена так же, как сервисы входа в систему и идентификации сохраняют пользовательские мандаты на контроллере домена. Библиотеки COM в прозрачном режиме получат информацию для активации из Active Directory. Изменения информации о конфигурации компонентов в Active Directory автоматически размножатся всем клиентам, связанным с этой частью AD.
Защита DCOM
DCOM использует расширенную структуру защиты Windows NT. Windows NT обеспечивает набор встроенных провайдеров защиты, которые поддерживают множественные идентифицирующие и опознавательные механизмы: от традиционных моделей защиты на базе доверительных доменов до защиты на основе публичных ключей. Центральная часть структуры защиты — пользовательский каталог, в котором хранится необходимая информация: имя пользователя, пароль, публичный ключ. Большинство DCOM, реализованных на платформах, отличных от Windows NT, обеспечивают подобный или идентичный механизм.
Что такое RPC
RPC — Remote Procedure Call — стандарт сетевого программирования, определяющий мощную технологию для того, чтобы создавать распределенные программы клиент/сервер.
RPC заглушки (stub) и библиотеки времени выполнения (run-time library) управляют большинством процессов, касающихся сетевых протоколов и связи. Это дает возможность разработчику программного обеспечения сосредоточиться на разработке приложения, а не на особенностях сетевых протоколов. Вы можете конфигурировать RPC, чтобы использовать один или более транспортов, один или более сервисов имен и один или более серверов защиты. Стандарт RPC разработан в начале 1980-ых годов организацией Open Software Foundation (OSF). Реализация RPC от Microsoft совместима со стандартом OSF. В природе существует еще один стандарт — SunRPC.
Как работает RPC
Средства RPC предоставляют возможность пользователям посредством клиента вызвать процедуру, расположенную в удаленной серверной программе. Клиент и сервер имеют собственные адресные пространства, то есть каждый имеет свой собственный ресурс памяти для используемых данных. Следующий рисунок иллюстрирует архитектуру RPC.
Как показано на рисунке, приложение-клиент вызывает локальную заглушку (stub) вместо фактического кода процедуры. Заглушки откомпилированы и связаны с приложением-клиентом. Вместо того, чтобы содержать в себе полный код удаленной процедуры, клиентская заглушка:
• получает нужные параметры из адресного пространства на клиенте.
• транслирует параметры в стандартный формат (NDR) для передачи по сети.
• вызывает RPC-функции клиентской библиотеки времени выполнения (run-time library) для того, чтобы послать запрос и необходимые параметры на сервер.
Сервер выполняет следующие действия:
• серверные RPC-функции библиотеки времени выполнения принимают запрос и вызывают серверную заглушку.
• серверная заглушка получает параметры из сетевого буфера и конвертирует данные из сетевого формата в формат серверного приложения.
• серверная заглушка вызывает фактическую процедуру на сервере.
Удаленная процедура выполняется. При этом, возможно, генерируя выходные параметры и возвращаемое значение. Когда выполнение удаленной процедуры заканчивается, следующая последовательность шагов возвращает данные клиенту:
• удаленная процедура возвращает данные серверной заглушке.
• серверная заглушка преобразовывает выходные параметры к формату, требуемому для передачи по сети, и возвращает их в RPC-функцию библиотеки времени выполнения.
• серверные RPC-функции библиотеки времени выполнения передают данные по сети на клиентский компьютер.
Клиент завершает процесс, принимая данные по сети и возвращая их запрашивающей функции:
• клиентская RPC-функция библиотеки времени выполнения получает возвращаемые удаленной процедурой значения и передает их клиентской заглушке.
• клиентская заглушка преобразовывает данные из NDR до формата, используемого клиентским компьютером.
• заглушка пишет данные в клиентскую память и возвращает результат запрашивающей программе на клиенте.
Запрашивающая программа продолжает выполняться, как будто вызов функции произошел на том же компьютере.
Продолжение следует
Юрий Трофимов, mr.Root@tut.by
Компьютерная газета. Статья была опубликована в номере 45 за 2003 год в рубрике soft :: win
