Russian LinkExchange Member

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

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

Существует три типа ограничения прав доступа:

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

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

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

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

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

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

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

Ограничение доступа по IP адресу эффективно против случайных попыток доступа, но не против хакера, действующего целенаправленно. Существуют различные способы обхода такого рода ограничений. Имя необходимую аппаратуру и программное обеспечение, хакер может "замазать" свой 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: Насколько надежны ограничения доступа по имени пользователя и паролю?

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

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

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

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

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

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

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

   <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: Как мне добавить новых пользователей и пароли?

Серверы на основе систем Unix используют файлы, подобные файлам passwd и group системы Unix. Хотя формат этих файлов таков, что позволяет использовать для сервера Web те же файлы, что и для самой операционной системы, делать этого не следует. Незачем давать хакеру, нашедшему пароль для доступа к серверу WWW, право на вход в систему Unix.

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

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

htpasswd попросит вас затем ввести пароль для нового пользователя. При первом запуске программы htpasswd нужно использовать флаг -c для создания нового файла паролей.

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

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

htadm попросит вас ввести пароль для пользователя.

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

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



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

     AuthType          Basic

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

     <Limit GET POST>

       require valid-user

     </Limit>



</Directory>

Вам придется заменить AuthUserFile на полный путь к файлу паролей. Такой способ защиты может быть скомбинирован с защитой на основе IP адресов, как описано в предшествующем разделе. Документация NCSA (http://hoohoo.ncsa.uiuc.edu/) и книга автора (How to Set Up and Maintain a Web Site) описывают это более подробно.

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

   Protection AUTHORIZED-USERS {

     AuthType     Basic

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

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

     GetMask      All

}

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

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

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

Различные скрипты подобного рода находятся в обращении. Автор предпочитает скрипт собственного производства, user_manage. Он работает с файлами паролей и групп, используемыми серверами Apache, NCSA httpd, CERN и серверами Netscape для Unix. Возможно, его можно использовать и для других серверов для систем Unix. Скрипт может быть использован пользователями для безопасной смены пароля и администраторами для добавления пользователей, манипулирования группами, изменения прав существующих пользователей. Этот скрипт можно получить на URL:

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?

Большинство серверов предоставляют возможность вместо того, чтобы указывать все директории в центральном файле управления доступом, помещать в каждом директории "спрятанный" (hidden) файл, регулирующий права доступа к этому директорию (такой файл называется .htaccess в серверах семейства NCSA и .www_acl в сервере CERN). Использование таких файлов очень удобно, поскольку вы можете ограничить доступ к директорию избегая редактирования центрального файла управления доступом. Но существует ряд причин, по которым не следует слишком доверяться файлу .htaccess. Одна из них состоит в том, что управляющие файлы разбросаны по дереву документов, а не находятся в одном месте, доступ к которому на уровне операционной системы четко контролируем. Другая причина состоит в том, что эти файлы могут быть легко стерты или изменены случайно, что откроет неограниченный доступ к части иерархии документов. Наконец, многие серверы (в том числе и NCSA) содержат ошибку, позволяющую получить файл управления доступом точно так же, как и любой другой файл документов WWW, используя подобный адрес URL:

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

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

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

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

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

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

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

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

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

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

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") защищенные серверы?

Существует некоммерческая реализация SSL, известная как SSLeay. Эта реализация распространяется в виде исходных текстов на языке C, которые могут быть использованы в таких приложениях, как Telnet и FTP. Среди поддерживаемых приложений - свободно распространяемые Web-серверы для Unix - Apache и NCSA httpd, а также различные браузеры для Unix, включая Mosaic. За пределами США этот пакет может быть использован бесплатно как в некоммерческих, так и в коммерческих приложениях. В США необходимо купить лицензию у RSA Data Security для использования SSL в коммерческих приложениях (может оказаться проще приобрести одну из коммерческих версий Apache-SSL, в цену которых включена стоимость лицензии).

Пакет состоит из нескольких компонентов. Для получения работающего 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

Вы можете получить откомпилированные заранее версии сервера Apache из двух источников. В США вы можете получить Stronghold от Community ConneXion, Inc. За пределами США вы можете получить Stronghold от Thawte Consulting, Ltd и на stronghold.ukweb.com. Эта версия Apache доступна со скидкой для некоммерческих организаций и образовательных учреждений.

После установки поддерживающего 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) убедитесь, что сертификат будет распознаваться теми браузерами, которые вы собираетесь поддерживать. VeriSign и Thawte распознаются последними версиями браузеров Netscape и Microsoft. Другие сертификаты могут не распознаваться. Для просмотра списка сертификатов, распознаваемых браузером, выберите в меню: Options-<Security Preferences->Site Certificates в Netscape Navigator, View->Options->Security->Sites в Internet Explorer. В Netscape Communicator информация доступна по кнопке Security на панели инструментов.

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

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

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

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

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

SSL можно использовать и для идентификации пользователя, что обеспечивает более надежную проверку, чем обычные имя пользователя и пароль. Для использования такой схемы каждый пользователь должен получить личный сертификат ("personal certificate") у CA.

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

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

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

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

Всегда можно попросить пользователя позвонить по телефону :-). Если серьезно, то вы _не должны_ предлогать удаленному пользователю вводить номер его кредитной карты, если вы не используете пару браузер/сервер, поддерживающую шифровку данных. Альтернативой может служить использование представительских систем (credit card proxy system), описываемых в следующем вопросе.

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

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

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

First Virtual

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

Перед использованием системы 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