Здравствуй, мой маленький любитель халявы!
Сегодня мы поговорим с тобой о воровстве
траффика. Мы обсудим один из наиболее
интересных (и, вместе с тем, муторных)
способов относительно честного отъема
траффика у провайдера, о туннелировании
через бесплатно доступные сервисы. Эта
статья будет особенно интересна
пользователям подключенным к Интернету
домовыми и корпоративными сетями, хотя,
возможо, диалап-пользователи тоже смогут
почерпнуть в ней что-то для себя
небесполезное.
Под термином "туннелирование" в данном
контексте я имею ввиду пакетную
инкапсуляцию IPv4-траффика внутрь протоколов
бесплатно доступных пользователю сервисов.
Иными словами, "упаковку" нелегального
IPv4-траффика на клиентской стороне, внутри
провайдерской инфраструктуры и "распаковку"
этого траффика обратно, на серверной
стороне, вне пределов провайдерской сети.
Приведенная принципиальная
схема наглядно иллюстрирует этот подход.
Технология весьма проста и очевидна:
1) Клиентская прокси-программа на
локалхосте злобного хакера выполняет
функции сетевого стека для
пользовательских программ. Она "схватывает"
и проксюет IPv4-траффик нужных программ, "запаковывая"
исходящий траффик и "распаковывая"
входящий (мы использовали совокупность
программ SocksCap и специально написанного для
этих целей socks-сервера).
2) Серверная прокси-программа на стороне-приёмнике
выполняет обратные описанным в [1] функции.
3) Траффик между [1] и [2] идёт по дозволенному,
вполне легальному с точки зрения политики
провайдера, туннелю. При необходимости,
связь между [1] и [2] можно прикрывать SOCKS- и HTTP-проксями,
чтобы админы насилуемого провайдера (в
случае обнаружения воровства траффика) не
смогли отыскать местонахождение серверной
прокси-программы.
По большому счёту, в этом подходе нет ничего
нового и оригинального. Туннелирование и
инкапсуляция используются весьма активно и
повсеместно: порой, это единственный способ
обойти естественные и объективные
топологические ограничения. Но, тем не
менее, я ни разу ещё не встречал людей,
использующих туннелирование с целью
воровства траффика (хотя я неоднократно
слышал об успехах таких деятелей =))
ЧЕМ?
Что касается технических вопросов
реализации туннелинга, то инкапсулировать
можно практически что угодно и практически
куда угодно =)) Что-то туннелировать проще,
что-то - сложнее. Например, mirc-туннелинг мне
удался куда проще, чем DNS-туннелинг,
несмотря на то, что у меня была программа LOKI
из журнала phrack (issue 51, volume 7), которая
выполняет схожие функции. И я уверен, что
технические трудности реализации не
отпугнут тебя, друг мой, а, наоборот,
заинтересуют!
И КУДА?
Есть ещё одна объективная трудность,
которая отпугнёт многих дельфистов:
необходимость иметь некий внешний ресурс,
который можно было бы нагрузить серверной
частью... Я вижу лишь два варианта: 1) взлом и
захват каких-нибудь бесхозных удалённых
машин (число коих -- легион =))) или 2)
приобретение в Буржандии легального
хостинга, цена которого вряд ли где-нибудь
превышает полутора-двух баксов за гигабайт.
БЕСПЛАТНЫЕ СЕРВИСЫ
Многие (если не все) домовые сети, о которых,
в основном, идёт речь, обладают некоторым
числом бесплатно доступных сервисов. Под
"бесплатно доступными сервисами"
можно понимать те сервисы, оплата за
использование которых либо не взимается
вовсе, либо она уже включена в оплату за
пользование локальной сетью. Это может быть
что угодно: игровые сервисы с выходом в мир,
ICMP-траффик (пинги), DNS-траффик, irc-сервер...
В сети, где проводили испытания мы, к этим
сервисам относятся email, DNS-резолвинг
произвольных имён и mirc-сервер с выходом в
мир. Именно про грамотное использование
этих сервисов я и расскажу сегодня. Я дам
тебе необходимое количество практических
советов по максимально эффективному обходу
подводных камней в этой области хакерской (хотя,
скорее хэкерской) деятельности =)))
ЭЛЕКТРОННАЯ ПОЧТА
Использование email'а для туннелирования
траффика в реальном времени (например, для
сёрфинга по сайтам) - идейка весьма-таки
премерзкая. Можешь представить себе,
сколько времени займет даже самая
маленькая транзакция по email'у туда-обратно,
особенно если для получения писем по POP
необходима SMTP-авторизация. Поэтому,
единственный, на мой взгляд, адекватный
способ применения email-туннелинга -- это
отложенный заказ файлов по ftp и http.
Насколько я знаю, ещё несколько лет назад
такие бесплатные и публичные сервисы
существовали и были повсеместно
распространены: нужно было лишь отправить
на некий email список нужных URL'ов и ждать, пока
эти файлы не придут на твой адрес. В
некоторых случаях (когда локальная сеть
имела лишь email-доступ в Интернет), это была
единственная возможность получать файлы =)))
Теперь таких сервисов уже не осталось. Стал
быть, нужно организовывать собственный.
Итак, серверная часть должна уметь:
1) скачивать файлы и фрагменты файлов по http и
ftp;
2) делить большие файлы на куски, желаемые
юзером;
3) упаковывать файлы в ту кодировку, которую
"скушает" насилуемый mail-сервак.
Если не заниматься хэкерством, т.е. если не
писать весь сервер с нуля на бейсике или на
ассемблере, то реализовать такую программу
можно связкой bash+sendmail+netcat+wget+whatever+you+want. Как
ты видишь, это - самый простой в реализации и
использовании способ скачивания файлов
нахаляву. Но, вместе с тем, самый легко
обнаруживаемый.
Кроме того, с этим методом весьма просто
бороться. Админу достаточно лишь ввести
квоту на количество мегабайт почты в сутки
для каждого рядового пользователя.
IRC-ТУННЕЛИНГ
Этот способ намного изящнее и гибче
предыдущего: здесь уже вполне реально
туннелирование траффика в реальном времени.
Даже при связи серверного баунсера с irc-серваком
через один SOCKS-прокси, мы имели средний "пинг"
около 400 миллисекунд. Этот способ (особенно
при довольно крепкой загрузке irc-сервака)
труднее обнаружить. Кроме того, стандартный
админ вряд ли сможет с пол-пинка придумать
адекватную защиту от irс-туннелинга, разве
что беспощадно учинив своему irc-серваку
жестокий шейпинг и квотирование (вызвав,
тем самым, волны недовольства среди честных
и мирных пользователей =))).
Итак, хакерский клиентский компонент, в
данном случае, оснащён irc-клиентом, а
серверная часть обладает irc-bouncer'ом с одним
или несколькими аккаунтами к насилуемому
irc-серваку. Баунсер может выходить на связь
с irc-сервером через один или несколько
проксей.
Плюсы этого способа очевидны, и если
серверные nick'и не выводить в какие-либо irc-каналы,
можно оставаться незамеченным сколь угодно
долго. А вот минусы этого способа следует
обсудить отдельно:
1) На том серваке, где проводили
тестирования мы, при превышении скорости в 2
kb/sec, мы стабильно получали Excess Flood на
принимающей стороне. Стало быть, нужно либо
придерживаться этого ограничения, либо
вводить несколько "ников"-принимателей
и работать с ними параллельно.
2) Следует избегать устойчивых сигнатур
протокола инкапсуляции воровского
траффика. Это относится к любому из
возможных вариантов пакетного
туннелирования: любая IDS-система (даже
доморощенная вроде snort-based) может быть
настроена отлавливать либо устойчивые
последовательности байт, либо устойчивые
размеры дейтаграмм, либо и то, и другое
одновременно.
Вообще говоря, протокол инкапсуляции
следует проектировать с особой
тщательностью, не перегружая его
избыточной информацией, необходимость в
которой сомнительна. Иными словами, тебе не
следует переписывать TCPv4 под собственные
нужды. Достаточно лишь реализовать
некоторые его основные функции:
1) Если речь идёт о irc-туннелинге (либо о
туннелировании через любой другой tcp-based-сервис),
то достаточно обойтись лишь нумерацией
очередной пачки данных.
2) Если ты занимаешься протоколом пакетной
инкапсуляции (поверх, например, udp или icmp),
тебе необходимо добавить обеспечение
целостности потоков передаваемых данных
дополнительной контрольной суммой.
Протокол неплохо бы оснастить возможностью
договора между клиентом и сервером о
желаемой скорости и насыщенности траффика
друг между другом.
3) Динамическое сжатие и шифрование данных
вполне могут иметь своё законное место в
протоколе инкапсуляции. Ты можешь
использовать открытые и весьма удобные
библиотеки libbzip2 и rsaeuro, для сжатия и
шифрования потоков данных, соответственно.
Кстати, я вскоре опубликую на этом сайте
небольшие хавту по программированию с
использованием этих библиотек.
Итак, mirc-туннелинг -- штука интересная и
романтичная.
DNS-ТУННЕЛИНГ
Это - самый сложный и грубый из освоенных
нами способов =)) Итак, если ты имеешь
возможность контролировать какой-нибудь name
server в Большом Интернете (в идеале - dns-сервер,
стоящий непосредственно выше dns-серверов
насилуемого тобой провайдера), то этот
способ - для тебя.
Смысл его состоит в том, что хакерский
клиентский компонент "упаковывает"
воровской IPv4-траффик в dns-запросы на
разрешение адреса по имени (или в какие-либо
другие запросы) и отправляет их dns-серверу
провайдера. Провайдерский сервак, не найдя
ответы на эти вопросы, форвардит их дальше,
вышестоящему dns-серверу. Таким образом, эти
запросы достигают серверного компонента (владельца
запрашиваемого домена). Серверная часть
отправляет осмысленные ответы (смысл
которых понятен лишь злобному хакеру =)),
которые, в конечном счёте, достигают
клиентского компонента.
Плюсы этого метода очевидны: приоритет у dns-запросов
настолько высок, что ты сможешь загрузить
весь канал провайдера по максимуму. Кроме
того, спуфинг UDP-траффика - дело крайне
простое и необременительное, и ты сможешь
легко и не напрягаясь подставлять любую
пару MAC/IP из твоего сегмента, отправляя с них
запросы и случая приходящие к ним ответы
сниффером.
К минусам можно, безусловно, отнести
трудности реализации этого метода, а также
весьма неприятные ограничения, связанные с
протоколом DNS/UDP: я не рекомендовал бы тебе
формировать запросы более чем из 8 слов
размером более чем по 25 символов каждый.
Необходимо соблюдать уникальность каждого
следующего запроса, так как велика
вероятность того, что dns-сервера будут
довольно-таки многомегабайтно кэшировать
твои запросы. Кроме того, есть вероятность
того, что один из насилуемых dns-серверов (провайдерский
или любой передающий) могут банально упасть,
если его кэш-база не сквотирована на
фиксированный размер.
Среди способов возможной борьбы с dns-туннелингом
можно выделить подушное квотирование dns-траффика.
Админ того провайдера, где мы проводили
испытания, просто обрубал dns-траффик на наш
сегмент и банил на роутерах те MAC/IP-адреса,
которые мы спуфили.
Как ты видишь, DNS-туннелинг - способ грубый,
трудноконтролируемый, и при слишком
активном использовании он может привести к
непредсказуемым последствиям. В локальных
сетях лучше использовать более щадящие и
нежные способы воровства траффика, а вот
для диалапщиков которые хотят абузить
гостевые телефонные входы это, пожалуй,
единственный вариант... Если ты, всё же,
решился изучить и реализовать этот способ,
обратись к помощи библиотеки libbind. Прочти
также седьмую статью 51-го phrack'а.
ПИНГИ
ICMP-туннелинг и разговоры о нём стары как
Интернет =) Я счёл нужным про него не забыть,
но рассказывать нём я не стану.
О РЕАЛИЗАЦИИ
Я, наверное, просто не умею пользоваться
поисковиками... Но мне так и не удалось найти
ни одной публичной реализации тех видов
туннелинга траффика реального времени, о
которых я рассказывал. И это даёт мне
основания полагать, что таких реализаций
просто нет. Поэтому, многое тебе придётся
делать самому. Бери libbind, libbzip2, rsaeuro, rfc 791, 792,
793, 768, 1122, 1034, 1035, а также те, которые
регламентируют протоколы доступных тебе
бесплатных сервисов и... желаю удачи! =)))
С уважением, [Privacy]
