Прозрачный proxy. Прозрачный прокси-сервер Squid. Режим - каскадный прокси

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

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

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

Я предполагаю что вы уже знаете что такое прокси сервер (в противном случае предлагаю ознакомится с статьей ). Вы уже не раз слышали: прозрачный (transparent), анонимный (anonymous) или элитный (elite) прокси сервер, но какая разница между ними? Во первых, надо обратить внимание на тот факт, что все прокси не смотря на то к какому типу они относятся, работают по одному и тому же принципу (они представляют из себя промежуточный пункт между вами и ресурсом который вы запрашиваете).

Что такое прозрачный (transparent) прокси сервер?
Прозрачный прокси сервер меняет ваш IP адрес на свой, НО ваш реальный IP все равно присутствует в вашем запросе (представьте что он просто перенесен в другое место). Таким образом если веб сайт (который вы запрашиваете) решит определить ваш реальный IP, то он без затруднений сделает это.

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

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

ИНТЕРЕСНО: если вы не используете прокси или используете но прозрачный, ваш ПК транслирует всем ваш уникальный IP адрес. Каждый раз когда вы открываете веб страничку, сервер на котором находится данная страница, имеет полную информацию о вашей операционной системе (ОС). Это значит что владелец веб сайта может с легкостью определить самые уязвимые места вашей ОС. Пользователь не должен быть профессиональным хакером с специальным образованием что бы используя эти уязвимости он смог взломать ваш ПК. Есть дюжина готовых, легких в использовании и (внимание) БЕСПЛАТНЫХ программ которые любой ребенок сможет использовать (пожалуйста не просите меня указать где можно скачать подобный софт, как взломать форум или почтовый ящик, я все равно вас не научу ). С помощью таких программ, любой желающий может получить доступ к вашим документам, письмам, личным фотографиям или фильмам которые вы храните на своем ПК - думая что они надежно скрыты от посторонних глаз Что бы предотвратить подобные хакерские атаки, вам необходимо скрыть ваш реальный IP адрес, и тем самым скрыть адрес вашего ПК в интернет сети.

Что такое анонимный (anonymous) прокси сервер?
Анонимный прокси сервер не передает информации о вашем реальном IP адресе. Это значит что вы как привидение в интернете, никому не известно о вашем реальном место положении и по этой простой причине, просто невозможно установить скрытое соединение с вашим ПК, для похищение информации.

Единственным ВОЗМОЖНЫМ недостатком анонимного прокси сервера можно посчитать тот факт, что веб сайт который вы запрашиваете, может определить что вы используете прокси для соединения (это в свою очередь может означать что вы скрываете ваш реальный IP адрес). Но с другой стороны, если пользователь использует прокси сервер, это не всегда значит что он пытается скрыть свой реальный IP адрес. Допустим когда вы используете мобильный WAP интернет, в таком случае все пользователи обязаны использовать один прокси сервер, который предоставляет мобильный оператор (главным образом для мониторинга).

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

Что такое элитный (elite) прокси сервер?
Элитные прокси самые "скрытные", они имеют все преимущества анонимных прокси серверов с точки зрения скрытия вашего реального IP, но плюс ко всему они ПЫТАЮТСЯ скрыть сам факт использования прокси сервера при запросе. Другими словами, они ведут себя таким образом, что создают впечатлени, что вы вовсе не использовали прокси для запроса и IP адрес который вы передаете серверу, ваш реальный адрес. Главное что вы должны знать о элитных прокси серверах это то что из за их возможности скрывать факт использования прокси, они очень популярны, а это в свою очередь приводит к тому что их очень часто перегружают и в результате они работают медленней.

Вы всегда можете проверить насколько надежно скрыть ваш IP адрес от веб сайта, посетив следующий линк: Покажи мой ИП

Подведем итог, в двух словах опишем преимущества и сферу применения каждого типа прокси сервера:

Прозрачный прокси сервер:

Анонимный прокси сервер:

• Преимущество: средняя скорость, средняя скрытность
• Возможный недостаток: виден факт использования прокси
• Общее применение: подходит для 99% задач

Элитный прокси сервер:

• Преимущества: высокий уровень скрытности, скрыт факт использования прокси
• Недостатки: низкая скорость
• Конкретное применение: очень редкий случай, когда необходимо скрыть сам факт использования прокси сервера

ВНИМАНИЕ: весь материал представленный в данной статье предназначен только в образовательных целях

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

Прозрачный прокси - схема связи, при которой трафик, или его часть, перенаправляется на прокси-сервер неявно (средствами маршрутизатора). При этом клиент может использовать все преимущества прокси-сервера без дополнительных настроек браузера (или другого приложения для работы с интернетом). Пример: 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 в каталоге ссылок

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

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 на сервера с виртуальными доменами, которые часто используются на бесплатных хостингах (и не только).

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

В данной статье приводится пример быстрой настройки кэширующего прокси сервера Squid в Linux Debian 6. Результатом настройки станет возможность выхода в Интернет через данный сервер по протоколам: http, https и ftp.

Сразу оговорюсь, что полученный сервер не является сетевым фильтром и потенциально уязвим для сетевых атак.
Настройка сервера осуществляется на базе ОС Linux Debian 6. Все приводимые ниже команды должны выполняться с правами суперпользователя (root).

Сразу важное предупреждение: авторизация и прозрачный прокси несовместимы! Придется выбирать что-то одно. Второе предупреждение: авторизация через прокси позволит ограничить доступ в Интернет только по HTTP протоколу. Остальные протоколы: FTP, SMTP, POP3 и другие будут спокойно продолжать работать через NAT. Хотя в небольших организациях это не столь критично, наиболее употребляемым (и злоупотребляемым) является именно протокол HTTP, и одной из задач администратора является ограничение доступа сотрудников в интернет именно через браузер.

Если Вы пользуетесь Apteture с загрузкой пакетов из сети, рекомендую перед установкой обновить списки актуальных пакетов:

# apt-get update

Запускаем установку Squid:

# apt-get install squid3

После окончания установки, начинаем редактировать файл конфигурации сквида. Не знаю как вам, лично мне удобнее когда в файле конфига нет ничего лишнего, то есть присутствуют только непосредственно параметры конфигурации. Для этого бекапнем оригинальную конфигурацию сквида (чтоб было где искать описания всех параметров):

cp /etc/squid/squid.conf /etc/squid/squid.conf.original

и выжмем из оригинальной конфигурации всё, не закоментированное:

cat /etc/squid/squid.conf.original | grep -v "^\(#\|$\)" > /etc/squid/squid.conf

В итоге заимеем дефолтный конфигчик без ничего нишнего. Но всё же очень советую кинуть взор в оригинальный конфиг и почитать его на досуге - там очень много интересного!

Ну, наконец, приступим к редактированию:

nano /etc/squid/squid.conf

После установки, требуется небольшая настройка. Открываем в редакторе конфигурационный файл Squid, который должен располагаться в /etc/squid/squid.conf. В этом файле находим строки:

Acl localnet src 10.0.0.0/8
acl localnet src 172.16.0.0/12
acl localnet src 192.168.0.0/16

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

# acl localnet src 10.0.0.0/8
# acl localnet src 172.16.0.0/12
# acl localnet src 192.168.0.0/16
acl localnet src 192.168.1.0/24 # Собственная локальная сеть

В последней строке вместо 192.168.1.0/24 нужно подставить параметры Вашей сети.

Чуть ниже комментария # TAG: http_access необходимо найти строку:

Http_access allow localhost
или
http_access allow manager localhost

Сразу после этой строки добавляем строку:

Http_access allow localnet
cache_dir ufs /var/cache/squid 2048 16 256
mkdir -p /var/cache/squid
chmod 755 -R /var/cache/squid

Разрешая тем самым доступ в сеть всем компьютерам из локальной сети. После этого сохраняем файл squid.conf и перезапускаем Squid сервер:

# /etc/init.d/squid restart

Если после рестарта squidа у вас вылезет ошибка (WARNING cache_mem is larger than total disk cache space!) просто уменьшите значение параметра cache_mem 8 MB я поставил 32

Если Вы с конфигурационный файл внесли изменения из ошибок, то Squid должен успешно перезагрузиться. При возникновении ошибки можно узнать из-за чего она произошла в Log-файле: /var/log/squid/cache.log
Настройка обозревателя на работу через Proxy-сервер

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

Важно, чтобы прокси сервер в локальной сети имел фиксированный IP-адрес. Предположим, что у Вас это 192.168.1.1. Например для настройки Internet Explorer требуется открыть Сервис-Свойства обозревателя-Подключения-Настройка сети. В открывшемся окне поставить галочку в поле Использовать прокси-сервер для локальных подключений. Поставить галочку на Не использовать прокси-сервер для локальных адресов. В поле Адрес ввести IP-адрес нашего прокси сервера: 192.168.1.1. В поле Порт ввести порт, применяемый Squid по-умолчанию: 3128.

После этих настроек Ваш обозреватель будет выходить в сеть через наш новый прокси-сервер. В других обозревателях настройка аналогичная приведенной выше для Microsoft Internet Explorer.

Порт прокси-сервера можно поменять по своему усмотрению в файле /etc/squid/squid.conf. Он задан в строке:

http_port 3128 transparent

Заключение
Установка и настройка кэширующего прокси сервера на базе Squid это всего лишь первый этап в создании производительного шлюза в Интернет. Чуть позже я расскажу как настроить «Прозрачный прокси сервер», Firewall и как можно вести статистику посещений пользователями сайтов пользователями локальной сети.

Очень важно правильно настроить iptables. Второй вариант чуть ниже, мне он больше по душе

На этом шаге я предлагаю Вам создать скрипт настройки, так как он пригодится как универсальное средство.1 # vim ./setiptables.sh

#!/bin/bash
LAN=$1
WAN=$2
IP=$3
GW=$4
iptables -t nat -A PREROUTING -i $LAN -p tcp --dport 80 -j DNAT --to $IP:3128
iptables -t nat -A PREROUTING -i $WAN -p tcp --dport 80 -j REDIRECT --to-port 3128
iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -A FORWARD -i $WAN -o $LAN -s $GW/24 -p tcp -m multiport --dport 443,21,22 -j ACCEPT
echo "net.ipv4.ip_forward = 1" > /etc/sysctl.conf
sysctl -w net.ipv4.ip_forward=1

Мы обозначили переменные (для удобства), 3 правила для таблицы NAT и 1 для FORWARD.
Порты 443,21,22 пускаем в обход прокси сервера.
Помимо настроек iptables, в этом скрипте, мы включаем форвардинг пакетов.
Запускаем так:1

# sh ./setiptables.sh eth0 eth1 192.168.100.1 192.168.100.0

6) Настроим автозагрузку натсроек iptables.
Сохраням настройки iptables.

# mkdir -p /usr/local/iptables && iptables-save > /usr/local/iptables/session.ipt

Добавляем команду авотзапуска в /etc/rc.local (мне нравится Perl но тут кому как).

# perl -i -pe "print "iptables-restore < /usr/local/iptables/session.ipt\n" if $. == 2" /etc/rc.local

Также не забываем про форвардинг пакетов

# perl -i -pe "print "sysctl -w net.ipv4.ip_forward=1\n" if $. == 3" /etc/rc.local

Второй вариант настройки firewall iptables

Включим в системе форвардинг. В файле /etc/sysctl.conf раскомментируем строчку

net.ipv4.ip_forward=1

Итак, на текущий момент мы имеем полностью сброшенные настройки файрвола (iptables).

Сбрасываем цепочки:

$ sudo iptables -F
$ sudo iptables -F -t nat
Запрещаем все входящие и разрешаем все исходящие и форвардинг:
sudo iptables -P INPUT DROP
sudo iptables -P OUTPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
Разрешаем принимать ответ на УЖЕ установленный соединени:
sudo iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
Разрешаем loopback-трафик:
sudo iptables -A INPUT -i lo -j ACCEPT
Разрешаем весь трафик с нашей внутренней сети (возьмем подсеть 222):
sudo iptables -A INPUT -s 192.168.222.0/24 -i eth1 -j ACCEPT
И, залог прозрачности! Перенапрявляем весь исходящий http-трафик (на порт 80) на порт сквида 3128:
iptables -t nat -A PREROUTING -s 192.168.222.0/24 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
iptables -t nat -A POSTROUTING -s 192.168.222.0/24 -o eth0 -j SNAT --to-source 192.168.56.39

Проверяем на клиенте интернет. Напомню, что если прокси указывать не обязательно, шлюз выставить необходимо!
Однако, после первой же перезагрузки, мы поймем, что все наши старания ушли впустую.
Научим же их выживанию!
Итак, сохраним всё то, чем мы тут занимались:

iptables-save > /etc/firewall.conf

У меня с судо этот финт не получился (хотя в теории вроде должен…), потому можно сделать влогинившись в рута полностью (su) и запустив команду, но без sudo.
А теперь создадим скрипт, заставляющий ifupdown воскрешать наш файрвол:

nano /etc/network/if-up.d/00-iptables

Впишем в него следующее:

#!/bin/sh
iptables-restore < /etc/firewall.conf

Выставим права на исполнение:

chmod +x /etc/network/if-up.d/00-iptables

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

Отключаем IPv6 если кто не использует

Предлагаю опять же сделать скрипт чтобы не запутаться.
nano ./ipv6disable.sh

#!/bin/bash
perl -i -pe "print "alias net-pf-10 ipv6 off\n" if $. == 17" /etc/modprobe.d/aliases.conf
perl -i -pe "print "alias net-pf-10 off\n" if $. == 18" /etc/modprobe.d/aliases.conf
perl -i -pe "print "alias ipv6 off\n" if $. == 19" /etc/modprobe.d/aliases.conf
echo 1 | tee /proc/sys/net/ipv6/conf/all/disable_ipv6
echo "blacklist ipv6" | tee -a /etc/modprobe.d/blacklist.conf
STR=$(cat /boot/grub/grub.cfg | sed -n "67p")
STR=${STR}" ipv6.disable=1"
sed "67d" /boot/grub/grub.cfg > /boot/grub/grub.cfg.backup
cp /boot/grub/grub.cfg.backup /boot/grub/grub.cfg
sed -i 67i\ "$STR" /boot/grub/grub.cfg

В общих чертах что в этом скриптике происходит:
Сперва отключаем пожжержку ipv6 в модулях ядра.
Далее указываем маркер в /proc на не использование ipv6.
И в 67 строке /boot/grub/grub.cfg дописываем параметр ipv6.disable=1.
Такая канитель с tee и sed нужна для того чтобы сохранить настройки /boot/grub/grub.cfg, так как там устройства обозначаются не по /dev/sd* и по UUID.
Хотя все всегда можно дописать ручками.
Теперь нам надо прикрутить squidguard
Итак, половина работы уже сделана, теперь осталось установить пакет SquidGuard и настроить его. Для установки пишем в терминале из под пользователя root (права root в Debian GNU/Linux можно получить командой su, в Ubuntu перед командами пишем sudo):

apt-get install squidguard

После установки скачаем черные списки blacklists комадной wget из терминала (внимание, размер файла 24 Мб!):
wget -c my_blacklists.tar.gz

И распакуем его в каталог, где должны распологаться базы SquidGuard (необходимы права администратора):

tar zxvf my_blacklists.tar.gz -C /var/lib/squidguard/db

В результате распаковки появится каталог /var/lib/squidguard/db/my, содержащий множество подкаталогов разных категорий со списками доменов и адресов нежелательных сайтов. Этот список был составлен нами на основе трёх чёрных списков, загруженных с сайтов http://www.squidguard.org , http://www.shallalist.de и http://www.urlblacklist.com . В результате наш список содержит более 3-х миллионов сайтов.

Теперь необходимо настроить связку Squid и SquidGuard и подключить к ним чёрные списки. Для этого в файл squid.conf дописываем следующие строки, открыв файл в редакторе nano с правами администратора:

nano /etc/squid/squid.conf

Добавляем строки в конец файла:

Redirector_bypass on
redirect_program /usr/bin/squidGuard
redirect_children 1

mv /etc/squid/squidGuard.conf /etc/squid/squidGuard.conf_original

Скачиваем файл конфигурации squidGuard.conf с нашего сайта командой wget в терминале:
wget -c squidGuard.conf

Копируем его на место старого файла (с правами администратора):

cp squidGuard.conf /etc/squid/squidGuard.conf

После копирования файла конфигурации инициируем конвертирование текстовых чёрных списков, которые вы скачали и распаковали, в формат баз данных Berkeley DB (команда будет выполняться некоторое время - нужно дождаться полного окончания), выполнив команду от администратора:

squidGuard -d -C all

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

2012-03-16 12:51:53 squidGuard 1.4 started (1331887787.768)
2012-03-16 12:51:53 db update done
2012-03-16 12:51:53 squidGuard stopped (1331887913.657)

Что скажет об успешном завершении создании баз черных списков. Далее задаём права сервера Squid на файлы баз, выполнив команду с правами администратора:

chown -R proxy:proxy /var/lib/squidguard/db/

И рестартуем сервер Squid выполнив в Debian от root:

/etc/init.d/squid3 restart

После рестарта в результате совместной работы Squid и SquidGuard будет работать перенаправление с нежелательных сайтов на сайт . Вместо неё вы можете поставить любую другую страничку, изменив адрес последней строки файла конфигурации /etc/squid/squidGuard.conf.

Изменение записей в списках доменов и URL
Пример. Рядом с файлом domains.db в папке /var/lib/squiguard/db/направление создаём файл domains.diff. В него заносим строку или несколько строк, по одной на каждую запись:

Сайт (что означает вычеркнуть этот домен из базы)
или +sysadmin -komi.ru (что означает добавить этот домен в базу)

Даём команды:

(обновить базы db из файлов diff. В логах squidguard"а можно посмотреть сколько добавилось/убылось.)

$ squid3 -k reconfigure

(перечитать настройки без перезапуска.)
Файл domains.diff удалять, или стирать из него записи, не надо. При глобальном обновлении баз этот файл ещё пригодится. И при многократном обновлении не происходит дублирования записей в БД.

Вы можете создавать свои правила редиректов, добавляя или исключая категории нежелательных сайтов. К сожалению, стопроцентной защиты невозможно получить, т.к. новые сайты с нежелательным содержанием появляются постоянно. Даже если и постоянно обновлять списки blacklists. Если вам требуется сильная защита, то SquidGuard можно настроить на работу с белым списком разрешенных сайтов, запретив всё остальное - но тогда будет совсем ограниченный набор сайтов.

И остался один момент! Поставим статистику кто что куда и почему, по имени sarg

apt-get install sarg

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

Подгоняем конфигурацию (/etc/squid/sarg.conf) под себя. Вот главные строчки, на которые следует обратить внимание:

Access_log /var/log/squid/access.log
...
output_dir /var/www/squid-reports
...
charset UTF-8

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

Ура! Заходим изнутри сети на наш сервер, любуемся отчетами по адресу http://IP_SERVER/squid-reports/
Все ребята готово. Будут вопросы спрашивайте, помогу чем смогу.