Прозрачный прокси. Прозрачный прокси сервер. Что такое анонимный прокси сервер

ДМИТРИЙ РЕПИН

Transparent proxy . Быть или не быть?

Весь текст этой статьи является исключительно личным мнением автора и не претендует на сборник аксиом. Все описанные в статье исследования и выводы также следует рассматривать через призму субъективности автора, ибо, как говорили древние мудрецы, «Errare humanum est». Также автор не несёт ответственности за любые действия (и их последствия), произведённые читателем после прочтения этой статьи.

Лирическое отступление

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

Системы семейства UNIX-подобных являются величайшим источником знаний для самообразования и полигоном для экспериментов. Открытость исходного кода системы и прикладного ПО, низкоуровневый доступ к настройкам и их гибкость... – всё это позволяет глубже вникнуть в принципы работы компьютерных систем и сетей. Кроме того, это позволяет создавать всевозможные нестандартные конфигурации привычного программного обеспечения. Для чего это нужно? В первую очередь для того, чтобы расширить возможности системы. Вторым аргументом в пользу подобных «хирургических вмешательств» в ПО является наличие различных ошибок при разработке программного обеспечения.

Данная статья посвящена проблемам прозрачного проксирования на примере популярного сервера Squid. В качестве ОС использовалась стабильная версия FreeBSD 4.7.

Общие принципы прозрачного проксирования

При работе прокси-сервера в прозрачном режиме (Trans-parent mode) для веб-доступа пользователей в Интернет не требуется настраивать браузер для взаимодействия с прокси на каждом рабочем месте, а сами пользователи могут вообще не знать о существовании прокси-сервера. В таком режиме администраторы и техники получают меньше вопросов и жалоб от пользователей по настройке пользовательского ПО.

Технически этот режим реализуется следующим образом. С помощью firewall все соединения на определённый порт (в случае HTTP – порт 80) внешних серверов перенаправляются на локальный порт прокси-сервера (обычно – 3128).

По стандарту протокола HTTP 1.1 (RFC2616) каждый запрос клиента должен содержать заголовок «Host», в котором указывается адрес сервера-получателя запроса. Именно с помощью этого заголовка прокси-сервер определяет адресата и соединяется с ним. Что же касается других популярных протоколов (FTP, HTTPS, и т. д.), то такой возможности в них просто не предусмотрено. На этой «весёлой ноте» можно начать описание проблем.

Авторизация на прокси-сервере позволяет производить учёт работы и разграничение доступа в Интернет пользователей локальной сети, используя их имена (логины) независимо от того, за каким компьютером находится пользователь и какой адрес имеет данный компьютер. В противном случае администратор имеет возможность контролировать работу сотрудников только на основе IP-адресов, что позволяет пользователям обходить ограничения. Таким образом, авторизация на прокси-сервере является необходимым элементом инфраструктуры локальной сети. А теперь о грустном: авторизация на «прозрачном» прокси-сервере практически невозможна. Однако подобное утверждение явно противоречит стандартам.

Обратимся к первоисточнику – описанию протокола HTTP – документу RFC2616. По стандарту, HTTP-клиент при получении статуса-ответа сервера с кодом 407 (Proxy Authentication Required) обязан отправить данные авторизации серверу. Для иллюстрации работы и для тестов автором был написан небольшой http-сервер на языке Perl, который выдавал нужные статусы и заголовки, а также писал лог запросов и ответов.

В результате работы сервера получение данных клиентом будет происходить в 4 этапа:

1. Клиент запрашивает документ, а сервер сообщает о необходимости Proxy-авторизации.
2. Клиент снова запрашивает документ, но уже с данными авторизации на прокси.
3. Для проверки работоспособности системы сервер просит авторизоваться ещё и для Web – модель ситуации, когда пользователь обращается к защищённому документу на удалённом сервере через прокси с авторизацией.
4. Клиент послушно авторизуется «вдвойне» – на прокси-сервере и веб-сервере.

В качестве тестовых клиентов использовались браузеры Mozilla FireBird 0.6.1, Microsoft Internet Explorer 6.0.2800.1106 и Opera 6.05.

Код тестового сервера:

#!/usr/bin/perl -w

use strict;

use Socket;

# Создаётся сокет, привязывается ко всем адресам (для удобства) на порт 8080 и включается прослушивание.

socket(SERVER,PF_INET,SOCK_STREAM,getprotobyname("tcp"));

setsockopt(SERVER,SOL_SOCKET,SO_REUSEADDR,1);

bind(SERVER,sockaddr_in(8080,INADDR_ANY));

listen(SERVER,SOMAXCONN);

$|=1;

my $CR="?15?12";

# Приём входящих соединений

while (1){

# Приём клиента, определение его адрес/порт/хост и вывод на экран (для отладки)

My $paddr = accept(CLIENT,SERVER);

My ($ip,$port,$name) = remote($paddr);

Print "Connection from $ip:$port ($name) ";

# Чтение всего запроса от клиента в одну переменную

My $DATA;

While(){

Chomp;

$_=~s/ //g;

Last unless $_;

$DATA.=$_." ";

# Запись запроса в лог-файл

Log($DATA);

# Теперь простая проверка на наличие в запросе нужных заголовков, отправка соответствующего ответа клиенту

# и запись ответов в лог-файл.

If($DATA !~/Proxy-Authorization/){

Log(Response407());

Print CLIENT Response407();

}elsif($DATA !~/?12Authorization/){

Log(Response401());

Print CLIENT Response401();

}else{

Log(Response200());

Print CLIENT Response200();

Print "Connection closed. ";

Close CLIENT;

# Закрытие текущего соединения

# Закрытие сокета сервера

close SERVER;

# Составление ответов сервера для удобства вынесено в отдельные функции

sub Response401{

Return "HTTP/1.1 401 Unauthorized$CR".

"Mime-Version: 1.0$CR".

"Content-Length: 20$CR".

"WWW-Authenticate: Basic realm=" --== Protected web-Area ==--"$CR".

"Connection: close$CR$CR

sub Response407{

Return "HTTP/1.1 407 Proxy Authentication Required$CR".

"Server: squid/2.5.STABLE3$CR".

"Mime-Version: 1.0$CR".

"Content-Type: text/html$CR".

"Content-Length: 20$CR".

"Proxy-Authenticate: NTLM$CR".

"Proxy-Authenticate: Basic realm="<-- 407 Protected Proxy-->"$CR".

"Connection: close$CR$CR

sub Response200{

Return "HTTP/1.1 200 OK$CR".

"Server: squid/2.5.STABLE3$CR".

"Mime-Version: 1.0$CR".

"Content-Type: text/html$CR".

"Content-Length: 19$CR".

"Connection: close$CR$CR

# Функция определения адреса, порта и имени хоста клиента

sub remote{

My $rem = shift;

Return undef unless $rem;

My ($port,$ip) = sockaddr_in($rem);

Return (inet_ntoa($ip),$port,gethostbyaddr($ip,AF_INET));

# Функция для записи в файл протокола

sub Log{

Open(F,">>connection.log");

Print F scalar(localtime)." ";

For(split/ /,$_){

Print F " $_ ";

Print F " //====// ";

Close(F);

Первый запрос браузера:

GET /?test HTTP/1.1 Host: localhost User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1

Сервер отвечает:

Сервер сообщает, что всё в порядке:

HTTP/1.1 200 OK Server: squid/2.5.STABLE3 Mime-Version: 1.0 Content-Type: text/html Content-Length: 19 Connection: close

Данный протокол на примере Mozilla FireBird 0.6.1 иллюстрирует вполне «законную» возможность использования авторизации на прозрачном прокси-сервере. Возникает резонный вопрос: почему в FAQ сервера Squid наличествует фраза «...proxy_auth can’t be used in a transparent proxy...»?

Для начала обратимся к исходным кодам Squid. Связь между авторизацией и режимом работы сервера прослеживается в двух файлах – acl.c и client_side.c. При анализе кода становится ясно, что возможность использования авторизации в данном случае просто игнорируется!

Участок исходного кода acl.c:

Http_hdr_type headertype;

If (NULL == r) {

Return -1;

} else if (!r->flags.accelerated) {

/* Proxy authorization on proxy requests */

Headertype = HDR_PROXY_AUTHORIZATION;

} else if (r->flags.internal) {

/* WWW authorization on accelerated internal requests */

} else {

#if AUTH_ON_ACCELERATION

/* WWW authorization on accelerated requests */

Headertype = HDR_AUTHORIZATION;

#else

Debug(28, 1) ("aclAuthenticated: authentication not applicable on accelerated requests. ");

Return -1;

#endif

Участок исходного кода client_side.c:

If (answer == ACCESS_REQ_PROXY_AUTH || aclIsProxyAuth(AclMatchedName)) {

If (!http->flags.accel) {

/* Proxy authorisation needed */

Status = HTTP_PROXY_AUTHENTICATION_REQUIRED;

} else {

/* WWW authorisation needed */

Status = HTTP_UNAUTHORIZED;

If (page_id == ERR_NONE)

Page_id = ERR_CACHE_ACCESS_DENIED;

} else {

Status = HTTP_FORBIDDEN;

If (page_id == ERR_NONE)

Page_id = ERR_ACCESS_DENIED;

Подобная странность, обнаруженная в ходе исследования, ещё больше разогрела интерес автора к обсуждаемому вопросу.

В связи с этим, естественно, исходный код сервера претерпел изменения. Результатом явилась модифицированная версия сервера Squid с совместной работой авторизации и прозрачного режима. Но...

В ходе дальнейшего исследования выяснилось, что популярнейший браузер Microsoft Internet Explorer не способен следовать стандартам! Если в настройках этого клиента явно не указано использование прокси-сервера, то MSIE просто игнорирует обработку http-статуса 407 и выдаёт ошибку. Мало того, старые версии под Windows 9X вообще «сыпятся» с критической ошибкой в библиотеке WININET.DLL при получении вышеописанного статус-кода.

В связи с этим становится ясно, что использование авторизации при прозрачном проксировании невозможно. Ведь подавляющее большинство пользователей работают именно с Microsoft Internet Explorer. Если в вашей сети используются браузеры только на основе Mozilla, вы можете модифицировать ваш сервер Squid-2.5.STABLE3 с помощью патчей, которые находятся по адресу http://www.comprice.ru/cmapuk/squid_patch.tgz

В дополнение к вышесказанному стоит добавить, что все нынешние браузеры, так или иначе, не полностью соблюдают стандарты. Например, HTTP-статус 305 (Use Proxy), сообщающий клиенту о необходимости использовать указанный в ответе прокси-сервер, игнорируется как браузером Microsoft Internet Explorer, так и Mozilla FireBird и Opera. Кроме того, браузер Opera (проверено на версии 6.05) не поддерживает NTLM-авторизацию, хотя статус-код 407 обрабатывает правильно и легко авторизуется по типу Basic.

Итак, в действительном существовании проблемы и практической невозможности её решения теперь сомнений нет. Однако остаётся неизвестной «политическая» подоплёка несоблюдения стандартов. После некоторых размышлений на эту тему автор статьи вывел гипотезу о причине «нестандартности» MSIE как HTTP-клиента.

Если абсолютно стандартный браузер при получении ответа сервера с кодом 407 отправляет данные для авторизации, то эта информация может быть получена любым третьим лицом. На примере это выглядит следующим образом. Пользователь-злоумышленник настраивает веб-сервер (внешний, либо в локальной сети) на ответ вышеозначенным кодом при любых запросах (это может быть элементарный «самописный» сервер в 10-15 строк). После этого путём простейших приёмов социальной инженерии пользователь-жертва заманивается в ловушку с целью получить всего лишь один HTTP-сеанс между жертвой и сервером злоумышленника. В результате «хакер» получает данные авторизации пользователя (например, данные NTLM-авторизации), что может повлечь за собой несанкционированный доступ к информации со всеми вытекающими последствиями.

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

Множество протоколов

Как правило, в задачу прокси-сервера входит обслуживание клиентов не только по протоколу HTTP, но и FTP и HTTPS. Кроме того, часто возникает необходимость HTTP-соединения по альтернативным портам (8000, 8080, и т. п.). С этим связана вторая и, пожалуй, самая сложная проблема прозрачного проксирования – прокси-сервер Squid в режиме прозрачности может обслуживать соединения только по одному протоколу – HTTP.

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

Альтернативные HTTP-порты

Как уже было сказано в начале статьи, спецификация протокола HTTP 1.1 предписывает клиенту включать в запрос обязательный заголовок «Host». Этот заголовок содержит имя сервера, которому адресован запрос. Таким образом, для получения данных по адресу http://www.server.info при прямом соединении минимальным HTTP-запросом будет следующий:

GET / HTTP/1.1

Host: www.server.info

Если клиентское ПО адаптировано для работы через прокси-сервер и настроено соответственно, то запрос будет выглядеть так:

GET http://www.server.info HTTP/1.1

Host: www.server.info

В случае если удалённый сервер обслуживает клиентов по альтернативному порту, запрос через прокси будет содержать информацию и об этом:

GET http://www.server.info:8080 HTTP/1.1

Host: www.server.info

При прямом соединении с удалённым сервером запрос клиента не меняется в зависимости от порта и остаётся таким же, как в первом примере. В результате при работе в прозрачном режиме прокси-сервер не может определить реальный порт удалённого сервера, к которому обратился клиент, так как клиент вообще не подозревает о существовании «посредника».

Современные версии прокси-сервера Squid поддерживают возможность определения хоста и порта с помощью библиотек пакетных фильтров, таких как ipfilter в BSD-системах или netfilter в Linux. Для работы с этими библиотеками при компиляции сервера необходимо указать соответствующие опции (--enable-ipf-transparent). После сборки сервера ему будет доступна подробная информация о соединении.

Участок кода client_side.c:

#if IPF_TRANSPARENT

NatLookup.nl_inport = http->conn->me.sin_port;

NatLookup.nl_outport = http->conn->peer.sin_port;

NatLookup.nl_inip = http->conn->me.sin_addr;

NatLookup.nl_outip = http->conn->peer.sin_addr;

Как может показаться, при таком подходе возникает необходимость использовать на firewall фильтрацию на основе ipfilter/ipnat и отказаться от ipfw. Однако для работы Squid достаточно просто включить поддержку данного пакетного фильтра, а перенаправлять пакеты можно по-прежнему с помощью ipfw.

Проксирование FTP и HTTPS

При обычном проксировании запросы клиента прокси-серверу на получение файла с удалённого сервера по протоколу FTP выглядят так же, как и HTTP-запросы:

GET ftp://ftp.server.info HTTP/1.1

Host: ftp.server.info

Клиентом, реализующим этот протокол FTP, в данном случае является сам прокси-сервер. Получив файл, прокси-сервер отвечает клиенту обычным HTTP-ответом и возвращает данные.

Также клиент может «потребовать» от прокси-сервера прямого соединения с удалённым хостом для обмена данными. Тогда запрос будет выглядеть так:

CONNECT ftp.server.info:21 HTTP/1.1

Host: ftp.server.info

Благодаря такому виду запросов посредник чётко понимает поставленную перед ним задачу и выполняет её в соответствии с рекомендациями системного администратора в виде директив acl и http_access в конфигурационном файле.

Общение клиента с удалённым сервером по SSL-защищённым протоколам всегда происходит по методу CONNECT:

CONNECT secure.server.info:443 HTTP/1.1

Host: secure.server.info

При прямом соединении клиента с удалённым хостом без посредников (а при прозрачном проксировании клиент «считает» именно так) он сам реализует протоколы прикладного уровня, такие как FTP и HTTP. В результате прокси-сервер не может определить поставленную перед ним задачу. При перенаправлении с помощью firewall всех соединений к портам 21 и 443 на порт прокси (3128) последний получает в первом случае строку «USER username», а во втором вообще набор несвязных символов.

Решение данной проблемы требует «хирургического» вмешательства в исходный код прокси-сервера Squid. Задача модификации сервера состоит в том, чтобы «научить» сервер становиться почти таким же посредником, как при методе CONNECT, в зависимости от номера порта запрашиваемого удалённого сервера.

Для демонстрации этой идеи напишем ещё один простейший сервер:

#!/usr/bin/perl -w

use strict;

use Socket;

# Локальный адрес мини-прокси

my $maddr = sockaddr_in(30021,inet_aton("localhost"));

# Допустим, мы уже знаем адрес удалённого FTP

my $paddr = sockaddr_in(21,inet_aton("ftp.freebsd.org"));

# Открываем сокет для прокси-сервера и начинаем прослушивать

socket(SOCK,PF_INET,SOCK_STREAM,getprotobyname("tcp")) or die $!;

setsockopt(SOCK,SOL_SOCKET,SO_REUSEADDR,1) or die $!;

bind(SOCK,$maddr) or die $!;

listen(SOCK,SOMAXCONN);

# Перехватываем сигнал PIPE. Этот сигнал появляется при попытке работы с закрытым потоком

$SIG{PIPE}=sub{

Close(SERVER);

Close(CLIENT);

Close(SOCK);

Exit;

$|=1; # отключаем буферизацию потока STDOUT

# Принимаем подключения

while (accept(CLIENT,SOCK)){

Print "Connection detect. ";

# Соединяемся с удалённым FTP

Socket(SERVER,PF_INET,SOCK_STREAM,getprotobyname("tcp")) or die $!;

Connect(SERVER,$paddr);

# Начинаем обмен информацией

While(1){

My $server="";

# Отключаем буферизацию потоков клиента и сервера

Select(CLIENT); $|=1;

Select(SERVER); $|=1;

Select(STDOUT);

# Пока сервер не завершил передачу

# идентификатором статуса принимаем все данные, отдаём клиенту, а заодно выводим на экран

While($server !~/^d{3}s/){

$server=;

Print CLIENT $server;

Print $server;

# Принимаем команду от клиента и передаём серверу. Также выводим на экран

My $client=;

Print SERVER $client;

Print $client;

Close SERVER;

Close CLIENT;

close SOCK;

Добавляем в firewall правило перенаправления всех запросов к 21-му порту на локальный порт 30021 и запускаем тестовый сервер.

ipfw add 30002 fwd 127.0.0.1,30021 tcp from 192.168.0.0/24 to any 21 via xl0

Теперь открываем браузер и пробуем зайти на ftp://ftp.freebsd.org (естественно, без прокси-настроек). Результат простейшего теста показывает, что прозрачное проксирование по протоколам, отличным от HTTP, вполне возможно. Теперь поставим уже конкретную задачу по модификации прокси-сервера Squid.

1. Добавить в возможности конфигурирования сервера новую директиву (назовём её direct_port) следующего формата:

direct_port PORT PROTOCOL

где PORT – конечный порт удалённого сервера; PROTOCOL – протокол, по которому прокси-серверу следует выступать посредником. Пример:

direct_port 21 FTP, direct_port 443 SSL

2. Добавить к уже имеющейся «услуге» посредничества при методе CONNECT её модифицированную версию, в которой исключены вмешательства прокси-сервера в общение клиента и удалённого сервера лишними заголовками.

3. Установить контроль над новым типом соединения с помощью директив ACL.

Решение этой задачи для исследователя, никогда не участвовавшего в разработке прокси-сервера Squid, является весьма трудоёмким процессом. Посему у автора данной статьи на данный момент нет готового решения в виде патчей и т. п. Однако, возможно, это исследование привлечёт внимание энтузиастов (или самих разработчиков Squid) к вышеописанной проблеме и решение появится.

Вывод

Исследование показало, что настоящее прозрачное проксирование без ущерба для пользователей и администраторов – это реальность. Единственной серьёзной проблемой на пути к внедрению технологии прозрачного проксирования остаётся несоответствие стандартам браузера Microsoft Internet Explorer. Вполне возможно, что в будущем этот недостаток у MSIE исчезнет, если обратить внимание специалистов из Microsoft на данную проблему. В настоящий момент, а точнее, после того, как прокси-сервер Squid будет модифицирован, любая организация, в чьи корпоративные стандарты не входит использование браузера MSIE, смогут полноценно пользоваться прозрачным проксированием.

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

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

Прозрачный прокси - схема связи, при которой трафик, или его часть, перенаправляется на прокси-сервер неявно (средствами маршрутизатора). При этом клиент может использовать все преимущества прокси-сервера без дополнительных настроек браузера (или другого приложения для работы с интернетом). Пример: route -p add 10.32.5.5 mask 255.255.255.255 10.32.1.14

Классификация прокси-серверов для целей анонимизации представлена в статье Веб-прокси .

Технические подробности

Клиентский компьютер имеет настройку (конкретной программы или операционной системы), в соответствии с которой все сетевые соединения по некоторому протоколу совершаются не на IP-адрес сервера (ресурса), выделяемый из DNS-имени ресурса, или напрямую заданный, а на IP-адрес (и другой порт) прокси-сервера.

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

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

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

Прокси-серверы являются самым популярным способом выхода в Интернет из локальных сетей предприятий и организаций. Этому способствуют следующие обстоятельства:

• Основной используемый в интернете протокол - HTTP , в стандарте которого описана поддержка работы через прокси;
• Поддержка прокси большинством браузеров и операционных систем;
• Контроль доступа и учёт трафика по пользователям;
• Фильтрация трафика (интеграция прокси с антивирусами);
• Прокси-сервер - может работать с минимальными правами на любой ОС с поддержкой сети (стека TCP/IP);
• Многие приложения, использующие собственные специализированные протоколы, могут использовать HTTP как альтернативный транспорт или SOCKS -прокси как универсальный прокси, подходящий для практически любого протокола;
• Отсутствие доступа в Интернет по другим (нестандартным) протоколам может повысить безопасность в корпоративной сети.

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

Наиболее распространённые прокси-серверы

• 3proxy (BSD, многоплатформенный)
• CoolProxy (проприетарный , Windows)
• Eserv (shareware, Windows)
• HandyCache (shareware, Windows) бесплатен для домашнего использования
• Kerio Control (проприетарный, Windows, Linux)
• Microsoft Forefront Threat Management Gateway , ранее Microsoft ISA Server (proprietary, Windows)
• Blue Coat Proxy SG (аппаратный/виртуальный appliance)
• nginx (веб-сервер, имеющий режим работы в качестве reverse proxy и часто для этого использующийся)
• Squid (GPL, многоплатформенный)
• Traffic Inspector (проприетарный, Windows)
• UserGate (проприетарный, Windows)
• Интернет Контроль Сервер (shareware, FreeBSD)
• Tor (BSD, многоплатформенный)
• Ideco ICS (проприетарный, Linux)
• WinGate (проприетарный, Windows)
• (с авторизацией)
• Apache (веб-сервер, имеющий дополнительные модули для реализации прямого и реверсного прокси)

Проксификаторы

Проксификатор - это программа, перенаправляющая другие программы через прокси-серверы. Проксификаторы часто применяются для интернет-клиентов, которые не поддерживают прокси-серверы.

• Сравнение проксификаторов (англ.)

• Proxy software and scripts в каталоге ссылок

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

Что такое прозрачный прокси-сервер?

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

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

Как добиться работы прозрачного проксирования?

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

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

Для чего нужен прозрачный прокси-сервер?

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

• Анонимность. Прокси-сервер позволяет скрывать собственный IP-адрес заходя на тот или иной сайт, что весьма удобно в том случае, если на каком-либо сайте вас забанили, или же вы не хотите показывать своего присутствия по каким-либо другим причинам.
• Сжатие данных. Перед тем как передать информацию конечному пользователю прокси-сервер её сжимает, что позволяет весьма неплохо экономить сетевой трафик.
• Ограничение доступа. Прокси-сервер также предлагает очень хорошие возможности по ограничению доступа, например, он позволяет запретить доступ к каким-либо сайтам, или же ограничить трафик конкретным пользователям в случае такой необходимости.

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

(Прокси сервер) – промежуточный компьютер, который является посредником между вашим компьютером и Интернетом. Прокси обычно используют либо для ускорения работы в сети Интернет, либо для анонимного прохождения в сети Интернет. Так же использование анонимного прокси, может быть использовано, как дополнительное средство защиты: анонимный прокси (anonymous proxy) подменяет Ваш IP-адрес, и злоумышленник будет пытаться совершить атаку не на Ваш компьютер, а на прокси сервер, у которого, зачастую, максимально мощная система защиты.

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

HTTP/HTTPS proxy – наиболее распространённый тип прокси серверов, который зачастую имеет 80, 8080, 3128 номер порта. HTTP прокси делятся уровнем анонимности на: прозрачные (не скрывают реальный IP адрес клиента), анонимные (указывают на то, что используется прокси, но не выдают реальный IP адрес клиента), искажающие (искажают IP адрес клиента), элитные прокси (не указывают на то, что используется прокси сервер, скрывают реальный IP адрес клиента).
SOCKS proxy – прокси сервер передающий абсолютно все данные от клиента к серверу, не изменяя и не добавляя ничего. С точки зрения web-сервера SOCKS proxy является клиентом, т.е. SOCKS proxy анонимны по определению. Имеет подтипы SOCKS4, SOCKS4a, SOCKS5. Чаще всего SOCKS proxy имеют 1080, 1081 номер порта.
FTP proxy – прокси сервер, предназначенный для работы с файловыми менеджерами.
CGI proxy или Anonymizer — web-страницы, которые позволяют осуществлять анонимный переход с одной web-страницы на другую. Для использования данного типа прокси не надо менять настройки браузера, достаточно перед адресом страницы, на которую вы собираетесь перейти указать адрес анонимайзера.

По принципу работы прокси-серверы можно разделить по двум ключевым при­знакам.

Во-первых, некоторые прокси-серверы имеют ассоциированные с ними
кэши, а другие - нет. Во-вторых, вне зависимости от кэширования, некоторые про­кси-серверы модифицируют проходящие через них сообщения, тогда как другие этого не делают.

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

Прозрачный прокси-сервер
По принципу передачи сообщений прокси-серверы можно разделить на две
группы: прозрачные и непрозрачные. Различие между ними связано с модифика­цией проходящих через прокси-сервер сообщений. Прозрачный прокси-сервер мо­дифицирует запрос или ответ лишь в меру необходимости. Примером такого изменения сообщения прозрачным прокси-сервером может служить добавление идентификационной информации о себе или сервере, от которого сообщение было
получено. Подобная информация может даже являться обязательной для протокола HTTP. В разделе 3.8 мы поговорим о неправильном использовании термина «прозрачный прокси-сервер» в различных сферах Web-индустрии для обозначения прокси-серверов, которые правильнее было бы назвать перехватывающими про­кси-серверами.
Непрозрачный прокси-сервер способен модифицировать запрос и/или ответы.
Примером такого изменения запроса является анопимизация, в соответствие с ко­торой информация о клиенте прокси-сервера скрывается. Примером изменения от­вета может послужить преобразование формата - изображение конвертируется из одного формата в другой для уменьшения размера ответа. Другой пример непро­зрачного прокси-сервера - прокси-сервер, осуществляющий перевод документа с одного языка на другой. Имеются правила, являющиеся общими для прокси-сер­веров обоих видов. В то же время с каждым видом прокси-серверов связаны свои собственные правила. Прозрачный прокси-сервер должен обеспечить, чтобы длина содержимого сообщения не изменялась при передаче сообщения через прокси-сер­вер. Заметим, что прозрачные и непрозрачные прокси-серверы отличаются от шлюзов и туннелей. Оба вида прокси-серверов могут, в отличие от туннелей, иметь ассоциированный с ними кэш. Оба вида прокси-серверов действуют как промежуточное звено между Web-клиентом и Web-сервером; т.е. обмен сообще­ниями осуществляется в формате HTTP.

Под прозрачными прокси понимаются стандартные прокси-серверы, которые не изменяют данные пользователя, оставляя их в «первозданном» виде. То есть они не прячут IP-адрес.

Transparent Proxy обрабатывает весь HTTP-трафик, при этом пользователю не нужно указывать никаких настроек.

Такие прокси помогают ускорить доступ к страницам сайтов, которые определяет пользователь – в основном часто посещаемым. Ускорение загрузки происходит за счет помещения сайтов в кэш. Как правило, прозрачные прокси работают быстрее (скорость загрузки выше), чем их элитные или анонимные «товарищи».

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

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

Transparent Proxy примерно так передают HTTP-заголовки:

REMOTE_ADDR – демонстрирует IP прокси

Присутствие переменной _X_ говорит о необязательности использования данной переменной. Передача аналогичной переменной происходит в виде HTTP_X_FORWARDER_FOR.

Однако лидеры прокси (Cash Engine, Squid) довольно активно поддерживают эту переменную.

Анонимные прокси (Anonymous proxy)

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

Анонимные прокси скрывают данные пользователя при интернет-серфинге. Они меняют IP-адрес случайным образом. И IP-адрес не является зарегистрированным по простой причине: значение HTTP_X_FORWARDER_FOR конечному сайту вообще не передается. Впечатляет, не правда ли?!

Анонимный прокси тоже выдает:

REMOTE_ADDR - демонстрирует IP прокси

HTTP_VIA – демонстрирует адрес прокси-сервера

HTTP_X_FORWARDER_FOR - сообщает прокси ваш IP-адрес.

Однако все сведения заполняются исключительно «для галочки» и не несут правдивой информации. А больше ничего и не нужно, как считают многие интернет-пользователи.

Элитные прокси (Elite Proxy)

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

Elite Proxy превосходно маскируется. Это значит, что в интернет-пространстве не появится никаких признаков использования прокси-сервера. Но узнать ваш IP-адрес будет невозможно. Заголовки HTTP_X_FORWARDED_FOR, HTTP_PROXY_CONNECTION, HTTP_VIA вообще не отправляются. Хост не получает никаких сведений: ни об использовании прокси, ни IP-адрес. В этом плане элитные прокси превосходят все остальные прокси-серверы.

Однако недостаток у Elite Proxy тоже имеется: заголовок REMOTE_ADDR сохраняет IP-адрес прокси. Поэтому при отправке пакетов с куками, сохраненными в результате интернет-серфинга, когда вы не использовали элитный прокси, сайты вас не узнают. Не хотите допустить подобное? Чистите кэш и cookies заранее.