 |
Прокси-сервер - контроллер и защитник
|
|
|
|
Возможность использования прокси-серверов как посредников между клиентом и 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-форм. Формы содержат поля ввода текстовой информации, радиокнопки, выпадающие списки и т. п. Интерес представляет то, как именно браузер присоединяет введенные данные к запросу. В тэге <form> содержатся два параметра: 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, помещается внутри пары тэгов <script> и </script>, передается на сторону клиента и выполняется браузером. На стороне клиента выполняются также программы, написанные на языке Java. Встретив в HTML-документе тэг <applet>, браузер загружает с сервера файл, содержащий байт-код программы, и передает его на выполнение Java-машине. Последнюю можно бесплатно загрузить из Интернета с сайта http://java.sun.com.
Кэширование данных
Часто между браузером и HTTP-сервером располагается промежуточное звено - HTTP-кэш, или прокси-сервер. Не всякий контент будет помещен в кэш. Администратор прокси-сервера формулирует политику кэширования: например, не кэшировать контенты больше определенного размера, контенты, в URL которых имеется каталог cgi или cgi-bin, или контенты, полученные с серверов локальной сети. Кроме того, используя заголовок Cache-Control, сервер может явно запретить кэширование выдаваемого им контента. Помещенный в кэш контент не хранится там вечно: на основании значения заголовков Last-Modified и Expires прокси-сервер определяет его "срок годности".
Очевидно, что не все информационные ресурсы WWW могут быть открыты для всеобщего просмотра. Для того чтобы ограничить доступ к какому-либо ресурсу, используется аутентификация клиента, прежде чем запрос обслуживается HTTP-сервером. Аутентификация выполняется с помощью заголовков WWW-Authenticate и Authorization. Сегодня определены две схемы аутентификации: Basic и Digest, фундаментально отличающиеся друг от друга с точки зрения безопасности. Первая представляет собой обычную процедуру пересылки имени и пароля пользователя в открытом виде; вторая использует алгоритм MD5.
|
|
|
