Раздел: Документация
0 ... 43 44 45 46 47 48 49 ... 125 Классические и прозрачные proxy-серверы В документе RFC 1919 описываются два основных типа proxy-серверов: так называемые классические proxy-серверы (classical proxies) и прозрачные proxy-серверы (transparent proxies), а также различия между ними. Классические proxy-серверы Как следует из их названия, классические proxy-серверы были первым типом таких приложений. Это в основном просто программы, находящиеся между клиентом и сервером. При этом перед началом работы с proxy-сервером клиент должен был выполнить авторизацию на нем. Например, пользователю классического proxy-сервера FTP необходимо подключиться к нему из утилиты FTP, произвести авторизацию, а затем сообщить proxy-серверу адрес узла, с которым следует установить соединение. Проблема подобных proxy-серверов состоит в том, что работа с ними требует от клиента дополнительных действий. Например, последовательность действий при непосредственном использовании FTP без proxy-сервера достаточно проста: 1.Пользователь запускает клиент FTP при помощи соответствующей команды, например ftp www.twoinc.com. 2.Сервер запрашивает имя учетной записи, пользователь вводит его. 3.Сервер запрашивает пароль, пользователь вводит его. 4.Пользователь вводит команды для приема или передачи файлов и т.д. 5.Сервер отвечает на команды, принимая файлы от клиентского приложения или передавая ему файлы. При работе через классический proxy-сервер ситуация становится более сложной: 1.Пользователь запускает клиент FTP при помощи соответствующей команды, например ftp proxyserver.twoinc.com. 2.Proxy-сервер запрашивает имя учетной записи, пользователь вводит его. 3.Proxy-сервер запрашивает пароль, пользователь вводит его. 4.Пользователь сообщает proxy-серверу имя сервера FTP, обычно в формате username@target.com. В данном случае target.com обозначает имя удаленной системы, a username - имя пользователя в ней. 5.Proxy-сервер пересылает эту информацию адресату и в случае успешной авторизации извещает клиентское приложение о том, что пользователь может начать выполнение команд FTP. 6.Proxy-сервер получает команды от клиентского приложения и передает их удаленному серверу. 7.Сервер отвечает на команды, поступающие от proxy-сервера, и возвращает ему данные в соответствии с введенными пользователем командами. 8.Proxy-сервер возвращает получаемые от удаленного сервера данные клиентскому приложению. Из этого примера видно, что для удаленного сервера proxy-сервер выглядит так же, как и любой другой клиент FTP. Клиентская программа конечного пользователя воспринимает proxy-сервер в качестве сервера FTP. Но поскольку proxy-сервер выступает посредником между клиентом и настоящим сервером, пользователь должен произвести дополнительные действия для авторизации на proxy-сервере и передачи ему адреса сервера FTP. Так как авторизация выполняется и на proxy-сервере, и в удаленной системе, пользователю приходится набирать лишние команды. Возможно, многим это не покажется слишком неудобным. Но наличие подобных proxy-серверов требует умения работать с ними. Не все proxy-серверы функционируют одинаковым образом, поэтому необходимо дополнительно обучать пользователей работе с proxy-сервером Telnet и т.д. Все это делает применение proxy-серверов подобного типа приемлемым, но не идеальным решением. Proxy-сервер блокирует прямой IP-трафик Обратите внимание - из данного примера также следует, что клиентское программное обеспечение не взаимодействует с удаленным сервером напрямую. Точнее, IP-пакет, переданный клиентским компьютером, никогда не достигнет удаленного сервера. Адресатом этого пакета является proxy-сервер, который интерпретирует информацию в пакете и устанавливает соединение с удаленным сервером. Таким образом, в действительности создается два соединения: одно - между клиентом и proxy-сервером, а другое - между proxy- и удаленным сервером. Так предотвращается попадание в сеть «неправильных» пакетов. Не забывайте о том, что для успеха атак некоторых типов не всегда обязательно, чтобы информация возвращалась нарушителю. Иногда достаточно просто послать в сеть пакет, который вызовет нужные нарушителю действия. Пакет Г/5 FWTK содержит несколько классических proxy-серверов. Более подробную информацию о FWTK и входящих в него proxy-серверах вы можете найти в главе 14. Прозрачные proxy-серверы Для облегчения управления proxy-серверами и их эксплуатации конечными пользователями предназначены proxy-серверы, работа которых прозрачна для пользователя. При этом пользователю не нужно выполнять никаких дополнительных команд, и он может вообще не подозревать о том, что применяется proxy-сервер. С точки зрения пользователя прозрачный proxy-сервер действует как прямое соединение. Устанавливать proxy-серверы такого типа намного проще, поскольку работе с ними обучать пользователей не приходится. Им даже не обязательно знать о существовании proxy-сервера. Вместо того чтобы запускать команду FTP с именем proxy-сервера, пользователь задает в качестве ее параметра имя удаленного сервера. Поскольку proxy-сервер находится на пути между пользователем и удаленным сервером и перехватывает определенный сетевой трафик, он способен распознать этот запрос и разрешить или запретить его выполнение. Это означает, что производящему запрос клиенту кажется, что он напрямую подключен к удаленному серверу. Стек TCP/IP projey-сервера модифицируется так, чтобы перехватывать IP-пакеты, адресованные не только ему, но и удаленным серверам. Так как прозрачный proxy-сервер перехватывает пакеты, он сумеет найти в них адрес удаленного сервера. Пользователю нет необходимости специально сообщать proxy-серверу имя удаленного сервера, как это было в случае классического proxy-сервера. Пользователь авторизуется на удаленном, а не на proxy-сервере. Тем не менее соединение осуществляется через proxy-сервер, и он способен блокировать некоторые действия - допустим, может разрешать пользователю загружать файлы с удаленного сервера при помощи команды GET, но запрещать передавать файлы на удаленный сервер командой PUT. Такой proxy-сервер в состоянии определять, кому и какие действия разрешены, а также обеспечивать возможность регистрации и выдачи предупреждений, как и классический proxy-сервер. Но для пользователя этот процесс вполне прозрачен и все выглядит так же, как при работе через прямое соединение. Более подробную информацию о демилитаризованной зоне вы можете найти в главе 4. Однако прозрачный proxy-сервер не скрывает IP-адреса сторон соединения. Клиент должен знать IP-адрес удаленного сервера. Если proxy-сервер реализует доступ к внутреннему серверу снаружи, последний считает, что его клиентом является proxy-сервер. Но внешнему клиенту известен IP-адрес внутреннего сервера. Эту проблему можно решить, поместив серверы в отдельную подсеть, например в демилитаризованную зону. При этом любой нарушитель, пытающийся причинить им ущерб, по-прежнему не будет располагать никакой информацией об остальной части сети, расположенной по другую сторону демилитаризованной зоны. Не забывайте о том, что находящиеся в этой зоне серверы, обычно называемые укрепленными компьютерами, должны быть особо защищены, поскольку они являются наиболее уязвимыми узлами сети. Независимо от выбранного тина proxy-сервера важно не забывать о том, что с его помощью позволено устанавливать соединения только пользователям (или узлам), которые указаны администратором. В отличие от пакетного фильтра, который проверяет информацию в заголовке пакета (например, адрес и номер порта), proxy-сервер понимает действия, выполняемые сетевой службой, и может быть 0 ... 43 44 45 46 47 48 49 ... 125
|