Информационная безопасность

         

К вопросу защиты карточек пополнения счета мобильных операторов связи


, Игорь Васильевич Шестак, Украинский Государственный Университет информационно-коммуникационных технологий

Данный вариант является переработанной версией статьи, опубликованной в журнале «Зв’язок» № 7, 2005.

Хотя материалом для написания статьи служила информация об операторах мобильной связи Украины, эти материалы будут полезны и сотрудникам служб безопасности операторов мобильной связи СНГ, а также фирм, предоставляющих услуги с предоплатой с помощью кодов пополнения счета. В статье описан некий абстрактный процес создания кода пополнения счета, а также описана методика его анализа. Хотя для процеса создания кодов пополнения счета использовались криптографически сильные хэш-алгоритмы, сам процес оказался криптографически слабым. Если же используются алгоритмы, разработанные самими операторами, то их криптографическая стойкость может оказаться как очень высокой, так и катастрофически низкой.

Что касается использованных карточек пополнения счета, то их легально можно получить, скупая у некоторых слоев населения. Таким образом, за короткий промежуток времени можно собрать большой обьем материала для анализа.

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

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

Функцией перемешивания могут быть хэш - алгоритмы: MD2 (128 бит), MD4 (128 бит), MD5 (128 бит), SHA (160 бит) и т.д.
В основном используются MD4 и MD5, обладающие высоким быстродействием и хорошими размешивающими характеристиками (MD4 в 3 раза быстрее MD5).

Далее будем полагать, что используется хэш-функция с 128 битным выходом

m=128.

Нулевая итерация (начальное заполнение) примет вид:

Г0 = Hash(NomSeria, GodenDo, Nominal, SecretKey). (1)

На выходе (1) получим фиксированную m - битную строку хэш - суммы.

В итоге возможно ? 2m начальных состояний генератора, вне зависимости от того, какой длины секретный ключ вводится и какой массив данных туда вводится.

Для получения остальных бит используется рекуррентное выражение:

Гi+1 = Hash(Гi)

, (2)

где N – количество карточек в выпускаемой серии, L – длина кода пополнения счета в битах, [ ] – округление до большего целого.

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

Свойством (2) является возможность однозначного определения через любой выход хэш-суммы Гk всех последующих хэш-сумм Гk+1.

Данный механизм идеален для получения секретных ключей криптоалгоритмов или вычисления (1), но совершенно непригоден для получения кодов пополнения счета, так как они «публикуются» на карточках.

Приведем один из возможных механизмов подделки кодов пополнения счета.

Количество карточек в выпускаемой серии N несложно определить по серийным номерам карточек.

По номеру карточки можно вычислить номер m - битного блока бит и смещение кода пополнения счета в этом блоке.

Длина кода пополнения счета L подбирается из анализа кодов пополнения счета.

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

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



При этом не спасает модификация формулы (2) к виду:

Гi+1 = Hash(Гi, SecretKey)
, (3)

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

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

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

Для минимизации возможности взлома кодов карточек пополнения счета, службам безопасности (далее СБ) операторов мобильной связи необходимо отказаться от пагубной стратегии, именуемой на Западе SbO, что в зависимости от чувства юмора расшифровывают либо как Security by Obscurity ("безопасность упрятыванием"), либо как Security by Ostrich ("безопасность по-страусиному"). Согласно этой стратегии, степень защиты любой системы в значительной степени увязывается с сохранением в тайне как особенностей ее конструкции, так и случаев ее компрометации. Автор еще в 2002 году лично столкнулся с проявлением этой стратегии в разговоре с представителем СБ одного оператора мобильной связи. СБ выразила заинтересованность в анализе защищенности кодов пополнения счета и даже хотела подкрепить свой интерес финансово. При этом они отказались предоставить для анализа уже использованную серию кодов пополнения счета, сославшись на ее … секретность! Секретным они называли то, что уже находилось в распоряжении автора и при этом было собрано из открытых источников без нарушения законодательства Украины.Налицо полная некомпетентность представителя СБ и непонимание того, что в действительности необходимо защищать. Не думаю, что сейчас что-либо изменилось в стратегии работы СБ.

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

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


Дополнительные и усиленные регуляторы безопасности для умеренного уровня ИБ


Для умеренного уровня информационной безопасности целесообразно применение следующих дополнительных и усиленных (по сравнению с минимальным уровнем) регуляторов безопасности.

Оценка рисков: сканирование уязвимостей. С заданной частотой или после появления сведений о новых критичных для ИС уязвимостях необходимо сканировать уязвимости в информационной системе.Планирование безопасности: планирование деятельности, связанной с безопасностью. Обеспечение должного планирования и координации деятельности, связанной с безопасностью и затрагивающей информационную систему, с целью минимизации отрицательного воздействия на работу и активы организации (в том числе на ее миссию, функции, имидж и репутацию).Закупка систем и сервисов: документация. Необходимо включать в общий пакет документов документацию от изготовителя/поставщика (при наличии таковой), описывающую функциональные свойства регуляторов безопасности, задействованных в информационной системе, достаточно детальную для того, чтобы сделать возможным анализ и тестирование регуляторов.Закупка систем и сервисов: принципы проектирования информационной безопасности. Проектирование и реализация информационной системы проводится с применением принципов проектирования информационной безопасности.Закупка систем и сервисов: тестирование безопасности разработчиком. Разработчик информационной системы формирует план тестирования и оценки безопасности, реализует его и документирует результаты; последние могут быть использованы для поддержки сертификации по требованиям безопасности и аккредитации поставленной ИС.Сертификация, аккредитация и оценка безопасности: оценка безопасности. С заданной частотой, но не реже, чем раз в год, целесообразно осуществлять оценку регуляторов безопасности в информационной системе, чтобы определить, насколько они корректно реализованы, функционируют в соответствии со спецификациями и дают ожидаемые результаты с точки зрения выполнения предъявляемых к ИС требований информационной безопасности.Сертификация, аккредитация и оценка безопасности: сертификация по требованиям безопасности. Оценка регуляторов безопасности в информационной системе для целей сертификации по требованиям безопасности осуществляется независимой сертифицирующей организацией.Физическая защита: контроль доступа к устройствам отображения информации. Контроль физического доступа к устройствам отображения информации с целью защиты последней от просмотра неавторизованными лицами.Физическая защита: мониторинг физического доступа. В режиме реального времени отслеживаются поступающие сигналы о вторжениях и данные со следящих устройств.Физическая защита: контроль посетителей. Обеспечение сопровождения посетителей и, если нужно, мониторинга их активности.Физическая защита: электрическое оборудование и проводка. Защита электрического оборудования и проводки для информационной системы от повреждений и разрушений.Физическая защита: аварийное отключение. Для определенных помещений, в которых концентрируются ресурсы информационной системы (центры обработки данных, серверные комнаты, машинные залы для мэйнфреймов и т.п.), следует обеспечить возможность отключения электропитания к любому отказавшему (например, из-за короткого замыкания) или оказавшемуся под угрозой (например, из-за разрыва водопровода) компоненту ИС, не подвергая при этом персонал опасности, сопряженной с доступом к оборудованию. Физическая защита: аварийное электропитание. Обеспечение краткосрочных источников бесперебойного питания, чтобы дать возможность аккуратно выключить информационную систему в случае нарушения основного электропитания.Физическая защита: противопожарная защита. Необходимо применять и поддерживать устройства/системы пожаротушения и обнаружения возгораний, автоматически срабатывающие в случае пожара.Физическая защита: запасная производственная площадка.

Для высокого уровня информационной безопасности рекомендуется применение следующих дополнительных и усиленных (по сравнению с умеренным уровнем) регуляторов безопасности.

Оценка рисков: сканирование уязвимостей. Средства сканирования уязвимостей включают возможность оперативного изменения списка сканируемых уязвимостей информационной системы.

С заданной частотой или после появления сведений о новых критичных для ИС уязвимостях организация изменяет список сканируемых уязвимостей информационной системы.Закупка систем и сервисов: документация. Следует включить в общий пакет документов документацию от изготовителя/поставщика (при наличии таковой), описывающую детали проектирования и реализации регуляторов безопасности, задействованных в информационной системе, со степенью подробности, достаточной для того, чтобы сделать возможным анализ и тестирование регуляторов (включая функциональные интерфейсы между компонентами регуляторов). Закупка систем и сервисов: управление конфигурацией разработчиком. Разработчик информационной системы создает и реализует план управления конфигурацией, контролирующий изменения системы в процессе разработки, прослеживающий дефекты безопасности, требующий авторизации изменений, и предоставляет документацию плана и его реализации.Физическая защита: контроль доступа к каналам передачи данных. Контролируется физический доступ к линиям распространения и передачи данных, принадлежащим ИС и расположенным в пределах охраняемых границ, чтобы предотвратить неумышленное повреждение, прослушивание, модификацию в процессе передачи, разрыв или физическое искажение линий.Физическая защита: мониторинг физического доступа. Применяются автоматические механизмы, чтобы обеспечить выявление потенциальных вторжений и инициирование реакции на них.Физическая защита: протоколирование доступа. Применяются автоматические механизмы, чтобы облегчить поддержку и просмотр регистрационных журналов.Физическая защита: аварийное электропитание. Необходимо обеспечить долгосрочные альтернативные источники электропитания для информационной системы, способные поддерживать минимальные требуемые эксплуатационные возможности в случае долговременного выхода из строя первичного источника электропитания.Физическая защита: противопожарная защита. Применяются и поддерживаются устройства/системы пожаротушения и обнаружения возгораний, автоматически извещающие о своей активации организацию и аварийные службы.Физическая защита: защита от затопления. Автоматические механизмы применяются, чтобы автоматически перекрыть воду в случае ее интенсивной утечки.Планирование бесперебойной работы: обучение. Моделирование событий включается в учебные курсы, чтобы способствовать эффективному реагированию сотрудников на возможные кризисные ситуации.Планирование бесперебойной работы: тестирование плана обеспечения бесперебойной работы. План обеспечения бесперебойной работы тестируется на запасной производственной площадке, чтобы ознакомить сотрудников с имеющимися возможностями и ресурсами и оценить способность площадки поддерживать непрерывность функционирования.Планирование бесперебойной работы: запасные места хранения. Запасное место хранения конфигурируется так, чтобы облегчить своевременные и эффективные восстановительные действия; определяются потенциальные проблемы с доступом к запасному месту хранения в случае широкомасштабных аварий или стихийных бедствий и намечаются явные действия по смягчению выявленных проблем.Планирование бесперебойной работы: запасные места обработки данных. Запасное место обработки данных полностью конфигурируется для поддержания минимальных требуемых эксплуатационных возможностей и готовности к использованию в качестве производственной площадки.Планирование бесперебойной работы: телекоммуникационные услуги. Запасной источник телекоммуникационных услуг должен быть в достаточной степени удален территориально от основного, чтобы не подвергаться тем же опасностям; основной и запасной источники телекоммуникационных услуг имеют адекватные планы обеспечения бесперебойной работы. Планирование бесперебойной работы: резервное копирование. Для восстановления функций информационной системы выборочно используются резервные копии как часть тестирования плана обеспечения бесперебойной работы.


Сотрудники организации на запасной производственной площадке применяют соответствующие регуляторы безопасности для ИС.Физическая защита: расположение компонентов информационной системы. Следует располагать компоненты информационной системы на отведенных площадях так, чтобы минимизировать потенциальный ущерб от физических рисков и угроз со стороны окружающей среды, а также возможность несанкционированного доступа.Планирование бесперебойной работы: план обеспечения бесперебойной работы. Организация координирует разработку плана обеспечения бесперебойной работы со структурами, ответственными за родственные планы (например, планы восстановления после аварий, реагирования на нарушения безопасности и т.п.).Планирование бесперебойной работы: обучение. В компании организуется обучение сотрудников их ролям и обязанностям по обеспечению бесперебойной работы информационной системы, а также с заданной частотой, но не реже, чем раз в год, проводятся тренировки для поддержания практических навыков.Планирование бесперебойной работы: тестирование плана обеспечения бесперебойной работы. С заданной частотой, но не реже, чем раз в год, в организации тестируется план обеспечения бесперебойной работы информационной системы. Для этого применяются заданные тесты и тренировочные процедуры, чтобы определить эффективность плана и готовность организации к его выполнению. Соответствующие должностные лица проверяют результаты тестирования плана и инициируют корректирующие действия. Организация координирует тестирование плана обеспечения бесперебойной работы со структурами, ответственными за родственные планы (например, планы восстановления после аварий, реагирования на нарушения безопасности и т.п.).Планирование бесперебойной работы: запасные места хранения. Необходимо определить запасное место хранения и заключить необходимые соглашения, чтобы сделать возможным хранение там резервных копий данных информационной системы; запасное место хранения территориально должно быть удалено от основного, чтобы не подвергать его тем же опасностям.Планирование бесперебойной работы: запасные места обработки данных. Определяется запасное место обработки данных, и инициируются необходимые соглашения, чтобы сделать возможным возобновление выполнения информационной системой критически важных производственных функций в течение заданного промежутка времени, если основные средства обработки данных оказываются недоступными.


Запасное место обработки данных территориально удалено от основного и, следовательно, не подвержено тем же опасностям. Определяются потенциальные проблемы с доступом к запасному месту обработки данных в случае широкомасштабных аварий или стихийных бедствий, намечаются явные действия по смягчению выявленных проблем. Соглашение о запасном месте обработки данных содержит обязательства приоритетного обслуживания в соответствии с требованиями организации к доступности.Планирование бесперебойной работы: телекоммуникационные услуги. Определяются основной и запасной источники телекоммуникационных услуг, поддерживающих информационную систему. Инициируются необходимые соглашения, чтобы сделать возможным возобновление выполнения информационной системой критически важных производственных функций в течение заданного промежутка времени, если основной источник телекоммуникационных услуг оказывается недоступным. Соглашения об основном и запасном источниках телекоммуникационных услуг содержат обязательства приоритетного обслуживания в соответствии с требованиями организации к доступности. Запасной источник телекоммуникационных услуг не разделяет единую точку отказа с основным источником.Планирование бесперебойной работы: резервное копирование. С заданной частотой в организации тестируются резервные копии, чтобы убедиться в надежности носителей и целостности данных.Управление конфигурацией: базовая конфигурация и опись компонентов информационной системы. При установке новых компонентов изменяются базовая конфигурация информационной системы и опись компонентов ИС.Управление конфигурацией: контроль изменений конфигурации. Документируются и контролируются изменения в информационной системе; соответствующие должностные лица санкционируют изменения ИС в соответствии с принятыми в организации политикой и процедурами.Управление конфигурацией: мониторинг изменений конфигурации. Необходимо отслеживать изменения в информационной системе и осуществлять анализ их воздействия на безопасность, чтобы определить эффект изменений.Управление конфигурацией: ограничение доступа для изменений. Организация проводит в жизнь физические и логические ограничения доступа, связанного с изменениями в информационной системе, и генерирует, сохраняет и пересматривает записи, отражающие все подобные изменения.Управление конфигурацией: минимизация функциональности. Следует конфигурировать информационную систему так, чтобы обеспечить только необходимые возможности, и явным образом запретить и/или ограничить использование определенных функций, портов, протоколов и/или сервисов.Сопровождение: периодическое сопровождение. Поддерживается регистрационный журнал сопровождения информационной системы, в котором фиксируются:



дата и время обслуживания;фамилия и имя лица, производившего обслуживание;фамилия и имя сопровождающего, если это необходимо;описание произведенных действий по обслуживанию ИС;список удаленного или перемещенного оборудования (с идентификационными номерами).Сопровождение: средства сопровождения. Организация санкционирует, контролирует и отслеживает применение средств сопровождения информационной системы и постоянно поддерживает эти средства.Сопровождение: своевременное обслуживание. Организация получает обслуживание и запчасти для заданных ключевых компонентов информационной системы в течение заданного промежутка времени.Целостность систем и данных: защита от вредоносного программного обеспечения. Централизованное управление механизмами защиты от вредоносного программного обеспечения.Целостность систем и данных: средства и методы мониторинга информационной системы. Применение средств и методов мониторинга событий в информационной системе, выявление атак и идентификация несанкционированного использования ИС.Целостность систем и данных: защита от спама. В информационной системе реализуется защита от спама.Целостность систем и данных: ограничения на ввод данных. Организация предоставляет право на ввод данных в информационную систему только авторизованным лицам.Целостность систем и данных: точность, полнота, достоверность и аутентичность данных. Информационная система проверяет данные на точность, полноту, достоверность и аутентичность.Целостность систем и данных: обработка ошибок. Информационная система явным образом выявляет и обрабатывает ошибочные ситуации.Целостность систем и данных: обработка и сохранение выходных данных. Выходные данные информационной системы обрабатываются и сохраняются в соответствии с принятыми в организации политикой и эксплуатационными требованиями.Защита носителей: метки носителей. Съемные носители данных и выходные данные ИС снабжаются внешними метками, содержащими ограничения на распространение и обработку этих данных; заданные типы носителей или аппаратных компонентов освобождаются от меток, поскольку остаются в пределах контролируемой зоны.Защита носителей: хранение носителей.


Следует организовать физический контроль и безопасное хранение носителей данных, бумажных и цифровых, основываясь на максимальной категории, присвоенной данным, записанным на носителе.Защита носителей: транспортировка носителей. Контроль носителей данных, бумажных и цифровых, и ограничение отправки, получения, транспортировки и доставки носителей авторизованным лицам.Реагирование на нарушения информационной безопасности: обучение. Компания обучает сотрудников их ролям и обязанностям, связанным с реагированием на нарушения информационной безопасности ИС, и с заданной частотой, но не реже, чем раз в год, проводит тренировки для поддержания практических навыков.Реагирование на нарушения информационной безопасности: тестирование. С заданной частотой, но не реже, чем раз в год, тестируются средства реагирования на нарушения информационной безопасности ИС, при этом используются заданные тесты и тренировочные процедуры, чтобы определить эффективность реагирования. Результаты документируются.Реагирование на нарушения информационной безопасности: реагирование. Для поддержки процесса реагирования на нарушения информационной безопасности применяются автоматические механизмы.Реагирование на нарушения информационной безопасности: мониторинг. Необходимо постоянно прослеживать и документировать нарушения информационной безопасности ИС.Реагирование на нарушения информационной безопасности: доклады о нарушениях. Применение автоматических механизмов для содействия докладам о нарушениях информационной безопасности.Реагирование на нарушения информационной безопасности: помощь. Применение автоматических механизмов, чтобы повысить доступность информации и поддержки, ассоциированной с реагированием на нарушения информационной безопасности.Идентификация и аутентификация: идентификация и аутентификация устройств. Информационная система идентифицирует и аутентифицирует определенные устройства, прежде чем установить с ними соединение.Управление доступом: управление счетами. Применение автоматических механизмов для поддержки управления счетами в информационной системе; информационная система автоматически терминирует временные и аварийные счета по истечении заданного для каждого типа счетов промежутка времени; информационная система автоматически отключает неактивные счета по истечении заданного промежутка времени.Управление доступом: проведение в жизнь. Информационная система обеспечивает, чтобы доступ к функциям безопасности (реализованным аппаратно и/или программно) и к защитным данным предоставлялся только авторизованным лицам (например, администраторам безопасности).Управление доступом: проведение в жизнь управления информационными потоками. Информационная система проводит в жизнь присвоенные привилегии для управления информационными потоками в системе и между взаимосвязанными системами в соответствии с принятой политикой безопасности.Управление доступом: разделение обязанностей. Информационная система проводит в жизнь разделение обязанностей посредством присвоения привилегий доступа.Управление доступом: минимизация привилегий. Информационная система проводит в жизнь наиболее ограничительный набор прав/привилегий доступа, необходимых пользователям (или процессам, действующим от имени этих пользователей) для выполнения их задач.Управление доступом: блокирование сеансов. Информационная система предотвращает дальнейший доступ к ИС посредством блокирования сеанса до тех пор, пока пользователь не восстановит доступ, применяя соответствующие процедуры идентификации и аутентификации.Управление доступом: терминирование сеансов. Информационная система автоматически терминирует сеанс по истечении заданного периода неактивности.Управление доступом: действия, разрешенные без идентификации и аутентификации. Организация разрешает выполнение действий без идентификации и аутентификации, только если они необходимы для достижения ключевых целей организации.Управление доступом: удаленный доступ. Применение автоматических механизмов, чтобы облегчить мониторинг и контроль методов удаленного доступа, шифрование — для защиты конфиденциальности сеансов удаленного доступа.


Необходимо контролировать весь удаленный доступ в управляемой точке контроля доступа.Управление доступом: ограничения на беспроводной доступ. Применение аутентификации и шифрования для защиты беспроводного доступа к информационной системе.Управление доступом: мобильные устройства. Организация:

устанавливает ограничения на применение и разрабатывает руководства по использованию мобильных устройств;документирует, отслеживает и контролирует доступ посредством подобных устройств к ИС; соответствующие должностные лица санкционируют использование мобильных устройств; применяются съемные жесткие диски или криптография для защиты данных, располагающихся в мобильных устройствах.Протоколирование и аудит: содержимое регистрационных записей. Информационная система обеспечивает возможность включения в регистрационные записи дополнительной, более детальной информации для протоколируемых событий, идентифицируемых по типу, месту или субъекту.Протоколирование и аудит: мониторинг, анализ и отчет о регистрационной информации. Необходимо регулярно изучать/анализировать регистрационную информацию с целью выявления ненадлежащей или нетипичной активности, расследовать случаи подозрительной активности или предполагаемых нарушений, докладывать о результатах соответствующим должностным лицам и предпринимать необходимые действия.Протоколирование и аудит: редукция регистрационной информации и генерация отчетов. Информационная система предоставляет возможности редукции регистрационной информации и генерации отчетов.Протоколирование и аудит: метки времени. Информационная система предоставляет метки времени для использования при генерации регистрационных записей.Защита систем и коммуникаций: разделение приложений. Информационная система разделяет пользовательскую функциональность (включая сервисы пользовательского интерфейса) от функциональности управления ИС.Защита систем и коммуникаций: остаточная информация. Информационная система предотвращает несанкционированную и ненамеренную передачу информации через разделяемые системные ресурсы.Защита систем и коммуникаций: защита границ. Целесообразно физически размещать общедоступные компоненты информационной системы (например, общедоступные web-серверы) в отдельных подсетях с отдельными физическими сетевыми интерфейсами, предотвратить публичный доступ во внутреннюю сеть, за исключением должным образом контролируемого доступа.Защита систем и коммуникаций: целостность передаваемых данных. Информационная система защищает целостность передаваемых данных.Защита систем и коммуникаций: конфиденциальность передаваемых данных. Информационная система защищает конфиденциальность передаваемых данных.Защита систем и коммуникаций: разрыв сетевых соединений. Информационная система терминирует сетевое соединение в конце сеанса или по истечении заданного периода неактивности.Защита систем и коммуникаций: выработка криптографических ключей и управление ими. Информационная система применяет автоматические механизмы и вспомогательные процедуры или ручные процедуры для выработки криптографических ключей и управления ключами.Защита систем и коммуникаций: коллективные приложения. Информационная система запрещает удаленную активацию механизмов коллективных приложений (например, видео- или аудиоконференций) и предоставляет явные свидетельства их использования локальным пользователям (например, индикацию использования видеокамер или микрофонов).Защита систем и коммуникаций: сертификаты инфраструктуры открытых ключей. Организация разрабатывает и реализует политику для сертификатов и спецификацию сертификационной практики для выпуска сертификатов открытых ключей, используемых в информационной системе.Защита систем и коммуникаций: мобильный код. Организация:



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

устанавливает ограничения на применение и разрабатывает руководства по использованию технологий VoIP, исходя из возможности нанесения ущерба информационной системе при злоумышленном применении этих технологий;документирует, отслеживает и контролирует использование VoIP в информационной системе; соответствующие должностные лица санкционируют использование VoIP.Защита систем и коммуникаций: сервис безопасного поиска имен (уполномоченные источники). Информационные системы (уполномоченные серверы доменных имен), предоставляющие внешним пользователям сервис поиска имен для доступа к информационным ресурсам организации через Интернет, обеспечивают атрибуты для аутентификации источника данных и контроля целостности данных, чтобы дать пользователям возможность получить гарантии аутентичности и целостности сообщений при получении данных в рамках сетевых транзакций.



Резервные копии операционной системы и другого критичного для ИС программного обеспечения хранятся в отдельном месте или в огнеупорном контейнере, расположенном отдельно от эксплуатационного ПО.Планирование бесперебойной работы: восстановление информационной системы. Организация включает полное восстановление информационной системы как часть тестирования плана обеспечения бесперебойной работы.Управление конфигурацией: базовая конфигурация и опись компонентов информационной системы. Применяются автоматические механизмы, чтобы поддерживать актуальную, полную, точную и легко доступную базовую конфигурацию информационной системы и опись компонентов ИС.Управление конфигурацией: контроль изменений конфигурации. Автоматические механизмы применяются, чтобы:

документировать предлагаемые изменения информационной системы;извещать соответствующих должностных лиц;привлекать внимание к не полученным своевременно утверждающим визам;откладывать изменения до получения необходимых утверждающих виз;документировать произведенные изменения информационной системы.Управление конфигурацией: ограничение доступа для изменений. Чтобы проводить в жизнь ограничения доступа и поддерживать протоколирование ограничивающих действий, применяются автоматические механизмы.Управление конфигурацией: настройки. Автоматические механизмы применяются для централизованного управления, применения и верифицирования настроек.Управление конфигурацией: минимизация функциональности. С заданной частотой пересматривается информационная система, чтобы идентифицировать и ликвидировать функции, порты, протоколы и иные сервисы, не являющиеся необходимыми.Сопровождение: периодическое сопровождение. Применяются автоматические механизмы, чтобы обеспечить планирование и проведение периодического сопровождения в соответствии с установленными требованиями, а также актуальность, точность, полноту и доступность регистрационных записей о необходимых и произведенных действиях по сопровождению.Сопровождение: средства сопровождения. Необходимо досматривать все средства сопровождения (например, диагностическое и тестовое оборудования), вносимые на территорию организации обслуживающим персоналом, на предмет видимых ненадлежащих модификаций.


Следует проверять все носители, содержащие диагностические тестовые программы (например, программное обеспечение, используемое для сопровождения и диагностики систем), на предмет наличия вредоносного ПО, прежде чем носители будут применены в информационной системе. Проверке подвергается все оборудование, применяемое в целях сопровождения и способное сохранять информацию, чтобы удостовериться, что в оборудовании не записана принадлежащая организации информация или что оно должным образом санировано перед повторным использованием. Если оборудование не может быть санировано, оно остается на территории организации или уничтожается, за исключением случаев, явно санкционированных соответствующими должностными лицами.Сопровождение: удаленное сопровождение. Протоколируются все сеансы удаленного сопровождения, а соответствующие должностные лица просматривают регистрационный журнал удаленных сеансов. Установка и использование каналов удаленной диагностики отражаются в плане безопасности информационной системы. Сервисы удаленной диагностики или сопровождения допустимы только в том случае, если обслуживающая организация поддерживает в своей ИС по крайней мере тот же уровень безопасности, что и обслуживаемая.Целостность систем и данных: защита от вредоносного программного обеспечения. Информационная система автоматически изменяет механизмы защиты от вредоносного программного обеспечения.Целостность систем и данных: верификация функциональности безопасности. Информационная система в рамках технических возможностей, при старте или перезапуске системы, по команде уполномоченного пользователя и/или периодически с заданной частотой верифицирует корректность работы функций безопасности и извещает системного администратора и/или выключает или перезапускает систему в случае выявления каких-либо аномалий.Целостность систем и данных: целостность программного обеспечения и данных. Информационная система выявляет и защищает от несанкционированного изменения программного обеспечения и данных.Целостность систем и данных: защита от спама. Организация централизованно управляет механизмами защиты от спама.Защита носителей: доступ к носителям. Применяются либо посты охраны, либо автоматические механизмы для управления доступом к местам хранения носителей, обеспечения защиты от несанкционированного доступа, а также регистрации попыток доступа и доступа предоставленного.Реагирование на нарушения информационной безопасности: обучение. В учебные курсы включается моделирование событий, чтобы способствовать эффективному реагированию сотрудников на возможные кризисные ситуации.Реагирование на нарушения информационной безопасности: тестирование. Для более тщательного и эффективного тестирования возможностей реагирования применяются автоматические механизмы.Реагирование на нарушения информационной безопасности: мониторинг. Автоматические механизмы применяются, чтобы способствовать прослеживанию нарушений безопасности, а также сбору и анализу информации о нарушениях.Идентификация и аутентификация: идентификация и аутентификация пользователей. Информационная система применяет многофакторную аутентификацию.Управление доступом: управление счетами. Применяются автоматические механизмы, чтобы обеспечить протоколирование и, при необходимости, уведомление соответствующих лиц о создании, модификации, отключении и терминировании счетов.Управление доступом: управление параллельными сеансами. Информационная система ограничивает число параллельных сеансов для одного пользователя.Управление доступом: надзор и просмотр.


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




Категорирование информации и информационных


Владимир Антонович Галатенко (доктор физико-математических наук)
Информационный бюллетень JET INFO

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


Владимир Антонович Галатенко (доктор физико-математических наук)
Информационный бюллетень JET INFO

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

Существуют три основных аспекта ИБ:

доступность;конфиденциальность;целостность.

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

Размер ущерба удобно оценивать по трехуровневой шкале как низкий, умеренный или высокий ().

Рисунок 1. Шкала оценки ущерба при нарушении информационной безопасности

Потенциальный ущерб для организации оценивается как низкий, если потеря доступности, конфиденциальности и/или целостности оказывает ограниченное вредоносное воздействие на деятельность организации, ее активы и персонал. Ограниченность вредоносного воздействия означает, что:

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

Потенциальный ущерб для компании оценивается как умеренный, если потеря доступности, конфиденциальности и/или целостности оказывает серьезное вредоносное воздействие на деятельность организации, ее активы и персонал.


Владимир Антонович Галатенко (доктор физико-математических наук)
Информационный бюллетень JET INFO

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

Рисунок 2. Уровни информационной безопасности

Минимальные требования безопасности () охватывают административный, процедурный и программно-технический уровни ИБ и формулируются следующим образом.

Рисунок 3. Базовые требования безопасности к информации и ИС.

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

выделить достаточный объем ресурсов для адекватной защиты ИС;при разработке систем учитывать требования ИБ;ограничивать использование и установку программного обеспечения;обеспечить выделение внешними поставщиками услуг достаточных ресурсов для защиты информации, приложений и/или сервисов.В области сертификации, аккредитации и оценки безопасности в организации следует проводить:

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




Владимир Антонович Галатенко (доктор физико-математических наук)
Информационный бюллетень JET INFO

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

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

Адекватный выбор регуляторов безопасности можно упростить, если производить его из предопределенных базовых наборов, ассоциированных с требуемым уровнем ИБ. Применяя трехуровневую шкалу, используют три базовых набора, соответственно, для минимального (низкого, базового), умеренного и высокого уровня информационной безопасности.




Владимир Антонович Галатенко (доктор физико-математических наук)
Информационный бюллетень JET INFO

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

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

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

Рисунок 6. Обеспечение информационной безопасности. Процессный подход.

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




Владимир Антонович Галатенко (доктор физико-математических наук)
Информационный бюллетень JET INFO

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




Владимир Антонович Галатенко (доктор физико-математических наук)
Информационный бюллетень JET INFO

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

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

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



Регуляторы безопасности для минимального уровня ИБ


На минимальном уровне информационной безопасности целесообразно применять следующие административные регуляторы безопасности.

Рисунок 4. Регуляторы безопасности по уровням ИБ

Оценка рисков: политика и процедуры. Разработка, распространение, периодический пересмотр и изменение:

официальной документированной политики оценки рисков, в которой представлены цель, охват, роли, обязанности, поддержка руководства, координация среди организационных структур и соответствие действующему законодательству;формальных документированных процедур, способствующих проведению в жизнь политики и ассоциированных регуляторов оценки рисков.Оценка рисков: категорирование по требованиям безопасности. Категорирование данных и информационной системы, документирование результатов, включая обоснование установленных категорий; документ заверяется руководством.Оценка рисков: проведение. Оценка рисков и возможного ущерба от несанкционированного доступа, использования, раскрытия, нарушения работы, модификации и/или разрушения данных и/или информационной системы, включая ресурсы, управляемые внешними организациями.Оценка рисков: пересмотр результатов. Пересмотр результатов оценки рисков проводится либо с заданной частотой, либо после существенных изменений в ИС или поддерживающей инфраструктуре, либо после иных событий, способных заметно повлиять на уровень безопасности ИС или ее статус аккредитации.Планирование безопасности: политика и процедуры. Разработка, распространение, периодический пересмотр и изменения:

официальной документированной политики планирования безопасности, в которой представлены цель, охват, роли, обязанности, поддержка руководства, координация среди организационных структур и соответствие действующему законодательству;формальных документированных процедур, способствующих проведению в жизнь политики и ассоциированных регуляторов планирования безопасности.Планирование безопасности: план безопасности ИС. Разработка и реализация для информационной системы плана, в котором описаны требования безопасности для ИС и имеющиеся и планируемые регуляторы безопасности, служащие для выполнения этих требований; документ заверяется руководством.Планирование безопасности: изменение плана безопасности ИС. С заданной частотой пересматривается план безопасности ИС.
В него вносятся изменения, отражающие изменения в компании и в ее информационной системе либо проблемы, выявленные при реализации плана или при оценке регуляторов безопасности.Планирование безопасности: правила поведения. В организации устанавливается и доводится до сведения пользователей ИС набор правил, описывающих обязанности и ожидаемое поведение по отношению к использованию информации и информационной системы. Прежде чем получить доступ к ИС и ее информационным ресурсам, пользователи подписывают подтверждение того, что они прочитали, поняли и согласны выполнять предписанные правила поведения.Планирование безопасности: оценка приватности. В компании проводится оценка выполнения в ИС требований приватности.Закупка систем и сервисов: политика и процедуры. Разрабатываются, распространяются, периодически пересматриваются и изменяются:

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



официальной документированной политики оценки безопасности, сертификации и аккредитации, в которой представлены цель, охват, роли, обязанности, поддержка руководства, координация среди организационных структур и соответствие действующему законодательству;формальных документированных процедур, способствующих проведению в жизнь политики и ассоциированных регуляторов оценки безопасности, сертификации и аккредитации.Сертификация, аккредитация и оценка безопасности: соединения с другими ИС. Авторизация компанией всех соединений своей информационной системы с другими ИС, находящимися вне границ аккредитации, и постоянное отслеживание/контроль этих соединений; подписание уполномоченными должностными лицами соглашения об установлении соединений между системами.Сертификация, аккредитация и оценка безопасности: сертификация по требованиям безопасности. Организация проводит оценку применяемых в ИС регуляторов безопасности, чтобы проверить, насколько корректно они реализованы, функционируют в соответствии со спецификациями и дают ожидаемые результаты с точки зрения выполнения предъявляемых к ИС требований информационной безопасности.Сертификация, аккредитация и оценка безопасности: календарный план мероприятий. В организации разрабатывается и с заданной частотой изменяется календарный план мероприятий. В нем описаны запланированные, реализованные и оцененные корректирующие действия, направленные на устранение всех недостатков, выявленных в процессе оценки регуляторов безопасности, и на уменьшение или устранение известных уязвимостей ИС.Сертификация, аккредитация и оценка безопасности: аккредитация. Компания явным образом санкционирует (осуществляет аккредитацию) ввод информационной системы в эксплуатацию и с заданной частотой, но не реже, чем раз в три года, проводит повторную аккредитацию.Сертификация, аккредитация и оценка безопасности: постоянный мониторинг. Постоянный мониторинг регуляторов безопасности в ИС.

Рисунок 5. Поддержание необходимого уровня безопасности





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

Кадровая безопасность: политика и процедуры. Разработка, распространение, периодический пересмотр и изменение:

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



официальная документированная политика физической защиты, в которой представлены цель, охват, роли, обязанности, поддержка руководства, координация среди организационных структур и соответствие действующему законодательству;формальные документированные процедуры, способствующие проведению в жизнь политики и ассоциированных регуляторов физической защиты.Физическая защита: авторизация физического доступа. В организации составляются и поддерживаются в актуальном состоянии списки сотрудников, имеющих доступ в помещения, в которых расположены компоненты информационной системы (кроме помещений, официально считающихся общедоступными), выпускаются соответствующие удостоверения (бэйджи, идентификационные карты, интеллектуальные карты); соответствующие должностные лица с заданной частотой пересматривают и утверждают списки и удостоверения.Физическая защита: управление физическим доступом. Необходимо контролировать точки физического доступа, в том числе официально определенные точки входа/выхода, в помещения, в которых расположены компоненты информационной системы (кроме помещений, официально считающихся общедоступными). Следует проверять предоставленные сотрудникам права, прежде чем разрешить им доступ. Кроме того, контролируется доступ в помещения, официально считающиеся общедоступными, в соответствии с проведенной оценкой рисков.Физическая защита: мониторинг физического доступа. Отслеживается физический доступ к системе с целью выявления и реагирования на нарушения.Физическая защита: контроль посетителей. Физический доступ к информационной системе контролируется аутентификацией посетителей перед разрешением войти в помещения, где расположены компоненты ИС (кроме помещений, официально считающихся общедоступными).Физическая защита: протоколирование доступа. В компании поддерживаются журналы посещений помещений (кроме тех, что официально считаются общедоступными), где фиксируются:

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



официальная документированная политика планирования бесперебойной работы, в которой представлены цель, охват, роли, обязанности, поддержка руководства, координация среди организационных структур и соответствие действующему законодательству;формальные документированные процедуры, способствующие проведению в жизнь политики и ассоциированных регуляторов планирования бесперебойной работы.Планирование бесперебойной работы: план обеспечения бесперебойной работы. Разрабатывается и реализуется план обеспечения бесперебойной работы информационной системы, в котором описываются роли, обязанности ответственных должностных лиц, указываются их контактные координаты. Кроме того, в плане прописываются действия, выполняемые при восстановлении ИС после повреждений и аварий. Соответствующие должностные лица пересматривают и утверждают этот план и доводят его до сведения сотрудников, ответственных за бесперебойную работу.Планирование бесперебойной работы: изменение плана обеспечения бесперебойной работы. С заданной частотой, но не реже одного раза в год, в организации пересматривается план обеспечения бесперебойной работы информационной системы, чтобы отразить изменения в структуре ИС или организации и/или устранить проблемы, выявленные при реализации, выполнении и/или тестировании плана. Планирование бесперебойной работы: резервное копирование. С заданной частотой проводится резервное копирование содержащихся в информационной системе пользовательских и системных данных (включая данные о состоянии ИС), резервные копии хранятся в местах, защищенных должным образом.Планирование бесперебойной работы: восстановление информационной системы. В организации применяются механизмы и поддерживающие процедуры, позволяющие восстановить информационную систему после повреждений или аварий.Управление конфигурацией: политика и процедуры. Разрабатываются, распространяются, периодически пересматриваются и изменяются:

официальная документированная политика управления конфигурацией, в которой представлены цель, охват, роли, обязанности, поддержка руководства, координация среди организационных структур и соответствие действующему законодательству;формальные документированные процедуры, способствующие проведению в жизнь политики и ассоциированных регуляторов управления конфигурацией.Управление конфигурацией: базовая конфигурация и опись компонентов информационной системы. В компании разрабатываются, документируются и поддерживаются актуальная базовая конфигурация информационной системы, опись компонентов ИС и соответствующие данные об их владельцах.Управление конфигурацией: настройки. В компании:



утверждаются обязательные настройки для продуктов информационных технологий, применяемых в ИС;устанавливаются настройки безопасности продуктов информационных технологий в наиболее ограничительный режим, совместимый с эксплуатационными требованиями;документируются настройки;обеспечиваются должные настройки всех компонентов информационной системы.Сопровождение: политика и процедуры. Разрабатываются, распространяются, периодически пересматриваются и изменяются:официальная документированная политика сопровождения, в которой представлены цель, охват, роли, обязанности, поддержка руководства, координация среди организационных структур и соответствие действующему законодательству;формальные документированные процедуры, способствующие проведению в жизнь политики и ассоциированных регуляторов сопровождения.Сопровождение: периодическое сопровождение. Планирование, осуществление и документирование повседневного, профилактического и регулярного сопровождения компонентов информационной системы в соответствии со спецификациями изготовителя или поставщика и/или организационными требованиями.Сопровождение: удаленное сопровождение. Организация санкционирует, контролирует и отслеживает удаленно осуществляемую деятельность по сопровождению и диагностике.Сопровождение: персонал сопровождения. Необходимо поддерживать список лиц, авторизованных для осуществления сопровождения информационной системы. Только авторизованный персонал осуществляет сопровождение ИС.Целостность систем и данных: политика и процедуры. Разработка, распространение, периодический пересмотр и изменение:

официальной документированной политики целостности систем и данных, в которой представлены цель, охват, роли, обязанности, поддержка руководства, координация среди организационных структур и соответствие действующему законодательству;формальных документированных процедур, способствующих проведению в жизнь политики и ассоциированных регуляторов целостности систем и данных.Целостность систем и данных: устранение дефектов. Идентификация дефектов информационной системы, информирование о них и исправление.Целостность систем и данных: защита от вредоносного программного обеспечения. В компании реализуется в информационной системе защита от вредоносного программного обеспечения, включая возможность автоматических обновлений.Целостность систем и данных: сигналы о нарушениях безопасности и сообщения о новых угрозах. Необходимо регулярно отслеживать сигналы о нарушениях безопасности и сообщения о новых угрозах для ИС, доводить их до сведения соответствующих должностных лиц и должным образом реагировать на них.Защита носителей: политика и процедуры. Разработка, распространение, периодический пересмотр и изменение:



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

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

официальной документированной политики реагирования на нарушения информационной безопасности, в которой представлены цель, охват, роли, обязанности, поддержка руководства, координация среди организационных структур и соответствие действующему законодательству;формальных документированных процедур, способствующих проведению в жизнь политики и ассоциированных регуляторов реагирования на нарушения информационной безопасности.Реагирование на нарушения информационной безопасности: реагирование. В компании формируются структуры для реагирования на нарушения информационной безопасности (группа реагирования), включая подготовку, выявление и анализ, локализацию, ликвидацию воздействия и восстановление после нарушений.Реагирование на нарушения информационной безопасности: доклады о нарушениях. Необходимо своевременно доводить информацию о нарушениях ИБ до сведения уполномоченных должностных лиц.Реагирование на нарушения информационной безопасности: помощь. Формирование структуры для выдачи рекомендаций и оказания помощи пользователям ИС при реагировании на нарушения ИБ и докладах о них; эта структура является неотъемлемой составной частью группы реагирования.Информирование и обучение: политика и процедуры. Разработка, распространение, периодический пересмотр и изменения:



официальной документированной политики информирования и обучения сотрудников, в которой представлены цель, охват, роли, обязанности, поддержка руководства, координация среди организационных структур и соответствие действующему законодательству;формальных документированных процедур, способствующих проведению в жизнь политики и ассоциированных регуляторов информирования и обучения сотрудников.Информирование и обучение: информирование о проблемах ИБ. Следует обеспечить, чтобы до всех пользователей, включая руководителей, доводилась основная информация по проблематике ИБ, прежде чем этим пользователям будет предоставлен доступ к ИС; подобное информирование должно продолжаться и дальше с заданной частотой, но не реже, чем раз в год.Информирование и обучение: обучение по проблематике ИБ. Необходимо определить должностных лиц, играющих важную роль и имеющих ответственные обязанности по обеспечению информационной безопасности ИС, документировать эти роли и обязанности и обеспечить соответствующее обучение указанных лиц, прежде чем предоставить им доступ к ИС. Подобное обучение должно продолжаться и дальше с заданной частотой.Информирование и обучение: документирование обучения по проблематике ИБ. В компании документируется и отслеживается ход обучения каждого сотрудника по проблематике ИБ, включая вводный курс и курсы, специфичные для ИС.Информирование и обучение: контакты с группами и ассоциациями информационной безопасности. Целесообразно установить и поддерживать контакты с группами, форумами и ассоциациями, специализирующимися в области информационной безопасности, чтобы быть в курсе современного состояния ИБ, передовых рекомендуемых защитных средств, методов и технологий.

На минимальном уровне информационной безопасности рекомендуется применение следующих программно-технических регуляторов безопасности.

Идентификация и аутентификация: политика и процедуры. Разработка, распространение, периодический пересмотр и изменения:

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



уникальной идентификации каждого пользователя;верификации идентификатора каждого пользователя; получения официальной санкции от уполномоченных должностных лиц на выпуск идентификатора пользователя;обеспечения выпуска идентификатора для нужного пользователя;прекращения действия идентификатора пользователя после заданного периода отсутствия активности;архивирования идентификаторов пользователей.Идентификация и аутентификация: управление аутентификаторами. Компания управляет аутентификаторами в информационной системе (токенами, сертификатами в инфраструктуре открытых ключей, биометрическими данными, паролями, ключевыми картами и т.п.) посредством:

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

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



об организационной принадлежности системы;о возможном мониторинге, протоколировании и аудите использования системы;о запрете и возможном наказании за несанкционированное использование системы;о согласии пользователя на мониторинг и протоколирование в случае использования системы; предупреждающее сообщение содержит соответствующие положения политики безопасности и остается на экране, пока пользователь не предпримет явных действий для входа в ИС.Управление доступом: надзор и просмотр. Организация надзирает и проверяет действия пользователей в отношении проведения в жизнь и использования имеющихся в ИС регуляторов доступа.Управление доступом: действия, разрешенные без идентификации и аутентификации. Определение конкретных действий пользователей, которые могут быть выполнены в информационной системе без идентификации и аутентификации.Управление доступом: удаленный доступ. Документирование, отслеживание и контроль всех видов удаленного доступа к ИС (например, через модемные входы или через Интернет), включая удаленный доступ для выполнения привилегированных действий; соответствующие должностные лица санкционируют применение каждого вида удаленного доступа и авторизуют для его применения только тех пользователей, которым он необходим.Управление доступом: ограничения на беспроводной доступ. Организация:

устанавливает ограничения на использование и руководит реализацией беспроводных технологий;документирует, отслеживает и контролирует беспроводной доступ к ИС; соответствующие должностные лица санкционируют применение беспроводных технологий.Управление доступом: персональные информационные системы. Ограничение применения персональных информационных систем для производственных нужд, включая обработку, хранение и передачу производственной информации.Протоколирование и аудит: политика и процедуры. Разработка, распространение, периодический пересмотр и изменения:

официальной документированной политики протоколирования и аудита, в которой представлены цель, охват, роли, обязанности, поддержка руководства, координация среди организационных структур и соответствие действующему законодательству;формальных документированных процедур, способствующих проведению в жизнь политики и ассоциированных регуляторов протоколирования и аудита.Протоколирование и аудит: протоколируемые события. Информационная система генерирует регистрационные записи для заданных событий.Протоколирование и аудит: содержимое регистрационных записей. Информационная система сохраняет в регистрационных записях достаточно информации, чтобы установить, какое событие произошло, что послужило источником события, каким оказался исход события.Протоколирование и аудит: ресурсы для хранения регистрационной информации. Необходимо выделять достаточный объем ресурсов для хранения регистрационной информации и конфигурировать протоколирование так, чтобы не допустить исчерпания этих ресурсов.Протоколирование и аудит: обработка регистрационной информации. В случае сбоя протоколирования или исчерпания ресурсов хранения регистрационной информации информационная система предупреждает соответствующих должностных лиц и предпринимает заданные дополнительные действия.Протоколирование и аудит: защита регистрационной информации. Информационная система защищает регистрационную информацию и средства протоколирования/аудита от несанкционированного доступа, модификации и удаления.Протоколирование и аудит: сохранение регистрационной информации. Следует сохранять регистрационную информацию в течение заданного времени, чтобы обеспечить поддержку расследований ранее произошедших нарушений информационной безопасности и выполнение требований действующего законодательства и организационных требований сохранения информации.Защита систем и коммуникаций: политика и процедуры. Разработка, распространение, периодический пересмотр и изменение:



официальной документированной политики защиты систем и коммуникаций, в которой представлены цель, охват, роли, обязанности, поддержка руководства, координация среди организационных структур и соответствие действующему законодательству;формальных документированных процедур, способствующих проведению в жизнь политики и ассоциированных регуляторов защиты систем и коммуникаций.Защита систем и коммуникаций: защита от атак на доступность. Информационная система защищает от атак на доступность заданных видов или ограничивает их воздействие.Защита систем и коммуникаций: защита границ. Информационная система отслеживает и контролирует коммуникации на своих внешних и ключевых внутренних границах ИС.Защита систем и коммуникаций: применение узаконенной криптографии. Если в информационной системе применяются криптографические средства, они должны удовлетворять требованиям действующего законодательства, технических регламентов, стандартов, руководящих и нормативных документов, отраслевых и организационных стандартов.Защита систем и коммуникаций: защита общедоступных систем. Информационная система обеспечивает целостность данных и приложений для общедоступных систем.


Лазерный диск с нулевым треком как средство защиты от копирования


, журнал CODE

Задумывались ли вы, почему нумерация треков лазерных дисков начинается с единицы, а не с нуля? Ведь говорят, чтобы отличить программиста от простого смертного достаточно дать ему команду "рассчитайсь!". Нормальный человек скажет "первый" (если он действительно первый) и будет по-своему прав. Программист же сначала уточнит в какой системе исчисления вести расчет (в двоичной, восьмеричной, шестнадцатеричной…) и затем, сделав шаг вперед, гордо скажет "нулевой". "Так ведь лазерные диски изначально разрабатывались для пользователей! – ответите вы. – А пользователи более привычны к натуральной, а не позиционной системе исчисления и потому первый трек должен быть именно первым, но никак не нулевым".

И все же, несмотря на всю убедительность своих доводов, вы будете не правы. Отсчет треков всякого диска начинается не с единицы, но с нуля. Да, нулевой номер зарезервирован за служебным треком (вводной областью диска) и его содержимое недоступно на интерфейсном уровне, но это ничего не меняет! Поле TNO (Track Number) Q-подканала Lead-In области диска равно нулю, следовательно, с точки зрения привода всякий диск начинается с трека номер ноль. Электронная начинка привода читает и адресует нулевой трек точно так же, как и любой другой трек диска, сохраняя тем самым прозрачность и упорядоченность принятой системы нумерации. С точки зрения системных программистов, разрабатывающих микропрограммные прошивки, отсчет треков всегда начинается с нуля. С точки же зрения пользователей привода – с единицы. Одним словом, и волки сыты и овцы целы!

Атрибуты нулевого трека отсутствуют в TOC, поскольку этот трек как раз и служит для хранения TOC. Давайте задумаемся, что произойдет, если одному из point'ов подлинного или фиктивного трека мы присвоим значение ноль, то есть, попросту говоря, создадим еще один нулевой трек в пользовательской области диска?

Если помимо внесения подложных данных в TOC мы еще и скорректируем содержимое Q-канала подкода, забив поле TNO нулями, то с точки зрения привода такой трек будет неотличим от вводной области диска и попытка его посекторного чтения будет обречена на провал (хотя некоторые приводы и не такое читают).
Субканальные данные нулевого трека теоретически должны быть доступны для чтения командами SEEK/READ SUBCHANNELL, но никаких гарантий на счет этого у нас нет, поскольку наличие двух подряд идущих Lead-In областей сильно нервирует привод, и его реакция становится совершенно непредсказуемой. Отказ от восстановления субканальных данных мало что меняет. Одно лишь наличие нулевого point'a в TOC'е – событие вполне неординарное и взаимно противоречивое.

Большинство приводов просто свихнутся и откажутся обрабатывать такой диск, совершенно непредсказуемым образом осуществляя чтение его оглавления. В частности, NEC при выполнении команды READ TOC возвращает ошибку, ASUS воспринимает нулевой трек как индикатор завершения TOC'а, а TEAC, столкнувшись с нулевым треком, начинает очень сильно нервничать и вместо атрибутов всех последующих треков выплевывает содержимое своих внутренних буферов вместе с мусором, оставшимся от TOC'а предыдущего диска. Короче говоря, нулевой трек делает лазерный диск практически полностью нечитабельным.

На этом, собственно, можно было бы и остановиться (кому нужна жутко конфликтная защита, работающая исключительно в лабораторных условиях и крайне нежизнеспособная на практике?!) если бы не одно "НО". Стремительное падение цены на оптические носители позволяет использовать лазерный диск не только для хранения полезной информации, но и в качестве своеобразного ключа.

Весь фокус в том, что наличие нулевого трека на диске никак не препятствует чтению субканальных данных спиральной дорожки, но подавляющее большинство копировщиков (включая Алкоголь и Clone CD) скорее зависнут, чем скопируют такой диск! Таким образом, алгоритм работы защитного механизма сводится к "ручному" чтению TOC'а командами SEEK/READ SUBCHANNEL с последующей проверкой его содержимого на предмет наличия нулевого трека.

И хотя ключевой диск не может содержать никаких других данных, кроме собственно самого проверяемого TOC'а, – это ли беда? В каком-то смысле это даже достоинство.


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

Если просто обнулить point первого трека, то Clone CD наотрез откажется открывать такой образ, ссылаясь на ошибку анализа. На самом деле этих ошибок по меньшей мере две. Первая – полная неосведомленность Clone CD о потенциальной возможности существования нулевых треков, коих он в упор не видит. Вторая – непростительный оптимизм, закладывающийся на тот факт, что каждая сессия должна содержать в себе по меньшей мере один трек (что в действительности вовсе не факт, а лишь допущение).

Алкоголик воспринимает сессию с единственным нулевым треком внутри более благодушно, корректно отображая его номер (см. листинг ниже), однако при попытке записи такого образа на диск, выпрыгивает "accessviolation" и копировщик наглухо повисает, даже не удосужившись аварийно завершить свою работу (см.


рис. 1). Вызов "Диспетчера программ" с последующим умерщвлением разбушевавшегося процесса не решает проблемы, т.к. лоток диска остается заблокированным и приходится прибегать к помощи утилиты CD.lock.exe для уменьшения счетчика блокировок на единицу.

Тип: Файл-образ CloneCD
Путь: L:\CD-hack\
Имя: IMAGE.CCD
IMAGE.img
IMAGE.sub
Размер: 8.81 MB
Сессий: 2
Треков: 2

Сессия 01:
Трек 00: Mode 1, Длина: 000000(0 Byte), Адрес: 000000
Сессия 02:
Трек 01: Mode 1, Длина: 000000(0 Byte), Адрес: 013458
Листинг 1 Алкоголик открывает образ защищенного диска вполне успешно, честно отображая нулевой номер первого трека, правда некорректно определяет его длину.



Рисунок 1 реакция Алкоголика на попытку записи образа диска с единственным нулевым треком внутри первой сессии

Постойте, но ведь это же… Это же настоящая золотая жила! Диск с единственным нулевым треком внутри первой сессии не то, что не копируется, он даже и не прожигается! Даже если хакер каким-то неизвестным науке способом снимет с защищенного диска правильный дамп, ему будет нечем этот дамп записать!!! Правда и разработчику защищаемого приложения ключевой диск нечем записать тоже… ну, разве что он отважится на разработку собственной программы "прожига". Естественно, изготовить штампованные CD с нулевым треков вообще не проблема, но этот путь доступен далеко не всем (индивидуальным программистам он недоступен точно).

Компромиссным вариантов защиты становится добавление в искажаемую сессию хотя бы единственного ненулевого трека. Такой диск может быть изготовлен с помощью того же Clone CD и корпеть над написанием собственной "прожигалки" в этом случае не надо, что есть плюс. Однако коль скоро для создания оригинального диска используется утилита массового распространения, процесс создания несанкционированных дубликатов значительно упрощается. Хакеру достаточно снять с диска корректный дамп, а все остальное – это забота Clone CD. Необходимость разрабатывать специализированный софт для взлома при этом отпадает.


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

Процесс подготовки защищенного диска не лишен определенных тонкостей. Создание фиктивного трека с нулевым номером не вызывает особых трудностей, но вот вопрос: где его разместить? В первой, а, может быть, лучше во второй сессии? До подлинного трека или после? Поскольку вводная область первой сессии недоступна для чтения на субканальном уровне, то прочитать TOC первой сессии вручную нельзя. Нельзя и закладываться на команду READ TOC, поскольку, как уже было сказано выше, ее корректное выполнение не гарантируется. Вводные области второй и всех последующих сессий свободно доступны на субканальном уровне и ручное чтение хранимого ими TOC'а все-таки возможно. Конкретная позиция нулевого трека внутри сессии особой роли не играет, и нулевой трек может быть с одинаковым успехом размещен как до ненулевого трека, так и после него.

Только, пожалуйста, не забывайте о необходимости коррекции point'а A0h, хранящего номер "первого" трека всякой сессии. Если его значение оставить без изменений, то образ диска запишется без каких-либо препирательств со стороны Clone CD, но никаких упоминаний о нулевом треке в TOC'е прожженного диска не окажется! Точно так же ведет себя и Алкоголь. Чтобы этого избежать, значение point'а A0h той сессии, к которой вы добавляете нулевой трек, должно быть сброшено в Zero.

Фрагмент отредактированного CCD-файла приведен ниже:

TocEntries=13TocEntries=14;корректируем количество входов в TOC
[Entry 8][Entry 8]; это вход не обязательно должен быть восьмым…
Session=2Session=2; …главное, чтобы Session == 2, а Point == A0h
Point=0xa0Point=0xa0; этот Point отвечает на номер первого трека
ADR=0x01ADR=0x01; это служебные поля ADR/Control, описывающие
Control=0x04Control=0x04; режим обработки трека (это трек с данными)
TrackNo=0TrackNo=0; TNO = 0 – это Lead-In область
AMin=0AMin=0; \
ASec=0ASec=0; +- условный текущий абсолютный адрес
AFrame=0AFrame=0; /
ALBA=-150ALBA=-150; условный текущий LBA-адрес
Zero=0Zero=0; это поле всегда равно нулю
PMin=2àPMin=0;корректируем номер "первого" трека
PSec=0PSec=0; эти поля не имеют никакого смысла и должны
PFrame=0PFrame=0; быть равны нулю
PLBA=8850PLBA=8850; LBA-"адрес" номера "первого" трека
[Entry 11];добавляем еще одно Entry, описывающее нулевой трек
Session=2; нулевой трек должен быть не в первой сессии
Point=0x00; номер трека - ноль
ADR=0x01; Sub-channel Q encodes current position data
Control=0x04; трек с данными
TrackNo=0; это Lead-In
AMin=0;\
ASec=0;  + - условный абсолютный адрес Lead-In
AFrame=0;/
ALBA=-150; условный LBA-адрес Lead-In
Zero=0; это поле должно быть равно нулю
PMin=3; \
PSec=1;  + - абсолютный стартовый адрес нулевого трека
PFrame=66; /
PLBA=13458; LBA-адрес нулевого трека
<


Листинг 2 фрагмент CCD-файла с добавленным нулевым треком

При просмотре геометрии защищенного таким образом диска Ahead Nero выдает приблизительно следующую информацию (см. рис. 2). То, что он посчитал вторую сессию открытой ("Session is open") вполне объяснимо, так как созданный нами нулевой трек был ошибочно принят Нероном за вводную область, в результате чего шаткое равновесие между вводными и выводными областями оказалось нарушенным. Между тем, вторая сессия диска все-таки закрыта, и анализ TOC подтверждает это. А не знать, что упоминание о вводных областях никогда в явном виде не присутствует в TOC'е – глупо. Разобраться, почему нулевой трек оказался приобщен Нероном к первой сессии, несколько сложнее. По видимому, это грубая алгоритмическая ошибка, которая не делает чести ни самому Нерону, ни его разработчикам.



Рисунок 2 наличие нулевого трека на диске срывает крышу Нерону, вводя его в глубокое заблуждение относительно состояния последней сессии диска. Нерон считает, что вторая сессии открыта, хотя на самом деле это не так.

Clone CD ведет себя аналогичным образом и при попытке копирования защищенного диска на приводах ASUS и TEAC со всего маху врезается в выводную область первой сессии диска. Вторая сессия (с нулевым треком) по причине грубых алгоритмических ошибок полностью выпадает из его поля зрения и в TOC'е скопированного диска о ней даже и не упоминается. Стартовый адрес выводной области первой сессии так же определяется неправильно (Clone CD устанавливает его на стартовый адрес нулевого трека второй сессии). Point'ы B0h (стартовый адрес следующей позиции для дозаписи) и C0h (стартовый адрес первой вводной области диска) тоже оказываются потерянными. Короче говоря, TOC скопированного диска более чем существенно отличается от TOC'а оригинального, и обнаружить факт несанкционированного копирования не составит никакого труда,. Д вы их сами сравните:

01 14 00 A0 00 00 00 00 01 00 00    01 14 00 A0 00 00 00 00 01 00 00
01 14 00 A1 00 00 00 00 01 00 00    01 14 00 A1 00 00 00 00 01 00 00
01 14 00 A2 00 00 00 00 00 1D 21    01 14 00 A2 00 00 00 00 03 01 42
01 14 00 01 00 00 00 00 00 02 00    01 14 00 01 00 00 00 00 00 02 00
01 54 00 B0 02 3B 21 03 16 0E 22
01 54 00 C0 A2 C8 E0 00 61 1B 15
02 14 00 A0 00 00 00 00 02 00 00
02 14 00 A1 00 00 00 00 00 00 00
02 14 00 A2 00 00 00 00 03 18 17
02 14 00 00 00 00 00 00 03 01 42
<


Листинг 3 TOC оригинального ключевого диска с нулевым треком внутри второй сессии (слева; атрибуты нулевого трека выделены серой заливкой) и TOC его копии, полученной с помощью Clone CD (справа). Все несовпадения выделены жирным шрифтом.

При попытке копирования защищенного диска на приводе NEC (который, как уже отмечалось, отказывается читать TOC с нулевым треком), Clone CD удивленно спрашивает "диск пуст?" и вне зависимости от нашего ответа даже не пытается приступить к его копированию, вызывая страшный хакерский гнев и раздражение.

Алкоголь при попытке копирования защищенного диска просто виснет, едва лишь успев перед смертью выбросить исключение "accessviolation", но зато заблокировав лоток привода так, что без уменьшения счетчика блокировок извлечь диск помогает разве что тотальная перезагрузка системы.

В общем, дело – мрак! (С точки зрения "пиратов", конечно). И мы по праву можем считать, что процедура создания некопируемого ключевого диска завершилась успешно. Теперь недурно бы разобраться: как с полученным диском вообще работать и каким именно образом защитный механизм сможет отличить копию от оригинала.

Первое, что приходит нам в голову – прочитать "сырой" TOC командой READ TOC и проверить наличие трека номер ноль, а для пущей надежности – и его атрибуты. Если нулевой трек действительно присутствует в TOC'е и его атрибуты (т. е. поля Session, ADR, Control, PMin:PSec:PFarme) полностью соответствуют эталону – это оригинальный диск и, соответственно, наоборот. Достоинство такого алгоритма в том, что он очень просто реализуется, укладываясь буквально в десяток строк кода, а недостаток – в нестабильности опознавания ключевого диска на определенных моделях приводов. Привод может отказаться читать TOC ? к такому повороту событий защита должна быть заранее готова. Давайте сделаем так: если команда READ TOC возвращает ошибку, но диск присутствует в приводе и не препятствует выполнению SEEK – это оригинальный диск. Конечно, подобное эвристическое допущение значительно ослабляет защиту, однако для большинства применений ее стойкости будет вполне достаточно.



Однако безошибочное выполнение команды READ CD еще не является свидетельством того, что она выполнена успешно. Ни один известный мне привод, способный читать TOC с нулевым треком, не читает его правильно, а потому защита должна заранее учитывать характер возможных искажений TOC'а и адекватно ему противостоять.

Рассмотрим, например, какой результат возвращает привод TEAC:

Номер сессии
  |      ADR/Control
  |   |      TNO
  |   |   |      Point
  |   |   |   |   |      AM:AS:AF  PM:PS:PF
  |   |   |   |   |   |   |   |   |   |   |
01 14 00 A0 00 00 00 00 01 00 00 ; point A0 - номер первого трека сессии 1 в PM
01 14 00 A1 00 00 00 00 01 00 00 ; point A1 - номер последнего трека сессии 1 в PM
01 14 00 A2 00 00 00 00 00 1D 21 ; point A2 - адрес Lead-out сессии 1 в PM:PS:PF
01 14 00 01 00 00 00 00 00 02 00 ; point 01 - стартовый адрес трека 1 в PM:PS:PF
01 54 00 B0 02 3B 21 03 16 0E 22 ; point B0 - позиция дозаписи в AM:AS:AF
01 54 00 C0 A2 C8 E0 00 61 1B 15 ; point C0 - стартовый адрес Lead-In в PM:PS:PF /искж
02 14 00 A0 00 00 00 00 02 00 00 ; point A0 - номер первого трека сессии 1 в PM
02 14 00 A1 00 00 00 00 00 00 00 ; point A1 - номер последнего трека сессии 2 в PM
02 14 00 A2 00 00 00 00 03 18 17 ; point A2 - адрес Lead-out сессии 2 в PM:PS:PF
02 14 00 00 00 00 00 00 03 01 42 ; point 00 - стартовый адрес трека 0 в PM:PS:PF
FB FD 00 FB F4 FB 7A FF FD FD FF ; \ | как видно, встретив нулевой трек, TEAC
FB DF 00 FA FD F5 FF BF FB FE FF ; + - мусор | вместо осмысленных данных начал изры-
FE F7 00 FB FF FD FB FF FF F7 FF ; / | гать мусор
<


Листинг 4 содержимое TOC' а ключевого диска, возращенное приводом TEAC, нулевой трек выделен серой заливкой, а мусор, следующий за ним – жирным шрифтом

Что это за подозрительный мусор, расположенный вслед за нулевым треком? Это – содержимое внутренних буферов привода, попавшее сюда в результате грубой программистской ошибке в микропрограмме привода (между прочим, тестировалась самая свежая на момент написания этих строк прошивка – 1.09). Небольшое расследование убедительно доказывает, что мусор носит не случайный характер и представляет собой "хвост" TOC'а предыдущего диска.

Давайте, вставив в привод какой-нибудь диск (например, "Soul Ballet Hit Collection"), сменим его на ключевой и посмотрим что у нас из этого получится:

01 10 00 A0 00 00 00 00 01 00 00     01 14 00 A0 00 00 00 00 01 00 00
01 10 00 A1 00 00 00 00 10 00 00     01 14 00 A1 00 00 00 00 01 00 00
01 10 00 A2 00 00 00 00 48 1C 05     01 14 00 A2 00 00 00 00 00 1D 21
01 10 00 01 00 00 00 00 00 02 00     01 14 00 01 00 00 00 00 00 03 00
01 10 00 02 00 00 00 00 03 35 40     01 54 00 B0 02 3B 21 03 16 0E 22
01 10 00 03 00 00 00 00 08 14 33     01 54 00 C0 A2 C8 E0 00 61 1B 15
01 10 00 04 00 00 00 00 0C 21 0D     02 14 00 A0 00 00 00 00 02 00 00
01 10 00 05 00 00 00 00 10 3A 2D     02 14 00 A1 00 00 00 00 00 00 00
01 10 00 06 00 00 00 00 16 23 19     02 14 00 A2 00 00 00 00 03 18 17
01 10 00 07 00 00 00 00 1C 1B 0C     02 14 00 00 00 00 00 00 03 01 42
01 10 00 08 00 00 00 00 21 07 49     09 25 00 1F 00 00 00 00 19 01 10
01 10 00 09 00 00 00 00 25 1F 19     0A 2A 00 01 00 00 00 00 06 01 10
01 10 00 0A 00 00 00 00 2A 01 06     0B 2D 00 2D 00 00 00 00 00 01 10
01 10 00 0B 00 00 00 00 2D 2D 00     0C 33 00 29 00 00 00 00 02 01 10
01 10 00 0C 00 00 00 00 33 29 02     0D 39 00 08 00 00 00 00 45 01 10
01 10 00 0D 00 00 00 00 39 08 45     0E 3F 00 1E 00 00 00 00 27 01 10
01 10 00 0E 00 00 00 00 3F 1E 27     0F 43 00 1E 00 00 00 00 29 01 10
01 10 00 0F 00 00 00 00 43 1E 29     10 44 00 03 00 00 00 00 15 FF FF
01 10 00 10 00 00 00 00 44 03 15
<


Листинг 5 TOC диска SoulBallet (слева) и TOC ключевого диска (справа), возвращенные приводом TEAC

Смотрите! Сейчас содержимое TOC' а ключевого диска существенно изменилось. Пускай не все содержимое, но вот хвост изменился точно. Причем последовательность байт "хвоста" ключевого диска соответствует последовательности байт диска "Soul Ballet". Пускай "…09 00 00 00 00 25 1F 19…" и "…09 25 00 1F 00 00 19…" и не совсем тождественные последовательности, но, если убрать паразитные нули, мы получим: "…09 25 1F 19…" и "…09 25 1F 19…", которые побайтно равны друг другу. Так что мы действительно имеем дело с ошибкой в прошивке, что не делает чести ни самому приводу, ни его разработчикам.

ASUS ведет себя более корректно, просто "обрубая" TOCпо нулевому треку, даже в том случае когда нулевой трек – не последний трек диска, что тоже расценивается как микропрограммная ошибка, пускай и не такая грубая.

01 14 00 A0 00 00 00 00 01 00 00
01 14 00 A1 00 00 00 00 01 00 00
01 14 00 A2 00 00 00 00 00 1D 21
01 14 00 01 00 00 00 00 00 03 00
01 54 00 B0 02 3B 21 03 16 0E 22
01 54 00 C0 A2 C8 E0 00 61 1B 15
02 14 00 A0 00 00 00 00 02 00 00
02 14 00 A1 00 00 00 00 00 00 00
02 14 00 A2 00 00 00 00 03 18 17
02 14 00 00 00 00 00 00 03 01 42
Листинг 6 TOC ключевого диска, возращенный приводом ASUS

NEC, как уже говорилось выше, вообще не выдает ничего, кроме ошибки, которую защитный механизм вынужден интерпретировать, как индикатор лицензионности диска, в противном случае разработчик может поплатиться своими яйцами, которые с удовольствием оторвут легальные пользователи, попытавшиеся "скормить" защищенный диск "неправильному" (с точки зрения защиты) приводу.

Тем не менее, преднамеренное ослабление стойкости защиты – не выход. Уж лучше попробовать прочитать TOC вручную. Это достаточно трудно реализуется на программном уровне, но еще труднее ломается! Если команду READ TOC легко и проэмулировать, то воссоздать особенности обработки субканальных данных практически нереально, благодаря чему усиленный вариант защиты с легкостью обойдет все копировщики, эмулирующие виртуальные диски.



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

Первое и главное: абсолютные адреса секторов ни коим образом не связаны с "соответствующими" им субканальными данными, хотя бы уже потому, что одна секция субканальных данных "размазана" по нескольким секторам, причем в силу определенных конструктивных особенностей обработка субканальных данных и данных основного потока осуществляется раздельно, благодаря чему при позиционировании головки на сектор X с последующим вызовом команды READ SUBCHANNEL мы получим субканальные данные не сектора X, а сектора Y, лежащего "поблизости" от сектора X. Понятие "поблизости" всякий производитель определяет самостоятельно, зачастую уползая не на одну сотню секторов вперед.

Второе: связка команд SEEK/READ SUBCHANNEL неустойчива и обладает хреновой воспроизводимостью результатов. Никто не гарантирует, что позиционирование на сектор X+k приведет к чтению субканальных данных сектора Y+k. Привод может возвратить как данные сектора Y, так и данные сектора Y+i. Также никто не гарантирует, что повторное позиционирование не сектор X приведет к чтению субканальных данных сектора Y. (кстати, не забывайте между двумя соседними вызовами командами SEEK выдерживать паузу хотя бы в 1 сек, иначе головка просто не успеет переместиться на новое место, и привод как ни в чем не бывало возвратит уже скэшированные субканальные данные с места предыдущего позиционирования). Остается опираться лишь на текущие адреса секторов, возвращаемые в самой субканальной информации (поле "Absolute CD Address"). Встретив в этом поле адрес "своего" сектора, мы можеь быть абсолютно уверенными в том, что эта субканальная информация принадлежит именно "нашему" сектору, а не какому-то сектору еще.





Листинг 7 правильная интерпретация субканальной информации

Третье: конкретный формат субканальной информации определяется не Стандартом, а самим приводом и значительно варьируется от одной модели к другой. Наиболее непостоянны в этом смысле вводные и выводные области диска. Стандарт вообще ничего не говорит о возможности их чтения на субканальном уровне, молчаливо полагая, что это никому на хрен не нужно. Вот производители и извращаются в меру своей распущенности и фантазий. Поля абсолютных и относительных адресов могут безо всяких предупреждений меняться местами, а сами адреса могут задаваться как в формате M:S:F, так и в LBA-форме. Значения point'ов A0h, A1h и A2h (номер первого трека, номер последнего трека и адрес Lead-Out области) могут замещаться значениями 64h, 65h и 66h соответственно. Наконец, нестандартные point'ы (в том числе и нулевые point'ы) в субканальных данных зачастую попросту отсутствуют – вместо этого возвращаются данные либо предыдущей, либо последующей секций!

Все это значительно усложняет интерпретацию субканальных данных и поиск в ней нулевых треков, поэтому приходится действовать так: последовательно читая субканальные данные различных секторов диска, дожидаемся того момента, когда номера треков сменяться сначала на AAh, а затем и на 00h, что будет соответствовать переходу головки с Lead-Out области первой сессии на Lead-In область второй сессий. Продолжая читать Lead-In, мы попытаемся определить в какой закономерности изменяются поля абсолютных и относительных адресов и форму их представления (LBA или M:S:F). Собственно, формат представления определить очень легко. Если младший байт адреса принимает значения больше, чем 75 (4Bh), – это, несомненно, LBA и наоборот. Далее – поскольку поля относительных адресов в вводной области диска используются для хранения атрибутов "своего" point'а, то они чрезвычайно сильно отличаются от текущих адресов секторов – тех, на которых и осуществлялось позиционирование. Напротив, поля абсолютных адресов к текущим адресам должны быть достаточно близки.



Остается решить последнюю проблему – что делать, если в субканальных данных Lead- In области нулевого трека попросту не окажется? Не спешите делать вывод о нелицензионности диска – ведь, как уже было сказано выше, некоторые приводы нестандартные point'ы просто не возвращают. При этом абсолютные адреса секторов, хранящих субканальные атрибуты нулевого трека, в считанном TOC'е не будут присутствовать! Копия диска, полученная любым из существующих на данный момент копировщиков, по данным абсолютным адресам будет содержать атрибуты совершенно других треков, которые привод вполне корректно прочитает и возвратит, либо же вовсе откажется позиционировать головку на эту область, выдавая ту или иную ошибку.

Ну что, парни, слабо реализовать такое? Для облегчения восприятия материала ниже будут приведены субканальные данные ключевого диска, возращенные различными приводами. А подробные комментарии, щедро разбросанные автором, помогут разобраться что к чему.

  +internal+  Format    
    |   | | | | ADR/Control
  |   | | | | | TNO
  |   | | | | | | Point
  |   | | | | | | | +- PLBA -+  +- ALBA -+
  |   | | | | | | | | | | | | | | |    
LBA - 10D4:00 15 00 0C 01 14 00 A0 00 00 22 92 00 00 11 6D ; LBA 10D4 а 116D
LBA - 10D5:00 15 00 0C 01 14 00 A0 00 00 22 92 00 00 11 6D ; LBA 10D5 а 116D
LBA - 10D6:00 15 00 0C 01 14 00 A0 00 00 22 92 00 00 11 6E ; LBA 10D5 а 116E
LBA - 10D7:00 15 00 0C 01 14 00 A0 00 00 22 92 00 00 11 6D ; LBA 10D7 а 116D (!)
LBA - 10D8:00 15 00 0C 01 14 00 A0 00 00 22 92 00 00 11 6E ; ("биение" головки)
LBA - 10D9:00 15 00 0C 01 14 00 A0 00 00 22 92 00 00 11 6E ; LBA 2292 = 02:00:00 M:S:F
LBA - 10DA:00 15 00 0C 01 14 00 A1 00 FF FF 6A 00 00 11 73 ; LBA FFh - 6Ah = 95h (149)
LBA - 10DB:00 15 00 0C 01 14 00 A1 00 FF FF 6A 00 00 11 73 ; LBA 149 == MSF 0:0:1
LBA - 10DC:00 15 00 0C 01 14 00 A1 00 FF FF 6A 00 00 11 74 ; что удивительно, т.к.
LBA - 10DD:00 15 00 0C 01 14 00 A1 00 FF FF 6A 00 00 11 75 ; последнего трека должен
LBA - 10DE:00 15 00 0C 01 14 00 A1 00 FF FF 6A 00 00 11 74 ; быть в PM, но не в PF
LBA - 10DF:00 15 00 0C 01 14 00 A1 00 FF FF 6A 00 00 11 74 ; учитывайте это!
LBA - 10E0:00 15 00 0C 01 14 00 A2 00 00 3B 45 00 00 11 79 ; продолжается биение го-
LBA - 10E1:00 15 00 0C 01 14 00 A2 00 00 3B 45 00 00 11 79 ; ловки: сектора идут не
LBA - 10E2:00 15 00 0C 01 14 00 A2 00 00 3B 45 00 00 11 7B ; упорядочено: 1179, 1179,
LBA - 10E3:00 15 00 0C 01 14 00 A2 00 00 3B 45 00 00 11 79 ; 117B, 1179, 117A, 117A и
LBA - 10E4:00 15 00 0C 01 14 00 A2 00 00 3B 45 00 00 11 7A ; нету секторов 1176, 1177
LBA - 10E5:00 15 00 0C 01 14 00 A2 00 00 3B 45 00 00 11 7A ; и 178
LBA - 10E6:00 15 00 0C 01 14 00 02 00 00 34 92 00 00 11 80 ;  
LBA - 10E7:00 15 00 0C 01 14 00 02 00 00 34 92 00 00 11 80 ;  
LBA - 10E8:00 15 00 0C 01 14 00 02 00 00 34 92 00 00 11 80 ; биение головки
LBA - 10E9:00 15 00 0C 01 14 00 02 00 00 34 92 00 00 11 7F ; продолжается
LBA - 10EA:00 15 00 0C 01 14 00 02 00 00 34 92 00 00 11 80 ;  
LBA - 10EB:00 15 00 0C 01 14 00 02 00 00 34 92 00 00 11 81 ;  
LBA - 10EC:00 15 00 0C 01 14 00 00 00 00 34 B3 00 00 11 85 ; а вот и нулевой трек, он
LBA - 10ED:00 15 00 0C 01 14 00 00 00 00 34 B3 00 00 11 85 ; располагается в секторах
LBA - 10EE:00 15 00 0C 01 14 00 00 00 00 34 B3 00 00 11 86 ; 1185 и 1186 - запомним
LBA - 10EF:00 15 00 0C 01 14 00 00 00 00 34 B3 00 00 11 85 ; это обстоятельство!
LBA - 10F0:00 15 00 0C 01 14 00 A0 00 00 22 92 00 00 11 8C ; point A0 повторяется…
LBA - 10F1:00 15 00 0C 01 14 00 A0 00 00 22 92 00 00 11 8C ; а вместе с ним и все
LBA - 10F2:00 15 00 0C 01 14 00 A0 00 00 22 92 00 00 11 8B ; остальные point'ы. Читая
LBA - 10F3:00 15 00 0C 01 14 00 A0 00 00 22 92 00 00 11 8B ; субканальные данные даль-
LBA - 10F4:00 15 00 0C 01 14 00 A0 00 00 22 92 00 00 11 8C ; ше мы вновь встретим ну-
LBA - 10F5:00 15 00 0C 01 14 00 A0 00 00 22 92 00 00 11 8B ; левой трек, но уже в дру-
LBA - 10F6:00 15 00 0C 01 14 00 A0 00 00 22 92 00 00 11 8B ; гих секторах. Запомним и
LBA - 10F7:00 15 00 0C 01 14 00 A0 00 00 22 92 00 00 11 8B ; из для надежности
<


Листинг 8 результат чтения субканальной информации из Lead-In на приводе TEAC; отчетливо просматривается нулевой трек

Здесь абсолютные адреса представлены в LBA-форме, причем расхождение между адресом, на который осуществляется позиционирование головки, и адресом, чьи субканальные данные при этом читаются (далее по тексту – дельта) составляет порядка 400 секторов. Правда, равномерность "часового хода" очень хороша, абсолютные идут кучным пучком строго социалистического характера, хотя TEAC все-таки не без греха, и оплошности типа 11:6D, 11:6E, 11:6D, 11:6E случаются сплошь и рядом. Атрибуты нулевого трека присутствуют в явном виде, что не может не радовать.

А вот привод ASUS ведет себя более разболтанно:

  +internal+  Format    
    |   | | | | ADR/Control
  |   | | | | | TNO
  |   | | | | | | Point
  |   | | | | | | | +- PLBA -+  +- ALBA -+
  |   | | | | | | | | | | | | | | |    
LBA - 10D3:00 15 00 0C 01 14 00 A0 00 00 22 92 00 00 11 6F ; здесь субканальные данные
LBA - 10D4:00 15 00 0C 01 14 00 A1 00 FF FF 6A 00 00 11 73 ; возвращаются еще более
LBA - 10D5:00 15 00 0C 01 14 00 A1 00 FF FF 6A 00 00 11 73 ; беспорядочно, и потому
LBA - 10D6:00 15 00 0C 01 14 00 A1 00 FF FF 6A 00 00 11 73 ; отделить соседние point'ы
LBA - 10D7:00 15 00 0C 01 14 00 A1 00 FF FF 6A 00 00 11 73 ; друг от друга уже не
LBA - 10D8:00 15 00 0C 01 14 00 A0 00 00 22 92 00 00 11 6F ; удается, между тем они
LBA - 10D9:00 15 00 0C 01 14 00 A0 00 00 22 92 00 00 11 6F ; лежат по тем же самым
LBA - 10DA:00 15 00 0C 01 14 00 A0 00 00 22 92 00 00 11 6F ; ALBA адресам, что и в
LBA - 10DB:00 15 00 0C 01 14 00 A0 00 00 22 92 00 00 11 6F ; предыдущем случае, а
LBA - 10DC:00 15 00 0C 01 14 00 A1 00 FF FF 6A 00 00 11 73 ; потому, ALBA адреса могут
LBA - 10DD:00 15 00 0C 01 14 00 A0 00 00 22 92 00 00 11 6F ; служить надежной опорой
LBA - 10DE:00 15 00 0C 01 14 00 A1 00 FF FF 6A 00 00 11 73 ; в идентификации point'ов
LBA - 10DF:00 15 00 0C 01 14 00 A1 00 FF FF 6A 00 00 11 73 ; не зависящей от настро-
LBA - 10E0:00 15 00 0C 01 14 00 A2 00 00 3B 45 00 00 11 79 ; ения, разболтанности
LBA - 10E1:00 15 00 0C 01 14 00 A2 00 00 3B 45 00 00 11 79 ; и конструктивных особен-
LBA - 10E2:00 15 00 0C 01 14 00 A2 00 00 3B 45 00 00 11 79 ; ностей конкретных моделей
LBA - 10E3:00 15 00 0C 01 14 00 A1 00 FF FF 6A 00 00 11 75 ; приводов, что значительно
LBA - 10E4:00 15 00 0C 01 14 00 A2 00 00 3B 45 00 00 11 7A ; упрощает процедуру про-
LBA - 10E5:00 15 00 0C 01 14 00 A1 00 FF FF 6A 00 00 11 75 ; верки степени лицензион-
LBA - 10E6:00 15 00 0C 01 14 00 02 00 00 34 92 00 00 11 80 ; ной "чистоты" анализиру-
LBA - 10E7:00 15 00 0C 01 14 00 02 00 00 34 92 00 00 11 81 ; емого диска…
LBA - 10E8:00 15 00 0C 01 14 00 A1 00 FF FF 6A 00 00 11 75    
LBA - 10E9:00 15 00 0C 01 14 00 A2 00 00 3B 45 00 00 11 7B    
LBA - 10EA:00 15 00 0C 01 14 00 00 00 00 34 B3 00 00 11 85 ; атрибуты трека 0, обрати-
LBA - 10EB:00 15 00 0C 01 14 00 02 00 00 34 92 00 00 11 81    
LBA - 10EC:00 15 00 0C 01 14 00 A2 00 00 3B 45 00 00 11 7B    
LBA - 10ED:00 15 00 0C 01 14 00 00 00 00 34 B3 00 00 11 85 ; те внимание, что они рас-
LBA - 10EE:00 15 00 0C 01 14 00 02 00 00 34 92 00 00 11 81    
LBA - 10EF:00 15 00 0C 01 14 00 00 00 00 34 B3 00 00 11 86 ; полгаются по тем же LBA
LBA - 10F0:00 15 00 0C 01 14 00 A0 00 00 22 92 00 00 11 8B    
LBA - 10F1:00 15 00 0C 01 14 00 00 00 00 34 B3 00 00 11 85 ; адресам: 1185h и 1186!
LBA - 10F2:00 15 00 0C 01 14 00 A0 00 00 22 92 00 00 11 8B    
<


Листинг 9 результат чтения субканальной информации из Lead-In на приводе ASUS

Здесь: абсолютные адреса так же представлены в формате LBA и дельта составляет все те же 400 секторов, однако степень неупорядоченности возвращаемой информации значительно выше и номера секторов начинают потихонечку "плясать" (см. поле ALBA).

  +internal+  Format    
    |   | | | | ADR/Control
  |   | | | | | TNO
  |   | | | | | | Point
  |   | | | | | | | +- PLBA -+  +- ALBA -+
  |   | | | | | | | | | | | | | | |    
LBA - 1171:00 15 00 0C 01 14 00 64 00 00 11 6E 00 02 00 00 ; point 64 - это на самом
LBA - 1172:00 15 00 0C 01 14 00 64 00 00 11 6E 00 02 00 00 ; деле point A0 (номер пер-
LBA - 1173:00 15 00 0C 01 14 00 64 00 00 11 6E 00 02 00 00 ; вого трека), просто глу-
LBA - 1174:00 15 00 0C 01 14 00 64 00 00 11 6E 00 02 00 00 ; пый привод так нелепо его
LBA - 1175:00 15 00 0C 01 14 00 64 00 00 11 6E 00 02 00 00 ; исказил, так же обратите
LBA - 1176:00 15 00 0C 01 14 00 64 00 00 11 6E 00 02 00 00 ; внимание, что все адреса
LBA - 1177:00 15 00 0C 01 14 00 64 00 00 11 6E 00 02 00 00 ; идут к сектору 116E!
LBA - 1178:00 15 00 0C 01 14 00 65 00 00 11 74 00 00 00 00 ; резкий переход адресов
LBA - 1179:00 15 00 0C 01 14 00 64 00 00 11 6E 00 02 00 00 ; с 116E на 1174 (+6)
LBA - 117A:00 15 00 0C 01 14 00 65 00 00 11 74 00 00 00 00 ; такова дискретность SEEKа
LBA - 117B:00 15 00 0C 01 14 00 65 00 00 11 74 00 00 00 00 ; привода NEC!
LBA - 117C:00 15 00 0C 01 14 00 65 00 00 11 74 00 00 00 00    
LBA - 117D:00 15 00 0C 01 14 00 65 00 00 11 74 00 00 00 00    
LBA - 117E:00 15 00 0C 01 14 00 65 00 00 11 74 00 00 00 00    
LBA - 117F:00 15 00 0C 01 14 00 65 00 00 11 74 00 00 00 00    
LBA - 1180:00 15 00 0C 01 14 00 65 00 00 11 74 00 00 00 00    
LBA - 1181:00 15 00 0C 01 14 00 66 00 00 11 7A 00 00 3B 45    
LBA - 1182:00 15 00 0C 01 14 00 66 00 00 11 7A 00 00 3B 45    
LBA - 1183:00 15 00 0C 01 14 00 02 00 00 11 7F 00 00 34 92 ; 117F - …
LBA - 1184:00 15 00 0C 01 14 00 66 00 00 11 7A 00 00 3B 45    
LBA - 1185:00 15 00 0C 01 14 00 66 00 00 11 7A 00 00 3B 45    
LBA - 1186:00 15 00 0C 01 14 00 66 00 00 11 7A 00 00 3B 45    
LBA - 1187:00 15 00 0C 01 14 00 02 00 00 11 81 00 00 34 92 ; 117F - 1181 диапазон
LBA - 1188:00 15 00 0C 01 14 00 02 00 00 11 7F 00 00 34 92 ; адресов, занятых субка-
LBA - 1189:00 15 00 0C 01 14 00 02 00 00 11 7F 00 00 34 92 ; нальной информацией
LBA - 118A:00 15 00 0C 01 14 00 02 00 00 11 81 00 00 34 92 ; point'a == 2
LBA - 118B:00 15 00 0C 01 14 00 02 00 00 11 80 00 00 34 92    
LBA - 118C:00 15 00 0C 01 14 00 02 00 00 11 81 00 00 34 92    
LBA - 118D:00 15 00 0C 01 14 00 66 00 00 11 7A 00 00 3B 45    
LBA - 118E:00 15 00 0C 01 14 00 64 00 00 11 8B 00 02 00 00 ; смотрите! резкий переход
LBA - 118F:00 15 00 0C 01 14 00 64 00 00 11 8B 00 02 00 00 ; с адреса 1181 на адрес
LBA - 1190:00 15 00 0C 01 14 00 64 00 00 11 8B 00 02 00 00 ; 118B - 10 секторов пропу-
LBA - 1191:00 15 00 0C 01 14 00 64 00 00 11 8B 00 02 00 00 ; щено, причем это не про-
LBA - 1192:00 15 00 0C 01 14 00 64 00 00 11 8B 00 02 00 00 ; сто биение головки - этих
LBA - 1193:00 15 00 0C 01 14 00 64 00 00 11 8D 00 02 00 00 ; секторов в субканальных
LBA - 1194:00 15 00 0C 01 14 00 64 00 00 11 8D 00 02 00 00 ; данных нет вообще! И как
LBA - 1195:00 15 00 0C 01 14 00 64 00 00 11 8B 00 02 00 00 ; раз в них и содержатся
LBA - 1196:00 15 00 0C 01 14 00 65 00 00 11 92 00 00 00 00 ; атрибуты трека ноль, а
LBA - 1197:00 15 00 0C 01 14 00 65 00 00 11 92 00 00 00 00 ; раз так, то трек ноль все
LBA - 1198:00 15 00 0C 01 14 00 65 00 00 11 92 00 00 00 00 ; таки есть на диске (иначе
LBA - 1199:00 15 00 0C 01 14 00 65 00 00 11 92 00 00 00 00 ; бы эти сектора возращ.)
<


Листинг 10 результат чтения субканальной информации из Lead-In приводом NEC

Здесь: дельта "уползания" составляет порядка 10 секторов, а зачастую даже менее того, однако сама упорядоченность секторов вообще никакая, а нулевых point'ов вообще нет. Сектора с адресами 1185h и 1186h (в которых, собственно, и хранятся атрибуты нулевых треков) внаглую отсутствуют – вместо этого привод спозиционировал головку на адреса 118Bh и 118Dh, в результате чего количество 64hpoint'ов (в "девичестве" – A0h) до неприличия возросло. Ко всему прочему абсолютные адреса секторов по непонятной причине перекочевали в поле относительных адресов, и если бы мы попытались проанализировать субканальную информацию согласно Стандарту, у нашей защиты точно бы съехала крыша.

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

А вот со взломом у нас туго. Да, в принципе, такой диск можно скопировать, но только не Сlone CD или Алкоголем и не на всех моделях приводах. Для взлома пригодны лишь те приводы, что уверенно читают TOC и возвращают атрибуты нестандартных point'ов, поскольку ко всему этому может привязываться защита. "Постойте! – воскликните вы, – но ведь защита не должна закладываться на доступность TOC'а и атрибуты нулевого point'а, иначе программа окажется неработоспособна на некоторых моделях приводов! " Это верно, однако, если привод соглашается читать TOC, – отчего же его не проверить?

Если привод взломщика не позволяет читать содержимое TOC, взломщик не сможет восстановить оригинальный TOC (ну разве что отдизассемблирует весь защитный механизм целиком) и потому скопированный диск будет работать лишь на его приводе!

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


Достаточно лишь, считав TOC (команда READ TOC), считать и само содержимое диска на субканальном уровне (команды SEEK/READ SUBCHANNEL), а также содержимое основного канала (команда READ CD), после чего остается лишь сформировать CCD-, -IMG- и SUB-файлы и с помощью того же Clone CD записать их на диск. Однако такой взлом по зубам далеко не всякому хакеру, а с натиском желторотых пользователей эта защита без труда справится.

document.write('');

This Web server launched on February 24, 1997

Copyright © 1997-2000 CIT, © 2001-2009
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав.
Уникальное предложение на сайте - от института.

<

Альтернативы


В качестве альтернатив помещению сервисов в CE мне видится только разнос сервисов по разным физическим машинам или виртуализация, т.е. организация на одном физическом сервере нескольких виртуальных посредством серверных решений компаний VMware, SWsoft и аналогов. В Linux существует хорошее средство виртуализации - vserver, позволяющее размещать на одном компьютере несколько систем, объединенных лишь общим ядром. Правда, оба эти метода связаны с большими накладными расходами, поэтому в ряде случаев более оправдано использовать chrooted environment, если нет возможности нарастить оборудование.



Автоматизация


Еще раз хотелось бы заострить внимание на автоматизации процесса: сисадмины, пишите скрипты! Не забывайте про китайский принцип "три года упорного труда - десять тысяч лет счастья" (c) Мао Цзе-дун.

Если серьезно, то на каждый сервис вам понадобится 3 скрипта - для начального развертывания CE, для его аккуратного апгрейда без убийства хранящихся там данных и конфигов, и скрипт запуска/остановки. Так вы сможете поддерживать сервис в актуальном состоянии - обновляете в основной системе пакет с искомым сервисом, запускаете скрипт апгрейда выбранного CE и остается только заново его запустить.

В качестве конкретного примера приведу пример стартового скрипта для Apache в CE (продолжая начатую тему веб-сервера в CE): #!/bin/sh # start/stop/restart chrooted Apache web server # Den aka Diesel <diesel@sherdart.net>

PREFIX=/chroot/httpd APACHE_PREFIX=/usr MYSQL_SOCK=/var/run/mysql/mysql.sock

# если вы хотите использовать каталоги ~/public_html в CE, установите # HOMES_BIND=1 # и постоянно синхронизируйте $PREFIX/etc/passwd с основной системой

HOMES_BIND=0

httpd_start() { if [ -x $PREFIX/$APACHE_PREFIX/sbin/httpd ]; then echo "Starting Apache web server in the chroot environment..."

if [ HOMES_BIND = 1 ]; then mount --bind /home $PREFIX/home fi if [ -e $MYSQL_SOCK ]; then ln $MYSQL_SOCK $PREFIX$MYSQL_SOCK fi if ! `/usr/sbin/chroot $PREFIX $APACHE_PREFIX/sbin/httpd` ; then echo "ERROR" httpd_stop fi fi }

httpd_stop() { killall httpd if [ HOMES_BIND = 1 ]; then umount $PREFIX/home fi if [ -e $PREFIX/$MYSQL_SOCK ]; then rm -f $PREFIX/$MYSQL_SOCK fi }

httpd_restart() { httpd_stop sleep 1 httpd_start }

case "$1" in 'start') httpd_start ;; 'stop') httpd_stop ;; 'restart') httpd_restart ;; *) echo "usage $0 start|stop|restart" esac



Базовые принципы


Итак, приступим к детальному разбору того, как этот метод работает. Сразу необходимо отметить, что делать системный вызов chroot() может только root. Это обусловлено рядом факторов - в частности, злоумышленник мог бы, имея только пользовательские привилегии, обмануть setuid программу, поместив ее в специально подготовленный CE с подтасованным passwd файлом, что позволило бы ему поднять привилегии.

Основные проблемы при создании chrooted среды создает именно тот факт, что приложение "не видит" никаких файлов за рамками своего корневого каталога. В общем - сильная сторона оказывается одновременно и слабой, как это часто бывает в этой жизни. Из этого обстоятельства вытекает тот факт, что если для нормальной работы программы нужны какие-то библиотеки и дополнительные файлы - их придется скопировать внутрь CE. Если с библиотеками вопрос в ряде случаев можно решить, статически слинковав искомое приложение и получить его в виде одного большого бинарного файла, то с остальными файлами этот трюк не пройдет. Для того, чтобы создать оптимальную изолированную "камеру" для сервиса, мы должны достаточно хорошо знать его внутреннее устройство, чтобы скопировать все нужное, не прихватив при этом в CE лишнего, т.к. жесткие диски у вас наверняка не бесконечного объема. Частично эту проблему помогают решить инструменты, входящие практически в любой современный дистрибутив Linux.



Что это такое?


Данная статья посвящена одному из приемов усиления безопасности функционирования сервисов в Linux системах - помещению их в chrooted environment (далее - "CE"). CE - это, по сути, такое программное окружение, в котором приложение считает корневым каталогом какой-то отдельный (с точки зрения основной системы) каталог.

Термин "chrooted environment" происходит от имени системного вызова chroot() и соответствующей утилиты chroot, которая производит запуск программы, имя которой передается ей в качестве аргумента, в таком окружении с измененным корневым каталогом, путь к которому также передается в качестве аргумента. Программа, запущенная в CE, ограничена в доступе к файловой системе его рамками. Во FreeBSD существует подобный подход к изоляции программ - jail (тюрьма), что более образно описывает ее назначение - целевое приложение оказывается в программной "тюрьме", из которой достаточно проблематично выбраться. Широко распространенным примером CE являются FTP-сервера, большинство из которых по умолчанию работают с chroot - клиент, зашедший на сервер, не может увидеть файлы выше каталога, назначенного администратором в качестве корневого.



Доступ до части основной файловой системы


Полная изоляция - это хорошо, но не всегда то, что надо. Пример из жизни: у пользователей на сервере есть свои веб-страницы, лежащие в ~/public_html, и адресуемые http://site/~user/. Как быть с ними, если веб-сервер в CE? Копировать пользовательские файлы - абсурд. Снова воспользоваться жесткими ссылками будет чрезвычайно неудобно при большом количестве файлов и, ко всему же, жесткие ссылки не работают для каталогов. Есть идея лучше: воспользоваться возможностью монтировать каталог в каталог (mount с опцией --bind). Т.е. мы просто при старте веб-сервера монтируем /home в /chroot/httpd/home, например, а при остановке - размонтируем. Однако здесь есть крупный подводный камень, из-за которого я и рекомендую все время размонтировать такие каталоги после остановки сервиса - на этапе настройки вы наверняка не с первого раза создадите работающее CE, и, возможно, будете несколько раз стирать /chroot/service - и не дай Бог в этот момент не отмонтировать оттуда каталоги - вы уже наверняка догадались, что произойдет в этом случае - нужные файлы отправятся прямиком в /dev/null.



Инструментарий


Вот они, наши основные помощники по помещению приложения в "тюрьму":

chroot - основная утилита, описанная выше, делает системный вызов chroot() chrootuid - функционально отличается от просто chroot лишь тем, что может еще и менять UID процесса посредствов setuid() - эта утилита может быть полезной, если вы хотите, чтобы сервис работал не от root, а его авторы не предусмотрели такой возможности (может отсутствовать в вашем дистрибутиве) ldd - выводит информацию о зависимостях от общедоступных (shared) библиотек strace - позволяет отслеживать системные вызовы и сигналы, чрезвычайно мощная утилита практический опыт - чем больше, тем лучше

Если помещенное в CE приложение не работает или работает не так, как нужно, то алгоритм отладки такой:

с помощью ldd выясняем, какие из библиотек требуются, и копируем их в CE (естественно, сохраняя структуру каталогов) внимательно смотрим вывод программы и лог-файлы - часто запускаемый сервис сам говорит, что ему не хватает для работы анализируем лог-файлы сервиса, лежащие уже внутри CE (если таковые имеются) запускаем программу через strace и сохраняем вывод STDOUT в файл для дальнейшего анализа: strace chroot /chroot/service /path/to/service 2> ./strace.log

проверяем права доступа на файлы и каталоги внутри CE в случае неудачи - пытаемся еще раз пройтись по этой цепочке, думаем, советуемся со знакомым гуру, идем гуглить и совершаем прочие эзотерические действия.

Помимо уже упомянутых утилит, существуют и более продвинутые инструментальные решения по созданию CE, например - jailkit (работающий, кстати, не только на Linux, но и на FreeBSD, OpenBSD и MacOSX). Однако, по сути, этот пакет лишь делает за вас часть рутины, в любом случае пригодится знание того, как собрать CE руками.

Еще один практический совет - автоматизируйте свой труд, создавайте shell-скрипты генерации CE, постепенно дописывая их по ходу мигрирования сервиса в CE - тем самым вы избавите себя от ненужной механической работы и снизите вероятность ошибки.



Практический пример: Apache


Наверное, один из наиболее часто помещаемых в CE сервисов - веб-сервер Apache. Про это много написано и под разными углами, но я все же рискну повториться. Рассмотрим пошагово перенос в CE программной связки Apache 1.3.x + PHP 5 с учетом взаимодействия с СУБД MySQL (классический комплекс, именуемый в народе "LAMP" - Linux + Apache + MySQL + PHP). В примере предполагается, что мы имеем дело с дистрибутивной сборкой Apache в Slackware (для вашей системы файлы могут быть расположены немного по-другому, но принцип должен быть понятен).

Вот скрипт для автоматизированного создания CE: #!/bin/sh # create chrooted environment for Apache 1.3 + PHP 5 # Den aka Diesel <diesel@sherdart.net>

PREFIX=/chroot/httpd APACHE_PREFIX=/usr PHP_PREFIX=/usr APACHE_DATADIR=/var/www

# создаем структуру каталогов:

mkdir -p $PREFIX mkdir -p $PREFIX/dev mkdir -p $PREFIX/etc mkdir -p $PREFIX/lib mkdir -p $PREFIX/tmp mkdir -p $PREFIX/var/cache/proxy mkdir -p $PREFIX/var/run mkdir -p $PREFIX/$APACHE_PREFIX/bin mkdir -p $PREFIX/$APACHE_PREFIX/lib mkdir -p $PREFIX/$APACHE_PREFIX/sbin mkdir -p $PREFIX/$APACHE_PREFIX/libexec mkdir -p $PREFIX/var/log/apache mkdir -p $PREFIX/var/run/mysql mkdir -p $PREFIX/$PHP_PREFIX/lib/php mkdir -p $PREFIX/home

# выставляем 'sticky bit' на /tmp:

chmod 1777 $PREFIX/tmp

# создаем файл устройства /dev/null:

mknod $PREFIX/dev/null c 1 3 chmod 666 $PREFIX/dev/null chown root:sys $PREFIX/dev/null

# копируем конфигурационные файлы:

cat /etc/group|egrep "apache:|nobody:|nogroup:" > $PREFIX/etc/group cat /etc/passwd|egrep "apache:|nobody:" > $PREFIX/etc/passwd cat /etc/shadow|egrep "apache:|nobody:" > $PREFIX/etc/shadow chmod 640 $PREFIX/etc/shadow cp /etc/HOSTNAME $PREFIX/etc cp /etc/host.conf $PREFIX/etc cp /etc/hosts $PREFIX/etc cp /etc/nsswitch.conf $PREFIX/etc cp /etc/resolv.conf $PREFIX/etc cp /etc/localtime $PREFIX/etc cp -R /etc/apache $PREFIX/etc

# копируем данные и лог-файлы:

cp -R $APACHE_DATADIR $PREFIX`dirname $APACHE_DATADIR` cp -R /var/log/apache $PREFIX/var/log


# копируем бинарные файлы:

cp $APACHE_PREFIX/bin/htdigest $PREFIX/$APACHE_PREFIX/bin cp $APACHE_PREFIX/bin/mm-config $PREFIX/$APACHE_PREFIX/bin cp $APACHE_PREFIX/bin/htpasswd $PREFIX/$APACHE_PREFIX/bin cp $APACHE_PREFIX/bin/checkgid $PREFIX/$APACHE_PREFIX/bin cp $APACHE_PREFIX/bin/dbmmanage $PREFIX/$APACHE_PREFIX/bin cp $APACHE_PREFIX/sbin/ab $PREFIX/$APACHE_PREFIX/sbin cp $APACHE_PREFIX/sbin/apxs $PREFIX/$APACHE_PREFIX/sbin cp $APACHE_PREFIX/sbin/httpd $PREFIX/$APACHE_PREFIX/sbin cp $APACHE_PREFIX/sbin/logresolve $PREFIX/$APACHE_PREFIX/sbin cp $APACHE_PREFIX/sbin/rotatelogs $PREFIX/$APACHE_PREFIX/sbin cp $APACHE_PREFIX/sbin/apachectl-standard $PREFIX/$APACHE_PREFIX/sbin cp $APACHE_PREFIX/sbin/apacheconfig $PREFIX/$APACHE_PREFIX/sbin cp -R $APACHE_PREFIX/libexec/apache $PREFIX/$APACHE_PREFIX/libexec

# копируем библиотеки:

for BINARY in "$APACHE_PREFIX/sbin/httpd $APACHE_PREFIX/libexec/apache/libphp5.so $APACHE_PREFIX/lib/php/extensions/mysql.so"; do for i in `ldd $BINARY|awk '{print $3}'`; do d=$(dirname $i) if [[ $d != .* ]]; then mkdir -p $PREFIX$d; fi if [[ $d != .* ]]; then cp $i $PREFIX$d; fi done done cp -d /lib/libnss_compat* $PREFIX/lib cp -d /lib/libnss_dns* $PREFIX/lib cp -d /lib/ld-* $PREFIX/lib cp -d /lib/libnsl* $PREFIX/lib cp -R -d /usr/lib/gconv $PREFIX/usr/lib cp -R $PHP_PREFIX/lib/php $PREFIX/$PHP_PREFIX/lib cp -d -R /usr/lib/locale/en_GB $PREFIX/usr/lib/locale cp -d -R /usr/lib/locale/en_GB.utf8 $PREFIX/usr/lib/locale cp -d -R /usr/lib/locale/ru_RU $PREFIX/usr/lib/locale cp -d -R /usr/lib/locale/ru_RU.koi8r $PREFIX/usr/lib/locale cp -d -R /usr/lib/locale/ru_RU.utf8 $PREFIX/usr/lib/locale

Обратите внимание на несколько моментов:

из /etc/passwd мы взяли только записи про apache, nobody, nogroup (не стоит подвергать информацию о других учетных записях опасности быть украденой при взломе этого конкретного сервиса, исключение составляет только ситуация с использованием ~/public_html/) не забывайте про /etc/localtime, если хотите, чтобы сервис жил с вами в одной временной зоне по-минимуму можно было не копировать все бинарные файлы Apache, а обойтись только httpd



обвязка ldd в этом скрипте сделана на скорую руку (однако работает в подавляющем большинстве случаев) - имя какой-нибудь библиотеки, нестандартно выведенной, может не захватиться в переменную не забывайте про /etc/nsswitch.conf и resolv.conf при помещении в CE сетевых сервисов также не забывайте про библиотеки libnss, libnss_dns и libnsl при желании уменьшить объем, занимаемый библиотеками и исполняемыми бинарными файлами - после копирования и тестирования работоспособности CE сделайте им strip

файлы из /usr/lib/gconv и /usr/lib/locale нужны для корректной работы с локалями, отличными от английской (C) - без этих файлов, например, русские буквы не будут восприниматься как корректные символы алфавита, что может сказаться на работе регулярных выражений в PHP некоторым сервисам может требоваться не только файл устройства /dev/null, но и /dev/random вместе с /dev/urandom (например, для того же BIND - иначе у него не работают корректно функции шифрования) если вам для работы каких-нибудь CGI-скриптов необходим PERL, его так же необходимо поместить в CE, не забыв про /usr/lib/perl5

учтите, что если вы не предпримете никаких дополнительных мер, PHP функция mail() не будет работать в CE, т.к. она пытается вызвать бинарный файл SMTP-клиента, который отсутствует в CE (в интернете описаны методы обхода этого с использованием модулей из репозитария PEAR) не пренебрегайте возможностью установить (с помощью утилиты chattr) флаг иммунитета к изменениям (immutable) для важных файлов, которые не должны меняться в ходе работы - например, для конфигурационных файлов

Возможно, есть еще какие-то тонкости, однако я в своей практике с ними не сталкивался, и поэтому написать ничего про них не могу. Помещение MySQL в CE производится аналогично, никаких особых подводных камней там нет, помимо уже описанных.


Уязвимости CE


Как это ни прискорбно, наш мир далек от идеала, и программное обеспечение здесь не является исключением из правил. Из CE можно "выпрыгнуть", причем, иногда очень легко. Один из методов "побега" описан прямо в документации по chroot - цитирую: In particular, the super-user can escape from a `chroot jail' by doing `mkdir foo; chroot foo; cd ..'.

Чтобы не делать из этого материала руководства по побегу из chroot, не буду развивать эту тему - она достаточно хорошо освещена на соотвествующих тематических сайтах.

Итак, существует ряд проблем с безопасной работой в CE, однако существуют и контрмеры по их устранению. Одна из наиболее эффективных подпорок CE - это набор патчей на ядро под названием grsecurity. Эти патчи достойны настоящего параноика и позволяют достаточно туго затянуть гайки (вплоть до доведения системы до самого защищенного состояния - неработающего). Из интересующего нас в аспекте усиления CE можно отметить раздел 'Chroot jail restrictions', в котором:

запрет mount запрет двойных вызовов chroot() запрет использования pivot_root() (аналога chroot()) принудительная смена текущего каталога на "/" запрет установки suid и sgid флагов на файлы запрет fchdir() (иначе из CE можно сбежать через открытый файловый дескриптор, ведущий наружу) запрет создания файлов устройств запрет использования shared memory за границами CE запрет подключения к абстрактным Unix domain sockets запрет на управление процессами вне CE (чтобы из CE нельзя было убить внешний процесс либо еще как-то на него повлиять) запрет смены приоритета процессов вне CE (иначе возможна реализация DoS при выставлении минимального приоритета на другие работающие сервисы) запрет манипулирования sysctl записями запрет подключения модулей ядра, raw I/O операций, перезагрузки системы, смены системного времени, изменения файлов с иммунитетом и многое другое

Если вы подумаете: "а зачем такой концлагерь?" - я рискуя, окончательно разрушить вашу веру в устойчивость программного обеспечения, скажу, что почти каждый из пунктов перечисленного списка позволяет "сбежать" из CE. А вообще grsecurity содержит много интересного, рекомендую принять на вооружение. Единственный неприятный момент, связанный с этим набором патчей - некоторая инертность разработчика (порой выпуски свежих версий патчей задерживаются).

При упоминании grsecurity на ум сразу приходят патчи проекта Openwall (который уже вырос в дистрибутив Openwall GNU/*/Linux, ориентированный на усиление безопасности) - однако, они менее эффективны и не предоставляют возможности тонкой настройки параметров.



В качестве заключения


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

PS: автор благодарит за конструктивные замечания, высказанные при подготовке статьи.

Статья написана по материалам доклада на .



Взаимодействие с другими сервисами


Итак, допустим, что мы благополучно упрятали сервис в CE. Казалось бы - дело сделано, можно идти пить согревающие напитки с друзьями, но в душу закрадываются какие-то смутные подозрения о том, что это не конец. И они вовсе не беспочвенны. Типовой пример - те же самые Apache + PHP + MySQL.

Предположим, что Apache с PHP у нас загорают в "тюрьме" CE, а MySQL "остался на свободе". Но им же надо как-то взаимодействовать друг с другом! Поместить MySQL в тот же CE - не очень хорошее решение (лучше его отсадить в отдельный CE, исходя из народной мудрости, учащей раскладывать яйца по разным корзинкам). С другой стороны, нарушать целостность CE тоже не хочется - иначе какой тогда в нем смысл? В такой ситуации есть неплохое решение: настроить связь с MySQL через UNIX domain socket (по умолчанию они так и взаимодействуют) и сделать на него жесткую ссылку (hard link) в CE с Apache. Единственное ограничение - жесткие ссылки работают только внутри одного раздела диска, поэтому лучше хранить все CE на одном разделе. В этой связи возникает новая проблема - слежение за тем, чтобы этот раздел не переполнился в результате действий пользователей или раздувания логов и тем самым не заблокировалась работа сервера (если речь идет о корневом разделе основной системы). Одним из эффективных путей предотвращения таких ситуаций может стать использование файловых квот, однако это уже выходит за рамки данной статьи. Помимо этого, не забывайте о том, что файл существует до тех пор, пока существует хотя бы одна жесткая ссылка на него - поэтому рекомендую в выше рассмотренном примере с MySQL убивать при остановке MySQL все жесткие ссылки на mysql.sock, а при запуске - создавать заново.

Альтернативным подходом является использование TCP сокетов для межпроцессного взаимодействия. Выбор конкретного решения - дело каждого.



Зачем это нужно?


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

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

Кстати, некоторые сервисы изначально подразумевают запуск в CE - например, распространенный DNS-сервер BIND создатели рекомендуют эксплуатировать в CE (создание окружения для нормальной работы этого сервиса подробно описано в официальной документации на BIND), при этом сам демон совершает системный вызов chroot(), если ему указать в качестве аргумента расположение корневого каталога CE. Аналогичная ситуация с MySQL - в конфигурационном файле указывается расположение подготовленного окружения для сервиса, демон при запуске помимо смены UID/GID, также вызывает chroot(). Те сервисы, в которых не предусмотрена работа в CE "из коробки", можно запускать с помощью уже упоминавшейся утилиты chroot.



Журналирование


Аналогичным же образом поступаем и с журналированием событий через syslog - настраиваем его для работы через дополнительный сокет (опция -a для syslogd) или пробрасываем жесткую ссылку с /dev/log в CE. Тем самым мы получаем обычное журналирование согласно syslog.conf, как будто бы сервис и не находился в CE.



Защита домашнего компьютера


,

Цель данного очерка - представить один из путей эффективной анти-(вирусной, спамовой, рекламной, шпионской, хакерской, и т.д.) защиты компьютера.

Здесь рассматривается вариант (домашнего или офисного) компьютера с эпизодическим (не постоянным) подключением к Интернету. Выбран именно этот вариант, как более интересный и сложный по сравнению со своим антиподом - постоянным подключением к Интернету; здесь всё просто: при загрузке ОС надо тупо запускать всё установленное защитное ПО - и хай воно борется с заразой!

Несколько ремарок. Для зануд: я владею "великим и могучим" достаточно свободно (см. ), чтобы не использовать килограммами смайлики, и если где-то коверкаю слова - то не по незнанию, а подчёркивания для.

Для передорослей: если вам что-то не нравится, оставьте своё мнение при себе; форум пришлось прикрыть именно из-за воинствующих подростков. Конструктив с благодарностью принимается.

Для сторонников теории заговора: я не рекламирую ничьих продуктов/услуг и не получаю за это мзду. Высказываю своё личное мнение, рождённое опытом работы с названными продуктами.

Для чайников: здесь не разжёвывается терминология и не проводится ликбез. Ориентируюсь на грамотных пользователей.

К делу. Целевой функцией наших действий является: максимизация защиты компьютера от всякой заразы; минимизация "тормозов"; по возможности, не "грузить" пользователя этими вопросами. Шибко умной железке вполне по силам самой о себе позаботиться. Рассматривается типовой случай домашнего компьютера среднестатистического пользователя.

Для затравки: за много лет не было ни единого случая, чтобы компьютер, "окученный" мною, подхватил заразу - ни мой личный - ни тех знакомых, которые просили меня об этой услуге. Более того, некоторые знакомые, "продавшиеся" другим халтурщикам, через какое-то время упрашивали меня прийти снова и сделать всё по-своему - у них либо "тормоза" страшные (а чего вы ждали от KAV?), либо зараза замучила.

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

Итак, шаг первый. Для защиты от спама я сам пользуюсь почтовыми ящиками на - очень эффективное средство. Рекомендую. У них там используется хороший спам-фильтр; легитимные сообщения не пропадают. Я и сам пользуюсь этим сервисом, и другим рекомендую. На прочих известных порталах тоже что-то такое есть, но... не пробовал.

Шаг второй. Для защиты от вирусов, рекламного, шпионского софта, и прочей требухи я использую антивирус . Почему-то у многих людей вопрос выбора антивируса вызывает что-то вроде религиозной истерики. Не хочу им уподобляться; скажу лишь, что меня Dr. Web устраивает как меньшими требованиями к системным ресурсам, так и большей управляемостью: я могу по своему хотению включать/отключать любые его компоненты. Кроме того, я считаю, что при корректной настройке и наличии актуальных вирусных баз любой антивирус покажет уровень защиты, сопоставимый с конкурирующими продуктами. Иными словами, если ручки не кривые и базы свеженькие, можете расслабиться.

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

Любой антивирус обеспечивает, как минимум, 3 инструмента: сканер, дисковый монитор, и монитор почтового трафика.

Сканер - это программа, которую можно "натравить" на диск или папку, и он проверит все находящиеся там файлы на предмет наличия в них вирусов; и при необходимости, вылечит/удалит/переместит в карантин/запретит доступ, и т.д. Перед началом "окучивания" компьютера его (комп) необходимо прошерстить антивирусным сканером (со свежими базами) - дабы увериться в его непорочности.

Файловый монитор - это резидентная программа, которая пропускает через себя (частично или полностью) файловый ввод-вывод - все операции чтения и записи файлов - и также пытается найти и уничтожить заразу. Именно этот компонент любого антивируса более всего "притормаживает" систему.


Поэтому так важно, во-первых, правильно настроить его (предварительно почитав документацию), а во-вторых, минимизировать его использование (время активной работы), не снизив, однако, уровень защиты. Цели прямо противоположные, но мы что-нибудь придумаем. Увы, вся наша жизнь - это цепь компромиссов. Бескомпромиссна только костлявая...

Почтовый монитор - резидентная программа, которая перехватывает почтовый трафик (протоколы POP3 и SMTP) и его анализирует всё на тот же предмет. Несколько раз он меня выручал - когда по почте приходили вирусы. Mail.ru декларирует, что вся почта, идущая через их сервер, проверяется антивирусом, но то ли базы у них несвежие, то ли ещё что, но вирусы они иногда пропускают.

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

Заботясь о безопасности, в наше время нельзя ограничиваться одним только антивирусом. Хороший современный брандмауэр - вот то, что нам нужно! Мне нравится . Кроме функций собственно файрволла, его дополнительные модули (плагины) выполняют полезные функции: вырезают рекламу с web-страниц, ограничивает доступ к указанным ресурсам, позволяет избирательно разрешить/запретить работу интерактивных элементов на сайтах: cookies, скриптов, Flash, Gif, всплывающих окон, и т.д.

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



Как я уже говорил, всем этим вполне может "рулить" сам компьютер.

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

Осуществляется выход в Интернет.

1.1. Дозвон до провайдера. В этот момент в память загружаются , "Spider Guard" (файловый монитор Dr. Web), "Spider Mail" (почтовый монитор Dr. Web), "Spider Gate" (монитор HTTP-трафика).

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

1.3. Производится синхронизация локальных часов компьютера с атомными часами - маленькое удобство.

1.4. Разрыв соединения. Всё это хозяйство (четыре защитных компонента) "вываливается" из памяти с тем, чтобы не тормозить работу в дальнейшем.

В дисковод вставляется CD или DVD-диск. При этом "взлетает" файловый монитор - мимо него не проскочит ни одна дрянь, даже если ею забит весь диск. А так как вирусные базочки у нас свеженькие (помните автообновление в каждом сеансе связи?), мы заслуженно имеем моральное удовлетворение.

2.1. При извлечении диска из привода файловый монитор сам "вывалится" из памяти - и компьютер опять не тормозит нисколечко!

В USB-порт вставляется флеш-накопитель. Всё происходит точно так же, как и в пункте 2.

В дисковод 3.5 '' вставляется дискета. Вот уж это событие я не знаю, как отследить. Поэтому всем усерам на панели быстрого запуска делаю два значка - для запуска и остановки службы "SpIDer Guard for Windows NT" - файлового монитора. И предупреждаю их: "перед вставкой дискеты нажми вот эту пимпочку, а после изъятия - эту".


Остаётся надеяться на его здравое желание оставить компьютер здравым.

Итак, мы перекрыли все каналы поступления "заразы" извне, и при этом не напрягли усера (всё крутится само собой, прям как у Емели), и не затормозили работу его системы. Честь нам и хвала!

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

Во время установки Dr. Web следует указать выборочную установку (см. ). "Родной" планировщик не стОит устанавливать: мы и так воспользуемся планировщиком, только более функциональным.

После успешной установки Dr. Web необходимо изменить метод запуска службы "SpIDer Guard for Windows NT" на ручной, а также удалить из автозагрузки (при помощи "msconfig") "spiderml" и "spidergate". Нечего им делать в отсутствие соединения с инетом.

Точно также, после установки , переводим в режим ручного запуска службу "Outpost Firewall Service".

Теперь устанавливаем планировщик . Он хорош своею компактностью, быстротою и мощностью языка заданий. А также халявностью для жителей б. СССР. Примечание. После установки и регистрации в его настройках (см. ) можно выключить "Непотопляемый режим", или отключить соответствующую службу. Лишнее это в наше время.

Не пугайтесь, вам не придётся писать скрипты для него. Я сделал это за вас. Вот, и пользуйтесь.

Единственное, что вам может понадобиться отредактировать в скрипте - это букву CD (DVD) дисковода, а также раскомментировать события "OnFlashInsert" и "OnFlashEject" и проверить правильность буквы USB-накопителя.

Если вы всё сделаете правильно, наградой вам будет надёжная защита и отсутствие тормозов в работе.

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


Модель вероятностного контроля доступа к ресурсам


Как и ранее, будем считать, что чем выше полномочия субъекта и категория объекта, тем соответственно, меньше их порядковый номер в линейно полномочно упорядоченных множествах субъектов и объектов —
С = {С1,…, Ск}
и
О = {О1,…, Оk}).
Обозначим же через Pi вероятность того, что документ i-й категории «заражен» макровирусом, при этом (как было сказано выше) априори имеем:
P1 < P2 <…< Pk.

Беря во внимание тот факт, что макровирус начинает действовать (что может нести в себе угрозу «заражения») лишь после прочтения его соответствующим приложением и что предотвращать следует возможность «заражения» документа более высокой категории макровирусом из документа более низкой категории (после его прочтения приложением), получаем следующую матрицу доступа F, описывающую вероятностную модель контроля доступа, реализуемую для антивирусного противодействия:

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

Видим, что при реализации данной схемы вероятность «заражения» документа более высокой категории, например, O1 (P1) не изменяется в связи с тем, что на том же компьютере обрабатывается информация более низкой категории, например, Ok (Pk). При этом будем понимать, что режимы обработки информации различных категорий могут кардинально различаться (например, при обработке на одном компьютере открытой Оk и конфиденциальной информации О1, имеем:
Pk >> P1,
причем в зависимости от реализованных правил и организационных мер по обработке конфиденциальных данных это отношение может составлять сотни, тысячи и более раз, то есть именно во столько раз можно снизить вероятность «заражения» конфиденциальных данных макровирусами, хранящимися в открытых данных, для которых порою, Pk = 1).



Назначение механизма контроля доступа к ресурсам


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

Пусть множества С = {С1,…, Ск} и О = {О1,…, Оk} — соответственно линейно упорядоченные множества субъектов и объектов доступа. В качестве субъекта доступа
Сi, i = 1,…, k
рассматривается как отдельный субъект, так и группа субъектов, обладающих одинаковыми правами доступа (заметим, что на практике это могут быть как различные пользователи, так и один и тот же пользователь, обладающий различными правами доступа при различных режимах обработки информации), соответственно, в качестве объекта доступа
Оi, i = 1,…, k
может также рассматриваться как отдельный объект, так и группа объектов, характеризуемых одинаковыми правами доступа к ним.

Пусть S = {0, Чт, Зп} — множество прав доступа, где «0» обозначает отсутствие доступа субъекта к объекту, «Чт» — разрешение доступа для чтения объекта, «Зп» — разрешение доступа для записи в объект.

Каноническую модель контроля доступа (модель контроля доступа, реализующая базовые требования к механизму защиты) можно представить матрицей доступа D, имеющей следующий вид:

Под канонической моделью контроля доступа для линейно упорядоченных множеств субъектов (групп субъектов) и объектов (групп объектов) доступа понимается модель, описываемая матрицей доступа, элементы главной диагонали которой «Зп/Чт» задают право полного доступа субъектов к объектам, остальные элементы «0» задают запрет доступа субъектов к объектам.

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

Сегодня при реализации частных решений по противодействию внутренним IT-угрозам широко используется полномочный контроль доступа. Его практическое использование в данных приложениях обусловлено тем, что в корпоративных системах, как правило, на одном и том же компьютере обрабатывается различная по уровню конфиденциальности информация, что позволяет ее категоризовать («открытая», «конфиденциальная», «строго конфиденциальная» и т.
д.), при этом необходимо обеспечить различные режимы обработки информации разных категорий на основе задания соответствующих полномочий субъектам доступа (откуда и название) к категоризованным объектам.

Основу полномочного контроля доступа составляет способ формализации понятий «группа пользователей» и «группа объектов», на основании вводимой шкалы полномочий. Наиболее широко на практике используется способ иерархической формализации отношения полномочий, состоящий в следующем. Иерархическая шкала полномочий вводится на основе категоризования данных (открытые, конфиденциальные, строго конфиденциальные и т. д.) и прав допуска к данным пользователей (по аналогии с понятием «формы допуска»). Будем считать, что чем выше полномочия субъекта и категория объекта, тем соответственно, меньше их порядковый номер в линейно полномочно упорядоченных множествах субъектов и объектов —
С = {С1,…, Ск}
и
О = {О1,…, Оk}).

Соответствующая формализация правил доступа субъектов к объектам при этом, как правило, сводится к следующему:

субъект имеет право доступа «Зп/Чт» к объекту в том случае, если полномочия субъекта и категория объекта совпадают;

субъект имеет право доступа «Чт» к объекту в том случае, если полномочия субъекта выше, чем категория объекта;

субъект не имеет прав доступа к объекту в том случае, если полномочия субъекта ниже, чем категория объекта.

Матрица доступа D, описывающая полномочную модель контроля доступа, имеет следующий вид:



Таким образом, основная задача, решаемая при реализации данного способа контроля доступа, состоит в предотвращении возможности понижения категории информации при ее обработке. Иногда дополнительно вводится правило, разрешающее запись информации более низкой категории в объекты более высокой категории, что также не противоречит идее противодействия понижению категории информации; матрица доступа D, описывающая полномочную модель контроля доступа, при этом имеет следующий вид:


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


Корректность реализации полномочного контроля здесь обеспечивается тем, что разрешается изменять категорию лишь в сторону ее повышения
(Ck Ck–1, …С1)
— после чтения открытого документа пользователю разрешается сохранять данные в объект категории «открыто», после чтения конфиденциального документа пользователю разрешается сохранять данные в объект категории «конфиденциально», причем все открытые ранее документы категории «открыто» также разрешается сохранять только в объект категории «конфиденциально».

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


Недостатки частного решения. Комплексный


Сравним матрицы D и F. Видим, что они полностью противоречат друг другу, то есть требования к реализации полномочного контроля доступа при решении альтернативных задач защиты информации не то чтобы были различны — они противоречивы.

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

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

Прежде рассмотрим, какую информацию мы категоризуем, применительно к решению задачи антивирусной защиты. Естественно, что качественное отличие в обработке имеет открытая информация и конфиденциальная информация, то есть мы можем выделить две основные категории: «открыто» и «конфиденциально». При этом обработка конфиденциальной информации различных категорий, в части вероятности быть исходно «зараженной» макровирусом, уже отличается не столь существенно. С учетом сказанного на практике имеет смысл рассматривать прежде всего следующее отношение вероятностей того, что документ i-й категории «заражен» макровирусом, обозначив категорию «открыто», как k, имеем:
P1 = P2 =…=Pk–1 << Pk.

Естественно, что если мы не можем разрешить ни чтения, ни запись (так как эти требования противоречивы в матрицах доступа), то остается лишь одно решение, связанное с полным запретом доступа. С учетом сказанного получаем модель полномочного контроля доступа, реализация которой позволяет решать рассмотренные альтернативные задачи в комплексе, описываемую матрицей доступа D(F):


Заметим, что при таком подходе к реализации полномочного контроля доступа обработка открытых данных по сути полностью изолируется от обработки конфиденциальных данных. Результатом такого решения, никак не противоречащего идее обработки данных на основе полномочий пользователей и категорий объектов, является то, что повышение вероятности «заражения» макровирусом открытых данных никак не сказывается на вероятности «заражения» макровирусом конфиденциальных данных, что определяется условием:
P1 = P2 = … = Pk–1 << Pk.
Важным здесь является тот момент, что если на вероятность «заражения» макровирусом открытых данных повлиять практически невозможно, кроме как уменьшить ее значение, за счет применения специализированных антивирусных средств защиты (что, с одной стороны, не даст решения в общем виде, так как сигнатурный анализ позволяет находить только известные макровирусы, с другой стороны, в данных приложениях выглядит несколько странным — защищаем открытые данные, вообще говоря не очень и нуждающиеся в защите, чтобы в конечном счете уберечь от «заражения» конфиденциальные данные), то вероятность «заражения» макровирусом конфиденциальных данных можно существенно снизить (на порядки — в сотни, в тысячи, а может быть, и более раз, реализовав соответствующие организационные мероприятия по их обработке (которые и так априори должны быть реализованы, но уже с целью противодействия понижению их категории)).

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

Матрица D(F) иллюстрирует тот факт, что при обработке на компьютере информации только двух категорий («открыто» и «конфиденциально» — наиболее распространенный случай), с точки зрения решения задачи защиты информации в комплексе использование полномочного контроля доступа недопустимо (а это ведь самый распространенный случай категоризования информации на практике).



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


В порядке замечания отметим, что при условии:
P1 << P2 <<…<< Pk–1 << Pk
должна быть реализована каноническая модель контроля доступа.

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


Задачи антивирусной защиты в корпоративных приложениях


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

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

Обработка категоризованной информации (например, «конфиденциально» и «открыто») априори предполагает, что в первую очередь объектом защиты является информация более высоких категорий (в частности, в первую очередь следует защищать конфиденциальную информацию, работа с открытой информацией в данных приложениях является опциональной, и ее защита не столь важна).

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

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

Из всего сказанного можем сделать очень важный вывод: чем ниже категория документа, тем менее он нуждается в защите от «заражения», что, в том числе, сказывается на реализуемых режимах его обработки, как следствие, тем большей вероятностью быть «зараженным» он характеризуется.

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



В заключение отметим, что средство


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

Защита информации в корпоративных приложениях. Частные решения


А. Щеглов, А. Оголюк

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

Все многообразие угроз компьютерной безопасности можно свести к двум большим группам: внутренние и внешние IT- угрозы.

Появление понятия внутренних IT-угроз для ОС Windows связано с началом использования ОС семейства Windows для обработки конфиденциальной информации в корпоративных приложениях. Конфиденциальная информация априори является потенциальным объектом несанкционированного доступа (НСД), так как обладает потребительской стоимостью для злоумышленников, то есть является товаром.

С учетом же того, что в основе архитектуры защиты современных универсальных ОС семейства Windows (не будем забывать, что это универсальные ОС, изначально созданные как персональные для домашнего использования) лежит принцип полного доверия к пользователю, некоторые ключевые механизмы защиты, встроенные в современные ОС Windows, по этой причине не могут обеспечить эффективного противодействия внутренним IT-угрозам — угрозам НСД к информации со стороны санкционированных пользователей (инсайдеров — пользователей, допущенных к обработке конфиденциальной информации в рамках выполнения своей служебной деятельности), именно санкционированные пользователи и несут в себе наиболее вероятную угрозу хищения конфиденциальных данных предприятия. Как следствие, эта задача сегодня не решается встроенными механизмами защиты ОС Windows, поэтому ее решение должно быть возложено на добавочные средства защиты. Понятие внешних IT-угроз для ОС Windows появилось гораздо раньше, но опять же в полной мере проявилось с началом использования ОС семейства Windows для обработки конфиденциальной информации в корпоративных приложениях, что опять же связано с высокой потребительской стоимостью конфиденциальных данных для злоумышленников.
И здесь ключевой причиной, на наш взгляд, является исторический подход к созданию универсальных ОС. Несмотря на то что архитектура защиты при переходе от версии к версии претерпевает заметные изменения, она и по сей день имеет принципиальные архитектурные недостатки (например, ошибки в приложениях никак не должны сказываться на уровне безопасности информации, защиту которой осуществляет ОС). Другая проблема кроется в систематически обнаруживаемых ошибках программирования. Здесь, вообще говоря, получается некий замкнутый круг. Очевидно, необходимо кардинально менять архитектуру защиты, что требует времени и серьезной проработки решений, но рынок требует обратного — необходимо максимально быстро создавать и поставлять на рынок решения с новыми потребительскими свойствами, а это возможно лишь при условии максимального использования существующего программного кода. Когда же речь заходит о потребительских свойствах, то в первую очередь разработчиком расширяются те свойства продукта, которые максимально востребованы (если изделие максимально ориентируется на использование частными лицами, то отнюдь не обеспечиваемый уровень информационной безопасности становится его основным потребительским свойством).

В результате получаем следующую статистику уязвимости ОС Windows. В 2005 году в ОС Windows было выявлено 812 «дыр» (исследования US-CERT). Специалисты из McAfee отмечают, что из 124 «дыр», обнаруженных в Windows XP Professional на сайте Secunia (Security Provider), 29 так и остались не устраненными, что дало компании основание присвоить Windows статус критически опасной ОС. Действительно, наличие уязвимостей (или «дыр») в системе делает ее защиту просто бесполезной — что толку в том, сколько и каких механизмов защиты реализовано, если есть известный канал НСД к информации?

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

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

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

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


Агрегирование


После консолидации событий начинается процесс их агрегирования, т.е. группирования однотипных событий вместе, что позволяет получить на экране вместо 10000 повторяющихся строк "UDP-Scan" или "SQL_SSRP_StackBo" (краткое название атаки Slammer в системе RealSecure Network 10/100) всего лишь одну строчку, которая дополнена новым параметром "число событий" (см. Таблицу 3).

Таблица 3. Снижение объема информации, отображаемой на консоли

Степень риска Событие Число событий Источник
Низкая UDP-Scan 11385 194.98.93.252
Высокая Backdoor-BO2k 1 194.98.93.252
Высокая SQL_SSRP_StackBo 1567 139.92.229.160
: : : :

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



Консолидация событий


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

Таблица 2. Консолидация событий на примере системы RealSecure SiteProtector с установленным модулем Third Party Module

Степень риска Событие Имя сенсора Тип сенсора
Низкая fw-cisco~ids-packet-not-IPSEC-packet cisco_fw_ras Cisco PIX FW
Высокая fw-checkpoint~SYN Attack cp_fw_dmz Check Point FW
Высокая Backdoor-BO2k network_sensor_1 RealSecure Network
: : : :

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

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

Собрав все данные в одном месте, мы не избавились от проблемы огромных объемов информации, отображаемых на консоли администратора безопасности, которую призван устранить механизм агрегирования.



Корреляция


Получив сообщение о том, что, например, ваша сеть атакована червем Slammer многие администраторы приходят в ужас и лихорадочно начинают вспоминать, а пропатчили ли они свои узлы. А что если, даже самая серьезная атака (например, Slammer) не нанесет вам никакого вреда по той простой причине, что у вас нет серверов на базе MS SQL? А если они у вас есть, но вы их давно защитили? Аналогичная ситуация происходит и с другими атаками, которые отвлекают внимание администратора и требуют вмешательства. А что, если на них вообще не надо реагировать (как ни парадоксально это звучит)? Ведь не каждый хакер знает всю подноготную вашей сети, и, зачастую, он наугад пытается атаковать ваши ресурсы, что приводит к тому, что атака не только не нанесет вам никакого ущерба, но и в принципе не может быть применима к вашей сети. Например, относительно недавно выпущенный SMBdie страшен только Windows-узлам, да и то, только тем, на которых не был установлен соответствующий Service Pack. Unix-машины к нему неуязвимы. Так зачем же реагировать на появление сообщения об атаке SMBdie? Хорошо, если ваша сеть небольшого размера и вы помните, что и где у вас установлено. А если нет? Куда лучше, если сообщения, не несущие никакой угрозы, вообще бы не показывались у вас на консоли и не отвлекали бы вас от более важных дел. Механизм корреляции, т.е. поиск взаимосвязей между разнородными данными, как раз и решает эту проблему, снимая с администраторских плеч нагрузку проведения ручного анализа и сопоставления разрозненных данных.

Модуль корреляции в SIMS не только автоматизирует процесс сопоставления разнородных данных, но и сам проводит анализ воздействия атаки на ваши ресурсы. Это может происходить по-разному:

Локальная корреляция, осуществляемая непосредственно на защищаемом узле. В этом процессе участвует система обнаружения и предотвращения атак уровня узла (host-based ID&PS), которая либо отражает атаку, о чем оповещает администратора безопасности, либо нет. В последнем случае требуется вмешательство специалистов, которые инициируют процесс расследования инцидентов.
В данном случае, система обнаружения и предотвращения атак должна не только зафиксировать атаку, но и оценить ее воздействие на атакуемый узел. Корреляция со сведениями об операционной системе. Если Windows-атака направлена на Unix-узел, то ее можно игнорировать и не забивать себе голову проблемой реагирования на такие нарушения. Если же атака "применима" к данной ОС, то в действие вступает следующий вариант корреляции. Корреляция атак и уязвимостей. Следуя определению атаки, она не может быть успешна, если атакуемый узел или сегмент сети не содержит уязвимости. Таким образом, сопоставляя данные об атаке с информацией об уязвимостях атакуемого узла или сегмента, можно с уверенностью будет сказать, применима ли зафиксированная атака к вашей сети и, если да, то нанесет ли она вам какой-либо ущерб.

Результатом работы механизма корреляции может служить одно из следующих сообщений в строке статуса атаки (с разъяснением причины такого вывода):

Вероятно удачная атака (узел уязвим) Вероятно неудачная атака (узел не уязвим) Вероятно неудачная атака (блокированы некоторые пакеты, составляющие атаку) Вероятно неудачная атака (атака не применима к данной операционной системе) Неудачная атака (узел блокировал атаку) Воздействие неизвестно (узел не сканировался) Воздействие неизвестно (операционная система не определена) Воздействие неизвестно (уязвимость не определена) Воздействие неизвестно (корреляция не проводилась)

Таблица 4. Результат работы механизма корреляции на примере системы RealSecure SiteProtector с установленным модулем SecurityFusion Module

Степень риска Событие Число событий Статус
Низкая NMap-Scan 139 Воздействие неизвестно (корреляция не проводилась)
Средняя SMTP-Sendmail-Relay 1 Вероятно неудачная атака (узел неуязвим)
Высокая Backdoor-BO2k 1 Неудачная атака (узел блокировал атаку)
Существуют и другие механизмы корреляции, облегчающие работу администратора. Например, анализ шаблона атаки, позволяющий сделать вывод о применении того или иного средства реализации атаки.


Такая информация позволяет оценить квалификацию хакера и в зависимости от этого предпринимать те или иные действия. Также может быть задействована функция сопоставления данных за заданный интервал времени, что позволяет несколько однотипных или разных событий объединить единым сообщением об атаке. Например, несколько неудачных попыток входа в систему с одного из узлов сети за короткий интервал времени могут говорить о попытке подбора пароля. Или еще один распространенный пример. Сразу после обнаружения факта сканирования Web-сервера, что само по себе является частым событием в Интернет, фиксируется попытка использования уязвимости Unicode в сервере MS Internet Information Server. По отдельности эти события могут говорить, как о реальной атаке, так и ложном срабатывании. Совокупность же этих действий, разделенных очень коротким интервалом времени, с очень высокой вероятностью говорит именно о реальной атаке, направленной на взлом сайта.

Приведу более сложный пример. Один из узлов вашей сети был успешно атакован, после чего он сам стал базой для дальнейшего распространения атаки. Система корреляции, сопоставив различные данные, может обнаружить такой факт и уведомить об этом администратора, который должен в срочном порядке отреагировать на возникшую ситуацию. Вот как может выглядеть такой факт в журнале регистрации системы обнаружения атак (см. выделение цветом в Таблице 1), а вот так он будет подан системой корреляции (см. первую строчку в Таблице 5).

Таблица 5. Результат работы механизма корреляции на примере системы RealSecure SiteProtector с установленным модулем SecurityFusion Module

Степень риска Событие Число событий Источник
Высокая Attack_From__Compromised_Host 1567 139.92.229.160
Высокая Targeted_Break_In_Attempt 1 194.98.93.252
: : : :
Кстати, здесь есть очень тонкий момент, на который необходимо обращать внимание при выборе системы управления информационной безопасности. Многие из них в своих рекламных материалах упоминают про поддержку огромного количества разнородных средств защиты (до нескольких десятков) и перечисляют известнейшие имена.


Но: на самом деле под поддержкой понимается только сбор данных от этих средств, не более того. Производитель SIMS должен обновлять свое решение также часто, как и все из поддерживаемых ими систем. Более того, с выходом обновления для системы обнаружения атак или сканера система корреляции также должна пополнить свою базу знаниями о новых уязвимостях и атаках. В противном случае она не сможет анализировать неизвестные ей события. Об этом умалчивают многие производители таких средств, считая, что достаточно указать в рекламных материалах факт поддержки разнообразных средств анализа защищенности, межсетевых экранов, систем обнаружения атак, proxy-серверов и т.д. Поэтому максимум, на что вы можете надеяться, устанавливая такой продукт, - это на сбор данных из разных источников без функции агрегирования и корреляции. Честнее поступают такие производители как Internet Security Systems, Cisco и т.п. Они не обещают золотых гор, но зато гарантируют полную поддержку всех своих решений и, возможно, парочки решений от других производителей.


Корреляция на службе безопасности


Лукацкий А.В., , опубликовано в журнале BYTE #10/2003

С чем регулярно приходится сталкиваться администратору безопасности? Разумеется с постоянным потоком сообщения от обслуживаемых им средств защиты о тех или иных проблемах с безопасностью. В качестве примера таких сообщений можно назвать:

Сканирование периметра сети Подбор пароля на узлах, видимых из Интернет Атаки червей Slammer и т.п. Использование уязвимостей Web-сервера и т.п.

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

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

Многие специалисты считают, что ложное обнаружение лучше, чем отсутствие сообщения об атаке. Однако это как раз та ситуация, когда количество переходит в качество. Со временем это становится головной болью любого администратора, которому приходится решать, реагировать на появившееся на консоли сообщение или проигнорировать его. В результате администратор просто перестает реагировать не только на ложные, но и на любые другие сообщения, в т.ч. и влекущие за собой тяжелые последствия. Например, в Таблице 1 показан фрагмент журнала регистрации широко известной в России системы обнаружения атак RealSecure Network 10/100, которая зафиксировала распространение червя Slammer, нашумевшего в начале этого года. Таких записей за период в один день в журнале может быть несколько десятков тысяч, ведь, как можно видеть, скорость распространения Slammer составляет несколько узлов в секунду.


Таблица 1. Атака червя Slammer

Дата Время Событие Нарушитель Цель Протокол Порт источника Порт назначения
4/8/2003 23:14:53 SQL_SSRP_StackBo 194.98.93.252 139.92.229.160 UDP 1690 1434
4/8/2003 23:14:54 SQL_SSRP_StackBo 139.92.229.160 213.253.214.34 UDP 1080 1434
4/8/2003 23:14:54 SQL_SSRP_StackBo 139.92.229.160 213.253.214.35 UDP 1081 1434
4/8/2003 23:14:54 SQL_SSRP_StackBo 139.92.229.160 213.253.214.36 UDP 1082 1434
4/8/2003 23:14:55 SQL_SSRP_StackBo 139.92.229.160 213.253.214.37 UDP 1083 1434
4/9/2003 23:14:55 SQL_SSRP_StackBo 139.92.229.160 213.253.214.38 UDP 1084 1434
4/9/2003 23:14:55 SQL_SSRP_StackBo 139.92.229.160 213.253.214.39 UDP 1085 1434
4/9/2003 23:14:56 SQL_SSRP_StackBo 139.92.229.160 213.253.214.40 UDP 1086 1434
4/9/2003 23:14:56 SQL_SSRP_StackBo 139.92.229.160 213.253.214.41 UDP 1087 1434
4/9/2003 23:14:56 SQL_SSRP_StackBo 139.92.229.160 213.253.214.42 UDP 1088 1434
4/9/2003 23:14:56 SQL_SSRP_StackBo 139.92.229.160 213.253.214.43 UDP 1089 1434
: : : : : : : :
Многие специалисты утверждают, что системы обнаружения атак уже не справляются с такими проблемами, а журналисты даже стали использовать в своих статьях громкие заголовки "системы обнаружения атак мертвы". Однако, как было замечено одним из экспертов в области обнаружения атак: "это не проблема систем обнаружения атак, это проблема управления данными и их представления".


Об авторе


Алексей Викторович Лукацкий, руководитель отдела Internet-решений Научно-инженерного предприятия "Информзащита" (Москва). Автор книг "Обнаружение атак", "Атака из Internet" и "Protect Your Information with Intrusion Detection". Связаться с ним можно по тел. (095) 937-3385 или e-mail: .



Огласите весь список, пжалуйста!


Число систем корреляции постоянно растет и к ним, например, можно отнести:

. . . . . . .

Несмотря на рост интереса к этим системам на Западе, в России о таких решениях говорят пока мало и это закономерно. У нас далеко не все используют системы обнаружения атак и межсетевые экраны, не говоря уже о средствах, стоящих существенно выше на эволюционной шкале защитных механизмов. Однако, несмотря на это, в России уже можно найти системы управления информационной безопасностью таких известных в мире безопасности компаний, как Internet Security Systems, Cisco Systems и Symantec.

Первая из них предлагает бесплатную систему , которая обладает описанными выше механизмами консолидации, агрегирования и корреляции событий, получаемых не только от всех своих решений в области обнаружения атак и анализа защищенности, но и от межсетевых экранов Check Point Firewall-1 и Cisco PIX Firewall. Также эта система поддерживает и другие средства защиты.

Компания Cisco предлагает систему , которое построено на базе широко известной на Западе системы управления информационной безопасности одноименной компании.

Компания Symantec предлагает систему и семейство , вошедшее в пакет предложений Symantec после покупки последней компании SecurityFocus.



Приоритезация


Одна и та же атака может иметь различные последствия для разных узлов корпоративной сети. Например, узел, работающий под управлением ОС Solaris 2.5.1, уязвим для атаки Ping of Death, а узел, работающий под ОС Windows NT, не подвержен данной атаке. Можно привести и другой пример - наличие модема. Если модем подключен к компьютеру с выполнением всех требований по обеспечению информационной безопасности, то это нормальная ситуация, не требующая пристального внимания администратора безопасности. Напротив, модем, подключенный в обход межсетевого экрана, должен быть немедленно удален. Или сервис Telnet. На маршрутизаторе он нужен, а на большинстве рабочих станций - нет. Именно поэтому система централизованного мониторинга атак должна предусматривать возможность задания приоритетов для обнаруживаемых атак или уязвимостей. При этом задание приоритетов может быть как статическим (что было продемонстрировано выше на трех примерах), так и динамическим.

Зачем нужно динамическое задание приоритетов, и почему недостаточно статического метода? Допустим, на компьютере существует учетная запись Guest, с помощью которой любой злоумышленник сможет делать на компьютере все, что ему заблагорассудится. В обычных условиях эта уязвимость имеет высокий приоритет. Однако на практике, в зависимости от того, разрешена (enable) ли эта учетная запись или запрещена (disable), данная уязвимость может иметь самый высокий или самый низкий приоритет, соответственно. В такой ситуации приоритет может быть назначен только после корреляции событий, т.е. он должен задаваться динамически (сравните Таблицы 4 и 6).

Таблица 6. Результат работы механизма динамической приоритезации на примере системы RealSecure SiteProtector с установленным модулем SecurityFusion Module

Степень риска Событие Число событий Источник
Высокая UDP-Scan 11385 194.98.93.252
Низкая Backdoor-BO2k 1 194.98.93.252
Низкая SQL_SSRP_StackBo 1567 139.92.229.160
: : : :



Системы управления информационной безопасностью


Для того чтобы избежать описанных проблем, необходима эффективная система управления информационной безопасности (Security Information Management System, SIMS), которая позволяет все используемые защитные средства объединить в единый управляемый комплекс. Такая система:

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

Использование таких систем позволяет ответить на множество вопросов, постоянно возникающих в процессе обеспечения информационной безопасности, например:

Уязвим ли атакуемый узел к зафиксированной атаке? Нанесла ли атака ущерб ресурсам моей сети? Заблокировал ли установленный на атакуемом узле агент системы защиты зафиксированную атаку? Какая система атакуется в данный момент? Какие узлы моей сети являются источниками атак?

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

Консолидация (event consolidation). Агрегирование (event aggregation). Корреляция (event correlation). Приоритезация (event prioritization).



в области информационной безопасности определяется


Уровень зрелости компании в области информационной безопасности определяется не количеством установленных в сети межсетевых экранов и систем обнаружения атак, а умением управлять ими. Одним из таких средств являются системы управления информационной безопасностью, которые получают все большее распространение в мире. По оценкам компании IDC к 2005 году объем рынка таких систем составит 1759 миллионов долларов (в т.ч. объем рынка систем корреляции - 405 миллионов долларов). Однако, несмотря на желание применять такие системы в своей повседневной деятельности (такое желание высказывают 89% респондентов), только 5% компаний задействуют всю мощь этих решений (в России число таких компаний измеряется сотыми долями процента). Остается надеяться, что в условиях растущей угрозы кибертерроризма отношение к таким системам изменится.

Безопасность СУБД


Михаил Савельев

, #09/2005

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

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

Кроме того, если вернуться к случаям взлома БД и провести простой расчет, то он покажет несостоятельность попыток свалить всю вину за происшедшее на хакеров. Разделив объем украденных данных на типовую скорость канала доступа в Интернет, мы получим, что даже при максимальной загруженности канала на передачу данных должно было бы уйти до нескольких месяцев. Логично предположить, что такой канал утечки данных был бы обнаружен даже самой невнимательной службой безопасности.

И если перед нами стоит задача обеспечить безопасность корпоративной СУБД, давайте озадачимся простым вопросом: кто в компании вообще пользуется базой данных и имеет к ней доступ?

Существует три большие группы пользователей СУБД, которых условно можно назвать операторами; аналитиками; администраторами.

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

Под аналитиками мы понимаем тех, ради кого, собственно, создается эта база данных: логистики, маркетологи, финансовые аналитики и прочие. Эти люди по роду своей работы получают обширнейшие отчеты по собранной информации.

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


Но различные роли по отношению к обрабатываемой информации - не единственный критерий. Указанные группы различаются еще и по способу взаимодействия с СУБД.

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

Но беда в том, что основные проблемы с безопасностью приходятся на две оставшиеся категории пользователей.

Проблема с аналитиками заключается в том, что они работают с СУБД на уровне ядра. Они должны иметь возможность задавать и получать всевозможные выборки информации из всех хранящихся там таблиц. Включая и запросы общего типа "select * *".

С администраторами дело обстоит ненамного лучше. Начиная с того, что в крупных информационных системах их число сопоставимо с числом аналитиков. И хотя абсолютно полными правами на СУБД наделены лишь два-три человека, администраторы, решающие узкие проблемы (например резервное копирование данных), все равно имеют доступ ко всей информации, хранящейся в СУБД.

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

Какие еще защитные механизмы можно задействовать, чтобы решить проблему безопасности данных?



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

Но и это еще не все. Очень часто обработка данных ведется не самим пользователем, а созданным и запущенным в СУБД скриптом. Так, например, поступают для формирования типовых или периодических отчетов. В этом случае скрипт запускается не от имени пользователя, а от имени системной учетной записи, что серьезно затрудняет понимание того, что же на самом деле происходит в базе данных. Притом сам скрипт может содержать практически любые команды, включая пресловутое "select * *". В ходе работы скрипт может сформировать новый массив данных, в том числе и дублирующий все основные таблицы. В итоге пользователь получит возможность работать с этим набором данных и таким образом обходить установленные нами средства аудита.

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

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



Задачу необходимо формулировать так: мы должны знать, кто, когда получает доступ к данным и к каким.

Попытка решить поставленную задачу средствами СУБД столкнется с вычислительными ресурсами серверов, поскольку помимо обработки данных им придется вести полное протоколирование своих действий. Но самое неприятное будет заключаться в том, что если за кражу информации возьмется один из администраторов, то его полномочий, скорее всего, хватит и на затирание следов своей деятельности в журналах регистрации.

Именно поэтому необходимо использовать внешние средства аудита.

Производители средств защиты готовы нам помочь средствами, которые способны контролировать и все входящие запросы и выборки данных на запуск скриптов для обработки информации, и обращения к отдельным таблицам. Подобные средства представляют собой некоторый сервис, работающий на сервере с установленной СУБД и контролирующий все обращения к базе.

Однако крупные хранилища данных работают под управлением специализированных ОС. Цены на решения для таких СУБД "кусаются". Ко всему прочему, администраторы начинают сильно переживать, что лишний установленный сервис если и не затормозит работу, то по крайней мере станет дополнительным "очагом нестабильности" системы в целом.

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

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


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

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

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


Блочные шифры


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

Наиболее простой и интуитивно понятный способ состоит в том, чтобы разбить исходный текст на блоки соответствующего размера, а затем отдельно каждый блок подвергнуть шифрующему преобразованию. Такой режим использования блочных шифров называют электронной кодовой книгой (ECB - electronic codebook). Его главный недостаток состоит в том, что одинаковые блоки исходного текста при шифровании дадут одинаковые же блоки шифр-текста - а это может существенно облегчить противнику задачу взлома. Поэтому режим ECB не рекомендуется использовать при шифровании текстов, по длине превышающих один блок - в таких случаях лучше воспользоваться одним из режимов, связывающих различные блоки между собой. По умолчанию в CryptoAPI блочные шифры используются в режиме сцепления блоков шифр-текста (CBC - cipher block chaining). В этом режиме при шифровании очередной блок исходного текста вначале комбинируется с предыдущим блоком шифр-текста (при помощи побитового исключающего ИЛИ), а затем полученная последовательность битов поступает на вход блочного шифра (рис. 14). Образующийся на выходе блок шифр-текста используется для шифрования следующего блока. Самый первый блок исходного текста также должен быть скомбинирован с некоторой последовательностью битов, но "предыдущего блока шифр-текста" еще нет; поэтому режимы шифрования с обратной связью требуют использования еще одного параметра - он называется инициализирующим вектором (IV - initialization vector).

Инициализирующий вектор должен генерироваться отдельно с помощью уже известной нам функции CryptGenRandom и, как и солт-значение, передаваться вместе с ключом в открытом виде. Размер IV равен длине блока шифра. Например, для алгоритма RC2, поддерживаемого базовым криптопровайдером Microsoft, размер блока составляет 64 бита (8 байтов).



Целостность и аутентичность информации


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

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

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

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



Цифровые конверты


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



Delphi и Windows API для защиты секретов (части 1,2,3)


Константин Виноградов, Лилия Виноградова,

Как реализовать методы криптографической защиты информации при помощи подручных средств – Windows и Delphi



Электронная цифровая подпись


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

Подписать вычисленный хеш в CryptoAPI позволяет функция CryptSignHash (хеш, описание ключа, комментарий, флаги, подпись, длина подписи). Вторым параметром может быть либо AT_KEYEXCHANGE, либо AT_SIGNATURE (в нашем случае логичнее использовать ключ подписи). Третий параметр в целях безопасности настоятельно рекомендуется оставлять пустым (nil). Флаги в настоящее время также не используются - на месте этого аргумента должен быть нуль. Готовую электронную подпись функция запишет в буфер, адрес которого содержится в предпоследнем параметре, последний же параметр будет содержать длину подписи в байтах.

На рис. 12 показана форма, позволяющая подписать заданный файл. , реализующую процесс подписания; результатом ее работы является файл, имеющий структуру, показанную на рис. 11.

Чтобы проверить правильность подписи, получатель подписанного сообщения должен иметь файл с открытым ключом подписи отправителя. В процессе проверки подписи этот ключ импортируется внутрь криптопровайдера. Проверка выполняется функцией CryptVerifySignature (хеш, подпись, длина подписи, открытый ключ, комментарий, флаги). О последних двух аргументах можно сказать то же, что и о параметрах комментарий и флаги функции CryptSignHash, назначение же остальных должно быть понятно. Если подпись верна, функция возвращает true. Значение false в качестве результата может свидетельствовать либо о возникновении ошибки в процессе проверки, либо о том, что подпись оказалась неверной. В последнем случае функция GetLastError вернет ошибку NTE_BAD_SIGNATURE. Для примера приведем наиболее значимые фрагменты программы проверки подписи:

Полный Delphi-проект примера можно найти .



Контейнеры ключей


Каждый криптопровайдер располагает базой данных, в которой хранятся долговременные ключи пользователей. База данных содержит один или более контейнеров ключей (рис.7). Пользователь может создать несколько контейнеров с различными именами (именем контейнера по умолчанию является имя пользователя в системе).

Подключение к контейнеру производится одновременно с получением контекста криптопровайдера при вызове функции CryptAcquireContext - имя контейнера ключей передается функции вторым ее аргументом. Если второй аргумент содержит пустой указатель (nil), то используется имя по умолчанию, т. е. имя пользователя. В том случае, если доступ к контейнеру не нужен, можно передать в последнем аргументе функции флаг CRYPT_VERIFYCONTEXT; при необходимости создать новый контейнер используется флаг CRYPT_NEWKEYSET; а для удаления существующего контейнера вместе с хранящимися в нем ключами - CRYPT_DELETEKEYSET.

Каждый контейнер может содержать, как минимум, две ключевые пары - ключ обмена ключами и ключ подписи. Ключи, используемые для шифрования симметричными алгоритмами, не сохраняются. Как мы уже говорили, такие ключи не рекомендуется применять более одного раза, поэтому их называют сеансовыми (англ. session key).



Криптографические возможности Windows


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

Итак, ОС мы доверяем. Чтобы криптозащиту нельзя было «обойти» с другой стороны - к примеру, перехватить из незащищенной области памяти секретные пароли - криптографические функции должны быть частью операционной системы. В семействе Windows, начиная с Windows 95, обеспечивается реализация шифрования, генерации ключей, создания и проверки цифровых подписей и других криптографических задач. Эти функции необходимы для работы операционной системы, однако ими может воспользоваться и любая прикладная программа - для этого программисту достаточно обратиться к нужной подпрограмме так, как предписывает криптографический интерфейс прикладных программ (CryptoAPI).

Разумеется, по мере совершенствования Windows расширялся и состав ее криптографической подсистемы. Помимо базовых операций, в настоящее время в CryptoAPI 2.0 поддерживается работа с сертификатами, шифрованными сообщениями в формате PKCS #7 и пр.

Описание функций CryptoAPI, помимо специальных книг, можно найти в MSDN Library.



Обмен ключами


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

PUBLICKEYBLOB - используется для сохранения открытых ключей. Поскольку открытые ключи не являются секретными, они сохраняются в незашифрованном виде; PRIVATEKEYBLOB - используется для сохранения ключевой пары целиком (открытого и закрытого ключей). Эти данные являются в высшей степени секретными, поэтому сохраняются в зашифрованном виде, причем для шифрования используется сеансовый ключ (и, соответственно, симметричный алгоритм); SIMPLEBLOB - используется для сохранения сеансовых ключей. Для обеспечения секретности данные ключа шифруются с использованием открытого ключа получателя сообщения.

Экспорт ключей в CryptoAPI выполняется функцией CryptExportKey (экспортируемый ключ, ключ адресата, формат, флаги, буфер, размер буфера):

экспортируемый ключ - дескриптор нужного ключа; ключ адресата - в случае сохранения открытого ключа должен быть равен нулю (данные не шифруются); формат - указывается один из возможных форматов экспорта (PUBLICKEYBLOB, PRIVATEKEYBLOB, SIMPLEBLOB); флаги - зарезервирован на будущее (должен быть равен нулю); буфер - содержит адрес буфера, в который будет записан ключевой BLOB (Binary Large OBject - большой двоичный объект); размер буфера - при вызове функции в этой переменной должен находиться доступный размер буфера, а по окончании работы в нее записывается количество экспортируемых данных. Если размер буфера заранее не известен, то функцию нужно вызвать с параметром буфер, равным пустому указателю, тогда размер буфера будет вычислен и занесен в переменную размер буфера.

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

Запросить у криптопровайдера дескриптор самого' экспортируемого ключа позволяет функция CryptGetUserKey (провайдер, описание ключа, дескриптор ключа). Описание ключа - это либо AT_KEYEXCHANGE, либо AT_SIGNATURE.

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

В приведены наиболее важные фрагменты программы

Экспортированные таким образом открытые части ключей понадобятся нам для проверки подписи и расшифровки сеансового ключа.

Импорт ключевых пар во вновь созданный контейнер - это самостоятельная процедура. Необходимо запросить у пользователя название контейнера и пароль, подключиться к провайдеру, создать на основании пароля ключ, считать из файла импортируемые данные в буфер, после чего воспользоваться функцией CryptImportKey (провайдер, буфер, длина буфера, ключ для расшифровки, флаги, импортируемый ключ). Если нужно обеспечить возможность экспорта импортируемой ключевой пары впоследствии, то в параметре флаги необходимо передать значение CRYPT_EXPORTABLE; в противном случае вызов для данной ключевой пары функции CryptExportKey приведет к ошибке.

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


От слов - к делу


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

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

Приведем основные фрагменты процедуры, осуществляющей шифрование и расшифровку файла (обработка ошибок опущена):

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

Полный Delphi-проект можно взять .

Продолжение статьи, посвященное сертификатам (часть 4) -

Авторы ищут издателя для публикации учебного пособия по данной теме.
Персональный сайт авторов - http://www.is.svitonline.com/vilys/.



Проблема распределения ключей


В прошлый раз при помощи CryptoAPI мы решали такую "классическую" задачу как шифрование на основе пароля. Напомним, что пароль использовался для создания ключа шифрования какого-либо симметричного алгоритма. В таком случае расшифровать файл может лишь тот, кто знает пароль. А значит, для обеспечения конфиденциальности нужно держать пароль в строжайшем секрете - желательно, чтобы его знали лишь отправитель и получатель информации. (А еще лучше, если отправитель и получатель - одно и то же лицо.)

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

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

Спасительный способ, позволяющий шифровать сообщения, обмениваясь ключами по открытым каналам связи, был придуман в середине 70-х годов прошлого столетия, а в начале восьмидесятых появился первый реализующий его алгоритм - RSA. Теперь пользователь может сгенерировать два связанных между собой ключа - ключевую пару. Один из этих ключей по несекретным каналам рассылается всем, с кем пользователь хотел бы обмениваться конфиденциальными сообщениями (рис. 4).
Этот ключ называют открытым (англ. public key). Зная открытый ключ пользователя, можно зашифровать адресованное ему сообщение, но вот расшифровать его позволяет лишь вторая часть ключевой пары - закрытый ключ (private key). При этом открытый ключ не дает "практической" возможности вычислить закрытый: такая задача, хоть и разрешима в принципе, но при достаточно большом размере ключа требует многих лет машинного времени. Для сохранения конфиденциальности получателю необходимо лишь хранить в строгом секрете свой закрытый ключ, а отправителю - убедиться, что имеющийся у него открытый ключ действительно принадлежит адресату.



Так как для шифрования и расшифровки используются различные ключи, алгоритмы такого рода назвали асимметричными. Наиболее существенным их недостатком является низкая производительность - они примерно в 100 раз медленнее симметричных алгоритмов. Поэтому были созданы криптографические схемы, использующие преимущества как симметричных, так и асимметричных алгоритмов (рис. 5):

для шифрования файла или сообщения используется быстрый симметричный алгоритм, причем ключ шифрования генерируется случайным образом с обеспечением "хороших" статистических свойств; небольшой по размерам симметричный ключ шифрования шифруется при помощи асимметричного алгоритма с использованием открытого ключа адресата и в зашифрованном виде пересылается вместе с сообщением; получив сообщение, адресат своим закрытым ключом расшифровывает симметричный ключ, а с его помощью - и само сообщение.

Описанная схема реализована и в CryptoAPI.


Шифрование с использованием паролей


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

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

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

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

по хеш-значению невозможно восстановить исходное сообщение; практически невозможно найти еще один текст, дающий такой же хеш, как и наперед заданное сообщение; практически невозможно найти два различных текста, дающих одинаковые хеш-значения (такие ситуации называют коллизиями).

При соблюдении приведенных условий хеш-значение служит компактным цифровым отпечатком (дайджестом) сообщения. Существует множество алгоритмов хеширования. CryptoAPI поддерживает, например, алгоритмы MD5 (MD - Message Digest) и SHA (Secure Hash Algorithm).


Итак, чтобы создать ключ шифрования на основании пароля, нам нужно вначале получить хеш этого пароля. Для этого следует создать с помощью CryptoAPI хеш-объект, воспользовавшись функцией CryptCreateHash (провайдер, ID_алгоритма, ключ, флаги, хеш), которой нужно передать дескриптор криптопровайдера (полученный с помощью CryptAcquireContext) и идентификатор алгоритма хеширования (остальные параметры могут быть нулями). В результате мы получим дескриптор хеш-объекта. Этот объект можно представить себе как черный ящик, который принимает любые данные и «перемалывает» их, сохраняя внутри себя лишь хеш-значение. Подать данные на вход хеш-объекта позволяет функция CryptHashData (дескриптор, данные, размер_данных, флаги).

Непосредственно создание ключа выполняет функция CryptDeriveKey (провайдер, ID_алгоритма, хеш-объект, флаги, ключ), которая принимает хеш-объект в качестве исходных данных и строит подходящий ключ для алгоритма шифрования, заданного своим ID. Результатом будет дескриптор ключа, который можно использовать для шифрования (рис. 3).

Следует обратить внимание, что при работе с CryptoAPI мы все время имеем дело не с самими объектами или их адресами, а с дескрипторами - целыми числами, характеризующими положение объекта во внутренних таблицах криптопровайдера. Сами таблицы располагаются в защищенной области памяти, так что программы-«шпионы» не могут получить к ним доступ.

Алгоритмы шифрования, поддерживаемые CryptoAPI, можно разделить на блочные и поточные: первые обрабатывают данные относительно большими по размеру блоками (например, 64, 128 битов или более), а вторые - побитно (теоретически, на практике же - побайтно). Если размер данных, подлежащих шифрованию, не кратен размеру блока, то последний, неполный блок данных, будет дополнен необходимым количеством случайных битов, в результате чего размер зашифрованной информации может несколько увеличиться. Разумеется, при использовании поточных шифров размер данных при шифровании остается неизменным.



Шифрование выполняется функцией CryptEncrypt (ключ, хеш, финал, флаги, данные, рамер_данных, размер_буфера):

через параметр ключ передается дескриптор ключа шифрования; параметр хеш используется, если одновременно с шифрованием нужно вычислить хеш-значение шифруемого текста; параметр финал равен true, если шифруемый блок текста - последний или единственный (шифрование можно осуществлять частями, вызывая функцию CryptEncrypt несколько раз); значение флага должно быть нулевым; параметр данные представляет собой адрес буфера, в котором при вызове функции находится исходный текст, а по завершению работы функции - зашифрованный; следующий параметр, соответственно, описывает размер входных/выходных данных, последний параметр задает размер буфера - если в результате шифрования зашифрованный текст не уместится в буфере, возникнет ошибка.

Для расшифровки данных используется функция CryptDecrypt (ключ, хеш, финал, флаги, данные, рамер_данных), отличающаяся от шифрующей функции только тем, что размер буфера указывать не следует: поскольку размер данных при расшифровке может только уменьшиться, отведенного под них буфера наверняка будет достаточно.

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

Полный пример приложения в формате Delphi 4 можно взять .

Конечно, шифрование вами всех файлов одним и тем же паролем облегчает «противнику» задачу их расшифровки, запоминание огромного числа паролей сильно усложняет жизнь, а их записывание в незашифрованном виде создает опасность раскрытия всей системы. CryptoAPI может предложить на этот случай ряд решений. О них поговорим ниже.


Создание ключевых пар


После создания контейнера ключей необходимо сгенерировать ключевые пары обмена ключами и подписи. Эту работу в CryptoAPI выполняет функция CryptGenKey (провайдер, алгоритм, флаги, ключ):

провайдер - дескриптор криптопровайдера, полученный в результате обращения к функции CryptAcquireContext; алгоритм - указывает, какому алгоритму шифрования будет соответствовать создаваемый ключ. Информация об алгоритме, таким образом, является частью описания ключа. Каждый криптопровайдер использует для обмена ключами и подписи строго определенные алгоритмы. Так, провайдеры типа PROV_RSA_FULL, к которым относится и Microsoft Base Cryptographic Provider, реализуют алгоритм RSA. Но при генерации ключей знать это не обязательно: достаточно указать, какой ключ мы собираемся создать - обмена ключами или подписи. Для этого используются мнемонические константы AT_KEYEXCHANGE и AT_SIGNATURE; флаги - при создании асимметричных ключей управляет их размером. Используемый нами криптопровайдер позволяет генерировать ключ обмена ключами длиной от 384 до 512 бит**, а ключ подписи - от 512 до 16384 бит. Чем больше длина ключа, тем выше его надежность, поэтому трудно найти причины для использования ключа обмена ключами длиной менее 512 бит, а длину ключа подписи не рекомендуется делать меньше 1024 бит**. По умолчанию криптопровайдер создает оба ключа длиной 512 бит. Необходимую длину ключа можно передать в старшем слове параметра флаги; ключ - в случае успешного завершения функции в этот параметр заносится дескриптор созданного ключа.

Рассмотрим пример создания ключевых пар при помощи формы, показанной на рис. 8. В поле "Контейнер" можно указать имя контейнера ключей; если оставить это поле пустым, будет использован контейнер по умолчанию. Назначение остальных элементов управления должно быть интуитивно понятным. После генерации ключа в memo-поле выводится отчет о его параметрах. Для этого используется функция CryptGetKeyParam (ключ, параметр, буфер, размер, флаги). Чтобы получить информацию о требуемом параметре, нужно через второй аргумент функции передать соответствующую константу: KP_ALGID - идентификатор алгоритма, KP_KEYLEN - размер ключа, и т. д. См. генерации ключей без операторов обработки ошибок.



Создание сеансовых ключей


CryptoAPI позволяет генерировать сеансовые ключи случайным образом - эту работу выполняет функция CryptGenKey, о которой шла речь ранее. Однако при использовании этой возможности за пределами США и Канады приходится учитывать американские ограничения на экспорт средств "сильной криптографии". В частности, до января 2000года был запрещен экспорт программного обеспечения для шифрования с использованием ключей длиной более 40 бит. Этим объясняется разработка Microsoft двух версий своего криптопровайдера - базовой и расширенной. Базовая версия предназначалась на экспорт и поддерживала симметричные ключи длиной 40 бит; расширенная же версия (Microsoft Enhanced Cryptographic Provider) работала с "полной" длиной ключа (128 бит). Поскольку алгоритм шифрования, как правило, требует использования ключа строго определенной длины, недостающее количество битв в урезанном "экспортном" ключе могло быть заполнено либо нулями, либо случайными данными, которые предлагалось передавать открыто.

В криптографической практике внесение в состав ключа определенной части несекретных данных, которые сменяются несколько раз в ходе обработки исходного или шифр-текста, используется для того, чтобы воспрепятствовать взлому шифра атакой "по словарю". В английской терминологии такие вставки называются salt values: их назначение - "подсолить" ключ (с учетом нашей ментальности можно перевести как "насолить" противнику). Поскольку этот термин используется и в CryptoAPI, будем употреблять его в транслитерированном виде - солт-значения.

Итак, CryptoAPI, в экспортном исполнении практически вынуждает нас использовать солт-значения, составляющие бОльшую часть ключа - 88 бит из 128-ми для симметричных алгоритмов в RC2; и RC4. Конечно, при такой эффективной длине ключа криптозащита не может считаться достаточно надежной. В реальной ситуации выход один - воспользоваться криптопровайдером, не ограничивающим длину ключа. Обладатели Windows XP могут прибегнуть к услугам расширенных версий провайдера Microsoft (Enhanced или Strong).
Пользователям более старых версий Windows, по-видимому, придется воспользоваться продуктами сторонних разработчиков. Например, свои версии криптопровайдеров предлагают российская компания и шведская . В Украине, насколько известно авторам, разработкой национального провайдера криптографических услуг занимается коллектив харьковских ученых под руководством профессора Горбенко, однако до широкого внедрения дело пока не дошло. Тем не менее, благодаря архитектуре CryptoAPI, прикладные программы могут разрабатываться и отлаживаться и с базовым провайдером Microsoft - так как интерфейс взаимодействия остается неизменным. Поэтому вернемся к обсуждению создания случайных сеансовых ключей.

Солт может быть сгенерирован вместе с ключом: для этого нужно в качестве флага передать функции CryptGenKey (или CryptDeriveKey) константу CRYPT_CREATE_SALT. Правда, при сохранении ключа (с помощью функции CryptExportKey) система уже не заботится о солт-значении, перекладывая ответственность на прикладную программу. Таким образом, корректная процедура создания и сохранения симметричного ключа предполагает:

1. при создании ключа функции CryptGenKey передается значение флага CRYPT_EXPORTABLE or CRYPT_CREATE_SALT;

2. с помощью функции CryptGetKeyParam с параметром KP_SALT сгенерированное солт-значение сохраняется в буфере;

3. ключ в зашифрованном виде сохраняется в буфере при помощи функции CryptExportKey, которой передается открытый ключ обмена ключами адресата;

4. зашифрованные ключевые данные сохраняются или передаются адресату вместе с экспортированным на втором шаге солт-значением.

С другой стороны, солт-значение может быть сгенерировано и отдельно от ключа. Для этого используется функция CryptGenRandom (провайдер, длина, буфер). Здесь параметр длина задает размер генерируемой случайной последовательности в байтах, а последний аргумент задает адрес буфера, в который будет записан результат. Полученное таким образом солт-значение может быть внесено в ключ с помощью функции CryptSetKeyParam (ключ, параметр, данные, флаги).Ей вторым аргументом нужно передать KP_SALT, а третьим - адрес буфера, содержащего сгенерированную последовательность. (Последний аргумент функции зарезервирован на будущее и должен быть равен нулю.)


Взаимодействие с CryptoAPI


Функции CryptoAPI можно вызвать из программы, написанной на любимом многими (в том числе и авторами) языке С++. Тем не менее, Pascal де-факто признан стандартом в области обучения программированию. (Не будем спорить о том, хорошо это или плохо, чтобы не ввязываться в драку, пусть даже и виртуальную.) Кроме того, в ряде отечественных компаний Delphi является базовым средством разработки. Поэтому все примеры были реализованы в среде Delphi. Хотя в качестве инструмента можно было бы выбрать и MS Visual C++.

Код функций криптографической подсистемы содержится в нескольких динамически загружаемых библиотеках Windows (advapi32.dll, crypt32.dll). Для обращения к такой функции из прикладной программы на Object Pascal следует объявить ее как внешнюю. Заголовок функции в интерфейсной части модуля будет выглядеть, например, так: function CryptAcquireContext ( phPROV: PHCRYPTPROV; pszContainer: LPCTSTR; pszProvider: LPCTSTR; dwProvType: DWORD; dwFlags: DWORD): BOOL; stdcall;

а в исполняемой части вместо тела функции нужно вписать директиву extern с указанием библиотеки, в которой содержится функция, и, возможно, ее имени в этой библиотеке (если оно отличается от имени функции в создаваемом модуле), например: function CryptAcquireContext; external ‘advapi32.dll’ name 'CryptAcquireContextA';

Таким образом, имея описание функций CryptoAPI, можно собрать заголовки функций в отдельном модуле, который будет обеспечивать взаимодействие прикладной программы с криптографической подсистемой. Разумеется, такая работа была проделана программистами Microsoft, и соответствующий заголовочный файл (wincrypt.h) был включен в поставку MS Visual C++. К счастью, появилась и Delphi-версия (wcrypt2.pas). Ее можно найти . Подключив модуль к проекту, вы сможете использовать не только функции CryptoAPI, но и мнемонические константы режимов, идентификаторы алгоритмов и прочих параметров, необходимых на практике.

И последнее замечание перед тем, как опробовать CryptoAPI в деле. Ряд функций был реализован только в Windows 2000. Но и на старушку Windows 98 можно найти управу: при установке Internet Explorer 5 интересующие нас библиотеки обновляются, позволяя использовать новейшие криптографические возможности. Нужно лишь задать для Delphi-проекта параметр условной компиляции NT5, после чего вызовы функций, появившихся лишь в Windows 2000, будут нормально работать.



Знакомство с криптопровайдерами


Функции CryptoAPI обеспечивают прикладным программам доступ к криптографическим возможностям Windows. Однако они являются лишь «передаточным звеном» в сложной цепи обработки информации. Основную работу выполняют скрытые от глаз программиста функции, входящие в специализированные программные (или программно-аппаратные) модули — провайдеры (поставщики) криптографических услуг (CSP - Cryptographic Service Providers), или криптопровайдеры (рис. 1).

Программная часть криптопровайдера представляет собой dll-файл, подписанный Microsoft; периодически Windows проверяет цифровую подпись, что исключает возможность подмены криптопровайдера.


Криптопровайдеры отличаются друг от друга:

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

По составу функций и обеспечивающих их алгоритмов криптопровайдеры подразделяются на типы. Например, любой CSP типа PROV_RSA_FULL поддерживает как шифрование, так и цифровые подписи, использует для обмена ключами и создания подписей алгоритм RSA, для шифрования — алгоритмы RC2 и RC4, а для хеширования - MD5 и SHA.

В зависимости от версии операционной системы состав установленных криптопровайдеров может существенно изменяться. Однако на любом компьютере с Windows можно найти Microsoft Base Cryptographic Provider, относящийся к уже известному нам типу PROV_RSA_FULL. Именно с этим провайдером по умолчанию будут взаимодействовать все программы.

Использование криптографических возможностей Windows напоминает работу программы с графическим устройством. Криптопровайдер подобен графическому драйверу: он может обеспечивать взаимодействие программного обеспечения с оборудованием (устройство чтения смарт-карт, аппаратные датчики случайных чисел и пр.).
Для вывода информации на графическое устройство приложение не должно непосредственно обращаться к драйверу — вместо этого нужно получить у системы контекст устройства, посредством которого и осуществляются все операции. Это позволяет прикладному программисту использовать графическое устройство, ничего не зная о его аппаратной реализации. Точно так же для использования криптографических функций приложение обращается к криптопровайдеру не напрямую, а через CryptoAPI. При этом вначале необходимо запросить у системы контекст криптопровайдера.

Первым делом, хотя бы из любопытства, выясним, какие же криптопровайдеры установлены в системе. Для этого нам понадобятся четыре функции CryptoAPI (выходные параметры выделены жирным шрифтом, а входные - курсивом):

CryptEnumProviders (i, резерв, флаги, тип, имя, длина_имени) - возвращает имя и тип i-го по порядку криптопровайдера в системе (нумерация начинается с нуля); CryptAcquireContext (провайдер, контейнер, имя, тип, флаги) - выполняет подключение к криптопровайдеру с заданным типом и именем и возвращает его дескриптор (контекст). При подключении мы будем передавать функции флаг CRYPT_VERIFYCONTEXT, служащий для получения контекста без подключения к контейнеру ключей; CryptGetProvParam (провайдер, параметр, данные, размер_данных, флаги) - возвращает значение указанного параметра провайдера, например, версии (второй параметр при вызове функции - PP_VERSION), типа реализации (программный, аппаратный, смешанный - PP_IMPTYPE), поддерживаемых алгоритмов (PP_ENUMALGS). Список поддерживаемых алгоритмов при помощи этой функции может быть получен следующим образом: при одном вызове функции возвращается информация об одном алгоритме; при первом вызове функции следует передать значение флага CRYPT_FIRST, а при последующих флаг должен быть равен 0; CryptReleaseContext (провайдер, флаги) - освобождает дескриптор криптопровайдера.

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

Текст процедуры, выводящей в Memo-поле FileMemo формы информацию об установленных в системе криптопровайдерах, приведен в . Предполагается, что процедура вызывается при выборе соответствующего элемента в главном меню формы. Для краткости в тексте программы опущены фрагменты, выполняющие обработку ошибок.

На рис. 2 показан пример отчета, выдаваемого приведенным выше кодом, выполненным в среде Windows 98.