Данные МЭ выполняют также функцию трансляции адресов (NAT), скрывая внутреннюю структуру сети от внешних пользователей. Они выполняют преобразование внутренних IP-адресов сети в один «надежный» IP-адрес, ассоциируемый с МЭ. Внешние пользователи открытой сети «видят» только внешний IP-адрес шлюза.

Недостатком шлюзов сетевого уровня является невозможность фильтрации трафика «внутри службы».

Шлюз прикладного уровня

Данные МЭ позволяют не только пропускать либо не пропускать определенные службы, но и осуществлять фильтрацию трафика «внутри» таких служб, как TELNET, FTP, HTTP и т. д. Например, пользователю внутри FTP соединения может быть запрещено использовать команду put. Данные МЭ используют стойкие протоколы аутентификации пользователей, не позволяющие осуществить подмену доверенного источника, позволяют снизить вероятность взлома систем с использованием уязвимостей ПО.

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

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

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

Рис. 8.2. Защита бастиона серверов

На рис. 8.3 представлен еще один вариант подключения МЭ – с выделением демилитаризованной зоны (DMZ). Организация DMZ предназначена для защиты хостов данной зоны от атак из INTERNET, а также от внутренних пользователей организации. В DMZ могут выноситься WEB, FTP SMTP, DNS серверы и пр.

Рис. 8.3. Схема подключения двух МЭ с введением демилитаризованной зоны

8.4.  Виртуальные частные сети (VPN)

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

Естественный вариант реализации такого объединения локальных сетей, мобильных пользователей в единую корпоративную сеть, видится с привлечением каналов открытой сети INTERNET. Основными задачами, которые должны быть решены при этом, являются [2,25]:

1.  Аутентификация взаимодействующих сторон.

2.  Криптографическая защита передаваемой информации.

3.  Подтверждение подлинности и целостности доставленной информации.

4.  Защита от повтора, задержки и удаления сообщений.

5.  Защита от отрицания фактов отправления и приема сообщений.

Данные проблемы позволяют эффективно решить виртуальные частные сети (Virtual Private Network), к использованию которых все больше склоняются многие крупные компании.

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

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

Рис. 8.4. Пример организации виртуальной частной сети

Известно несколько наиболее часто используемых способов образования защищенных виртуальных каналов [26].

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

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

3.  Конечные точки – провайдеры INTERNET. В этом случае не защищаются каналы локальной сети и выделенные каналы связи, защищаются только каналы INTERNET.

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

Канальному уровню соответствуют такие протоколы реализации VPN, как PPTP, L2F, L2TP. Сетевому уровню соответствуют протоколы IPSec, SKIP. Сеансовому уровню – SSL, SOCKS. Чем ниже уровень эталонной модели OSI, на котором реализуется защита, тем она прозрачнее для приложений и незаметнее для пользователей. Однако при снижении этого уровня уменьшается набор реализуемых услуг безопасности и становится труднее организация управления. Оптимальное соотношение между прозрачностью и качеством защиты достигается при формировании защищенных виртуальных каналов на сетевом уровне модели OSI.

Протокол SKIP

Протокол SKIP (Simple Key management for Internet Protocol) управляет ключами шифрования и обеспечивает прозрачную для приложения криптозащиту IP-пакетов на сетевом уровне модели OSI.

SKIP предусматривает самостоятельное формирование противоположными сторонами общего секретного ключа на основе ранее распределенных или переданных друг другу открытых ключей сторон. Выработка общего секретного ключа KAB осуществляется в рамках протокола Диффи-Хеллмана.

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

1.  Исходный IP пакет шифруется на пакетном ключе Kp и инкапсулируется в защищенный SKIP пакет.

2.  Пакетный ключ Kp шифруется на общем секретном ключе KAB и помещается в SKIP заголовок.

3.  Полученный SKIP-пакет инкапсулируется в результирующий IP-пакет.

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

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

Организация виртуальных частных сетей, основанных на протоколе SKIP, реализована в семействе продуктов VPN «ЗАСТАВА» компании ЭЛВИС+. Кроме этого, широко используемыми продуктами построения VPN являются «ТРОПА» компании Застава-JET, F-Secure VPN+ компании F-Secure Corporation, Check Point VPN-1/Firewall-1 и др.

8.5.  Доменная архитектура в Windows NT. Служба Active Directory

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

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

Базы данных доменов Windows NT не поддерживают иерархической структуры и не могут быть распределены между несколькими серверами Windows NT. Эти обстоятельства существенно ограничивают максимальное количество объектов в домене. Однодоменная структура в Windows NT может быть реализована, если число пользователей измеряется одной - двумя сотнями. Для управления сетями Windows NT больших масштабов фирма Microsoft предлагает использовать многодоменную структуру и доверительные отношения между доменами. Доверительные отношения между доменами обеспечивают междоменное администрирование, позволяя предоставлять пользователям из одного домена доступ к ресурсам другого домена.

Реализация доменной архитектуры в Windows NT имеет ряд серьезных недостатков, которые Microsoft попыталась преодолеть в Windows 2000 за счет введения службы Active Directory.

Active Directory (AD) – это объектно-ориентированная, иерархическая, распределенная система базы данных службы каталогов, которая обеспечивает централизованное хранение информации об оборудовании, программном обеспечении и человеческих ресурсах всей корпоративной сети [27].

Active Directory включает в себя следующие компоненты:

1.  Объекты.

2.  Домены.

3.  Организационные единицы.

4.  Деревья.

5.  Леса.

Под объектом в AD понимают определяющие ресурс набор атрибутов (имя, собственные права доступа, права доступа к объекту, дополнительная информация об объекте и т. д.). Пользователи сети представлены объектами в службе каталогов. Администраторы могут применять эти объекты для предоставления пользователям доступа к ресурсам корпоративной сети. Ресурсы также представляются в виде объектов. Группы доменов могут быть объединены в дерево, группы деревьев – в лес. В Active Directory права и разрешения объектов распространяются вниз по дереву.

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

Дерево в AD - это иерархия нескольких доменов (рис. 8.5), лес – множество деревьев.

В AD используется система аутентификации Kerberos, основанная на протоколе Нидхема-Шредера выдачи мандатов (билетов), предъявление которых позволяет получить доступ субъекта к некому сетевому ресурсу.

Рис. 8.5. Дерево AD

8.6.  Централизованный контроль удаленного доступа. Серверы аутентификации

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

Рис. 8.6. Схема централизованного контроля удаленного доступа

Сервер аутентификации исполняет роль посредника во взаимодействии между серверами удаленного доступа и центральной базой данных системы защиты. Централизованный контроль удаленного доступа к ресурсам сети с помощью сервера аутентификации выполняют на основе специализированных протоколов. Эти протоколы позволяют объединить серверы удаленного доступа и сервер аутентификации в единую подсистему, выполняющую все функции контроля удаленных соединений на основе взаимодействия с центральной базой данных системы защиты. Сервер аутентификации в данном случае создает единую точку наблюдения и проверки всех удаленных пользователей и контролирует доступ к компьютерным ресурсам в соответствие с установленными правилами. Наиболее известными протоколами централизованного контроля удаленного доступа являются протоколы TACACS (Terminal Access Controller Access Control System) и RADIUS (Remote Authentication Dial-In User Service).

В системах, основанных на протоколах TACACS и RADIUS, администратор может управлять базой данных идентификаторов и паролей пользователей, предоставлять им привилегии доступа и вести учет обращений к системным ресурсам. В рамках данных протоколов сервер аутентификации может иметь как собственную базу данных системы защиты, так использовать и службы каталогов – Novell Directory Services (NDS), Active Directory (AD).

8.7.  Прокси – сервер

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

Чаще всего прокси-серверы применяются для следующих целей:

1.  Обеспечение доступа с компьютеров локальной сети в Интернет.

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

3.  Сжатие данных: прокси-сервер загружает информацию из Интернета и передаёт информацию конечному пользователю в сжатом виде. Такие прокси-серверы используются в основном с целью экономии внешнего трафика.

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

5.  Ограничение доступа из локальной сети к внешней: например, можно запретить доступ к определённым веб-сайтам, ограничить использование интернета каким-то локальным пользователям, устанавливать квоты на трафик или полосу пропускания, фильтровать рекламу и вирусы.

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

Многие прокси-серверы используются для нескольких целей одновременно. Некоторые прокси-серверы ограничивают работу несколькими портами: 80 (Браузер - ), 443 (Шифрованное соединение (HTTPS)), 20,21 (FTP).

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

Большинство браузеров также наделены способностями к просмотру оглавления FTP - серверов.

HTTPS — расширение протокола HTTP, поддерживающее шифрование. Данные, передаваемые по протоколу HTTP, «упаковываются» в криптографический протокол SSL или TLS, тем самым обеспечивается защита этих данных. В отличие от HTTP, для HTTPS по умолчанию используется TCP-порт 443. Эта система была разработана компанией Netscape Communications Corporation, чтобы обеспечить аутентификацию и защищенное соединение. HTTPS широко используется в мире Веб для приложений, в которых важна безопасность соединения, например, в платежных системах.

В настоящее время HTTPS поддерживается наиболее популярными браузерами.

FTP (англ. File Transfer Protocol — протокол передачи файлов) — протокол, предназначенный для передачи файлов в компьютерных сетях. FTP позволяет подключаться к серверам FTP, просматривать содержимое каталогов и загружать файлы с сервера или на сервер; кроме того, возможен режим передачи файлов между серверами (см. FXP).

FTP является одним из старейших прикладных протоколов, появившимся задолго до HTTP, в 1971 году. До начала 90-х годов на долю FTP приходилось около половины трафика в сети Интернет. Он и сегодня широко используется для распространения ПО и доступа к удалённым хостам.

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

В отличие от шлюза прокси-сервер чаще всего не пропускает ICMP-трафик (невозможно проверить доступность машины командами ping и tracert).

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

9. Защита программного обеспечения

9.1. Проблема защиты программного обеспечения

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

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

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

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

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

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

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

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

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

Организационно-экономические меры

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

К данным мерам относят:

1. Обеспечение подробной пользовательской документацией.

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

3. Горячая линия для справки, тех. поддержка.

4. Регулярное оповещение об изменениях и обнаруженных ошибках.

5. Обучение пользователей, организация семинаров.

6. Обновление версий со скидкой и т. д.

Правовые меры

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

Технические меры

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

9.2.  Модульная архитектура технических средств защиты ПО

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

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

Основными требованиями к системе защиты ПО от несанкционированного использования являются следующие:

-  система защиты должна выявлять факт несанкционированного запуска программы;

-  система защиты должна реагировать на факт несанкционированного запуска программы;

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

На рисунке 9.1 представлена иерархия модулей системы защиты ПО от несанкционированного использования, а также направления взаимодействия данных модулей.

Рис. 9.1. Модульная архитектура системы защиты ПО от несанкционированного использования

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

· подсистемы внедрения механизмов системы защиты;

· внедряемого защитного кода.

Последний блок, в свою очередь, состоит из двух подсистем:

·  подсистемы реализации защитных функций и

·  подсистемы противодействия нейтрализации защитных механизмов

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

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

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

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

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

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

1. Разработчик программы внедряет защитные механизмы в защищаемую программу.

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

3. При каждом запуске программы выполняются следующие действия:

-  снимаются текущие характеристики среды;

-  текущие характеристики сравниваются с эталонными;

-  если сравнение характеристик дало положительный результат, то ПО запускается (либо продолжает работать);

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

Рассмотрим более подробно функциональное назначение каждой из подсистем и модулей.

9.3.Функционирование подсистем и модулей системы защиты ПО

Подсистема внедрения управляющих механизмов

Системы защиты ПО от несанкционированного использования по способу ассоциации (внедрения) защитного механизма можно подразделить на два типа [0,Error! Reference source not found.,Error! Reference source not found.]:

·  встроенные системы (внедряются при создании ПО);

·  пристыковочные системы (подключаются к уже готовому ПО).

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

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

У каждого вида защит есть свои преимущества и недостатки.

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

К преимуществам защит пристыковочного типа относятся:

-  простота тиражирования программных систем защиты;

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

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

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

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

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

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

Подсистема противодействия нейтрализации защитных механизмов

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

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

Блок ответной реакции

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

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

Блок сравнения характеристик среды

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

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

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

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

Из за большого объема этот материал размещен на нескольких страницах: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16