byajhv (Информация и личная безопасность), страница 3

ВОЗМОЖНОЕ РЕШЕНИЕ - SSL

Проблема подлога и перехвата данных злоумышленником, прослушивающим сеть или оккупировавшим прокси-сервер, решается с помощью протокола SSL (новое название - TLS).

Протокол SSL в стеке TCP/IP расположен между транспортным (TCP) и прикладным уровнями. SSL обеспечивает шифрование (и, соответственно, дешифрацию) всех данных прикладного уровня. В контексте HTTP это означает, что все данные, а также заголовки HTTP-запросов и ответов передаются через сеть в зашифрованном виде.

Для того чтобы воспользоваться SSL, HTTP-сервер должен быть сконфигурирован соответствующим образом, а браузер должен поддерживать протокол SSL (все распространенные браузеры его поддерживают). URL ресурсов, защищенных с помощью SSL, начинаются с "https://". Перед собственно обменом HTTP-запросами и ответами клиент (браузер) и сервер устанавливают SSL-соединение. При этом сервер предъявляет клиенту сертификат, подтверждающий "личность" сервера. Следовательно, злоумышленник не может выдать себя за искомый сервер. Подлинность сертификата автоматически проверяется браузером в общеизвестной базе данных сертификатов, например базе компании VeriSign. Если же сертификат не найден ни в одной общеизвестной регистратуре, то пользователю предстоит самому решить, доверять этому сертификату или нет.

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

SSL и прокси-серверы

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

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

Прокси-сервер - контроллер и защитник

Возможность использования прокси-серверов как посредников между клиентом и HTTP-сервером является весьма полезной не только с точки зрения уменьшения трафика путем кэширования, но и с точки зрения обеспечения безопасности.

Разумная политика состоит в том, что все хосты внутренней сети должны пользоваться WWW через прокси-сервер предприятия. Правила фильтрации брандмауэра строятся таким образом, что разрешен только HTTP-трафик, следующий к прокси-серверу или от него. Особенность HTTP-трафика состоит в том, что он далеко не всегда привязан к порту 80, поэтому в общем случае для прокси-сервера должны быть открыты все порты или хотя бы наиболее популярные из них (80-86, 8000-8006, 8080-8086, 8888).

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

• разрешение доступа к тому или иному сайту;

• разрешение использовать те или иные методы запроса (особенно CONNECT, позволяющего туннелировать сквозь прокси-сервер);

• качество обслуживания запроса: например, выделение определенной полосы пропускания;

• учет объема полученного за определенный период трафика и отказ в обслуживании пользователя при превышении определенного лимита;

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

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

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

Идентификация пользователя

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

Прокси-аутентификация выполняется аналогично аутентификации на конечном WWW-сервере, но с помощью заголовка Proxy-Authorization. Если требуется прокси-аутентификация, но требуемые данные клиентом не предоставлены, то возвращается отклик с кодом 407 Proxy Authentication Required и заголовком Proxy-Authenticate, аналогичным по смыслу заголовку WWW-Authenticate. При использовании схемы Digest применяется также заголовок Proxy-Authentication-Info.

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

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

Заключение

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

ЭКСКУРС В ТЕХНОЛОГИЮ

WWW представляет собой клиент-серверную технологию, основанную на прикладном протоколе HTTP.

В HTTP имеются два типа сообщений: запросы от клиента (браузера) к серверу и ответы сервера клиенту. Для передачи сообщений используется протокол TCP и стандартный порт HTTP-сервера - 80. Запрос содержит URL - идентификатор ресурса (документа), который хотел бы получить клиент, и несколько вспомогательных заголовков.

Предполагается, что в ответ на запрос, проанализировав требуемый URL, сервер предоставит клиенту искомую информацию. Эта информация называется контентом. В простейшем случае это HTML-документ или файл в другом формате, однако контент может генерироваться сервером "на лету", например может быть вызвана сторонняя программа и ее вывод принят в качестве контента. Чтобы браузер правильно определил тип информации, содержащейся в контенте, и, соответственно, применил адекватный способ представления этой информации пользователю, контент сопровождается заголовком Content-Type, в котором указывается МIМЕ-тип данных.

Взаимодействие с клиентом

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

Пользователь задает параметры запроса путем заполнения и отправки HTML-форм. Формы содержат поля ввода текстовой информации, радиокнопки, выпадающие списки и т. п. Интерес представляет то, как именно браузер присоединяет введенные данные к запросу. В тэге содержатся два параметра: action и method. Первый указывает URL, к которому будет отправлен запрос по заполнению формы, а второй - метод этого запроса.

Существуют два метода: GET и POST. При отправке запроса методом GET данные, введенные в форму, присоединяются к URL после вопросительного знака. В этом случае URL может выглядеть, например, так: "/cgi-bin/dir/script.pl?name=John&age=25 &hobby=reading&hobby=football". Нетрудно заметить, что данные состоят из пар "имя=значение", разделенных амперсандами. При отправке данных методом POST та же самая строка: "па-me=John&age=25&hobby=reading&hob-by=football" помещается после заголовке запроса, отделяясь от них пустой строкой В этом случае к URL ничего не добавляется.

Очевидно, что никакой HTTP-сервер не может предусмотреть всего разнообразия интерактивных www-приложений. Вместо этого HTTP-сервер предлагает разработчику интерфейс, используя который, сторонняя программа может получить от HTTP-сервера все необходимые для обработки запроса данные, а в ответ сгенерировать контент, который будет возвращен сервером браузеру. Таким образом, задача генерации контента возлагается на приложения, разрабатываемые под нужды конкретной задачи. В комплексных информационных системах на базе WWW говорят, что HTTP-сервер - это front end www-сайта, а приложения, генерирующие контент, - back end. Часто приложения работают в связке с базой данных: таким образом, имеет место трехуровневая схема: HTTP-сервер - приложение - база данных.

Интерфейс CGI

Наиболее общим и распространенным интерфейсом подобного типа является CGI. При его использовании HTTP-сервер запекает приложение, которое должно обработать запрос, и передает ему на стандартный ввод все, что поступило в запросе после заголовков. Также HTTP-сервер устанавливает несколько переменных окружения, в том числе переменную QUERY_STRING, которая содержит часть URL, расположенную после вопросительного знака (а это, как мы знаем, данные, переданные методом GET). Таким образом, CGI-приложение получает доступ к данным, введенным пользователем в форму. Отметим, что сами данные, их наличие или отсутствие, размещение в теле запроса или в URL или сразу в обоих местах HTTP-сервером никак не интерпретируются и не декодируются, а передаются приложению как есть. Все задачи по интерпретации и преобразованию данных возложены на CGI-приложение. Обработав запрос, приложение передает сгенерированный контент на свой стандартный вывод, где он перехватывается HTTP-сервером и пересылается клиенту. Единственный заголовок, который обязано выставить само CGI-приложение, - Content-Type.

Выполняемые составляющие

Другой способ динамической генерации контента - внесение программного кода непосредственно в текст HTML-файла. Код размещается внутри специальных тэгов (например, ). Приняв запрос такого файла, HTTP-сервер производит разбор его содержимого, обнаруживает программный код и исполняет его. В текст исходного файла вставляется результат выполнения кода и итоговый контент отправляется клиенту. Популярными технологиями, использующими встроенный код на стороне сервера, являются PHR ASP (Active Server Pages), JSP (Java Server Pages). В отличие от CGI, где от сервера, в общем случае, не требуется никаких знаний о том, как работает запускаемая им CGI-программа, при использовании встроенного кода требуется поддержка соответствующей технологии сервером, так как выполнение кода производится внутри процесса сервера.

Особый случай встроенного кода - язык Javascript. Код, написанный на Javascript, помещается внутри пары тэгов и , передается на сторону клиента и выполняется браузером. На стороне клиента выполняются также программы, написанные на языке Java. Встретив в HTML-документе тэг , браузер загружает с сервера файл, содержащий байт-код программы, и передает его на выполнение Java-машине. Последнюю можно бесплатно загрузить из Интернета с сайта http://java.sun.com.

Кэширование данных

Часто между браузером и HTTP-сервером располагается промежуточное звено - HTTP-кэш, или прокси-сервер. Не всякий контент будет помещен в кэш. Администратор прокси-сервера формулирует политику кэширования: например, не кэшировать контенты больше определенного размера, контенты, в URL которых имеется каталог cgi или cgi-bin, или контенты, полученные с серверов локальной сети. Кроме того, используя заголовок Cache-Control, сервер может явно запретить кэширование выдаваемого им контента. Помещенный в кэш контент не хранится там вечно: на основании значения заголовков Last-Modified и Expires прокси-сервер определяет его "срок годности".

Очевидно, что не все информационные ресурсы WWW могут быть открыты для всеобщего просмотра. Для того чтобы ограничить доступ к какому-либо ресурсу, используется аутентификация клиента, прежде чем запрос обслуживается HTTP-сервером. Аутентификация выполняется с помощью заголовков WWW-Authenticate и Authorization. Сегодня определены две схемы аутентификации: Basic и Digest, фундаментально отличающиеся друг от друга с точки зрения безопасности. Первая представляет собой обычную процедуру пересылки имени и пароля пользователя в открытом виде; вторая использует алгоритм MD5.

Пользователь вновь под ударом