 |
|
|
|
В поисках анонимного прокси-сервера
В поисках анонимного прокси-сервера Вопрос о безопасном серфинге по Интернету поднимался не раз. При использовании для этой цели прокси-сервера возникает вопрос, что лучше: искать прокси или создать свой? Если искать – как быстрее? А если создавать – как проще? Зачастую возникает задача анонимно посетить необходимый ресурс в локальной или глобальной сети. Цели могут быть разные, первое и самое распространенное в работе системного администратора – это тестирование только что настроенной системы авторизации сервера. Второе – анонимно ответить подозрительному человеку по электронной почте, через веб-интерфейс своей почтовой системы. Третье, выполнить просьбу начальства, скрытно посетить сайт конкурирующей фирмы. Четвертое – просто быть уверенным, что, заходя в чат, IRC-канал или форум, нас не распознают. Ситуации бывают абсолютно разные, возникают они не каждый день, но все же бывают. Что тогда делать? Искать по Интернету прокси-лист? Но чаще всего в нем 90% недействующих ссылок. Просить друга администратора дать доступ по ssh-протоколу, и, воспользовавшись lynx или links из консоли, посетить необходимый ресурс? Выход есть всегда, но хорошо иметь под рукой необходимые средства для анонимной работы. О прокси-серверах Вопрос о безопасном серфинге по Интернету поднимался не раз. Существует множество методов скрыть свой реальный IP-адрес. Рассмотрим известную вам тему – как скрыть свой реальный IP-адрес с помощью прокси-сервера. Самое простое решение – это прокси c веб-интерфейсом (например [1]). Заходим на страницу и в появившемся окне вводим необходимый URL. Метод самый простой, не требуюет даже перенастраивать браузер, но очень часто подобные сервисы, чтобы существовать, зарабатывают на рекламе, которую показывают нам. Кроме простоты использования, данные веб-прокси имеют еще один плюс – они долговечны. Но и минусы очевиды: реклама, невысокая скорость, отсутствие гибкости настроек и смены IP-адреса. Что ж, самое легкое – не значит самое хорошее. В Интернете можно найти сотни списков http-прокси, от простых кэширующих до анонимных с поддержкой шифрования, антивирусной проверкой и «чистыми» логами. Последние, как правило, пользуются большой популярностью, но они не бесплатны. Если необходимо, можно купить пару таких прокси, благо цена на обслуживание в месяц у них колеблется от 1 до 50 долларов, хотя если прокси стоит более 20-30 условных единиц – это не более чем попытка его владельца заработать большие деньги. Что ж, хороший прокси иметь под рукой всегда полезно, но не всякий готов платить деньги, да и анонимность тоже под вопросом (неизвестно где этот прокси расположен). Последний и, на мой взгляд, самый эффективный прокси – это root shell. Имея под рукой собственный сервер на Linux/BSD, мы можем делать с ним очень многое: выбрать саму программу прокси (Squid, oops! и другие), добавить антивирус, отрегулировать кэш и выстроить каскад. При этом все зависит только от нас: обновление антивируса и прокси-сервера, настройка цепочки прокси. Тема настройки шлюзов и прокси-серверов под ОС Linux/BSD очень хорошо освещена в Интернете, поэтому не будем ее касаться. Рассмотрим два первых вопроса: автоматизация процесса поиска, выбора, проверки прокси и создание собственного cgi прокси-сервера, проанализируем плюсы и минусы. В поисках анонимных прокси Задав в форме поиска Google ключевую фразу «proxy list», будет выведено «...примерно 45.900.00 для proxy list». Как обработать подобную информацию? Конечно же, столько листов не нужно. У многих есть 5-6 закладок на любимые страницы, где каждый день появляются обновленные списки, но выборка и проверка прокси занимает немалое время, попробуем автоматизировать данную задачу стандартными средствами ОС Linux/BSD. Независимо от того, есть ли у нас страницы-«фавориты» с прокси-серверами или нет, нам понадобятся прокси-листы, после сбора их необходимо отсортировать, удалить дубликаты и проверить. Итак, приступим: #!/bin/bash # Переменная счетчик n=1 echo "Всего ресурсов "`wc -l ./site.list` while [ 1 ] do # Текстовым редактором sed построчно читаем файл site.list и заносим значение в переменную f1=`sed -n ''$n'p' ./sity.list` # Если переменная пуста, что означает конец файла – выходим из цикла if [ "$f1" = "" ]; then echo "Список обработан" exit 1 fi # Для наглядности выводим каждый раз номер строки и название ресурса echo "$n $f1" # Считываем информацию с ресурса curl $f1 --user-agent "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" | grep -o "[0-9.]\+[0-9.]\+[0-9.]\+:[0-9]\+" >> proxy.list # Счетчик увеличивается на 1 let "n += 1" done # Количество прокси-серверов до удаления дубликатов echo "Всего найдено"`wc -l proxy.list` cat proxy.list | sort | uniq > proxy.list # Количество прокси-серверов после удаления дубликатов echo "После сортировки осталось"`wc -l proxy.list` Рассмотрим скрипт подробнее. В файл site.list мы самостоятельно заносим «любимые» ресурсы с прокси-листами (или только что найденные). Например (имена ресурсов вымышлены): http://www.proxy.com http://www.proxy-list.com/list1.html http://www.proxy-list.com/list2.html http://www.proxy-list.com/listN.html Желательно занести более 20-30 ресурсов. Утилитой wc подсчитаем строки в файле site.list и выведем их количество для наглядности. Текстовым редактором построчно читаем файл, и утилитой curl выбираем из html-страниц адреса прокси-серверов. При посещении ресурсов лучше задействовать параметр --user-agent, так как некоторые ресурсы не удастся посетить не представившись каким-нибудь популярным браузером. В скрипте приведен пример идентификации браузера Internet Explorer из Windows XP, но это необязательно, например, идентификация Firefox из ОС семейства Linux будет выглядеть так: «Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7». Утилитой grep сделаем выборку необходимой информации со страницы. Заметьте, что можно сделать выборку и короче, например, так: «[0-9.]\+:[0-9]\+». Но, к сожалению, на страницах может быть много иной, подходящей под данную маску информации (например, «время жизни» прокси), тогда в финальном файле вы увидите много лишних данных. На последнем этапе найдите и удалите дубликаты прокси-серверов в файле proxy.list, с помощью стандартных команд sort и uniq. Все, в конечном файле мы получим «чистый» список прокси-серверов, осталось их проверить на работоспособность. В Интернете можно найти множество программ, проверяющих подобные списки, но в основном эти программы под ОС Windows и не бесплатны (чаще пробные версии весьма ограниченны). Заметьте, что тестировать прокси-серверы со своей машины очень неэффективно, так как мы будем ограничены пропускной способностью канала. Чтобы не зависеть от сторонних разработчиков, Windows и пропускной способности нашего канала, воспользуемся одним из многих on-line-прокси-чекером [2]. Итак, в итоге мы получили список рабочих прокси-серверов... или нет? Было упомянуто, что файл с сайтами по возможности должен содержать более 20-30 ресурсов. Это связано с тем, что многие ресурсы дублируются по своему содержанию. В моем примере было обработано 32 сайта, найдено 1532 прокси-сервера, из них после удаления дубликатов осталось 325, после проверки on-line-чекером было найдено рабочих 15, из них закрылись через 5 минут 4, остальные – в течение часа. Возможно, этот метод и результаты кому-то и подойдут, так как время работы скрипта и чекера достаточно мало (около 7 минут), можно дополнительно автоматизировать передачу списка на on-line-чекер (тем же самым curl, с помощью опций -F или -d), но зависеть от удачи и ждать, повезет или нет, был получен не конечный результат. Поэтому предлагаю вам рассмотреть решение с использованием cgi-прокси. Работаем с CGIProxy С самого начала было ясно, что для стабильности необходимо иметь свой собственный прокси-сервер, но что если свободного доступа на удаленном ресурсе по протоколу ssh нет? Да и конфигурировать удаленно прокси-сервер не всегда бывает удобно. Для подобных задач и существуют cgi-прокси. Их главное удобство: легкость установки и конфигурирования, небольшой размер, возможность работать удаленно по протоколу http (если более ничего нет). Рассмотрим ниже один из cgi-прокси-серверов, написанный на языке Perl – CGIProxy [3]. Итак, закачав скрипт, приступим к его установке. Как и любой cgi-скрипт, его достаточно просто поместить в cgi-bin директорию веб-сервера, и все готово к работе (см. рисунок). Главное – не забудьте проверить путь к интерпретатору языка perl, по умолчанию значение равно #!/usr/bin/perl. Из пользовательских опций доступны лишь 5:
Подробнее об опциях расскажу немного позже. Как настраивать скрипт? Конфигурирование CGIProxy не должно вызвать затруднений, ведь это простой скрипт, написанный на Perl. Даже если язык вам плохо знаком, открыв файл любым текстовым редактором, вы увидите в первой части скрипта все 50 параметров (которые являются не чем иным, как переменными) и богатую справку по ним с примерами. Веб-интерфейс CGIProxy Итак, пользовательские опции (см. рисунок) доступны как администратору, так и пользователю. Если скрипт будет использоваться несколькими лицами, рекомендуется убрать данные параметры для посетителей (опция «$ALLOW_USER_CONFIG») по соображениям безопасности. Связано это с тем, что, если пользователь отключит опцию «Remove all scripts», анонимность серфинга уже будет не гарантирована (о чем нас предупреждают на сайте разработчиков) и второй параметр «Hide referrer information» скрывает от посещаемого сайта данные, откуда «мы пришли», если открыть данную опцию, директива HTTP_REFERER в заголовках честно выдаст информацию о наших переходах. Дополнительно для анонимности стоит раскомментировать опцию «$USER_AGENT», так как она отвечает за идентификацию нашей системы. По умолчанию значение равно: «Mozilla/4.05 [en] (X11; I; Linux 2.0.34 i586)», рекомендуется выставить что-то более распространенное и новое. Примеры браузера FireFox на ОС семейства Linux и Internet Explorer на Windows XP были выше, но если хочется экзотики, можно представиться браузером Camino из MacOS X, запись users-agent тогда будет иметь вид: «Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060911 Camino/1.0.3». Перечисленных изменений для безопасного серфинга достаточно. Изменения в скрипте можно сохранить и хранить его локально, а в необходимый момент выгрузить на хост. Можно использовать CGIProxy и в каскаде, но это не очень удобно. Настройка скрипта достаточно гибкая, множество списков доступа к ресурсам и баннерным сетям позволяет при желании достичь максимальной производительности. Например, для экономии трафика можно включить замену gif-изображения на пустой пиксель 1*1 (параметр $RETURN_EMPTY_GIF). Редактировать текст приглашения и другие сообщения прокси-сервера, как не трудно догадаться, можно прямо в скрипте. Блок сообщений находится в нижней части скрипта, поэтому при необходимости локализация CGIProxy будет очень проста. Несмотря на то что разработчики предупреждают нас о том, что следует отключать обработку скриптов (так как только в этом случае будет гаратирована анонимность), после посещения 5-7 ресурсов проверяющие на анонимность пользователя мне так и не удалось увидеть свой IP, точные данные о ОС и браузере. Проверить «себя» на анонимность можно, к примеру, по ссылке [4]. Итак, в итоге все же был получен стабильный прокси-сервер, легкий в установке, простой и гибкий в конфигурировании. CGIProxy за свою простоту и в то же время за богатство возможностей часто используется на «анонимайзерах», и если внимательно приглядеться на сайт по ссылке [1], мы увидим слегка измененный cgiproxy. Из минусов можно выделить: проблемы при работе скрипта с веб-сервером IIS от компании Microsoft (на сайте проекта описаны возможные проблемы и их решения) и все же существующую затрудненность конфигурирования. Как вы уже, наверное, заметили, по описанию сложно сориентироваться: «где-то наверху», «в нижний части скрипта», к сожалению, когда проект был «молодым», скрипт был небольшим, размером 260 Кб (последняя stable-версия 2.0.1 от 19 ноября 2002 г.), и разобраться в файле не составляло труда, тогда как разыскать нужные опции, параметры, текстовые поля в файле размером 450 Кб уже сложнее и без использования поисковых средств текстового редактора найти необходимые параметры сложно. Возможно, также у кого-то из вас возникнут затруднения с поиском хостинга, поддерживающего Perl, но обратившись в раздел часто задаваемых вопросов на сайте CGIProxy, вы можете найти список ресурсов, предоставляющих место под сайт с интерпретатором языка Perl. Выводы Если выбирать между стабильным и нестабильным решением, стоит опираться, конечно, на первый вариант (с личным cgi-прокси), но исключать вторую возможность (поиска) нельзя. Иметь root shell где-нибудь в Европе с установленным прокси-сервером, конечно, еще намного удобнее, но такая возможность доступна не всегда. Найти простой хостинг, даже без доменного имени, SQL и почтовых серверов, но с интерпретатором языка Perl намного проще. CGIProxy можно с легкостью закрыть, открыть, иметь в запасе 2-3 штуки или просто хранить как запасной вариант, так как у большинства системных администраторов есть доступ к корпоративным страницам, которые легко можно использовать в тестовых целях. В различных ситуациях могут быть различные решения, главное, чтобы всегда был выбор. Удачной работы! Приложение Коротко о CGIProxy CGIProxy представляет собой сетевую службу, позволяющую клиентам выполнять запросы к ресурсам сети, скрывая реальные сведения клиента (или проще говоря – анонимный прокси-сервер). Первый релиз скрипта был выпущен 13 августа 1998 г. Проект постоянно развивается, дорабатывается, исправляются ошибки, вводятся новые функции. Последняя доступная версия (на момент написания статьи) 2.1beta15 от 26 октября 2006 года, размер скрипта 455 Кб. Данный cgi-proxy является http, ftp-прокси, может работать по протоколу SSL, доступны средства авторизации, имеет 50 внутренних опций, которые позволяют конфигурировать: cookie (сохранение, просмотр, удаление), обработку скриптов (полное их исключение из страниц, фильтр), листы доступа (доступны как «белые», так и «черные» списки по доменам или IP-адресам), фильтры баннеров (опять же обычные списки) и другие полезные опции. Системные требования у скрипта очень скромные: веб-сервер и интерпретатор языка Perl (версии выше 5.6.1). Замечу, что CGIProxy является nph-скриптом (Non-Parsed Header). Данные скрипты полностью формируют http-заголовок, и веб-сервер не обрабатывает выданные этими скриптами данные, а передает результат браузеру без изменений. Для некоторых веб-серверов указание в начале имени файла «nph-» обязательно, будьте внимательны. Также напомню, что для работы по протоколу ssl необходимо, чтобы на сервере были установлены библиотека OpenSSL и модуль Net::SSLeay (их легко найти в портах/пакетах всех современных Linux/BSD-систем). CGI:IRC Рассказывая о распространенных cgi-скриптах, нельзя не упомянуть о еще одном знаменитом скрипте, написанном на Perl – CGI:IRC [5]. Именно этот скрипт обеспечивает работу многим известным ресурсам («шлюзам в IRC»). Последняя доступная версия на сайте проекта 0.5.9 от 6 июня 2006 года. Этот скрипт, как и CGIProxy, является nph-скриптом, поэтому требования у них примерно одинаковые, за исключением версии Perl, для cgi:irc необходима версия 5.0.4 или выше. Программа в отличие от cgi-прокси-сервера состоит не из одного скрипта, а из 3 основных (client-perl.cgi, irc.cgi и nph-irc.cgi) и вспомогательных каталогов (в них содержатся картинки, звуки, модули), поэтому, перенося скрипт на веб-сервер, будьте внимательны. Для настройки скрипта отредактируйте файл cgiirc.config (или возьмите его полную версию cgiirc.config.full, но это не столь необходимо), замечу, что при всем разнообразии опций назначение их понятно с первого взгляда (default_port, default_server и другие), благодаря чему настройка не вызывает трудностей. Очень жаль, что в CGIProxy конфигурационный файл также отдельно не вынесен, так было бы намного удобней.
|
Иван Максимов
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
