Туннелирование (компьютерные сети)

Туннелирование — это метод передачи данных между компьютерными сетями, осуществляемый с помощью специальных сетевых протоколов туннелирования. Такой протокол позволяет, например, организовать пересылку приватных данных по публичной сети (например, через Интернет), или использовать один сетевой протокол поверх несовместимой инфраструктуры, что достигается посредством инкапсуляции.

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

Протоколы туннелирования работают, используя полезную нагрузку (полезная нагрузка) обычного сетевого пакета для передачи дополнительной информации другого протокола. При этом, несмотря на опору на эшелонированные модели взаимодействия, такие как OSI или стек TCP/IP, туннелирование нарушает принцип строгого разделения уровней, позволяя передавать сервисы, не предусмотренные базовой сетью. Обычно протокол доставки сети действует на том же или более высоком эшелоне, чем протокол, чьи данные инкапсулируются.

Применение

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

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

Обход политик межсетевого экрана[править | править код]

Туннелирование может использоваться для обхода политик межсетевых экранов, когда запрещённый для передачи протокол «упаковывается» в разрешённый, например, HTTP. Если политика брандмауэра прямо не исключает такой вариант «обёртки», обход блокируемого трафика становится возможным.

Другой вариант — применение команды HTTP CONNECT: клиент отправляет соответствующий запрос на прокси-сервер, после чего тот устанавливает TCP-соединение с целевым узлом и перенаправляет весь передаваемый трафик между ними^[1]. Из соображений безопасности прокси часто ограничивают применение CONNECT только портом 443 (HTTPS)^[2].

Существуют способы обхода межсетевых экранов и другими протоколами, такими как DNS^[3], MQTT^[4], SMS^[5].

Технические особенности

Пример применения протокола сетевого уровня: Generic Routing Encapsulation (GRE, протокол IP №47) предназначен для передачи пакетов IP (в том числе с приватными адресами из RFC 1918) через Интернет, инкапсулируя их в пакеты с публичными адресами. При этом протокол доставки и полезной нагрузки совпадают, но адресация между ними различается и несовместима.

Также возможно создание туннеля на уровне канального слоя. Layer 2 Tunneling Protocol (L2TP) позволяет передавать кадры между двумя узлами. По умолчанию туннель не шифруется: уровень защищённости определяется выбранным сетевым протоколом из стека TCP/IP.

Безопасная оболочка использует порт 22 для шифрования передаваемых данных по публичной сети, что реализует функционал VPN. Протокол IPsec реализует сквозной режим передачи (Transport Mode), а также может работать в режиме туннелирования через доверенный шлюз.

Для анализа протокольного стека, формируемого в процессе туннелирования, специалисту важно разбираться как в протоколе нагрузки, так и в протоколе доставки.

Распространённые протоколы туннелирования

IP in IP (IP-протокол 4): IP поверх IPv4/IPv6
SIT/IPv6 (IP-протокол 41): IPv6 поверх IPv4/IPv6
GRE (IP-протокол 47): общая маршрутизирующая инкапсуляция
OpenVPN (UDP-порт 1194)
SSTP (TCP-порт 443): протокол туннелирования через защищённые сокеты
IPSec (IP-протоколы 50 и 51): защита протокола Интернет
L2TP (UDP-порт 1701): протокол туннелирования второго уровня
L2TPv3 (IP-протокол 115): версия 3 протокола L2TP
VXLAN (UDP-порт 4789): расширяемая виртуальная локальная сеть
PPTP (TCP-порт 1723 для управления, GRE для данных): протокол туннелирования точка-точка
PPPoE (EtherType 0x8863 для управления, 0x8864 для данных): PPP поверх Ethernet
GENEVE
WireGuard (UDP-динамический порт)

Проблема «TCP meltdown»

Туннелирование полезной нагрузки, реализованной с помощью TCP, через другое TCP-соединение (например, PPP по TCP с применением SSH-переадресации портов), называется TCP-over-TCP и ведёт к значительной деградации производительности передачи — данное явление известно как проблема TCP meltdown^[6]^[7]. Поэтому программное обеспечение VPN часто использует более простой, нежели TCP, протокол для туннельного соединения. Проблема возникает, когда одно TCP-соединение вложено в другое: нижний уровень обнаруживает неполадку и пытается компенсировать её, а вышестоящий уровень предпринимает дополнительные действия по компенсации, что приводит к задержкам и снижению производительности.

Туннелирование через SSH

SSH-туннель представляет собой зашифрованный канал, устанавливаемый по протоколу SSH (Secure Shell). Такой туннель применяется для пересылки незашифрованного трафика через защищённый канал и обеспечивает программно реализуемое средство сетевой защиты с обеспечением прозрачности шифрования^[8].

Например, протокол SMB позволяет обмениваться файлами на платформе Microsoft Windows без шифрования. Если подключиться к файловой системе Windows через Интернет, трафик можно перехватить. Для защищённого доступа создаётся SSH-туннель, через который весь SMB-трафик передаётся по зашифрованному каналу; несмотря на отсутствие встроенного шифрования в SMB, безопасность трафика обеспечивается SSH.

Локальное перенаправление порта с помощью SSH

Удалённое перенаправление порта с помощью SSH

SSH может прослушивать порт на удалённом или локальном хосте; любое подключение к нему перенаправляется на указанный адрес и порт противоположной стороны (локального или удалённого хоста).

Проблема TCP meltdown часто неактуальна для переадресации портов в OpenSSH, поскольку большинство сценариев не используются для вложенного TCP-over-TCP: клиент OpenSSH обрабатывает локальное TCP-соединение, извлекает из него полезную нагрузку и передаёт её по основному подключению туннеля, где сервер OpenSSH обрабатывает пакет аналогичным образом и направляет его к точке назначения^[9]. Обработка происходит в обратном направлении аналогичным образом.

Создание SSH-туннелей позволяет обходить межсетевые экраны, запрещающие определённые виды Интернет-сервисов, если разрешены исходящие соединения. Например, организация может блокировать доступ к сайтам напрямую (порт 80), принуждая использовать прокси, но при наличии внешнего SSH-сервера пользователь может через туннель перенаправлять трафик своего браузера локально на порт, который далее транслируется на порт 80 веб-сервера в Интернете (через localhost).

В ряде SSH-клиентов поддерживается динамическое перенаправление портов через создание локального прокси SOCKS 4/5. Тогда пользователь указывает этот прокси в настройках приложений, что обеспечивает большую гибкость, нежели туннелирование одного порта. Если приложение не поддерживает SOCKS, можно использовать проксификатор, некоторые из которых (например, Proxycap) обладают встроенной поддержкой SSH.

В новых версиях OpenSSH возможна организация туннелей 2 или 3 уровня, если такая поддержка включена на обеих сторонах. В результате создаются виртуальные интерфейсы tun (третий уровень, по умолчанию) или tap (второй уровень) на обеих точках. Это позволяет обычными средствами маршрутизации и управления направлять через туннель весь трафик подсети; интерфейсы tap эмулируют прямое сетевое соединение по Ethernet.

Кибератаки на основе туннелирования

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

В рамках таких атак применяются протоколы HTTP^[10], SSH^[11], DNS^[3],^[12] MQTT^[4].

Примечания

↑ Upgrading to TLS Within HTTP/1.1 (англ.). RFC 2817 (2000). Дата обращения: 11 июня 2024.
↑ Vulnerability Note VU#150227: HTTP proxy default configurations allow arbitrary TCP connections (англ.). CERT Coordination Center. US-CERT (17 мая 2002). Дата обращения: 11 июня 2024.
↑ ¹ ² Raman, D., Sutter, B. D., Coppens, B., Volckaert, S., Bosschere, K. D., Danhieux, P., & Buggenhout, E. V. DNS tunneling for network penetration. International Conference on Information Security and Cryptology (2012), 65–77.
↑ ¹ ² Vaccari, I., Narteni, S., Aiello, M., Mongelli, M., & Cambiaso, E. Exploiting Internet of Things Protocols for Malicious Data Exfiltration Activities. IEEE Access, 9, 104261–104280 (2021).
↑ Narteni, S., Vaccari, I., Mongelli, M., Aiello, M., & Cambiaso, E. Evaluating the possibility to perpetrate tunnelling attacks exploiting shortmessage-service. Journal of Internet Services and Information Security, 11, 30–46 (2021).
↑ Titz, Olaf Why TCP Over TCP Is A Bad Idea (англ.) (23 апреля 2001). Дата обращения: 3 января 2023. Архивировано 3 января 2022 года.
↑ Honda, Osamu; Ohsaki, Hiroyuki; Imase, Makoto; Ishizuka, Mika; Murayama, Junichi (октябрь 2005). “Understanding TCP over TCP: effects of TCP tunneling on end-to-end throughput and latency”. Performance, Quality of Service, and Control of Next-Generation Communication and Sensor Networks III [англ.]. 6011. DOI:10.1117/12.630496. Проверьте дату в |date= (справка на английском)
↑ Barrett, Daniel J. SSH, the Secure Shell: The Definitive Guide : [англ.]. — O'Reilly Media, Inc., 2001. — ISBN 978-0-596-00011-0.
↑ Kaminsky, Dan Re: Extensions for long fat networks? (англ.). openssh-unix-dev@mindrot.org (13 июня 2003). Дата обращения: 11 июня 2024.
↑ Pack, D. J.; Streilein, W.; Webster, S.; Cunningham, R. Detecting HTTP tunneling activities (англ.). Massachusetts Institute of Technology Lexington Lincoln Lab (2002). Дата обращения: 11 июня 2024.
↑ Dang, F.; Li, Z.; Liu, Y.; Zhai, E.; Chen, Q. A.; Xu, T.; ... & Yang, J. (июнь 2019). “Understanding fileless attacks on linux-based iot devices with honeycloud”. Proceedings of the 17th Annual International Conference on Mobile Systems, Applications, and Services [англ.]. pp. 482—493. Проверьте дату в |date= (справка на английском)
↑ Aiello, M.; Mongelli, M.; Cambiaso, E.; Papaleo, G. (2016). “Profiling DNS tunneling attacks with PCA and mutual information”. Logic Journal of the IGPL [англ.]. 24 (6): 957—970.

Литература

Raman, D., Sutter, B. D., Coppens, B., Volckaert, S., Bosschere, K. D., Danhieux, P., & Buggenhout, E. V. DNS tunneling for network penetration. In International Conference on Information Security and Cryptology (pp. 65-77). Springer, Berlin, Heidelberg, 2012.
Vaccari, I., Narteni, S., Aiello, M., Mongelli, M., & Cambiaso, E. Exploiting Internet of Things Protocols for Malicious Data Exfiltration Activities. IEEE Access, 9, 104261-104280, 2021.
Narteni, S., Vaccari, I., Mongelli, M., Aiello, M., & Cambiaso, E. Evaluating the possibility to perpetrate tunnelling attacks exploiting shortmessage-service. Journal of Internet Services and Information Security, 11, 30-46, 2021.
Barrett, Daniel J. SSH, the Secure Shell: The Definitive Guide. O'Reilly Media, Inc., 2001. ISBN 978-0-596-00011-0.

Ссылки

[1] Upgrading to TLS Within HTTP/1.1 (англ.). RFC 2817 (2000). Дата обращения: 11 июня 2024.

[2] Vulnerability Note VU#150227: HTTP proxy default configurations allow arbitrary TCP connections (англ.). CERT Coordination Center. US-CERT (17 мая 2002). Дата обращения: 11 июня 2024.

[tunneling_dns-3] ¹ ² Raman, D., Sutter, B. D., Coppens, B., Volckaert, S., Bosschere, K. D., Danhieux, P., & Buggenhout, E. V. DNS tunneling for network penetration. International Conference on Information Security and Cryptology (2012), 65–77.

[tunneling_mqtt-4] ¹ ² Vaccari, I., Narteni, S., Aiello, M., Mongelli, M., & Cambiaso, E. Exploiting Internet of Things Protocols for Malicious Data Exfiltration Activities. IEEE Access, 9, 104261–104280 (2021).

[tunneling_sms-5] Narteni, S., Vaccari, I., Mongelli, M., Aiello, M., & Cambiaso, E. Evaluating the possibility to perpetrate tunnelling attacks exploiting shortmessage-service. Journal of Internet Services and Information Security, 11, 30–46 (2021).

[6] Titz, Olaf Why TCP Over TCP Is A Bad Idea (англ.) (23 апреля 2001). Дата обращения: 3 января 2023. Архивировано 3 января 2022 года.

[7] Honda, Osamu; Ohsaki, Hiroyuki; Imase, Makoto; Ishizuka, Mika; Murayama, Junichi (октябрь 2005). “Understanding TCP over TCP: effects of TCP tunneling on end-to-end throughput and latency”. Performance, Quality of Service, and Control of Next-Generation Communication and Sensor Networks III [англ.]. 6011. DOI:10.1117/12.630496. Проверьте дату в |date= (справка на английском)

[8] Barrett, Daniel J. SSH, the Secure Shell: The Definitive Guide : [англ.]. — O'Reilly Media, Inc., 2001. — ISBN 978-0-596-00011-0.

[9] Kaminsky, Dan Re: Extensions for long fat networks? (англ.). openssh-unix-dev@mindrot.org (13 июня 2003). Дата обращения: 11 июня 2024.

[10] Pack, D. J.; Streilein, W.; Webster, S.; Cunningham, R. Detecting HTTP tunneling activities (англ.). Massachusetts Institute of Technology Lexington Lincoln Lab (2002). Дата обращения: 11 июня 2024.

[11] Dang, F.; Li, Z.; Liu, Y.; Zhai, E.; Chen, Q. A.; Xu, T.; ... & Yang, J. (июнь 2019). “Understanding fileless attacks on linux-based iot devices with honeycloud”. Proceedings of the 17th Annual International Conference on Mobile Systems, Applications, and Services [англ.]. pp. 482—493. Проверьте дату в |date= (справка на английском)

[12] Aiello, M.; Mongelli, M.; Cambiaso, E.; Papaleo, G. (2016). “Profiling DNS tunneling attacks with PCA and mutual information”. Logic Journal of the IGPL [англ.]. 24 (6): 957—970.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]