RSS

Компьютерная терминология    1_9  A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  Q  R  S  T  U  V  W  X  Y  Z  .....  A  Б  В  Г  Д  Ж  З  И  К  Л  М  Н  О  П  Р  С  Т  У  Ф  Х  Ц  Ч

HTTP протокол


  1. Про HTTP-туннелирование
  2. Cкрытые каналы в протоколе прикладного уровня HTTP
  3. FIREPASS
  4. Следующие шаги
    4.1 Политика брандмауэра
    4.2 Приобретение брандмауэра
    4.3 Организационные вопросы с брандмауэрами
  5. Библиография
Cкрытые каналы в протоколе прикладного уровня HTTP
ВВЕДЕНИЕВ любом наборе информации, будь то исполняемая программа, графическое изображение или сетевой протокол есть пути переноса дополнительных «скрытых» данных. Такая возможность есть и практически на всех уровнях модели OSI. Широко известны инструменты туннелирования, использующие служебные заголовки протоколов сетевого уровня TCP/UDP. Однако практическое применение таких туннелей ограничено из-за их низкой пропускной способности. Более широкие перспективы для построения скрытых коммуникационных каналов основываются на использовании прикладных протоколов. Здесь есть возможность быстрой передачи больших объемов произвольной информации в качестве полезной нагрузки самого протокола, а не кода внутри его служебных заголовков. Одним из таких протоколов является HTTP.
Основное поле для использования скрытых каналов это локальные сети, имеющие доступ в Интернет. Как правило, работа с сетевыми сервисами за пределами домашней сети жестко регламентируется различными системами контроля доступа. Эта статья является практической, в ней мы рассмотрим два способа использования протокола HTTP для туннелирования произвольных данных протоколов сетевого уровня. Оба метода могут быть использованы как для доступа из локальной сети за ее пределы, так и для обратной задачи.ССTT
СCTT – (“Covert Channel Tunneling Tool”) Инструмент Туннелирования в Скрытых Канналах. CCTT позволяет создавать коммуникационные каналы через системы контроля сетевого доступа с потоками данных, которые позволяют:
Для использования CCTT необходимо установить его клиентскую часть в локальной сети и серверную во внешней сети. В качестве канала передачи между ними могут выступать TCP, UDP соединения и TCP соединения с использованием метода HTTP CONNECT через локальный HTTP прокси сервер или через цепь HTTP прокси серверов. Одна из интересных особенностей CCTT это работа в режиме реверсивного прокси. ССTT клиент устанавливает соединение с CCTT сервером (TCP, UDP, HTTP CONNECT) и регистрируется на нем как реверсивный прокси. CCTT сервер, находящийся за пределами локальной сети, принимает соединения от клиентов, находит соответствующую запись в таблице зарегистрированных реверсивных прокси и использует уже открытое соединение с соответствующим прокси, как канал для передачи данных. ССTT клиент, принимает эти данные и устанавливает соединение с нужным сервисом внутри локальной сети. Так же есть возможность кодировать поток данных между CCTT клиентом и сервером.
FIREPASS
В большинстве локальных сетей использование метода HTTP CONNECT запрещено на внутреннем HTTP прокси сервере. В этом случае может работать технология, реализованная в проекте Firepass. Здесь используется метод HTTP POST. Firepass клиент располагается на сервере внутри локальной сети и «слушает» несколько TCP/UDP портов. Как только устанавливается соединение с ним, Firepass клиент отправляет HTTP/1.1 POST запрос на веб сервер во внешней сети. Он может сделать это как напрямую, так и с использованием локального HTTP прокси сервера. Ресурс, на который он отправляет POST запрос, это Firepass сервер. В заголовке первого HTTP запроса указываться адрес, порт и протокол сервиса во внешней сети с которым необходимо установить соединение. Firepass сервер, получив первый запрос, порождает новый процесс – “менеджер соединения”, который и будет устанавливать дальнейшее соединение со внешним сервисом.. Далее Firepass клиент с некоторым интервалом отправляет серверу HTTP POST запросы с TCP/UDP данными, полученными от своего клиента. Эти данные отправляются на целевой сервис с использованием «менеджера соединения». Данные же полученные от сервиса проходят обратный путь и возвращаются Firepass клиенту в качестве HTTP ответа на очередной POST запрос. В некоторых случаях, если позволяет конфигурация сети и DMZ возможно проникновение извне в локальную сеть через, например, корпоративный веб сервер. В этом случае Firepass сервер работает на корпоративном веб сервере, а Firepass клиент общается с ним из внешнего мира. Одно из достоинств технологии использованной в Firepass это множество вариантов размещения его серверной части. Требуется только веб сервер и возможность устанавливать с него исходящие TCP/UDP соединения.
ЗАКЛЮЧЕНИЕ
Приведенные здесь методы, показывают только несколько вариантов использования протокола HTTP в качестве среды передачи произвольных данных. В целом же можно сказать, что если в локальной сети есть клиент с возможностью отправлять/принимать HTTP запросы (методы GET, POST, CONNECT), то для него так же всегда есть возможность использования HTTP как туннеля для протоколов сетевого и прикладного уровня.
Про HTTP-туннелирование.
Это неплохо работающий способ обойти файрвол и достучаться до внутренних хостов локальной сети через веб-сервер, который открыт «наружу».
Если можно залить на этот сервер специальный веб-сценарий, то с большой вероятностью получишь возможность обращаться к узлам из локальной сети этого сервера, которые при этом в инете не открыты! Любое подобное решение состоит из двух частей — клиента и сервера, которые инкапсулируют трафик в обычные HTTP GET- и POST-запросы и передают в таком виде данные между собой.
Данные при этом сжимаются, криптуются и кодируются в base64. Существует много реализаций подобного подхода, в том числе немало коммерческих. Есть две бесплатные разработки: reDuh и HTTPTunnel. Мне приглянулась первая, так как ее серверная часть (та, которая заливается на веб-сервер) доступна в трех вариациях: на JSP, PHP и ASPX. В зависимости от того, какие технологии используются на веб-сервере, можно выбрать подходящий вариант.
Клиентская часть при этом написана на Java и, соответственно, может быть запущена под любой ОС.Рассмотрим конкретный пример.
Допустим, пентестер Иван, проводя исследование, нашел в некотором вебсценарии уязвимость и может загрузить на сервер скрипт для HTTP-туннелинга.
При этом ему стало известно, что где-то внутри локалки находится RPD-сервер с названием хоста term-serv.victim.com, к которому нет доступа «снаружи» из-за файрвола. Брандмауэр пропускает к вебсерверу только HTTP-трафик и больше ничего. Подключиться к этому серверу и другим хостам из внутренней локальной сети Иван может с помощью HTTPтуннелинга. Это выглядит так:
1. Иван заливает на сервер скрипт reDuh.jsp, который становится доступным по некоторому адресу (пусть это будет ubunt00.victim.com/uploads/reDuh.jsp). Это серверная часть, и она не нуждается в настройке.
2. На локальной машине запускается клиентская часть reDuh — reDuhClient. Это консольное приложение, которому в качестве параметра для запуска передается адрес только что загруженного скрипта:
$ java reDuhClient ubunt00.victim.com 80 /uploads/reDuh.jsp
3. Указать адрес серверной части мало — необходимо еще отконфигурировать туннели с помощью админки, которая по умолчанию запускается на 1010 порту.
Ивану требуется пробросить локальный порт 1234 на порт 3389 (RPD) хоста termserv.victim.com, поэтому правило будет следующим:
[createTunnel]
1234:term-serv.victim.com:3389

4. Все, теперь если Иван подключится с помощью любого RDP-клиента к localhost:1234, то весь его TCP-трафик будет инкапсулироваться в HTTP-запросы, которые передаются на ubunt00.victim.com/uploads/reDuh.jsp, а оттуда уже переадресуются на целевой сервер. Таким образом, он получит желанный доступ к удаленному рабочему столу.
Тут надо сказать, что reDuh не ограничивает количество соединений, поэтому ты можешь создать несколько туннелей для разных хостов и разных сервисов (например, SSH) и использовать их одновременно! Ради интереса я попробовал еще и HTTPTunnel, которая оказалась не менее замечательной разработкой.
Ее большой плюс заключается в наличии специальной клиентской версии с удобным GUI-интерфейсом (только для Windows).
Серверная часть есть в двух вариантах: на PHP и Perl’е. При этом HTTPTunnel может работать в качестве SOCKS-сервера.
Соответственно, подключаясь к внутренним хостам (например, в том же самом RDP-клиенте), ты можешь сразу указывать внутренний адрес хостов для подключения (если возвращаться к нашему примеру, то это term-serv.victim.com).
Но при этом надо предварительно позаботиться о том, чтобы в настройках программы был прописан локальный SOCKS, созданный HTTPTunnel. На случай, если какое-то приложение не поддерживает работу через прокси, его трафик можно принудительно соксофицировать с помощью FreeCap, tsocks или любых других аналогичных приложений.

seo & website usability html os faq hardware faq memory video cpu hdd mainboard faq printer & scaner modem mobiles hackzone

Магазин цифровой техники | Новинки магазина | Windows7: Общие настройки | Windows7: Реестр | Windows7: Реестр faq | Windows7: Настроки сети | Windows7: Безопасность | Windows7: Брандмауэр | Windows7: Режим совместимости | Windows7: Пароль администратора |  |  |  |  |  |  | Память | SDRAM | DDR2 | DDR3 | Quad Band Memory (QBM) | SRAM | RDRAM | FeRAM | Словарь терминов | Video | nVIDIA faq | ATI faq  | Интегрированное видео faq | TV tuners faq | Терминология | Форматы графических файлов | Работа с цифровым видео(faq) | Кодеки faq | DVD faq | DigitalVideo faq | Video faq (Архив) | CPU | HDD & Flash faq | Как уберечь винчестер | HDD faq | Cable faq | SCSI адаптеры & faq | SSD | Mainboard faq | Printer & Scaner | Горячая линия бесплатной юридической консультации | Благотворительность

На главную | Cookie policy | Sitemap

 

po gonn © 2004