| Аннотация |
В этом документе способ использования PPP поверх telnet, целью которого является работа с сетью в обход firewall. |
ПОЖАЛУЙСТА, ВНИМАТЕЛЬНО ПРОЧТИТЕ ЭТУ ОЧЕНЬ ВАЖНУЮ ИНФОРМАЦИЮ !!!
Я снимаю всякую ответственность с себя за содержание этого документа. Если его использование обернется против вас самих - это ваши проблемы. А не моя вина. Если вы не осознаете риск сопряженный с выполнением этих инструкций, не делайте этого. Если вы это сделаете и после этого кто-то проникнет в сеть вашей компании и вы потеряете работу, а компания миллионы долларов, не приходите ко мне со слезами.
Copyright ╘ 1998 by Francois-Rene Rideau.
This document is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
Авторские права на русский перевод этого текста принадлежат ╘ 2000 ASPLinux Все права зарезервированы.
Этот документ является частью проекта Linux HOWTO.
Авторские права на документы Linux HOWTO принадлежат их авторам, если явно не указано иное. Документы Linux HOWTO, а также их переводы, могут быть воспроизведены и распространены полностью или частично на любом носителе, физическом или электронном, при условии сохранения этой заметки об авторских правах на всех копиях. Коммерческое распространение разрешается и поощряется; но, так или иначе, автор текста и автор перевода желали бы знать о таких дистрибутивах.
Все переводы и производные работы, выполненные по документам Linux HOWTO должны сопровождаться этой заметкой об авторских правах. Это делается в целях предотвращения случаев наложения дополнительных ограничений на распространение документов HOWTO. Исключения могут составить случаи получения специального разрешения у координатора Linux HOWTO, с которым можно связаться по адресу приведенному ниже.
Мы бы хотели распространить эту информацию по всем возможным каналам. Но при этом сохранить авторские права и быть уведомленными о всех планах распространения HOWTO. Если у вас возникли вопросы, пожалуйста, обратитесь к координатору проекта Linux HOWTO по электронной почте: <linux-howto@metalab.unc.edu> или к координатору русского перевода Linux HOWTO компании ASPLinux по адресу <linux-howto@asplinux.ru>
Даже несмотря на то, что я в этом документе переписал заново практически все, кроме главы "Ответственность", я все-таки очень обязан Barak Pearlmutter bap@cs.unm.edu за его Мини-HOWTO "Term-Firewall": я думаю, что была необходимость написать мини-HOWTO об обходе firewall, а его документ стал для этого причиной и основой.
Не является секретом тот факт, что системные администраторы и пользователи смотрят на вопросы безопасности и применения ограничений немного по-разному. Достаточно часто по этой причине пользователь оказывается за firewall, который он может и обойти, испытывая при этом некоторые неудобства. В этом мини-HOWTO приводится описание простого способа использования стандартных утилит работы с интернетом, в обход firewall, при помощи IP-эмулятора, запущенного поверх telnet.
Идея создания данного документа была навеяна Мини-HOWTO "Term+Firewall", автора Barak Pearlmutter bap@cs.unm.edu, описавшего старую, и более нигде не применяемую программу, Term (кстати, великолепную для своих времен вещь). Также эта идея была подкреплена наличием некоторых особенностей не совсем стандартных telnet-ов.
Конечно, если ваш системный администратор установил firewall, то у него (нее) были на это причины - и вы могли подписать с ним контракт, запрещающий вам обходить этот firewall. С другой стороны, если вам разрешен telnet наружу (это главное условие для описанного здесь обхода firewall), значит вам разрешен доступ к внешним компьютерам - а если у вас есть доступ к внешним компьютерам, то вы можете выполнить то, что описано ниже.
Поэтому использование существующих прорех в firewall - это всего лишь вопрос удобства использования стандартных утилит и протоколов - это не использование специальных или модифицированных (и перекомпилированных) программ, использующих несколько специализированных прокси, неправильно или плохо настроенных, некомпетентным или невнимательным системным администратором; это не установка большого количества специализированных преобразователей, позволяющих работать вам с интернетом через пути, разрешенные на firewall (например, через HTTP).
Более того, использование пользовательского IP-эмулятора (такого, как SLiRP) должно оградить firewall от внешних атак, если конечно вы сами этого не разрешите (или они очень умны и хитры, и root на внешней машине следит за вами).
Вообще, описанный здесь обход firewall относительно безопасен. Однако, многое зависит от конкретных обстоятельств, и я не даю никаких гарантий. Многие вещи в Интернете сами по себе небезопасны, с этим обходом или без него - подходите ко всему с должной мерой осторожности, если у вас нет причин чувствовать себя безопасно. Если необходимо - используйте шифрование, дополнительную авторизацию и т.п..
Если подытожить - не используйте эту информацию, если не знаете, что делаете. Еще раз прочитайте главу "Ответственность".
Вы знаете, что делаете; Вы знаете, как установить сетевое соединение; У вас есть имя и пароль входа в две системы на обеих сторонах от firewall; Вы можете устанавливать telnet-соединение с одной системы на другую (или ssh-, или нечто подобное) ; Вы можете запустить IP-эмулятор в оболочках в обеих системах; У вас есть программы, умеющие использовать эмуляцию IP на обеих сторонах; Заметьте, что эмуляцию может использовать любая программа, так как локальный эмулятор - это pppd, взаимодействующий с ядром Linux; другие эмуляторы (например Term) требуют рекомпиляции и подключения соответствующих библиотек.
pppd можно найти на любом уважающем себя ftp-сайте; там же обычно можно найти и SLiRP. Если на удаленной машине у вас нет прав системного администратора, то вы можете использовать SLiRP.
Многие из описанных здесь программ обычно входят в комплект вашего дистрибутива, правда, возможно, не полностью или с некоторыми ограничениями; во всяком случае, все пакеты, кроме двух последних, существуют в формате rpm. Если вы хотите получить последнюю версию исходных текстов или уже готовых программ (ведь может на одном из концов соединения быть не-Linux), посетите следующие страницы:
SLiRP можно найти по адресу http://blitzen.canberra.edu.au/slirp и/или ftp://www.ibc.wustl.edu/pub/slirp_bin/..
zsh можно найти по адресу http://www.peak.org/zsh/.
ppp можно найти по адресу ftp://cs.anu.edu.au/pub/software/ppp/.
fwprc и cotty можно найти по адресу http://www.tunes.org/~fare/files/fwprc/
Четкое понимание сути проблемы - большая половина ее решения.
Если вы хотите, чтобы этот обходной путь работал для вас, вам придется понять, КАК он работает, чтобы, если что-то сломается, вы знали где искать неисправность.
Первый шаг на пути к пониманию проблемы - присвоить всему соответствующие названия.
Итак "локальная" - это машина, которая устанавливает соединение, файлы на ней тоже называются "локальными"; и наоборот - "удаленная" - это машина с другой стороны соединения.
Наша цель - соединить между собой ввод и вывод локального IP-эмулятора, соответственно, с выводом и вводом удаленного IP-эмулятора
Каналами связи между двумя эмуляторами могут быть либо устройства (обычно pppd), либо "текущий терминал (tty)". Первый вариант, практически, невозможен в telnet-соединениях. Второй должен быть достаточно хитрым, потому что, когда вы запускаете локальный эмулятор из командной строки, он подключен к текущему tty пользователя, а не к telnet-сессии; если мы захотим открыть новую сессию (локальную или удаленную) на новом терминале, нам придется синхронизировать запуск и соединение IP-эмуляторов, иначе мусор одного из эмуляторов будет восприниматься как команды на другой стороне - это приведет еще к большему мусору и т.п..
Чтобы все было хорошо, локальный эмулятор должен позволять создавать IP-соединения на уровне ядра, то есть, быть pppd. Однако pppd достаточно глуп - он позволяет создавать соединения только через /dev-устройства или через текущий tty; это должно быть tty, а не парой потоков (pipe) (как все было бы просто!). Он подходит для удаленной стороны - он может использовать tty telnet-сессии; но вот для локальной машины он никак не подходит - он не может запустить telnet-соединения; должен существовать какой-то обходной путь.
Telnet работает почти правильно с парой потоков, хотя он все-таки настаивает на выполнении ioctl с tty, с которым он взаимодействует; использование telnet без tty тоже не совсем правильно, потому что на медленных компьютерах соединение будет прерываться (fwprc 0.1 работал правильно на P/MMX 233, один из 6 раз на 6x86-P200+, и вообще не работал на 486dx2/66).
[Примечание: Если я найду того негодяя (возможно он из фанатов MULTICS, да и в UNIX должны были найтись пара недоумков, скопировавших глупую идею), который изобрел принцип "tty"-устройств - запись и чтение производятся с одним "псевдо"-файлом, вместо того, чтобы иметь одну чистую пару потоков - Я его задушу!]
Программа обхода firewall fwprc будет использовать "tty-прокси", cotty, который открывает два псевдо-tty устройства, выполняет команды на каждом из устройств, а затем глупо копирует символы в обоих направлениях. Одной командой будет telnet на удаленную машину, а другой - локальный pppd, который после этого может открыть и контролировать telnet-соединение, при помощи стандартного chat-скрипта.
Я написал очень хорошо документированный скрипт для обхода firewall - fwprc, который есть на моем сайте http://www.tunes.org/~fare/files/fwprc/, там же можно взять и cotty(необходимый для fwprc версии 0.2 и новее). На момент написания этого документа самые новые версии программ - это fwprc 0.3a и cotty 0.3a.
Название "fwprc" специально сделано нечитаемым и непроизносимым, чтобы путать некомпетентных параноиков-сисадминов, которые сами по себе могут быть причиной существования мучающего вас firewall (конечно, могут существовать и нормальные firewall, и даже очень необходимые; безопасность - это определяющий фактор правильной конфигурации). Но если вы прочтете это название при администраторе вслух - ожидайте наихудшего из всех возможных последствий .
КОНКУРС! КОНКУРС! Пошлите мне аудио-файл .au с записью того, как вы произносите название "fwprc". Выиграет самый непонятный вариант, и имя его создателя попадет на страницу fwprc версии 1.0!
Я проверил работу этой программы в нескольких вариантах, настраивая ее через файлы конфигурации. Но, конечно, у вас она не заработает согласно закона Мерфи. Пожалуйста, посылайте мне свои предложения и дополнения, чтобы облегчить жизнь тем, кто встанет на этот нелегкий путь после вас.
Работу fwprc можно настроить при помощи файла настройки .fwprcrc, который должен быть на обеих сторонах firewall. Существует возможность использовать несколько различных конфигураций (например, Я делаю так), и несколько из них оставлены в качестве примера для читателя.
Для начала скопируйте соответствующую (предпоследнюю) секцию файла fwprc в файл .fwprcrc в вашем домашнем каталоге. Затем замените в нем значения переменных, чтобы они соответствовали вашим машинам. Затем скопируйте этот файл на удаленную машину, и все проверьте.
По умолчанию локально используется pppd, а удаленно - slirp. Чтобы это изменить, вы можете подправить соответствующую функцию в файле .fwprcrc примерно так:
remote_IP_emu () { remote_pppd } |
Заметьте, что SLiRP безопаснее pppd, к нему проще получить доступ - он не требует администраторских прав на удаленной машине. Другой его плюс - он игнорирует все пакеты, которые идут не прямо с соединенной с ним машины (этот плюс становится минусом, если вы хотите таким образом работать с целой подсетью при помощи маскарадинга). Обычно стандартных функций SLiRP достаточно, но все-таки некоторые минусы у него обнаружились (например, управляемость при работе); конечно, это бесплатная программа - исправляйте исходные тексты: вносите в них все, что вам необходимо.
Часто возникают такие ситуации, при которых telnet-соединение может быть установлено только с одной стороны firewall; однако, некоторые способы связи с другой стороны все-таки существуют (например e-mail). В этом случае, обход firewall возможен - это делается при помощи некоторого сообщения на "правильную" сторону firewall с указанием установить telnet-соединение.
fwprc включает в себя код, позволяющий это сделать. Для этого, с удаленной стороны, должно придти письмо с PGP-аутентификацией; все, что вам надо - запустить fwprc в качестве фильтра procmail(1), (подробные инструкции есть внутри самого fwprc). Однако заметьте, что вам придется запускать pppd с соответствующими правами - возможно, придется писать свой su для того, чтобы стать root-ом. Инструкции приведены в fwprc.
Более того, аутентифицированный триггер - это еще не безопасное соединение. В этом случае я бы посоветовал вам использовать ssh (возможно поверх telnet) для того, чтобы обезопасить себя. И еще, опасайтесь того, что может произойти между приходом письма-триггера и установкой соединения при помощи ssh. Я приветствую любые советы по поводу этого.
Если ваша машина находится за firewall, то ваша почта может находиться на центральном сервере, который, естественно, не делает фильтрование при помощи procmail(1) и не позволяет установить telnet-соединение. Нет проблем! Вы можете в этом случае использовать fetchmail(1), запустив его в режиме демона - он будет посылать и принимать почту в вашем Linux, (и/или вы можете использовать cron для связи с сервером через равные промежутки времени). fetchmail(1) будет посылать локальную почту через sendmail(8), а он в свою очередь должен быть настроен на использование для локальной доставки procmail(1). Заметьте, что если вы запустите fetchmail(1) в режиме демона, вы не сможете параллельно запускать еще одну копию fetchmail(1) для приема почты в определенное время - это аналогично запуску fwprc; конечно, вы можете запускать демон fetchmail(1) от некоего псевдо-пользователя. Частый запуск процедуры получения почты не даст ничего хорошего ни вашей машине, ни серверу. Слишком редкий запуск приведет к большой задержке писем в пути (а значит и задержке установки обратного соединения). Я запускаю свой fetchmail(1) каждые две минуты.
На самом деле существуют разные firewall, а не только те, которые позволяют вам устанавливать telnet-соединения. Но, в любом случае, пока может существовать поток пакетов, идущий через firewall, будет и способ его обойти. Вопрос лишь в сложности написания программы обхода.
Достаточно простой случай - когда вы можете запустить ssh на локальной машине и pppd на удаленной. Чисто теоретически, cotty версии 0.3a должен это поддерживать, но в fwprc поддержки ssh нет. Возможно, вы реализуете эту поддержку самостоятельно. Вы даже можете сделать это без firewall - таким образом вы получите защищенную Виртуальную Частную сеть "VPN" (Virtual Private Network). Подробнее читайте мини-HOWTO "VPN".
Если вы должны работать с 7-битной линией - используйте SLIP, вместо PPP. Я никогда не тестировал подобный вариант - в этом просто нет необходимости, почти все линии в наше время более-менее поддерживают 8 бит; но больших трудностей быть не должно.
Если единственный путь через firewall - это WWW-прокси (обычно - это самый минимум в сети, подключенной к Интернету), то еще не все потеряно. Вы можете написать демона, который буферирует входящие и исходящие данные, и посылает их по HTTP-соединениям, достигая тем самым некоторого подобия протокола telnet-поверх-HTTP, над которым можно запустить fwprc. Возможно, это будет не очень быстро и гибко, но для fetchmail(1), suck(1) и им подобным неинтерактивным программам этого хватит.
Если вам надо нечто более производительное, но не фильтруется нечто очень дикое (запросы DNS, ICMP-пакеты, и т.п.), то у вас дела достаточно плохи. Вам придется править в ядре работу с IP, используя (например) систему работы с пакетами из проекта Fox. Вы сможете получить IP-по-HTTP, IP-по-DNS, IP-по-ICMP, или нечто подобное - это все требует не только достаточно сложного протокола обмена, но и работы с ядром OS - это достаточно сложно.
Кстати, если вы будете обходить Firewall при помощи псевдо-HTTP демона, не забудьте вложить в него пару-тройку веб-страниц, чтобы сбить с толку противных подозрительных администраторов firewall.
Я ощущал необходимость написать этот документ, но у меня не было достаточно времени, поэтому этот мини-HOWTO получился достаточно сыроват. Он таким и останется до тех пор, пока я не получу достаточно отзывов и предложений, и из них пойму, что и где дописать. Я буду очень рад отзывам и помощи. С радостью отдам в хорошие руки поддержку этого мини-HOWTO.
В любом случае, данный документ осветил некоторые проблемы, решением которых может заняться человек, которому не жалко времени (или денег?), чтобы их разрешить: в идеях нет ничего сложного, но вот детали могут достаточно сложны.
Не стесняйтесь присылать мне свои вопросы, и, я надеюсь, решения проблем, связанных с этим документом.
" Я снимаю всякую ответственность с себя за содержание этого документа. Если его использование обернется против вас самих - это ваши проблемы. А не моя вина. Если вы не осознаете риск сопряженный с выполнением этих инструкций, не делайте этого. Если все же сделаете, а после этого кто-то проникнет в сеть вашей компании, вы потеряете работу, компания - миллионы долларов, то не приходите ко мне со слезами."