Архив номеров / 2005 / Выпуск №12 (37) / TCP поверх TCP – не такая уж плохая идея!
Рубрика: Сети / Сети
АЛЕКСЕЙ БАРАБАНОВ
TCP поверх TCP – не такая уж плохая идея!
Есть расхожее мнение, что сетевые туннели выгоднее делать на основе протоколов низкого уровня с минимальными размерами заголовков и очень простым протоколом. Считается, что TCP как несущий протокол создает много проблем. Так ли это?
Использование TCP стало столь привычным, что большинство просто не задумывается о заложенных в этот протокол механизмах и во всех случаях полагается на «интеллект» системы. Одновременно с этим, если встречаются какие-то сведения, объясняющие что-то в его поведении, или теории, построенные на основе, так сказать, «упрощенных» представлений, то у многих просто недостает знаний правильно оценить полученную информацию. Что приводит к появлению технологических мифов. Один из которых, порожденный статьей [1] Олафа Титца (Olaf Titz), здесь и попробуем опровергнуть. К сожалению, в России все, что написано на иностранном языке да еще размещено на зарубежном сайте, воспринимается как святое откровение. Хотя многие далее вынесенного в ее заголовок тезиса «Why TCP Over TCP Is A Bad Idea» и не читают. Чтобы уравнять шансы тех, кто имеет затруднения с английским языком, предложим дословный технический перевод упомянутого опуса [2]. В переводе не использовались никакие литературные экстраполяции, чтобы максимально точно донести идеи автора и ни в коем случае не исправить на этапе перевода что-то из многочисленных его ошибок. Разберем текст этой статьи.
Рассуждения Олафа, где он считает, что трафик TCP в Интернете регулируется тайм-аутами, просто выкинем, как не соответствующие реальности и потому не актуальные. Конечно, можно было бы везде, где в тексте встречается «timeout», при переводе подставить «таймер», что сильно приблизит многие рассуждения к действительному положению дел, но тогда пришлось бы исправить и многое другое. Но, как уже было сказано выше, перевод сделан самым безжалостным способом.
Второе, что смутило Олафа Титца – это взаимодействие транспортного TCP и транспортируемого. Для ясности обратимся к схеме инкапсуляции, которая обсуждается в [1]. Скопируем ее в переводном варианте и добавим немного комментариев.
Рисунок 1. Схема инкапсуляции
Давайте представим, что реально может случиться изза потерь сегментов (именно так и следует далее их называть, а не пакетами) в таком туннеле. Во-первых, просто обрыв связи будет обработан и тем и другим TCP соответственно и в пределах перечисленных RFC. А вот с повторами, и правда, могут возникнуть некоторые проблемы. Покажем на схеме (рис. 2), что будет происходить, если в пути потеряется сегмент с данными.
Рисунок 2. Последствия потери сегмента
Предположим, что пропал сегмент D4. Тогда оба стека протоколов получат повторный ACK с последним принятым номером и согласно алгоритму Fast Retransmission, или быстрой повторной передачи, пропущенный пакет будет повторен. На рисунке изображена ситуация, когда оба стека имеют одинаковый RTT и, значит, близкие RTO. Тогда транспортный TCP сформирует повтор пропавшего сегмента T44 и точно так же добавит в поток сегмент T7-4, содержащий сегмент с данными D4, повторенный в транспортируемом TCP. Это самый худший вариант развития событий. Иначе говоря, если потери канала составляют 10%, то из полезной емкости канала будет изъято уже 20%. Но, как уже замечено, это предельно плохой вариант. Поскольку RTT туннеля и RTT транспортируемого TCP на практике не совпадают, то, скорее всего, реальные потери полосы будут гораздо меньше.
Может показаться, что в этих рассуждениях упущена ситуация, когда будет потерян не сегмент с данными, а его подтверждение. Но если это произойдет, все случится точно так же, как и на рис. 2.
Для TCP нет разницы между потерянным сегментом и потерянным подтверждением, если и те и другие высылаются не так, как рассуждает Олаф, а сериями в пределах размера CWND. Но, с другой стороны, теперь уже для TCPтрафика происходит теоретическое учетверение потерь, то есть из полезной емкости канала будет изыматься уже 40%. Хотя это лишь «на бумаге», то есть снова здесь приведен самый плохой вариант.
Теперь, глядя на рис. 2, ответьте, в каком TCP надо запретить повторы? Олаф Титц делает вывод, что повторы надо запретить в верхнем транспортируемом TCP. На самом деле, повторы следует запретить в нижнем туннельном TCP.
Во-первых, потому что туннель это одно TCP-соединение, а вложенных может быть множество.
Вовторых, потому что туннель создается на специальном хосте, а внутренние потоки соединяют разные клиентские компьютеры со стандартным TCP-стеком. И, наконец, втретьих, кроме TCP есть еще много разных протоколов, сегменты c которыми все-таки очень не бесполезно восстановить при потере, а отличить их от TCP может только стек туннеля. Но такое расширение TCP-туннелей пока не реализовано. Здесь лишь рассматривается гипотетическая возможность. Но ничего не мешает в практической ситуации для пробы запретить повторы через параметры sysctl линуксового ядра на тех хостах, между которыми поднят туннель, и проверить действенность такой настройки.
Итак, и вторая часть рассуждений о проблемах TCP не выдерживает элементарной проверки. Быть может, в разделе «Практический опыт» нам откроется истина? Рассмотрим и его повнимательнее.
В практической части статьи [1] содержится информация, которая может стать разгадкой всех проблем Олафа Титца. Оказывается, у автора этой статьи, цитирую, «использовалась волоконно-оптическая связь, которая страдала частыми потерями пакетов, иногда 1020%». Странная связь! Вероятно, на карманных фонариках. Последннее конечно шутка, но тем не менее это позволяет точно определить условия применения тезисов автора упомянутой статьи. Обратимся к RFC 2001 [3]. Там однозначно установлено, что все алгоритмы TCP рассчитаны при допущении, что потери в канале составляют менее 1%. Вероятно, у Олафа были проблемы с кабельщиком. Быть может, суровому монтеру не понравилась его прическа [5] и он решил таким путем выразить свое возмущение. Олаф утверждает, что, создав CIPE [6], смог решить проблемы и обеспечить надежную работу на канале с потерями до 20%. И если не проверить утверждения автора с помощью тестов с туннелем на подобном канале, то получится, что здесь предлагается рассуждения Олафа Титца заменить рассуждениями Алексея Барабанова. Лишь опыт позволит рассудить, на чьей стороне правда (или правдоподобность). Поскольку нет простой возможности создать искусственную линию связи с характеристиками, похожими на те, что создали так много проблем Олафу, то заменим реальные, обычно модулированные, помехи случайными. И дополнительно ограничим их 10-процентными. Думаю, что эта замена, не помешает понять суть происходящих процессов, так как на практике и 10% и 20% значительно больше указанного в RFC 1%, и отличаются лишь временем, затраченным на проведение эксперимента, поскольку чем больше потери, тем меньше скорость передачи.
Проверку будем проводить путем передачи тестового массива псевдослучайных данных в одном направлении через TCP- и UDP-туннели. Это, конечно, примитивная модель взаимодействия, но только так можно в чистом виде попытаться определить зависимость характеристик канала и свойств полученного потока данных. Дополнительно в центре маршрута ограничим полосу, например до 10 Мбит, и внесем случайные потери в трафик. Конечно, 10 Мбит значительно выше типичной скорости канала, предоставленного ISP для подключения к Интернету. Но иначе придется уменьшить объем пересылаемых данных, чтобы в приемлемое время провести эксперимент. Перечислим элементы, которые нужны для организации таких проверок. Во-первых, хост-отправитель и хост-получатель трафика. Во-вторых, два хоста, между которыми проложен туннель. Поскольку «удаленный» конец туннеля может совпадать с хостом-получателем, то, кроме перечисленных трех хостов, нужен еще один, где будет эмулироваться «узкое место» в сети. Итого, достаточно будет 4 компьютера соединить последовательно. Строго говоря, хост-отправитель можно совместить с «ближним» концом туннеля. Но надо учесть, что вход в туннель тоже является своего рода ограничителем трафика, или шейпером, поэтому пусть будут в тестовой сети четыре компьютера, которые назовем wstovert, wsalekseybb, wskostja и server. Общий вид полученной сети представлен на рис. 3, и дальнейший комментарий будем вести согласно изображенной там схемы.
Рисунок 3. Схема тестовой сети
Все компьютеры включены в общую сеть 192.168.0.0/24, объединены общей кабельной системой с помощью коммутатора 1 Гбит и обмениваются данными по протоколу 1000BaseTX, то есть значительно выше проверяемых скоростей передачи, что позволит максимально снизить систематическую ошибку. На эту сеть наложены две виртуальные сети. Первая из них, с адресом 192.168.10.0/24 включает wstovert, wsalekseybb и server, а вторая – с адресом 192.168.11.0/24 – только server и wskostja. Практически все компьютеры могут резолвить адреса друг друга с помощью arp и обмениваться пакетами через общий коммутатор. Но нам ведь нам надо обеспечить передачу трафика между компьютерами так, будто они включены последовательно один за другим. Поэтому с помощью правил маршрутизации и преобразования адресов заставим трафик от wstovert проходить до wskostja через wsalekseybb и server так, как указывает стрелка на рис. 3. Для этого на каждом компьютере укажем статический маршрут до следующей по ходу движения стрелки на рис. 3 сети через соседний компьютер, а на том включим NAT так, чтобы заменять в таком маршруте адрес отправителя на собственный. Окончательно должно получиться так:
traceroute to 192.168.11.2 (192.168.11.2), 30 hops max, 40 byte packets
1 192.168.10.2 0.000 ms 0.000 ms 0.000 ms
2 192.168.10.1 0.566 ms 0.086 ms 0.088 ms
3 192.168.11.2 0.145 ms 0.170 ms 0.241 ms
Поскольку главный вопрос заключается в изучении поведения инкапсулированного трафика, то в тестовой сети настроим также и туннель. Воспользуемся программным обеспечением, которое позволит поднять туннель, как на основе UDP-транспорта, так и TCP. По этой причине CIPE [6] не подходит. Выберем OpenVPN [7]. Тем более что согласно сравнительной таблице [8] этот проект рекордсмен в разделе Popularity. Туннельная сеть образует виртуальное соединение между wsalekseybb и wskostja, определенное как сеть 192.168.12.0/24. Для станции wsalekseybb настройки OpenVPN в режиме клиента TCP-туннеля будут производиться согласно следующему файлу конфигурации:
ifconfig 192.168.12.1 192.168.12.2
route 192.168.12.0 255.255.255.0 192.168.12.1
Для станции wskostja все аналогично, меняются лишь адреса, протокол на tcp-server и удаляется строка remote, что переводит туннель в состояние прослушивания. В режиме UDP на обоих концах протокол просто переключается в udp и удаляется параметр tcp-queue-limit. И теперь путь между wstovert до wskostja проходит через туннель.
traceroute to 192.168.12.2 (192.168.12.2), 30 hops max, 40 byte packets
1 192.168.10.2 0.000 ms 0.000 ms 0.000 ms
2 192.168.12.2 7.088 ms 5.756 ms 0.787 ms
Чтобы доказать, что сам туннель проходит через server, проверим путь до удаленного конца туннеля от wsalekseybb:
traceroute to 192.168.11.2 (192.168.11.2), 30 hops max, 40 byte packets
1 192.168.10.1 0.195 ms 0.106 ms 0.120 ms
2 192.168.11.2 0.233 ms 0.000 ms 0.000 ms
Таким образом, можно, отправляя трафик со станции wstovert до станции wskostja, осуществлять на промежуточном хосте server нужные манипуляции в соответствии с исследуемой моделью канала.
На wstovert подготовим файл с данными, которые будут посылаться в тестовых сеансах:
# ssh tovert@wstovert «dd if=/dev/urandom of=
/100M.bin bs=1024 count=102400″
Симуляцию TCP-трафика будем создавать с помощью команды, отправляющей 100 Мб из файла на целевой хост. В качестве слушателя TCP используем sshd, который перешлет все принятые данные в /dev/null, чтобы не помешала буферизация. Причем для сокращения затрат на загрузку файла с диска каждую тестовую отправку будем предварять локальным копированием в /dev/null:
Так что фильтр будет направлять в шейпер только трафик, помеченный маркером 10 (0xa). Весь непомеченный трафик будет проходить в обход шейпера, так как в HTB не указан поток по умолчанию. Метиться будут лишь пакеты, направляемые на виртуальный адрес wskostja:
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
Последняя деталь – эмулятор помех. По логике, если шейпер на исходящем интерфейсе хоста server имитирует сужение канала, то участок с потерями должен находиться за ним.
И у нас не остается иного места, где можно внести (или точнее изъять) потери в трафик, кроме входного интерфейса wskostja:
Chain INPUT (policy ACCEPT)
target prot opt source destination
Тут проницательный читатель заметит, что недостает еще эмулятора помех для обратного трафика. Но какой может быть обратный трафик у UDP? И внося еще помехи для пакетов, движущихся в обратную сторону, мы явно ухудшаем характеристики всех TCP-соединений, которые принципиально всегда интерактивны, в отличие от UDP. Скажите несправедливо? Ну и пусть! Нам нечего бояться. Сделаем так:
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Чуть выше уже было замечено, что это очень грубая имитация линии с потерями. Дело в том, что потери являются функцией линии передачи, а не числа переданных пакетов, как в нашем случае. Но даже такая модель позволит понять, что же происходит с трафиком в ненадежных сетях.
Теперь все окружение построено. Договоримся о точках, где будут сниматься данные. В условиях эксперимента будет тип трафика, тип туннеля, объем отправленных с wstovert данных. Скорость передачи нам сообщит команда dd на wstovert. Объем данных, поступивших в туннель, и число уничтоженных на входе пакетов узнаем через ifconfig tun0 на wsalekseybb. Статистика шейпера на server покажет, сколько данных и пакетов прошло через ограничитель трафика, сколько пакетов было уничтожено. На счетчиках iptables на wskostja узнаем, сколько данных добралось до назначения и сколько было уничтожено как имитация потерь в линии связи. И для UDP после отключения слушателя netcat получим объем реально полученных данных, подсчитанный командой wc.
С примерами некоторых скриптов, использованных для настроек, можно ознакомиться в архиве [9].
Передача TCP в туннелях
Сначала проверим самую главную версию, что трафик TCP внутри TCP-туннеля якобы плохо передается, а вот внутри туннеля UDP напротив очень хорошо. Для этого поднимем туннель OpenVPN сначала в режиме TCP, затем в режиме UDP, и в каждом состоянии проведем тестовую пересылку без потерь, с потерями 10% и с двухсторонними потерями. Полученные числа соберем в таблицу. К сожалению, так как используется высокоскоростная сеть, тестовый файл невелик, а время не позволяет делать сотни прогонов и затем производить сглаживание результатов, то в таблицу 1 будут занесены наиболее показательные данные из 23 прогонов на каждом условии и дополнительно указан возможный разброс.
Продвинутое туннелирование: атакуем внутренние узлы корпоративной сети
В этой статье будут рассмотрены сценарии атаки защищенных сегментов корпоративной сети с помощью 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.
Заключение
Атакующий обнаружил две скрытые сети в результате следующих шагов:
Таким образом, атакующий, имея доступ лишь к одной сети, через серию атак, сумел скомпрометировать хост, находящийся далеко в глубине корпоративной сети за защищенным сетевым периметром.
TCP поверх TCP – не такая уж плохая идея!
TCP поверх TCP – не такая уж плохая идея!
АЛЕКСЕЙ БАРАБАНОВ
