1. Скажите пожалуйста, какими программами можно организовать цепь проксей в Линуксе? (у меня Gentoo Linux). 2. Что такое Socks прокси? Чем они отличаются от HTTP? 2.1. Там по-моему ещё какие-то версии этих Соксов есть, то ли 5ая чтоль... Чем они отличаются? 3. Какая самая надёжная защита, чтобы не запалили? Спасибо большое за внимание и Ваши ответы.
Для генты попробуй tsocks или proxychain(s). Сокс прокси отличается от http прокси тем что поддерживает работу не толькл по http протоколу но и по ssh и тд. А самая хорошая защита чтобы не запалили - это в первую очередь твои мозги и умение пользоваться поиском.
Учимся пользоватся поиском!!! Цепь проксей можно в принципе на многом даже думаю на апаче Ж) mod_proxy если заюзать 2 Socks4 от 5 отличается тока тем что в 5 можно указывать логин и пароль... Самая надёжная защита, дать пиво админу провайдера чтобы логи с твоим ипом тупо потёр )
хм, а я почему-то думал, что socks5 отличается от socks4 - поддержкой UDP протокола - поддержкой DNS запросов - поддержкой IPv6 адресации - возможностью авторизации а не
хм значит я всю жизнь ошибался Ж) но как бы ни днс ни удп ни ipv6 меня не трогало и хватало сорри за деинформацию спасибо что поправили
Прочёл ссылку во втором сообщении. Спасибо. Во сколько Вы прог мне надавали. Спасибо! Я понятия не имею чем эти проги отличаются друг от друга, не использовал ни одну. И вообще проксю в Линуксе использую только в Опере но.. "времена меняются когда приходят они.." Если взять скажем, proxychains. Там можно выстроить цепь из socks проксей, но это должны ещё эти прокси поддерживать переадресацию (или как-то это там называется). А какой у меня шанс найти фришные соксы с поддержкой такой штуки (выстраивания в цепь)? Я вообще читал где-то, что основное отличие сокс-проксей от хттп в том, что при соксах логи не ведуться в виду специфики этого протокола. Но так ли это? Кстати, а ещё общий такой вопрос, который уже длительное время меня беспокоит.. А зачем собсно прокси вообще в общий доступ выкладывают? Прокси-лист.орг например? Нафига им-то это нужно? Никакой прибыли ведь с прокси или.. всё же...? Я слышал, что многие прокси это затрояненные/зарученные/зомбированные компы. Но вот зачем их в общий доступ выкладывать не совсем мне это понятно. Даже точнее сказать, совсем не понятно.
Бред. Смотря как проксю настроить. http прокси позволяют только работать с http протоколом, socks`ы со всеми протоколами.
Не бред, всё правильно сказано. Он ведь не сказал, что логи всегда ведутся на проксе. Он сказал, что они не ведутся на соксах. А это чуть разные вещи. p.S>Заметил, что наачате люди часто недопонимают друг друга, что собственно и является причиной всех проблем. Живой тому пример - мои посты в теме про програмное удаление куков.
Платные сервисы предоставляющие анонимные VPN. Без них - хотя-бы TOR. Socks и HTTP передают траффик в нешифрованном виде, потому у провайдера (и соответственно правоохранительных органов) есть возможность следить что и где ты делаешь. А вообще как уже было сказано выше, в первую очередь мозг. Никакие прокси не спасут при наличии следов непосредственно на твоей машине.
да... для похода по порникам я юзают ТОР )) а лучше всяких саксов и впэнов... wi-fi публичный поинт (или как там правильно ... хот-спот )) идешь в мак, закказываешь коктейль и рубишься в хакинг ) канешно для этого нуна ноут или кпк, а то другие посетители не поймут если ты туда свою стационарку притащишь
Друг мой, ты плохо себе представляешь как работает провайдер. Сотрудникам провайдера глубоко пофиг что за траффик идёт, им главное знать откуда, куда и в каком количестве. Смотреть что ты там передаёшь будут только по особому решению если уже где-то до этого спаслился.
Я это прекрасно знаю, но факт остается фактом. Тебя никто не будет предварительно уведомлять если ты где-то спалился и за тебя взялись всерьез. Проще гонять все через впн, меньше шансов случайно накосячить.
Что есть Socks прокси? дока по спецификации сакса 5 Network Working Group M. Leech Request for Comments: 1928 Bell-Northern Research Ltd Category: Standards Track M. Ganis International Business Machines Y. Lee NEC Systems Laboratory R. Kuris Unify Corporation D. Koblas Independent Consultant L. Jones Hewlett-Packard Company Март 1996 Протокол SOCKS 5 Статус данного документа Этот документ описывает протокол связи по стандартам Интернет, и открыт для обсуждения и предложений. Пожалуйста обращайтесь к текущей редакции "Internet Official Protocol Standards" (STD 1) чтобы справится о стадии стандартизации и статусе этого протокола. Распространение этого документа не ограничивается. Благодарности Этот документ описывает протокол, который является развитием предыдущей версии протокола 4 [1]. Этот новый протокол основывается на бурных дискуссиях и прототипах реализаций. Основной вклад внесли: Marcus Leech: Bell-Northern Research, David Koblas: Independent Consultant, Ying-Da Lee: NEC Systems Laboratory, LaMont Jones: Hewlett-Packard Company, Ron Kuris: Unify Corporation, Matt Ganis: International Business Machines. 1. Введение Использование сетевых файрволов и систем, эффективно скрывающих организацию внутренней сетевой структуры от внешней сети, такой как Интернет, становится все более популярным. Эти файрволы обычно работают как гэйтэвэи прикладного уровня между сетями, предлагая обычно администрируемый TELNET, FTP, и SMTP доступ. С появлением более сложных протоколов прикладного уровня предназначенных для облегчения глобального информационного взаимодействия, появилась потребность в обеспечении общей основы для прозрачной и безопасной работы через файрволл для этих протоколов. Leech, et al Standards Track [Страница 1] RFC 1928 Протокол SOCKS 5 Март 1996 Существует также необходимость в строгой аутентификации при работе через файрволл, в некоторой степени похожей на используемые сейчас методы. Это требование обусловлено тем, что отношения типа клиент-сервер появляются между сетями различных организаций, и эти отношения должны быть управляемыми и, зачастую, строго аутентифицированны. Описываемый здесь протокол разработан чтобы обеспечить основу для удобного и безопасного использования сервиса сетевых файрволов для приложений типа клиент-сервер работающих по протоколам TCP и UDP. Протокол представляет собой "уровень-прокладку" между прикладным уровнем и транспортным уровнем, и, как таковой, не обеспечивает сервиса гэйтэвэев сетевого уровня, такого как пересылка пакетов ICMP. 2. Текущее положение дел Существующий сейчас протокол, SOCKS v4, предназначен для работы через файрволл без аутентификации для приложений типа клиент-сервер работающих по протоколу TCP, таких как TELNET, FTP и таких популярных протоколов обмена информацией, как HTTP, WAIS и GOPHER. Новый протокол расширяет модель SOCKS v4 добавляя к ней поддержку UDP, обеспечение универсальных схем строгой аутентификации и расширяет методы адресации, добавляя поддержку доменных имен и адресов IP v6. Реализация протокола SOCKS обычно влечет за собой перекомпиляцию или пересборку клиентских программ, работающих по протоколу TCP, для использования оответствующх функций SOCKS-библиотеки. Замечание: Если не оговорено обратное, десятичные числа в диаграммах формата пакетов обозначают длинну соответствующего поля в октетах (8-битных элементах). Если октет должен иметь определенное значение, используется обозначение X'hh' для определения значения октета в данном поле. Если используется слово 'Variable', это означает, что соответствующее поле имеет переменную длинну, определяемую либо связанным (одно- или двух-октетным) полем длинны, либо типом данных данного поля. 3. Процедура для клиентов работающих по TCP Когда работающий по TCP клиент хочет соединиться с объектом, доступным только через файрволл, он должен открыть TCP-соединение c соответствующим SOCKS-портом SOCKS-сервера. Сервис SOCKS обычно находится на TCP-порту 1080. Если соединение прошло успешно, клиент начинает переговоры о методе аутентификации, который будет Leech, et al Standards Track [Страница 2] RFC 1928 Протокол SOCKS 5 Март 1996 использоваваться, проходит аутентификацию по выбранному методу и посылает свой запрос. SOCKS-сервер обрабатывает запрос и либо пытается установить соответствующее соединение, либо отказывает в нем. Клиент соединяется с сервером и посылает сообщение с номером версии и выбором соответствующего метода аутентификации: +----+----------+----------+ |VER | NMETHODS | METHODS | +----+----------+----------+ | 1 | 1 | 1 to 255 | +----+----------+----------+ Значение поля VER равно X'05' для данной версии протокола. Поле NMETHODS содержит число октетов в идентификаторах методов авторизации в поле METHODS. Серевер выбирает один из предложенных методов, перечисленных в METHODS, и послылает ответ о выбранном методе: +----+--------+ |VER | METHOD | +----+--------+ | 1 | 1 | +----+--------+ Если выбранный метод в METHOD равен X'FF', то ни один из предложенных клиентом методов не применим и клиент должен закрыть соединение. Эти значения определены для поля METHOD: o X'00' аутентификация не требуется o X'01' GSSAPI o X'02' USERNAME/PASSWORD (см. RFC1929) o X'03' до X'7F' зарезервировано IANA o X'80' до X'FE' преднозначено для частных методов o X'FF' нет применимых методов Затем клиент и сервер начинают аутентификацию согласно выбранному методу. Leech, et al Standards Track [Страница 3] RFC 1928 Протокол SOCKS 5 Март 1996 Описание методов аутентификации находится в отдельных документах. Разработчики новых методов аутентификации применимых для этого протокола должны обращаться в IANA для получения номера метода. Документ с выделеными номерами должен дополнить текущий список номеров и соответствущих им методов аутентификации. Совместимые реализации должны поддерживать GSSAPI и могут поддерживать аутентификацию USERNAME/PASSWORD. 4. Запросы После того как аутентификация выполнена, клиент посылает детали запроса. Если выбранный метод аутентификации требует особое формирование пакетов с целью проверки целостности и/или конфедициальности, запросы должны инкапсулироваться в пакет, формат которого определяется выбранным методом. SOCKS-запрос формируется следующим образом: +----+-----+-------+------+----------+----------+ |VER | CMD | RSV | ATYP | DST.ADDR | DST.PORT | +----+-----+-------+------+----------+----------+ | 1 | 1 | X'00' | 1 | Variable | 2 | +----+-----+-------+------+----------+----------+ Где: o VER версия протокола: X'05' o CMD o CONNECT X'01' o BIND X'02' o UDP ASSOCIATE X'03' o RSV зарезервировано o ATYP тип адреса, следующего вида: o IP v4 адрес: X'01' o имя домена: X'03' o IP v6 адрес: X'04' o DST.ADDR требуемый адрес o DST.PORT требуемый порт (в сетевом порядке октетов) SOCKS-сервер обрабатывает запрос на основании исходного и целевого адресов и посылает одно или несколько сообщений в ответ, в соответствии с типом запроса. Leech, et al Standards Track [Страница 4] RFC 1928 Протокол SOCKS 5 Март 1996 5. Адресация Тип адреса содержащегося в адресном поле (DST.ADDR, BND.ADDR), определяется содержимым поля ATYP: o X'01' адрес является адресом IP v4, длинна адреса 4 октета o X'03' поле адреса содержит имя домена. Первый октет адресного поля содержит число октетов в последующем за ним имени, завершающий NUL-октет в конце строки не применяется. o X'04' адрес является адресом IP v6, длинна адреса 16 октет 6. Ответы SOCKS-запрос посылается клиентом как только он установил соединение с SOCKS-сервером и выполнил аутентификацию. Сервер обрабатывает запрос и посылает ответ в следующей форме: +----+-----+-------+------+----------+----------+ |VER | REP | RSV | ATYP | BND.ADDR | BND.PORT | +----+-----+-------+------+----------+----------+ | 1 | 1 | X'00' | 1 | Variable | 2 | +----+-----+-------+------+----------+----------+ Где: o VER версия протокола: X'05' o REP код ответа: o X'00' успешный o X'01' ошибка SOCKS-сервера o X'02' соединение запрещено набором правил o X'03' сеть недоступна o X'04' хост недоступен o X'05' отказ в соединении o X'06' истечение TTL o X'07' команда не поддерживается o X'08' тип адреса не поддерживается o X'09' до X'FF' не определены o RSV зарезервирован o ATYP тип последующего адреса Leech, et al Standards Track [Страница 5] RFC 1928 Протокол SOCKS 5 Март 1996 o IP v4 адрес: X'01' o имя домена: X'03' o IP v6 адрес: X'04' o BND.ADDR выданный сервером адрес o BND.PORT выданный сервером порт (в сетевом порядке октетов) Значения зарезервированных (RSV) полей должны быть установлены в X'00'. Если выбранный метод аутентификации требует особое формирование пакетов с целью проверки целостности и/или конфедициальности, запросы должны инкапсулироваться в пакет, формат которого определяется выбранным методом. CONNECT В ответ на CONNECT, BND.PORT содержит номер порта, который сервер назначает для соединения с указанным хостом, а BND.ADDR содержит связанный IP-адрес. Выданный BND.ADDR зачастую отличается от IP-адреса, который клиент использует для доступа к SOCKS-северу,
так как такие сервера часто имеют несколько IP-адресов. Ожидается, что сервер будет использовать DST.ADDR и DST.PORT и адрес клиента при обработке запроса CONNECT. BIND Запрос BIND используется в протоколах, которые требуют чтобы клиент принимал соединение со стороны сервера. Хорошим примером этого является FTP, который использует основное соединение клиент-к-серверу для комманд и сообщений, но может использовать соединение сервер-к-клиенту для передачи данных по запросу (например LS, GET, PUT). Ожидается, что клиентская сторона прикладного протокола будет использовать запрос BIND только для установки вторичного соединения, после первичного соединения, установленного с использованием CONNECT. Ожидается, что сервер будет использовать DST.ADDR и DST.PORT при обработке запроса BIND. SOCKS-сервер посылает два ответа клиенту в течении операции BIND. Первый послыается после того, как сервер создает и привязывает новый сокет. Поле BND.PORT содержит номер порта, который SOCKS-сервер выделил для входящего соединения. Поле BND.ADDR содержит связанный IP-адрес. Клиент может использовать эту информацию для уведомления (через первичное соединение) приложения-сервера об адресе для взаимодействия. Второе уведомление происходит после ожидаемого входящего соединения или неудачной попытке входящего соединения. Leech, et al Standards Track [Страница 6] RFC 1928 Протокол SOCKS 5 Март 1996 При втором ответе поля BND.PORT и BND.ADDR содержат адрес и номер порта присоединившегося хоста. UDP ASSOCIATE Запрос UDP ASSOCIATE используется для установления соединения посылающим UDP-сообщения процессом. Поля DST.ADDR и DST.PORT содержат адрес и порт, на который клиент собирается слать UDP-датаграммы после установки соединения. Сервер может использовать эту информацию в целях ограничения доступа. Если клиент не располагает информацией об адресе на момент запроса UDP ASSOCIATE, то клиент должен заполнить нулями номер порта и адреса. UDP-связь обрывается, когда обрывается TCP-соединение выполнившее запрос UDP ASSOCIATE. В ответе на запрос UDP ASSOCIATE, поля BND.PORT и BND.ADDR определяют порт и адрес, куда клиент должен слать UDP-датаграмы для пересылки. Обработка ответов Когда приходит ответ с сообщением о неудаче (значение REP не равно X'00'), то SOCKS сервер должен оборвать TCP-соединение вскоре после посылки ответа. Это должно произойти не более чем спустя 10 секунд после определения причин вызвавших неудачу. При получении ответа с сообщением об удаче (значение REP равно X'00'), если запросом был BIND или CONNECT, то клиент может начинать передавать данные. Если выбранная схема аутентификации требует особое формирование пакетов с целью проверки целостности и/или конфедициальности, данные должны инкапсулироваться в пакет, формат которого определяется выбранным методом. Подобно этому, когда данные для клиента получаются SOCKS-сервером, сервер должен инкапсулировать данные согласно тому, как это требует выбранный метод аутентификации. 7. Процедура для клиентов работающих по UDP Клиент, работающий по UDP, должен посылать свои датаграмы на порт пересылающего их UDP-сервера, указанного в поле BND.PORT в ответе на запрос UDP ASSOCIATE. Если выбранная схема аутентификации требует особое формирование пакетов с целью проверки целостности и/или конфедициальности, датаграмма должна инкапсулироваться в пакет, формат которого определяется выбранной схемой. Каждая UDP-датаграма содержит в себе заголовок UDP-запроса: Leech, et al Standards Track [Страница 7] RFC 1928 Протокол SOCKS 5 Март 1996 +----+------+------+----------+----------+----------+ |RSV | FRAG | ATYP | DST.ADDR | DST.PORT | DATA | +----+------+------+----------+----------+----------+ | 2 | 1 | 1 | Variable | 2 | Variable | +----+------+------+----------+----------+----------+
Поля заголовка UDP-запроса: o RSV зарезервировано X'0000' o FRAG текущий номер фрагмента o ATYP тип адреса: o IP v4 адрес: X'01' o имя домена: X'03' o IP v6 адрес: X'04' o DST.ADDR требуемый целевой адрес o DST.PORT требуемый целевой порт o DATA пользовательские данные Когда пересылающий UDP-датаграммы сервер пересылает датаграмму, он делает это молча, без какого-либо уведомления выполнившего запрос клиента. Аналогично, сервер будет молча отбрасывать датаграммы, которые он не может или не будет пересылать. Когда пересылающий UDP-датаграммы сервер получает ответную датаграмму с удаленного хоста, он должен инкапсулировать эту датаграмму используя помимо заголовка UDP-запроса еще и инкапсуляцию, определяемую выбранной схемой аутентификации. Обращение к пересылающему UDP-датаграммы серверу должно производиться с ожидаемого SOCKS-сервером IP-адреса клиента, который (клиент) будет посылать датаграммы на BND.PORT, данный в ответе на UDP ASSOCIATE. Сервер должен отбрасывать датаграммы полученные с любого IP-адреса, отличного от того, что был записан для этой связи. Поле FRAG показывает, является ли эта датаграмма самостоятельной или же фрагментом. Если датаграмма - фрагмент, то установленный старший бит является признаком последнего фрагмента, в то время как значение X'00' показывает, что это обычная датаграмма. Значения от 1 до 127 обозначают на позицию фрагменте в последовательности. Каждый получатель будет иметь REASSEMBLY QUEUE (очередь сборки) и REASSEMBLY TIMER (таймер сборки) связанные с такой фрагментной датаграммой. Очередь сборки должна быть переинициализирована и связанные с ней фрагменты выкинуты всякий раз при истечении таймера сборки или с приходом новой датаграммы, чье значение в поле FRAG меньше, чем наибольшее значение поля FRAG датаграмм, обработанных при сборке фрагмента. Таймер сборки должен быть не менее 5 секунд. Приложениям рекомендуется избегать фрагментацию везде, где только это возможно. Реализация фрагментации опциональна, в реализациях где фрагментация не поддерживается, должны отбрасываться любые датаграммы, у которых поле FRAG отлично от X'00'. Leech, et al Standards Track [Страница 8] RFC 1928 Протокол SOCKS 5 Март 1996 Программный интерфейс для UDP работающего через SOCKS должен сообщать о оставшемся свободном пространстве в буфере для UDP-датаграмы, которое меньше, чем действительный размер буфера, выделенный операционной системой: o если ATYP равен X'01' - на 10+зависит_от_метода октетов меньше o если ATYP равен X'03' - на 262+зависит_от_метода октетов меньше o если ATYP равен X'04' - на 20+зависит_от_метода октетов меньше Иными словами, так как в заголовке UDP-запроса, включенного в датаграмму, нет информации о длинне данных, то приложение должно помнить об этом самостоятельно. 8. Замечания по безопасности Этот документ описывает протокол для работы на прикладном уровне с файрволлами в IP-сетях. Безопасность такой работы в большой степени зависит от особенностей аутентификации и инкапсуляции методов, обеспеченных в конкретной реализации и выбранных во время соединения клиента с SOCKS-cервером. При выборе метода аутентификации администраторы должны проявить особое внимание. Careful consideration should be given by the administrator to the selection of authentication methods. 9. Ссылки [1] Koblas, D., "SOCKS", Proceedings: 1992 Usenix Security Symposium. Адрес автора Marcus Leech Bell-Northern Research Ltd P.O. Box 3511, Stn. C, Ottawa, ON CANADA K1Y 4H7 Phone: (613) 763-9145 EMail: [email protected] Leech, et al Standards Track [Страница 9] ------------------------------------------------------------------------ Не стреляйте в переводчика, он переводит как умеет (с) неизвестен Перевод сделан Александром Горлачем, [email protected] ------------------------------------------------------------------------
