stringtranslate.com

Протокол туннелирования

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

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

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

Использует

Например, протокол туннелирования может разрешить работу стороннего протокола в сети, которая не поддерживает этот конкретный протокол, например, запуск IPv6 поверх IPv4 .

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

Обход политики брандмауэра

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

Другой метод туннелирования на основе HTTP использует метод/команду HTTP CONNECT . Клиент отправляет команду HTTP CONNECT HTTP-прокси. Затем прокси устанавливает TCP-соединение с определенным сервером:портом и передает данные между этим сервером:портом и клиентским соединением. [1] Поскольку это создает брешь в безопасности, HTTP-прокси с поддержкой CONNECT обычно ограничивают доступ к методу CONNECT. Прокси-сервер разрешает соединения только с определенными портами, например, 443 для HTTPS. [2]

Другие методы туннелирования, способные обойти сетевые брандмауэры, используют различные протоколы, такие как DNS , [3] MQTT , [4] SMS . [5]

Технический обзор

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

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

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

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

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

Проблема сбоя TCP

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

Безопасное туннелирование Shell

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

Например, машины Microsoft Windows могут обмениваться файлами, используя протокол Server Message Block (SMB), не зашифрованный протокол. Если бы кто-то смонтировал файловую систему Microsoft Windows удаленно через Интернет, кто-то, следящий за соединением, мог бы увидеть переданные файлы. Чтобы безопасно смонтировать файловую систему Windows, можно установить туннель SSH, который направляет весь трафик SMB на удаленный файловый сервер через зашифрованный канал. Несмотря на то, что сам протокол SMB не содержит шифрования, зашифрованный канал SSH, по которому он передается, обеспечивает безопасность.

Локальная и удаленная переадресация портов с помощью ssh, выполненная на синем компьютере.

После установки SSH-соединения туннель начинается с прослушивания SSH-порта на  удаленный или локальный хост. Любые соединения с ним перенаправляются на указанный  адрес и порт, исходящие из  противостоящий (удалённый или локальный, как ранее) хост.

Проблема #TCP meltdown часто не является проблемой при использовании переадресации портов OpenSSH, поскольку многие варианты использования не подразумевают туннелирование TCP-over-TCP; расплавления удается избежать, поскольку клиент OpenSSH обрабатывает локальное TCP-соединение на стороне клиента, чтобы добраться до фактической отправляемой полезной нагрузки, а затем отправляет эту полезную нагрузку напрямую через собственное TCP-соединение туннеля на сторону сервера, где сервер OpenSSH аналогичным образом «разворачивает» полезную нагрузку, чтобы «упаковать» ее снова для маршрутизации к конечному пункту назначения. [9] Естественно, эта упаковка и распаковка также происходят в обратном направлении двунаправленного туннеля.

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

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

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

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

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

В этом контексте известные туннели включают такие протоколы, как HTTP , [10] SSH , [11] DNS , [12] [13] MQTT . [14]

Смотрите также

Ссылки

  1. ^ "Обновление до TLS в HTTP/1.1". RFC 2817 . 2000 . Получено 20 марта 2013 .
  2. ^ "Заметка об уязвимости VU#150227: конфигурации HTTP-прокси по умолчанию допускают произвольные TCP-подключения". US-CERT . 2002-05-17 . Получено 2007-05-10 .
  3. ^ Раман, Д., Саттер, Б.Д., Коппенс, Б., Волкарт, С., Босшер, К.Д., Данье, П., и Буггенхаут, Э.В. (2012, ноябрь). DNS-туннелирование для проникновения в сеть. На Международной конференции по информационной безопасности и криптологии (стр. 65-77). Шпрингер, Берлин, Гейдельберг.
  4. ^ Ваккари, И., Нартени, С., Айелло, М., Монджелли, М. и Камбиазо, Э. (2021). Использование протоколов Интернета вещей для вредоносной деятельности по извлечению данных. IEEE Access, 9, 104261-104280.
  5. ^ Narteni, S., Vaccari, I., Mongelli, M., Aiello, M., & Cambiaso, E. (2021). Оценка возможности совершения туннельных атак с использованием службы коротких сообщений. Журнал Internet Services and Information Security, 11, 30-46.
  6. ^ Тиц, Олаф (2001-04-23). ​​"Почему TCP поверх TCP — плохая идея". Архивировано из оригинала 2022-01-03 . Получено 2023-01-03 .
  7. ^ Хонда, Осаму; Охсаки, Хироюки; Имасе, Макото; Ишизука, Мика; Мураяма, Дзюнъити (октябрь 2005 г.). "Понимание TCP через TCP: влияние туннелирования TCP на сквозную пропускную способность и задержку". В Atiquzzaman, Mohammed; Баландин, Сергей I (ред.). Производительность, качество обслуживания и управление сетями связи и датчиков следующего поколения III . Том 6011. Bibcode : 2005SPIE.6011..138H. CiteSeerX 10.1.1.78.5815 . doi : 10.1117/12.630496. S2CID  8945952. 
  8. ^ Барретт, Дэниел Дж.; Барретт, Дэниел Дж.; Сильверман, Ричард Э.; Сильверман, Ричард (2001). SSH, Secure Shell: Полное руководство. "O'Reilly Media, Inc.". ISBN 978-0-596-00011-0.
  9. ^ Каминский, Дэн (2003-06-13). "Re: Расширения для длинных толстых сетей?". [email protected] (список рассылки). код пересылки TCP также довольно быстрый. Просто чтобы заранее ответить на вопрос, ssh декапсулирует и повторно инкапсулирует TCP, так что у вас нет классических проблем TCP-over-TCP.
  10. ^ Пак, DJ, Стрейлайн, W., Вебстер, S. и Каннингем, R. (2002). Обнаружение активности HTTP-туннелирования. MASSACHUSETTS INST OF TECH LEXINGTON LINCOLN LAB.
  11. ^ Dang, F., Li, Z., Liu, Y., Zhai, E., Chen, QA, Xu, T., ... и Yang, J. (2019, июнь). Понимание атак без файлов на устройства IoT на базе Linux с помощью honeycloud. В материалах 17-й ежегодной международной конференции по мобильным системам, приложениям и услугам (стр. 482–493).
  12. ^ Раман, Д., Саттер, Б.Д., Коппенс, Б., Волкарт, С., Босшер, К.Д., Данье, П., и Буггенхаут, Э.В. (2012, ноябрь). DNS-туннелирование для проникновения в сеть. На Международной конференции по информационной безопасности и криптологии (стр. 65-77). Шпрингер, Берлин, Гейдельберг.
  13. ^ Айелло, М., Монгелли, М., Камбьязо, Э. и Папалео, Г. (2016). Профилирование атак туннелирования DNS с помощью PCA и взаимной информации. Logic Journal of the IGPL, 24(6), 957-970.
  14. ^ Ваккари, И., Нартени, С., Айелло, М., Монджелли, М. и Камбиазо, Э. (2021). Использование протоколов Интернета вещей для вредоносной деятельности по извлечению данных. IEEE Access, 9, 104261-104280.

Внешние ссылки