Безопасность -> Интернет -> Вопросы и ответы по безопасности данных в WWW

	Наверх, к Содержание
Назад, к Поддержка защищенного сервера		Вперед, к Скрипты CGI

5. Защита конфиденциальных документов на вашем сервере

В17: Какие существуют типы ограничения доступа?

1. Ограничения на основе IP адреса, подсети или домена.

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

2. Ограничения по имени пользователя и паролю

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

3. Шифрование с использованием открытого ключа (public key cryptography)

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

В18: Насколько надежно ограничение по IP адресу или имени домена?

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

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

Ограничения доступа по имени компьютера или домена, обладающие теми же слабостями, что и ограничения по IP адресам, чуствительны, кроме того, к "замазыванию имен DNS" (DNS spoofing) - атаке, при которой ваш сервер убеждают на время в том, что разрешенное имя соответствует другому (нужному хакеру) IP адресу. Для уменьшения подобного риска некоторые серверы могут быть настроены на дополнительную проверку имени DNS для каждого клиента. После преобразования IP адреса, с которого пришел запрос, в имя компьютера, сервер использует систему DNS для обратного преобразования имени в адрес IP. Если два IP адреса не совпадают, то доступ не предоставляется. Смотри ниже инструкции по использованию этой возможности в NCSA httpd.

В19: Насколько надежны ограничения доступа по имени пользователя и паролю?

Другая проблема состоит в возможности перехвата пароля при его передаче по сети от браузера на сервер. Хакер, обладающий соответствующим оборудованием и программами, имеет возможность "вытащить" пароль из Internet при его прохождении. Кроме того, в отличие от прямого входа (login) пользователя в систему, когда пароль передается по Сети только один раз, браузер посылает пароль заново при каждом обращении к защищенному документу, что делает задачу хакера по перехвату пароля более легкой. Для избежания перехвата необходимо шифровать данные при передаче. Смотри далее.

Если вам необходимо защищать документы от доступа _локальных_ пользователей системы, на которой установлен сервер, то вам придется запускать сервер с правами, отличными от прав пользователя "nobody", и устанавливать права доступа к файлам документов и скриптов CGI так, чтобы они не были общедоступны для чтения. Смотри В9.

В20: Что такое проверка пользователя (user authentication)?

В21: Как мне ограничить доступ к документам по IP адресу или имени домена удаленного браузера?

   <Directory /полный/путь/к/директорию>




     <Limit GET POST>

       order mutual-failure

       deny from all

       allow from 192.198.2 .zoo.org

       allow from 18.157.0.5 stoat.outback.au

     </Limit>



   </Directory>

Таким образом вы запрещаете доступ для всех, кроме указанных машин (18.157.0.5 и stoat.outback.au), подсети (182.198.2) и домена (.zoo.org). Хотя имеется возможность использовать либо цифровые IP адреса, либо имена машин, безопаснее использовать цифровые адреса, поскольку этот способ идентификации труднее "обмануть" (В18).

Один из способов повышения надежности ограничений по именам доменов состоит в настройке сервера на двойную проверку имен DNS. Вы можете включить эту возможность в NCSA httpd (и в родственном сервере Apache) установив флаг -DMAXIMUM_DNS в файле Makefile перед компиляцией.

Для сервера CERN необходимо объявить схему защиты при помощи директивы Protection и связать ее с локальным адресом URL директивой Protect. Фрагмент файла httpd.conf, разрешающий доступ только из определенных доменов, может выглядеть следующим образом:

   Protection LOCAL-USERS {


     GetMask @(*.capricorn.com, *.zoo.org, 18.157.0.5)

   }


   Protect /относительный/путь/к/директорию/* LOCAL-USERS

В22: Как мне добавить новых пользователей и пароли?

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

   htpasswd /путь/к/файлу/паролей имя_пользователя

Сервер CERN снабжен иной программой, называемой htadm:

   htadm -adduser /путь/к/файлу/паролей имя_пользователя

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

   <Directory /полный/путь/к/защищаемому/директорию>



     AuthName          имя.вашего.сервера

     AuthType          Basic

     AuthUserFile      /usr/local/etc/httpd/conf/passwd

     <Limit GET POST>

       require valid-user

     </Limit>



</Directory>

Для сервера CERN соответствующий фрагмент файла httpd.conf выглядит примерно так:

   Protection AUTHORIZED-USERS {

     AuthType     Basic

     ServerID     имя.вашего.сервера

     PasswordFile /usr/local/etc/httpd/conf/passwd

     GetMask      All

}

Protect /относительный/путь/к/директорию/* AUTHORIZED-USERS

В23: Существуют ли скрипты CGI, позволяющие пользователю изменять его пароль при работе с сервером?

http://www.genome.wi.mit.edu/~lstein/user_manage/

Bill Jones написал многофункциональный скрипт под названием WebPass. Кроме пароля Web пользователи могут изменять свои пароли для входа в систему и для доступа к POP и news серверам, если они имеют такие пароли. Скрипт использует сочетание Perl и Expect для осуществления этих чудес. Скрипт можно найти по адресу:

http://webmaster.fccj.cc.fl.us/Webmaster/WebPass.html

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

В24: Использование для управления доступом к директориям индивидуальных файлов контроля так удобно, почему я должен использовать файл access.conf?

   http://имя.вашего.узла/защищенный/директорий/.htaccess

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

В25: Как работает шифрование?

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

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

Более подробную информацию о шифровании с открытыми ключами можно найти в книге "Applied Cryptography", автор - Bruce Schneier.

В26: Что такое: SSL, SHTTP, Shen?

SSL (Secure Socket Layer) - это схема, предложенная Netscape Communications Corporation. Это схема шифрования на низком уровне, используемая для кодирования транзакций протоколов более высокого уровня, таких как HTTP, NNTP и FTP. Протокол SSL поддерживает проверку сервера (server authentication - подтверждение идентичности сервера для клиента), шифрование данных при передаче и возможность проверки клиента (client authentication, подтверждение идентичности клиента для сервера). SSL в настоящее время реализован коммерчески в различных браузерах, включая Netscape Navigator, Secure Mosaic и Microsoft Internet Explorer; и в различных серверах, включая серверы Netscape, Microsoft, IBM, Quarterdeck, OpenMarket и O'Reilly and Associates. Детали протокола SSL можно найти по адресу:

http://home.netscape.com/newsref/std/SSL.html

SHTTP (Secure HTTP - безопасный HTTP) - это схема, предложеная CommerceNet, объединением организаций, заинтересованных в развитии Internet для коммерческого использования. Это протокол более высокого уровня, который работает только с протоколом HTTP, но потенциально более расширяемый, чем SSL. В настоящее время SHTTP реализован для сервера Open Marketplace Server, распространяемого компанией Open Market, Inc, на стороне сервера и в Secure HTTP Mosaic от Enterprise Integration Technologies на стороне клиента. Здесь можно найти детали:

http://www.eit.com/creations/s-http/

Shen - схема, предложенная Phillip Hallam-Baker из CERN. Подобно SHTTP, это замена существующего протокола HTTP. Хотя предложение существовало около двух лет, оно не было реализовано ни в одном браузере или сервере. Более того, поскольку URL с описанием Shen более не доступен, есть основания считать эту схему отмершей.

В27: Существуют ли некоммерческие ("freeware") защищенные серверы?

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

The SSLeay FAQ

http://www.psy.uq.oz.au/~ftp/Crypto/. Вам придется это внимательно прочесть.

SSLeay

Это собственно библиотека SSL. Она может быть получена через FTP на ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL/

Исправления (patches) для различных приложений Internet

Это исправления для исходных текстов telnet, ftp, Mosaic и им подобных, необходимые для использования SSL. Их можно получить по FTP: ftp://ftp.psy.uq.oz.au/pub/Crypto/SSLapps/.

Исправления для сервера Apache

В настоящее время есть исправления для серверов Apache 0.8.14h и 1.0.1a. Исправления могут работать и для других версий, но это не гарантировано. ftp://ftp.ox.ac.uk/pub/crypto/SSL/

Исходные тексты сервера Apache

http://www.apache.org

После установки поддерживающего SSL сервера вам необходимо получить удостоверение сервера (server certificate) от утверждающей организации. Сертификаты предоставляют различные компании, со слегка различающимися правилами подачи заявки и расценками. В США первой была корпорация VeriSign Corporation, которая остается наиболее популярной и в настоящее время. Однако, по причине недавнего поднятия цен корпорацией VeriSign ($495 за сертификат коммерческого сервера) она стала одной из самых дорогих. Хорошей альтернативой VeriSign является Thawte Consulting; их цены значительно ниже и процедура подачи заявки для компаний за пределами США проще. Другие сертифицирующие организации включают:

Entrust

http://www.entrust.com/

GTE CyberTrust

http://www.cybertrust.gte.com/

EuroSign

http://eurosign.com

COST

http://www.cost.se

BiNARY SuRGEONS

http://www.surgeons.co.za/certificate.html

Keywitness

http://www.keywitness.ca

SoftForum

http://www.softforum.co.kr/

CompuSource

http://www.compusource.co.za/

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

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

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

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

В28: Можно ли использовать личные сертификаты (Personal Certificates) для контроля доступа к серверу?

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

Если вы используете интранет, то вам может иметь смысл создать свои собственные личные сертификаты для использования служащими вашей компании. Для этого вам необходимо получить и установить сервер сертификатов. Такие системы можно получить у следующих компаний: Microsoft, Netscape, XCert, Entrust и GTE.

Для использования личных сертификатов с целью контроля доступа к серверу вам необходимо будет настроить сервер соответствующим образом. Обсуждение того, как это сделать, выходит за рамки рассмотрения настоящего документа, но подробные инструкции содержатся в книге автора оригинального документа The Web Security Reference Guide, которая будет доступна в декабре 1997 года.

В29: Как получать заказы по кредитным картам через Web?

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

В30: Что такое: First Virtual Accounts, DigiCash, CyberCash, SET?

First Virtual

Перед использованием системы First Virtual потребитель должен подписаться и получить счет, заполнив форму ввода на узле First Virtual (см. ниже). Процесс подписки заканчивается по телефону. В ходе подписки потребитель предоставляет информацию о номере своей кредитной карты, информацию для контакта, и получает свой персональный идентификационный номер (PIN, Personal Identification Number) в системе First Virtual. Далее при заказах у членов First Virtual потребитель использует свой номер PIN вместо номера кредитной карты. Прежде чем снимать деньги с карты, First Virtual запросит подтверждения заказа по электронной почте. Чтобы открыть счет в системе First Virtual потребитель должен уплатить разовый сбор в размере двух долларов США. Дополнительных выплат нет, и пользователю не требуется устанавливать у себя какого-либо специального программного обеспечения для использования системы.

Поставщики, желающие принимать оплату через систему First Virtual, должны открыть в системе счет за одноразовую плату в размере $10.00. First Virtual предоставит поставщику простую программу для проверки пользовательских номеров PIN и информирующую First Virtual о полученных заказах. Эта программа легко может быть использована в скрипте CGI, принимающем заказ. First Virtual получает с поставщика плату в размере $0.29 за каждый заказ плюс 3% от суммы заказа.

Дальнейшую информацию о First Virtual можно получить по адресу:

http://www.fv.com/

DigiCash

Программное обеспечение, поддерживающее DigiCash, препятствует повторному использованию КиберБаксов. Как и настоящие деньги, КиберБаксы могут быть использованы анонимно. Вы не должны идентифицировать себя для того, чтобы иметь возможность потратить или получить "цифровую валюту", и ее использование не оставляет следов. Это отличает систему DigiCash от систем, основанных на кредитных картах, таких, как CyberCash и SET, в которых каждая операция фиксируется на бумаге, что может быть использовано для изучения привычек потребителя. В дополнение, DigiCash может использоваться для безопасной передачи денег между индивидуумами, позволяя обычным людям продавать услуги и товары через Internet без вовлечения банковской системы.

DigiCash требует установки специальных программ на компьютерах заказчика и продавца. В настоящее время имеются версии для Windows 95, Windows NT и некоторых систем Unix. В силу своей молодости эта система пока не получила широкого распространения, однако ситуация должна измениться. Дальнейшую информацию, включая список банков, поддерживающих DigiCash, можно получить на URL:

http://www.digicash.nl/

CyberCash

При заказе в магазине, поддерживающем CyberCash, wallet открывает окно и запрашивает у пользователя информацию о выборе системы оплаты. Пользователь может выбрать оплату через кредитную карту или переводом со счета. Программа, установленная на стороне продавца, проверяет и фиксирует операцию, соединяясь с сервером CyberCash. Этот процесс занимает 10-15 секунд. Wallet ведет учет всех заказов, позволяя пользователю сверять данные записей с информацией о состоянии кредитной карты или счета, полученной из банка. Программа доступна для многих платформ, включая Macintosh, Windows 95 и Windows NT.

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

Для того, чтобы принимать платежи через CyberCash, продавцу необходимо открыть счет в банке, поддерживающем систему. Счет похож на счет, открываемый для принятия платежей по кредитным картам через заказы по почте, и требует примерно тех же затрат: разовая выплата 100 долларов при открытии счета, примерно 15 долларов в месяц для его поддержания и выплаты 2-3% от стоимости с каждого заказа. Точные расценки устанавливаются самостоятельно местными банками и могут несколько различаться. Сейчас несколько сотен банков поддерживают систему CyberCash, и это число постоянно растет.

После открытия счета продавец устанавливает у себя на сервере программу "электронный регистратор валюты" (Electronic Cash Register). Программа запускается при нажатии заказчиком кнопки "заплатить" ("pay") или ее аналога и берет на себя соединение, создавая запись, которую продавец может использовать в своей системе доставки. Программа распространяется бесплатно и существует в вариантах для различных платформ, включая Windows NT и Unix.

Основное преимущество системы CyberCash в сравнении с DigiCash состоит в том, что заказчик обеспечен в ней той же степенью защиты потребителя, которую дает кредитная карта сама по себе. Если продавец не предоставляет товар, или предоставляет товар неудовлетворительного качества, то потребитель может обратиться в компанию, выдавшую кредитную карту. Недостатки включают потерю анонимности, характерную для всех расчетов по кредитным или дебетным картам и невозможность осуществления расчетов между равными. Кроме того, выплаты продавцов за обработку заказов делают систему невыгодной для мелких поставщиков, таких как поставщиков интерактивных видеоигр. Эта последняя проблема однако решается CyberCash путем введения системы CyberCoin, позволяющей заказчику вносить единовременно некоторую сумму, после чего использовать ее частями в мелких заказах.

Для получения дальнейшей информации можно обратиться на http://www.cybercash.com

SET

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

SET требует специального программного обеспечения и на стороне продавца, и на стороне покупателя. По крайней мере, на стороне заказчика программа может быть загружена тут же в форме апплета Java и/или элемента ActiveX. В настоящее время имеются два продукта, поддерживающие SET. Microsoft Merchant - система, предлагаемая фирмой Microsoft Corporation. Построенный вокруг Internet Information Server, Microsoft Merchant предлагает проверку кредитных карт с использованием службы Verifone. Вдобавок, Microsoft Merchant предлагает такие услуги, как поддержание каталогов, скрипты для заказов, вычисление налогов с продаж. Microsoft Merchant существовал в виде предварительной (beta) версии в ноябре 1996 года, и должен быть доступен в то время, когда вы это читаете.

В свою очередь, корпорация Netscape, в сотрудничестве со своим стратегическим партнером First Data, предлагает LivePayment. Это - добавочный модуль для сервера Netscape Secure Commerce Server, предоставляющий возможность защищенной передачи, прверки и обработки информации о кредитноц карте. вы можете добавлять модули для поддержки каталогов, связи с корпоративной базой данных и другие. В его теперешней реализации, LivePayment использует предшественник SET, похожий на стандарт, но не идентичный. Полностью SET-совместимая версия должна быть выпущена в скором времени.

Open Market Web Commerce System

http://www.openmarket.com

	Наверх, к Содержание
Назад, к Поддержка защищенного сервера		Вперед, к Скрипты CGI