Http-Tunnel, как настроить?
В http-tunnel после установки зайдите в Diagnostic Tools, нажмите кнопку тест, после проверки там покажут скорость, с которой тоннель работает. Далее Tunnel Setting — набираете адрес вашего Прокси с авторизацией, отметьте Specify proxy settings. Затем, здесь же нажмите Advanced — появится меню, в нем набираете все адреса серверов Forex Club и порты (это в строке adress or IP и порт соответственно в строке Application Port Protocol – TCP).
Если у Вас IDS, запустите диск С:Program FilesFXClubIDSystem — IDSystem параметры конфигурации . Затем открываете последний файл и все адреса и порты, которые там видите заносите в http-tunnel, потом переделываете сам файл конфигурации (перед переделкой сохраните где-нибудь). Переделать надо следующее — строка IP, далее идет адрес сервера — его убираете, а вместо него пишите 127.0.0.1 В строке порт у вас должен быть указан тот же порт что и в http-tunnel, где вы адреса и порты прописывали (обратите внимание что в http-tunnel когда вы пишите Application Port то Local Port может с ним не совпасть, например этот порт занят на вашем компьютере, тогда в Local Port появится другой — значит Вы именно этот локальный порт и должны записать в файл конфигурации IDS.
Точно также переделываете и остальные адреса и порты в файле конфигурации, то есть у Вас получится , что IDS http-tunnel одним краем подсоединен к адресам и портам серверов Forex Club, а другим краем к вашим локальным портам.
HTTP туннель
After you have successfully installed and set up the HTTPTunnel client and server, you can test your setup by trying to establish your first tunnel connection.
Start your network application and direct it either to a mapped port on the HTTPTunnel client or connect over the SOCKS proxy. If your application does not support SOCKS, there are utility programs that socksify, which allows adaptation of any software to connect to external networks via SOCKS.
Ну или, если у Вас есть проги, которые не поддерживают socks, то ставить типа FreeCap.
Что, так трудно там всё почитать до конца?
HTTP туннель — вариант, но хоть вы и не просили другое, я бы посоветовал DNS туннель сделать.
Потому что раз есть потребность в http туннеле, значит выход в мир (туннелирование) «административно» запрещен (но технически, вероятно, это обойти можно). Но будет ататат если заметят. А обнаруживается он очень легко, мне кажется. Либо если просматривают статистику хоть какую-то по прокси, либо если просто случайно заглянут в лог. Видно невооруженным взглядом. Дело в том, что при HTTP тоннеле, как я понимаю, у вас будет по 1 HTTP запросу на 1 пакет. Для примера, эта скромная страница (ваш вопрос в QA) у меня скачалась в 54 пакетах. То есть, через тоннель, была бы нагрузка в 50 раз больше. На других страницах это соотношение может быть еще больше. Запущенная аська или скайп через тоннель — это еще потом постоянных http запросов. В итоге получается, что вы один создаете запросов (да еще и странно выглядящих запросов) столько, сколько средних размеров офис в сумме. Случайный взгляд в логи — и половина запросов будет ваших, что вызовет любопытство. А ваш гейтвей сервер будет, по итогам статистики, самым посещаемым среди всех сотруников, кто ходит через гейтвей (ведь они зашли на какой-то сервер и вышли. а у вас любая сетевая операция — это очень много запросов к одному вашему серверу).
В общем я бы посоветовал изначально подумать про DNS туннелирование. Затраты те же — виртсервер + домен (хоть даже третьего уровня). Есть громадный плюс в том, что обычно DNS запросы нигде не логируются и не просматриваются, если уж совсем каких-то странностей не наблюдается.
HTTP туннель: путь вперед
Несмотря на то, что все больше трафика
подвергается исследованию и ограничению,
администраторы в основном забывают про
главный порт в их сети — 80-ый. Пользователи,
как и админы, постоянно бороздят просторы
Инета, как в рабочих целях так и в не очень.
Так или иначе, но большинству компаний
нужно присутствие в Сети, а это требует
своего веб-сервера, размещенного у
провайдера или внутри собственной сети. С
каждым новы червем, багом, уязвимостью,
найденной в IIS или Apache, администраторы
стараются все больше и больше закрыть свой
сервер от любопытных взглядов, внедряют IDS (Intrusion
Detection Systems) и IPS (Intrusion Prevention Systems). Однако все
это не 100% защита и ее всегда можно обойти, о
чем и будет рассказано в этой статье.
Ничего нового в самом туннелинге, конечно,
нет. Вероятно самым известным его
применением является IPSec, может быть SSH. Не
все обеспечивают удаленный доступ через IPSec
или SSH, но если такой существует, то с
определенной вероятностью можно сказать,
что на сервер на котором они используются
пробиться будет довольно трудно. Посмотрим
на сеть с другой стороны. Веб-сервер — вот
превосходная мишень для атаки. Именно с
такого сервера можно начать свое
путешествие вглубь сети, даже не взирая на
то, если он защищен файрволом. Тут нам на
помощь и приходит HTTP туннелинг. Опасаясь
различных напастей админы внедряют все
новые и новые системы защиты, как на пути
между инетом и сервером, так и на сервере
самом. В таких условиях использование HTTP
вероятно единственный способ обмануть их.
HTTP туннелинг позволяет клиенту
инкапсулировать трафик в HTTP заголовки.
Затем трафик направляется к серверу на
другом конце канала и там пакеты программой
обрабатываются обратно, извлекаются данные
из заголовков, и только потом уже
редиректятся к своей конечной цели. По
такой схеме можно передавать как UDP, так и
ТСР данные, это обусловлено самой природой
туннелирования.
Сейчас существует только две программы
для HTTP туннелирования. Одна с открытым
кодом, другая продается за деньги. Первая
это GNU
HTTPtunnel, вторая — HTTP
Tunnel. Обе выполняют одну задачу — передачу
информации через HTTP.
Программу можно использовать для доступа
к тем портам, которые в нормальном
состоянии недоступны. Посмотрите на
рисунок, слева атакующий, целевая система —
справа.
Роутер, допустим, имеет такие настройки:
inbound:
permit tcp any host WWW port 80
permit tcp any host WWW port 443
permit tcp any host DNS/SMTP port 25
permit udp any host DNS/SMTP port 53
outbound:
permit ip any any
inbound:
permit ip host DNS/SMTP host SSH eq 22
permit ip host DNS/SMTP host SSH eq 80
permit ip host DNS/SMTP host SSH eq 443
outbound:
permit ip any any
Не обращайте внимание на некоторое
упрощение схемы, она достаточная для
демонстрации. Представим, что атакующему
удалось взломать WWW сервер с IIS (ведь это не
так трудно представить? :)) и получить доступ
к командной строке. Хакер загружает
скомпилированную версию HTTP tunnel сервера (hts).
Синтаксис командной строки выглядит так:
hts.exe -F (SRC PORT) (TARGET):(DST PORT)
(SRC PORT) — порт который будет форвардится
(TARGET) — IP адрес хоста на который будут
посылаться данные
(DST PORT) — целевой порт, который будет
принимать трафик.
В таком виде когда клиент посылает
информацию на SRC PORT и она будет пересылаться
на DST PORT компьютера TARGET. С установленным hts
сервером атакующий стартует клиента на
своей системе и передает трафик на SRC PORT
сервера. Синтаксис клиента таков:
htc -F (SRC PORT) (TARGET):(DST PORT)
Все не более сложно: клиент слушает на SRC
PORT и передает на DST PORT компьютеру TARGET.
Вернемся к нашим баранам. Вот рисунок,
иллюстрирующий дальнейшее развитие
ситуации: атакующий установил hts на WWW и
запустил клиента htc на своей системе.
Процесс hts слушает на 80 порту, в примере он
перенаправляет данные к 23 порту DNS/SMTP
сервера. Атакующий соединяется с 1025 портом
на своей машине — htc инкапсулирует трафик в
HTTP заголовки — пересылает на WWW на 80 порт —
сервер принимает пакеты и вырезает из них
полезную информацию — передает на DNS/SMTP на 23
порт. Вот и выход — хотя телнетовский порт на
прямую не открыт, к нему мы достучались в
обход и теперь с ним можно делать
практически все, что душе угодно.
Другая возможность — указать hts на
удаленном сервере на finger port (79) на SMTP/DNS
машине и вывести список всех пользователей
системы. Дальше уже дело техники — можно
подбирать пароли к логинам брутфорсом,
можно через переполнение буфера в sadmind, в
общем получить доступ к серваку за роутером
достаточно реально. Завоевав SMTP/DNS можно и
его использовать для дальнейшего
разворачивания атаки. Например, можно
мониторить соединения и определить
потенциальные службы и компьютеры, которые
работают за файрволом, в корпоративной сети
за демилитаризованной зоной. Обнаружив
хост с SSH сервером можно использовать SMTP/DNS и
полученные данные о логинах/паролях для
соединения с новой целью.
Итак, становится ясно, что с использование
HTTP туннелинга можно обойти многие
ограничения, налагаемые администраторами.
Это довольно удобный инструмент о котором
не следует забывать как защитникам, так и
нападающим :).
Настройка http tunnel client
Send us your email address and we’ll reply with all your product keys!
