В современных сетях с виртуализацией и автоматизацией широкое применение получило туннелирование трафика. Однако, туннелирование ориентировано на построение сети и обеспечение надежной передачи данных, а вопросы информационной безопасности и мониторинга обычно остаются «за скобками». Проблема невидимости туннелированного трафика для систем информационной безопасности – давно известная проблема – уже в 2011 году было опубликовано RFC 6169 «Security Concerns with IP Tunneling», указывающее на потенциальные риски применения туннелей. Непосредственно средства DPI не отстают от инфраструктуры и уже давно разбирают туннели и смотрят пользовательский трафик (когда это в целом технически возможно), однако, остается узкое место – передача данных из инфраструктуры на эти системы.

Туннелирование и передача трафика в системы мониторинга и информационной безопасности

GTP, GRE, L2TP, PPPoE, VXLAN и другие аббревиатуры туннелей знакомы любому сетевому инженеру. Туннелирование трафика позволяет:

• Обеспечить управление потоками данных за счёт построения сети на 3 уровне модели OSI
• Связывать удаленные офисы в единую сеть с общими ресурсами
• Упрощать администрирование сети за счёт разделения на уровень инфраструктуры и уровень пользователей
• Строить единые сети на базе различных технологий
• Обеспечивать мобильность пользователей (мобильные сети, миграция виртуальных машин в дата-центрах)

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

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

1. Пакеты дублируются посредством дополнительных функций сетевого оборудования и отправляются в выделенные (SPAN) порты
2. В оптическую линию устанавливаются пассивные ответвители трафика (TAP), разделяющие оптическую мощность на две линии – изначальному получателю и в систему DPI
3. В инфраструктуру добавляется брокер сетевых пакетов, выполняющий функцию зеркалирвания пакетов, как и в случае с TAP – изначальному получателю и в систему DPI

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

Чаще всего применяется комбинация из пассивных оптических ответвителей и брокеров сетевых пакетов.



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

Фильтрация и классификация туннелированного трафика

Без возможности анализа брокером сетевых пакетов вложенных заголовков туннелированных пакетов бессмысленно говорить об оптимизации средств DPI. Фильтрация и классификация, позволяющие снизить нагрузку на системы DPI и уменьшить их количество, должны работать именно по полям пользовательского трафика (вложенных заголовков). Иначе отделить IP-адреса конкретных пользователей, требуемые протоколы или шифрованный трафик невозможно – по внешним полям это будет просто туннель. Попытка очистить трафик на системы DPI от нецелевого по внешним полям только создаст «дыру в безопасности» — целевой трафик «проскользнет мимо» информационной безопасности и мониторинга в туннеле.



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

Балансировка туннелированного трафика

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



Возьмём 2 сессии (AB-ВА и CD-DC) и передадим их через туннелированные каналы T1, T2 и T3. Допустим, речь идёт об абонентах мобильного оператора, гуляющих между базовыми станциями. Пакеты этих сессий окажутся в разных туннелях и при попадании туннелированного трафика на брокер сетевых пакетов есть 2 варианта их балансировки с сохранением целостности сессий:

1. Балансировка по внешним заголовкам. Фактически брокер сетевых пакетов при этом разделит разные туннели между системами DPI: Т1 и Т3 в DPI 1, а Т2 в DPI 2. При этом пакеты запросов (AB) информационного потока AB-BA, инкапсулированные в туннели Т1 и Т2 для обеспечения мобильности абонента, оказываются в разных системах DPI, а пакеты ответов (BA) в туннелях Т2 и Т3, соответственно, попадут в DPI 1 и DPI 2. Аналогичная ситуация произойдет и с информационным потоком CD-DC. Большинство систем DPI для корректной работы требуют все данные информационного обмена. Декапсулируя трафик, каждая из систем DPI увидит «обрывки» информационного обмена, посчитает его не требующим обработки (как несостоявшегося) или обработает некорректно. Данная балансировка может быть интересна для мониторинга состояния отдельных участков инфраструктуры (когда в систему анализа на самом деле должны прийти именно все пакеты заданного туннеля), но для этого обычно используется фильтрация.
2. Балансировка по вложенным заголовкам. Брокер сетевых пакетов для балансировки игнорирует внешние заголовки и распределяет пакеты между системами DPI с сохранением целостности сессий AB-BA и CD-DC. При этом для мониторинга состояния отдельных участков инфраструктуры можно настроить фильтрацию по внешним заголовкам. Таким образом каждое средство DPI получит цельный поток информационного обмена пользователей, а средства мониторинга – все пакеты заданного туннеля.

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



То есть, если сессии AB и CD по 10 Гбит/с каждая инкапсулированы в туннель T1, то получается 20 Гбит/с трафика (которые могут передаваться по интерфейсу 40GbE/100GbE или через агрегированные каналы LAG 10GbE). После копирования и попадания данного потока в брокер сетевых пакетов возникает необходимость разбалансировать этот трафик на несколько систем DPI по интерфейсам 10 GbE. Сделать это с сохранением целостности сессий используя внешние заголовки невозможно – поток превысит пропускную способность выходного интерфейса и пакеты начнут теряться.

Балансировка по вложенным заголовкам обеспечивает возможность разделить поток на более мелкие без ущерба для целостности информационного обмена и качества работы систем DPI.

Балансировка фрагментированного туннелированного трафика

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


Когда на вход туннелирующего устройства приходит пакет с размером равным MTU, то после добавления туннельных заголовков пакет начинает MTU превышать (на количество байт туннельного заголовка) и делится на фрагменты. Причём вложенный заголовок содержится только в первом фрагменте. В результате два пакета одной сессии (AB1 и AB2), попавшие в разные туннели (T1 с заголовком XY и T2 с заголовком XZ) превращаются в четыре пакета:

• с внешним заголовком XY и вложенным заголовком AB
• с внешним заголовком XY без признаков туннелирования
• с внешним заголовком XZ и вложенным заголовком AB
• с внешним заголовком XZ без признаков туннелирования

В данном случае без функции отслеживания фрагментов выбор будет между нарушением целостности информационного потока из-за распределения разных туннелей между разными системами DPI и нарушением целостности информационного потока из-за распределения разных фрагментов между разными системами DPI. Отслеживание фрагментов с балансировкой по вложенным заголовкам обеспечивает сохранение целостности даже в таких случаях.

Столкнувшиеся с указанными проблемами в большой части трафика понимают их и решают. Как обычно хуже всего, когда проблема касается менее 10% трафика – она может быть незаметна и создается иллюзия, что всё в безопасности. А под безопасностью – туннель.