vcom tunnel что это

Знакомство с виртуальными интерфейсами Linux: туннели

Linux поддерживает множество видов туннелей. Это запутывает новичков, которым бывает сложно разобраться в различиях технологий, и понять то, каким туннелем лучше воспользоваться в конкретной ситуации. В материале, перевод которого мы сегодня публикуем, будет дан краткий обзор часто используемых туннельных интерфейсов ядра Linux. Сильно углубляться в эту тему мы не будем, рассмотрев лишь общие особенности туннелей и варианты их использования в Linux.

Здесь будут рассмотрены следующие часто используемые интерфейсы: IPIP, SIT, ip6tnl, VTI и VTI6, GRE и GRETAP, GRE6 и GRE6TAP, FOU, GUE, GENEVE, ERSPAN и IP6ERSPAN.

Прочитав эту статью, вы узнаете об особенностях этих интерфейсов и выясните различия между ними. Вы научитесь их создавать и узнаете о ситуациях, в которых их лучше всего использовать.

Туннель IPIP, как можно понять из его названия — это туннель, работающий в режиме «IP over IP» (RFC 2003). Заголовок пакета туннеля IPIP выглядит так, как показано ниже.

Заголовок пакета туннеля IPIP

Такие туннели обычно используются для соединения двух внутренних IPv4-подсетей через общедоступную IPv4-сеть (интернет). Применение IPIP создаёт минимальную дополнительную нагрузку на систему, но по такому туннелю можно выполнять только однонаправленную передачу данных (unicast). То есть, построив подобный туннель, нельзя будет использовать его для групповой передачи данных (multicast).

IPIP-туннели поддерживают режимы «IP over IP» и «MPLS over IP».

Вот как создать IPIP-туннель:

SIT (Simple Internet Transition) — это технология создания туннелей, главной целью существования которой является соединение изолированных IPv6-сетей через интернет с использованием протокола IPv4.

Режим any используется для работы с IP- и IPv6-трафиком, что может оказаться полезным в некоторых ситуациях. SIT-туннели также поддерживают ISATAP. Вот пример использования этой технологии.

Заголовок SIT-пакета выглядит так, как показано ниже.

Заголовок пакета туннеля SIT

Вот как создать SIT-туннель (эти действия надо выполнить на серверах A и B):

Ip6tnl

Интерфейс ip6tnl работает в режиме «IPv4/IPv6 over IPv6». Он похож на IPv6-версию туннеля SIT. Вот как выглядит заголовок пакета ip6tnl.

Заголовок пакета туннеля ip6tnl

Вот как создать туннель ip6tnl:

VTI и VTI6

Интерфейс VTI (Virtual Tunnel Interface) в Linux похож на интерфейс VTI Cisco и на Juniper-реализацию защищённого туннеля (st.xx).

Этот драйвер туннелирования реализует IP-инкапсуляцию, что может быть использовано с xfrm для создания защищённых туннелей и для последующего использования поверх таких туннелей маршрутизации уровня ядра.

В целом, VTI-туннели работают почти так же как туннели IPIP или SIT. Исключением является то, что они задействуют fwmark и инкапсуляцию/декапсуляцию IPsec.

VTI6 — это IPv6-эквивалент VTI.

Вот как создать VTI-туннель:

Кроме того, конфигурировать IPsec можно с помощью libreswan или strongSwan.

GRE и GRETAP

Технология GRE (Generic Routing Encapsulation) описана в RFC 2784. При GRE-туннелировании между заголовками внутреннего и внешнего IP-пакета добавляется дополнительный заголовок GRE.

Теоретически, GRE может инкапсулировать пакеты любого протокола 3 уровня с допустимым Ethernet-типом. Это отличает технологию GRE от технологии IPIP, которая поддерживает лишь инкапсуляцию IP-пакетов. Вот как выглядит заголовок пакета при использовании технологии GRE.

Заголовок пакета туннеля GRE

Обратите внимание на то, что туннели GRE позволяют выполнять групповую передачу данных и поддерживают IPv6.

Вот как создать туннель GRE:

В то время как туннели GRE работают на 3 уровне модели OSI, туннели GRETAP работают на 2 уровне OSI. Это означает, что одними из внутренних заголовков соответствующих пакетов являются Ethernet-заголовки.

Заголовок пакета туннеля GRETAP

Вот как создать туннель GRETAP:

GRE6 и GRE6TAP

GRE6 — это IPv6-эквивалент GRE. Туннели GRE6 позволяют инкапсулировать любые протоколы 3 уровня в IPv6. Вот как выглядит заголовок пакета GRE6.

Заголовок пакета туннеля GRE6

В туннелях GRE6TAP, как и в туннелях GRETAP, среди внутренних заголовков пакета есть и Ethernet-заголовки.

Заголовок пакета туннеля GRE6TAP

Вот как создать туннель GRE:

Туннелирование может выполняться на разных уровнях сетевого стека. Туннели IPIP, SIT и GRE существуют на уровне IP. А туннели FOU (они устроены по схеме «foo over UDP») работают на уровне UDP.

В применении UDP-туннелирования есть некоторые преимущества перед IP-туннелированием. Дело в том, что протокол UDP работает с существующей аппаратной инфраструктурой.

Например, это RSS в сетевых картах, ECMP в коммутаторах, это технологии расчёта контрольных сумм без участия центрального процессора. Применение соответствующего FOU-патча для разработчиков показывает значительное увеличение производительности для протоколов SIT и IPIP.

В настоящее время FOU-туннели поддерживают инкапсуляцию протоколов на основе IPIP, SIT и GRE. Вот как может выглядеть заголовок FOU-пакета.

Заголовок пакета туннеля FOU

Вот как создать туннель FOU:

Обратите внимание на то, что FOU-туннели не поддерживаются в Red Hat Enterprise Linux.

Ещё одна разновидность UDP-туннелирования представлена технологией GUE (Generic UDP Encapsulation). Разница между FOU и GUE заключается в том, что у GUE имеется собственный заголовок, который содержит сведения о протоколе и другие данные.

В настоящее время туннели GUE поддерживают внутреннюю инкапсуляцию IPIP, SIT и GRE. Вот как может выглядеть заголовок GUE-пакета.

Заголовок пакета туннеля GUE

Вот как создать GUE-туннель:

Благодаря этим командам будет создан принимающий GUE-порт для IPIP, привязанный к номеру 5555, и IPIP-туннель, настроенный на GUE-инкапсуляцию.

GUE-туннели не поддерживаются в Red Hat Enterprise Linux.

GENEVE

Туннели GENEVE (Generic Network Virtualization Encapsulation) поддерживают все возможности XLAN, NVGRE и STT. Технология GENEVE спроектирована с учётом обхода выявленных ограничений этих трёх технологий. Многие считают, что данная технология способна, в перспективе, полностью заменить эти три более старых формата. Вот как выглядит заголовок пакета туннеля GENEVE.

Заголовок пакета туннеля GENEVE

Этот заголовок похож на заголовок VXLAN-пакета. Основное различие между ними заключается в том, что заголовок GENEVE является более гибким. Он позволяет очень легко реализовывать новые возможности путём расширения заголовков с помощью полей Type-Length-Value (TLV).

Подробности о GENEVE можно узнать здесь и здесь.

GENEVE используется в SDN-решении Open Virtual Network (OVN) как стандартное средство инкапсуляции. Вот как создать туннель GENEVE:

ERSPAN и IP6ERSPAN

Технология ERSPAN (Encapsulated Remote Switched Port Analyzer) использует GRE-инкапсуляцию для расширения базовых возможностей по зеркалированию портов со 2 уровня до 3 уровня. Это позволяет пересылать зеркалируемый трафик по маршрутизируемой IP-сети. Вот как выглядит заголовок пакета ERSPAN.

Заголовок пакета туннеля ERSPAN

Туннели ERSPAN позволяют Linux-хостам действовать в роли источника трафика ERSPAN и отправлять отзеркалированный ERSPAN-трафик либо на удалённый хост, либо в некий пункт назначения ERSPAN, который принимает и обрабатывает ERSPAN-пакеты, сгенерированные коммутаторами Cisco или другими устройствами, поддерживающими ERSPAN. Подобную систему можно использовать для анализа и диагностики сети, для выявления вредоносного трафика.

Linux в настоящее время поддерживает большинство возможностей двух версий ERSPAN — v1 (type II) и v2 (type III).

Вот как создавать ERSPAN-туннели:

Ещё можно поступить так:

Добавим tc-фильтр для мониторинга трафика:

Итоги

Мы рассмотрели здесь довольно много технологий создания туннелей в Linux. Вот сводная таблица по ним.

Обратите внимание на то, что все туннели, примеры создания которых здесь показаны, существуют только до перезагрузки сервера. Если вы хотите создать туннель, восстанавливающийся и после перезагрузки, рассмотрите возможность использования демона для настройки сети, наподобие NetworkManager, или примените подходящий механизм из используемого вами дистрибутива Linux.

Уважаемые читатели! Какими Linux-туннелями вы пользуетесь?

Источник

Продвинутое туннелирование: атакуем внутренние узлы корпоративной сети

В этой статье будут рассмотрены сценарии атаки защищенных сегментов корпоративной сети с помощью pivoting-техник, metasploit framework и proxychains.

Многослойная сетевая архитектура создается для защиты важных корпоративных сервисов согласно концепции Defense-in-Depth, которая занимает важное место в сфере информационной безопасности. Другими словами, критичные для компании системы не могут располагаться в той же сети, что и все остальные. В данной статье я покажу на примерах, как атакующий может получить доступ к «скрытой» сети, не имея к ней прямого доступа на первых этапах тестирования на проникновение, используя методы pivoting’а или продвинутого туннелирования.

Маршрутизация

Процесс, во время которого устройства в различных сетях определяют, как им связываться друг с другом называется маршрутизацией. Маршрутизация обычно происходит на устройствах, называемых маршрутизаторами или роутерами. Они перенаправляют сетевые пакеты между узлами сети, используя таблицу маршрутизации, пока те не достигнут конечной точки назначения. Вообще говоря, маршрутизацию могут выполнять не только роутеры, но и обычные операционные системы, установленные на рабочих компьютерах.

Согласно примеру на схеме выше, для успешной маршрутизации между подсетями 192.168.1.0/24 и 192.168.10.0/24, роутер должен иметь соответствующую запись в своей таблице маршрутизации. Эта запись говорит о том, как сетевой пакет должен попадать из сети 192.168.1.0/24 в сеть 192.168.10.0/24 и наоборот.

Путь сетевого пакета можно представить так (начинается путь с узла, отправляющего пакет):

1. Может ли целевой IP-адрес находиться в моей подсети?
— Если да, то доставить пакет по адресу назначения.
— Если нет, то отправить пакет на шлюз.
2. Когда маршрутизатор получает пакет, он проверяет свою таблицу маршрутизации.
3. Есть ли у меня запись об узле или подсети, которой предназначен IP-пакет?
— Если да, то отправить пакет в сеть назначения.
— Если нет, то отправить пакет на следующий шлюз.
4. Тот же процесс повторяется на всех других роутерах.
5. В итоге пакет попадает на маршрутизатор, отвечающий за выход в Интернет из корпоративной сети, и пакет отправляется в Интернет.

Pivoting

Pivoting, это техника, с помощью которой организовывается доступ к тем сетям, к которым мы не имеем доступ при обычных обстоятельствах и полученный с использованием скомпрометированных компьютеров. Сетевая изоляция будет бесполезна в случае, если мы скомпрометируем узел сети, имеющий доступ во все изолированные подсети. Таким образом, атакующий может использовать возможности маршрутизации на скомпрометированной машине для доступа к внутренним корпоративным ресурсам. Каждый запрос, который будет сделан к внутренней сети, будет проходить через скомпрометированный хост, обычно называемый pivot. Другими словами мы получаем туннель во внутреннюю сеть для наших пакетов.

Как видно на схеме выше, устройство в центре имеет два сетевых интерфейса, чтобы получать доступ в обе сети, 192.168.1.0/24 и 192.168.10.0/24. При нормальной работе между этими двумя сетями маршрут пролегает только через маршрутизатор с сетевыми интерфейсами 192.168.1.1 и 192.168.10.1. Согласно архитектуре, авторизованный пользователь устройства в центре схемы должен иметь доступ к некоторым сервисам в DMZ.

Компрометация первого узла проброса (pivot) и проброс портов

Согласно сценарию атаки, мы получили шелл метерпретера на машине RD, которая находится в DMZ и, как выяснилось, имеет два сетевых интерфейса.

Как мы видим — роутер на схеме не имеет маршрута между нужными злоумышленнику сетями.

Далее, согласно сценарию, атакующий хочет получить доступ к подсети за интерфейсом 7.7.7.0/24. Для этого ему нужно задать правило маршрутизации для хоста RD, т.е. превратить скомпрометированный хост в pivot.

Это очень просто сделать средствами полезной нагрузки (payload) метерпретер. Следующая команда может быть использована для создания туннеля через существующую сессию метерпретера.

Согласно заданному правилу, пока сессия метерпретера с ID 2 запущена, другие модули Metasploit Framework имеют доступ к сети 7.7.7.0/24. Другими словами, после выполнения команд выше, IP адрес хоста JC будет определен, если мы воспользуемся таким модулем, как arp_scanner. JC – это хост, работающий во внутренней сети и имеющий IP-адрес 7.7.7.20.

Мы узнали IP-адреса доступных хостов в сети 7.7.7.0/24.

Пробрасываем nmap через туннель

Чтобы пробросить nmap, маршрут должен быть сконфигурирован в metasploit, а сама конфигурация должна быть доступна через socks4 прокси. Для этого используем модуль socks4a в metasploit:

Теперь, используя утилиту ProxyChains, любое TCP соединение может быть отправлено к цели назначения через TOR, SOCKS4, SOCKS5, HTTP/HTTPS прокси. Несколько прокси-серверов могут быть построены в цепочку. В дополнение к анонимности, при использовании такой схемы приложения могут получать доступ к обнаруженным внутренним сетям.

Прежде чем использовать ProxyChains, нужно произвести небольшую настройку в файле /etc/proxychains.conf. Для этого нужно отредактировать последнюю строку в файле.

Теперь можно выполнить сканирование утилитой nmap через созданный нами socks4 прокси-сервер:

На основании результатов сканирования, мы можем сказать, что нам доступны SSH и HTTP сервисы на хосте 7.7.7.20. Прежде чем двигаться дальше, мы рассмотрим еще одну технику, часто применяемую во время pivoting-а, технику проброса портов или port forwarding.

Проброс портов

Проброс портов – это один из базовых шагов во время туннелирования. Данная техника используется, когда сервис внутри обнаруженной сети недоступен напрямую. Это происходит потому что наша маршрутизация однонаправленная. Мы знаем, как получить доступ к внутреннему сервису, но сервис не имеет соответствующего маршрута к машине атакующего.

Поэтому мы перенаправим порт с машины атакующего на порт целевого сервиса через сессию метерпретера. Этот проброс порта будет работать, пока существует процесс метерпретера на скомпрометированной машине (на pivot-е).

Стоит заметить, что туннель, который был создан при помощи autoroute существует только к контексте фреймворка metasploit и доступен для других модулей. Но если мы хотим использовать туннель другими утилитами, выходящими за пределы фреймворка, нам нужны инструменты вроде proxychains и техники, такие как port forwarding.

Проброс порта может быть выполнен при помощи модуля portfwd, который является одним из post-модулей фреймворка Metasploit.

Когда мы будем отправлять запрос на подключение к нашему локальному порту 2323, вводя в браузере соответствующий URL, наш запрос будет перенаправлен на порт 80 узла 7.7.7.20 через Metasploit Framework. Ранее при помощи nmap и proxychains мы обнаружили, что во внутренней сети есть веб-сервис, работающий на TCP порте 80. Чтобы получить к нему доступ всеми доступными утилитами Kali Linux, мы должны пробросить наш локальный порт 2323 на удаленный порт 80, узла 7.7.7.20.

Теперь попробуем получить доступ к веб-сервису Eash File Sharing Web Server.

SSH-брутфорс через pivoting

Как вы помните, мы обнаружили так же SSH сервис на машине 7.7.7.20. Мы можем провести атаку на перебор учетных данных (брутфорс) через наш туннель. Для этого будем использовать вспомогательный модуль SSH_enumusers:

В результате выполнения команды мы обнаружили множество пользователей.

В дополнении к вспомогательным модулям Metasploit Framework, для атаки могут быть использованы такие инструменты как Hydra. Мы запустим брутфорс при помощи Hydra через ProxyChains. Весь траффик будет проходить через туннель, работающий на скомпрометированном узле RD.

Далее подключиться по SSH можно через прокси-сервер с логином admin и паролем 123456, полученными при помощи Hydra.

Получение доступа ко второму узлу pivot

Во время сканирования nmap сети 7.7.7.0/24 были обнаружены хосты, уязвимые к MS08-067 и BoF уязвимость в приложении Easy File Share. Доступ ко второму узлу pivot может быть получен с использованием одной из уязвимостей. Другой опцией будет являться продолжение прокладывания туннеля при помощи техники SSH Port Forwarding, но здесь мы будем использовать MS08-067 и BoF.

Уязвимость MS08-067 и Bind TCP

Metasploit Framework имеет модуль для эксплуатации уязвимости exploit/windows/smb/ms08_067_netapi.
Важно заметить, что мы используем пейлоад bind_tcp, т.к. у нас не определены маршруты в обе стороны и целевая система не сможет выполнить обратное подключение на машину атакующего, т.к. не имеет соответствующего маршрута. Таким образом, целевая машина будет просто ждать подключения на порт, который мы укажем в настройках пейлоада bind_tcp. Ниже на схеме указана последовательность шагов при использовании прямого и обратного подключений.

Выберем модуль для эксплуатации MS08-067, пейлоад bind_tcp и скомпрометируем вторую машину:

Уязвимость Easy File Share BoF

Также можно воспользоваться другой найденной уязвимостью в приложении Easy File Share. Компрометация машины может быть произведена следующим образом:

Ниже схематично представлена атака:

Так как мы получили доступ на машину 7.7.7.20, мы можем продолжить сбор информации. Как оказалось, машина JC так же имеет два сетевых интерфейса. Это означает, что мы нашли вторую сеть, к которой не имеем прямого доступа (8.8.8.0/24).

Двойной удар pivoting

Мы обнаружили сеть 8.8.8.0/24. У нас уже есть маршрут между 172.16.0.0/24 и 7.7.7.0/24 через скомпрометированную машину RD. В текущей конфигурации пакеты, приходящие из сети 172.16.0.20 на хост JC (вторая скомпрометированная машина) сперва идут на хост RD (первая скомпрометированная машина) и RD уже транслирует их на машину JC. Если атакующий (172.16.0.20) теперь хочет получить доступ к новой сети 8.8.8.0/24, должно быть определено новое правило маршрутизации. Чтобы использовать инструменты за пределами Metasploit Framework мы должны запустить новый socks4 прокси-сервер, чтобы соединить два pivot-узла, после чего задать новый прокси сервер в настройках proxychains.

Сетевые пакеты с адресом назначения 8.8.8.9, отправленные с машины атакующего (172.16.0.20) должны пройти через две скомпрометированные машины:

Всемогущий ProxyChains

Инструмент ProxyChains создает туннель через цепочку прокси-серверов и передает по нему пакет до адреса назначения. Последним шагом будет создание socks4 прокси-сервера, слушающего порт 1081 для сети 8.8.8.0/24.

Остается адаптировать настройки proxychains в файле /etc/proxychains.conf. Опция Dynamic Chain используется, чтобы пакеты шли строго по цепочке прокси-серверов, указанному в файле конфигурации proxychains, в порядке сверху вниз.

Теперь при помощи proxychains мы можем просканировать хост 8.8.8.9 через наш туннель:

Как видите, пакеты проходят через два прокси-сервера и, в конечном счете, достигают цели.
В результате сканирования можно обнаружить уязвимую версию vsftpd на хосте 8.8.8.9. Выполним следующие шаги, чтобы скомпрометировать цель:

Меры противодействия

Незащищенные хосты, имеющие два сетевых интерфейса, среди которых один доступен из DMZ, должны быть удалены из сетевой инфраструктуры. Хосты, находящиеся в DMZ должны быть доступны только из DMZ.

Заключение

Атакующий обнаружил две скрытые сети в результате следующих шагов:

Таким образом, атакующий, имея доступ лишь к одной сети, через серию атак, сумел скомпрометировать хост, находящийся далеко в глубине корпоративной сети за защищенным сетевым периметром.

Источник

Vcom tunnel что это

Предположим, что мы получили доступ к корпоративному веб-серверу, который имеет два сетевых интерфейса: один в Интернет, а второй в локальную корпоративную сеть. Что дальше? Веб-сервер разрешает входящие подключения только на TCP порт 80, да и весь трафик находится под пристальным присмотром системы IPS, а нам просто необходимо продвинуться вглубь инфраструктуры. В данной статье я расскажу как это можно сделать.

От простого к сложному

Для простоты, будем предполагать, что внешняя сеть это 192.168.1.0/24 а внутренняя корпоративная 192.168.2.0/24.

Сперва рассмотрим простейший пример, когда веб-сервер позволяет подключиться к нему по протоколу SSH и мы завладели учетными данными.

Ни для кого не секрет, что в таком случае мы может организовать SOCKS прокси на нашей машине, который будет отправлять весь трафик по зашифрованному каналу, сервер будет расшифровывать его и отправлять дальше в локальную сеть.

Напомню, что такой туннель можно создать выполнив подобную команду:

Где 192.168.1.5 — IP адрес скомпрометированного веб-сервера. Его мы будем использовать и в следующих примерах.

После этого, используя proxychains можно произвести, например, сканирование хоста корпоративной сети.

/etc/proxychains.conf
[ProxyList]
socks4 127.0.0.1 8888

Если мы не можем работать через proxychains, то можно сделать проброс фиксированного порта (например RDP) через SSH туннель.

Далее подключиться по RDP можно будет выполнив команду

Что если мы не хотим для каждого удаленного хоста пробрасывать порт?
В таком случае можем использовать утилиту sshuttle
Установить утилиту можно из репозитория или с github-а

В простейшем виде запуск выглядит так:

После запуска мы можем подключаться к удаленным хостам, как будто мы в их локальной сети, т.е. просто

Как это работает, можно почитать на github.

Если нам нужно к примеру подключиться по SSH к хосту в другой подсети, мы можем выполнить следующие команды на скомпрометированном веб-сервере (192.168.1.5/24):

После этого можно получить доступ по SSH к удаленному серверу с машины атакующего следующим образом:

Подключение произойдет к хосту с IP-адресом 192.168.2.4, который напрямую с машины атакующего недоступен.

Усложняем задачу

Предположим, что доступа по SSH у нас к корпоративному веб-серверу нет, но мы нашли уязвимость, и выполнили шелл-код на стороне веб-сервера.
В качестве шелл-кода мы выполнили meterpreter фреймволка метасплойт и теперь имеем сессию.
Теперь, каким-то образом, мы должны проэксплуатировать другие машины внутренней корпоративной сети 192.168.2.0/24.

В состав фреймворка метасплойт входят инструменты, позволяющие это сделать.

Номер сессии метерпретера — 1
Чтобы выполнять другие модули фреймворка метасплойт на хостах корпоративной сети, нужно из сессии метерпретера выполнить следующие команды:

background — свернуть текущую сессию метерпретера.
route add 192.168.2.0 255.255.255.0 1 — добавить маршрут.

Используйте route print чтобы посмотреть активные маршруты:

msf exploit(handler) > route print

Subnet Netmask Gateway
—— ——- ——-
192.168.2.0 255.255.255.0 Session 1

Теперь, используя модули метасплойт, вы можете указывать в параметрах RHOST/RHOSTS хосты подсети 192.168.2.0/24.

Но этот маршрут доступен только в рамках контекста фреймворка метасплойт. Что если нам нужно получить доступ по RDP или другому протоколу у внутреннему хосту для стороннего приложения, скажем rdesktop?

для этого снова открываем сессию метерпретера и выполняем команду:

Теперь можно подключиться как обычно:

Чтобы отменить портфорвардинг используйте:

Прячемся лучше

И здесь нам потребуются инструменты для инкапсуляции нашего трафика в «разрешенные» пакеты.

Для начала стоит, пожалуй, сказать, что метерпретер может работать по протоколам HTTP и HTTPS.
Для этого можно использовать следующие пейлоады для ОС семейства Windows:

В таком случае весь трафик виден системе IPS как HTTP.

Но метерпретер — не единственный инструмент, позволяющий инкапсулировать трафик в HTTP и перенаправлять во внутреннюю сеть. К тому же, не всегда нам удается им воспользоваться.

Идея состоит в том, чтобы на скомпрометированном хосте разместить инструмент, который будет отвечать за инкапсуляцию трафика, например php-скрипт, который будет выполнять веб-сервер без каких-либо проблем.

Такое решение обычно представляет собой клиент-серверное приложение. Серверная часть находится на шлюзе и инкапсулирует трафик в GET/POST запросы, если мы инкапсулируем в HTTP. При этом данные могут сжиматься, шифроваться, кодироваться в base64 и т.п.

Одним из таких инструментов является reGeorg.
Он позволяет создавать SOCKS прокси и созданный туннель можно использовать сразу для нескольких подключений.
Есть серверные части под различные веб-платформы, а клиентская часть написана на Python.

Т.е. основаня задача — это разместить на корпоративном веб-сервере подходящую серверную часть reGeorg-а, через SQL-injection или как-то еще, которая будет доступна, скажем, по такой ссылке

Когда сервер доступен по ссылке, мы можем запустить клиентскую часть на машине атакующего:

Если вы получаете сообщение [INFO ] Georg says, ‘All seems fine’, значит соединение установлено.

Дальше все просто, настраиваем proxychains

/etc/proxychains.conf
[ProxyList]
socks4 127.0.0.1 8888

И используем туннель

proxychains rdesktop 192.168.2.4

Можете запустить wireshark и убедиться, что весь передаваемый трафик является HTTP-трафиком, хотя мы работаем с удаленным сервером по протоколу RDP.

Инкапсулировать трафик можно не только в HTTP, но и, к примеру, в DNS UDP пакеты!
Для этого служит утилита dnscat2.
Подробнее про нее вы можете прочитать в другой статье на DefconRU.

В качестве заключения

Как можно убедиться после прочтения данной статьи, уязвимость одного узла может привести к компрометации всей сети.
Существует множество способов маскировки трафика и обхода систем IDP/IPS. Поэтому следует уделять повышенное внимание к узлам, имеющим выход в сеть Интернет.

КОММЕНТАРИИ

Добрый день. Можно сказать все варианты завязаны на ssh или nc. Можно сделать такое-же но имея веб шел на целивом сервере.?

Добрый день! Но если Вы смогли закинуть веб-шелл на удаленный хост, что Вам мешает закинуть туда серверный скрипт reGeorg или выполнить тот же netcat через веб-шелл?

Я поторопился, не дочитал до конца статьи прошу прощения. Спасибо за статью, я нашёл ответ на твой вопрос. Продолжайте в том же духе. Спасибо

Источник