NGFW: архитектура и необходимая функциональность

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

 

 

 

 

 

 

1. Введение
2. Функциональность, которой должен быть наделён NGFW
3. Специальное аппаратное обеспечение
4. Типовое ПО с открытым исходным кодом — MITM-прокси для SSL / TLS
5. Выводы

Введение

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

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

1. Возможность компрометации изделия на уровне аппаратного обеспечения.
1. Закладки на уровне прошивки.
2. Аппаратные закладки.
2. Возможность компрометации программного обеспечения (например, через уязвимости применяемого ПО с открытым исходным кодом).
3. Возможность компрометации сложных алгоритмов (например, шифрования) посредством «алгоритмических закладок». Такие закладки трудно или даже невозможно обнаружить, но легко использовать.
4. Использование передовых достижений технического прогресса злоумышленником (например, квантовые вычисления).
5. Высокая экономическая эффективность (либо размер нанесённого ущерба) атак на объекты КИИ и, как следствие, допустимость высоких затрат на их осуществление.
6. Ограниченность вариантов исполнения типовых по назначению продуктов, к которым относится и межсетевой экран (злоумышленник способен с достаточной точностью предугадать как общую архитектуру, так и реализацию решения).
7. Постоянная сетевая доступность реализованного решения (злоумышленник постоянно может проверять и подбирать методы проникновения, подстраиваться под реализацию).
8. Рост вычислительных возможностей аппаратного обеспечения и пропускной способности контролируемых сетей.

Пункт 8 подразумевает, что нужно учитывать возможность масштабирования ещё на этапе разработки архитектуры.

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

 

Рисунок 1. Уровни (эшелоны) обработки трафика

 

В самом простом варианте исполнения реализация может содержать два уровня (эшелона) обработки. На первом уровне трафик классифицируется и разделяется на сессии, а на втором выделенные сетевые сессии распределяются между узлами обработки. На уровне «LVL1» может также выполняться дополнительная предобработка трафика. 

Функциональность предварительной обработки может зависеть в том числе от способа реализации межсетевого экрана. Например, при использовании ПЛИС (программируемой логической интегральной схемы, FPGA) целесообразно реализовать на уровне первого эшелона возможность детектирования и блокировки нежелательного паразитного трафика (возможных утечек) со стороны программного обеспечения, в том числе стороннего. Целесообразность отсечения паразитного трафика на уровне аппаратно реализованной логики заключается в том, что аппаратная реализация — это наиболее устойчивое и доверенное звено с точки зрения возможной компрометации (в модели нарушителя без физического доступа к устройству). Актуальность последнего довода возрастает, если используется отечественная аппаратная база.

Детектирование паразитного трафика на уровне первого эшелона реализовать относительно просто, поскольку известны состав трафика, поступающего на сетевые интерфейсы («if1» и «if2»), и все изменения, которые вносит в него подсистема обработки («LVL2 processor»). При реализации NGFW по схеме прозрачного L2-моста (а не маршрутизатора) задача детектирования паразитного трафика с учётом легитимных изменений будет многократно упрощена.

Детектирование и блокировка паразитного трафика решают некоторые проблемы, перечисленные в начале раздела (пункты 1 и 2). Это не исключает компрометацию, но предотвращает возможность её эксплуатации — получения доступа к скомпрометированному аппаратному или программному обеспечению на уровне «LVL2». Аналогичным образом может быть устранена проблема нелегитимного изменения трафика в результате, например, использования алгоритмической закладки (пункт 3).

Помимо описанной выше функциональности (реализованной на ПЛИС) целесообразно перенести на уровень «LVL1» те задачи, алгоритм реализации которых легко адаптируется к исполнению на ПЛИС:

• сигнатурный анализ (поиск), например анализ сегмента кода исполняемых файлов в расшифрованном трафике;
• удаление заголовков «магистральных» протоколов (например, MPLS) для передачи на процессор только трафика IP (упрощает и унифицирует реализацию распределённых цепочек обработки трафика);
• удаление дубликатов (только для пакетов передаваемых на обработку в «LVL2»).

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

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

Функциональность, которой должен быть наделён NGFW

На рисунке 2 ниже показаны функциональные модули в составе программно-аппаратного комплекса (ПАК) NGFW. Здесь также условно отображены взаимодействие и зависимости модулей. Модули сгруппированы в соответствии с описанным ранее подходом к реализации с разделением по уровням обработки. На уровне 1 («LVL1») производится предварительная обработка трафика, а на уровне 2 (и выше) — основная.

 

Рисунок 2. Детализация уровней обработки трафика

 

Далее приводим описание составных частей каждого уровня.

1. Подсистема контроля

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

На уровне «LVL1» она должна выявлять паразитный трафик, источник которого — ПО на уровне «LVL2». К такому трафику должен быть отнесён любой исходящий с рабочих интерфейсов поток данных (сетевой пакет), наличие которого не может быть причиной штатной работы комплекса, в том числе по модификации поступающего трафика. 

Функционально эта подсистема на уровне «LVL1» представлена модулем «SS-agent», работа которого зависит от модулей анализа и обработки трафика («TLS proxy», «DPI», «MTP (media traffic processor)»). Взаимодействие с этими модулями необходимо для регистрации штатных изменений трафика на уровне подсистемы обработки и для передачи их на уровень подсистемы контроля. Все остальные изменения (так же как и потоки данных, не зарегистрированные в качестве входящих на рабочих интерфейсах) будут отнесены к паразитному трафику, который окажется заблокирован. 

К штатным модификациям трафика можно отнести новые сессии TLS / SSL на уровне соответствующих подсистем обработки («ssl-proxy»), а также изменения реквизитов трафика (например, контрольных сумм сетевых пакетов). Их могут вносить модули «TLS proxy», «DPI», «MTP» в процессе проксирования и очистки трафика. Входящий трафик, который не подвергается очистке и проксированию на уровне NGFW, не должен отличаться от исходящего (либо все отличия должны быть прогнозируемы).

В задачи подсистемы контроля на уровне глубокой обработки трафика («LVL2») входит контроль целостности исполняемых программных модулей (на носителе), процесса загрузки ОС и кода исполняемых программных модулей. Из перечисленных типов контроля только первые два уже получили распространение у производителей ПАК в сфере ИБ. 

Динамический контроль целостности исполняемых процессов может быть реализован в составе ПАК NGFW на уровне ядра ОС в качестве отдельного программного модуля либо на уровне аппаратного обеспечения, например с помощью предоставления доступа на чтение к оперативной памяти (и файлу подкачки, при наличии такового) доверенному аппаратному обеспечению. Это необходимо, так как надо помнить о рисках связанных с возможностью компрометации ПО и сложных алгоритмов с помощью «алгоритмических закладок» (2-й и 3-й факторы из самого начала статьи). Минимальная реализация такого модуля предполагает контроль целостности сегментов кода исполняемых процессов.

2. Подсистема глубокого анализа трафика

2.1. Подсистема анализа трафика TLS / SSL

Подсистема анализа трафика на уровне TLS / SSL предполагает реализацию (см. п. 4) в составе NGFW прокси-сервера TLS / SSL («terminator proxy»), который производит расшифровку проксируемого трафика и его последующий анализ. Расшифровка должна производиться на сертификате, который с согласия заказчика устанавливается на рабочих станциях контролируемой (защищаемой) сети. Такое решение широко используется в подобных NGFW по функциональности продуктах, но в зависимости от сферы применения его возможности могут сильно различаться. Обычно в качестве основы используются открытые программные реализации в их базовой функциональности, которая не предполагает обработки инкапсулируемого трафика (трафика второго уровня) — QUIC, HTTP-2(3). Это сильно снижает эффективность контроля в целом. Полноценная реализация NGFW должна не только включать в себя обработку перечисленных видов трафика, но и архитектурно быть рассчитанной на расширение списка инкапсулируемых протоколов.

В состав подсистемы анализа TLS / SSL также должны быть опционально (в зависимости от конфигурации и настроечных параметров) включены:

• предотвращение работы на ненадёжных сертификатах (отозванных, «самоподписанных» и т. д.);
• предотвращение работы на ненадёжных наборах шифров (cipher suite);
• детектирование различных распространённых видов атак на SSL / TLS (например, «TLS downgrading»), которые возможны при устаревшем ПО на рабочих станциях контролируемой подсети.

2.2. Подсистема DPI

Базовые (распространённые / открытые) реализации глубокой инспекции пакетов (DPI) подразумевают детектирование трафика определённого протокола по набору статических критериев и ограниченный набор действий: блокировку либо допуск выделенного трафика в контролируемую сеть. Актуальная реализация подсистемы DPI должна предусматривать расширенный набор методов детектирования трафика, критического для защищаемой инфраструктуры. Также требуется расширить возможности подсистемы по обработке выделенного трафика.

Расширение методики детектирования подразумевает не только удлинение списка протоколов, которые позволяет выделить из общего трафика подсистема фильтров DPI. С точки зрения подсистемы интерес должен представлять абсолютно весь трафик, классификацию которого выполнить не удалось, либо трафик, который корректно отнесён к какой-то конкретной группе на основании статических критериев (порт протокола, «магическое число» (protocol magic number) и т. д.), но обладает при этом существенными отличиями по другим критериям. Оба случая подпадают под понятие «аномалии», которым обозначается подобный трафик, когда мы применяем методы математической статистики для классификации потоков данных. 

Аномалии могут быть выделены для их дальнейшего исследования с помощью внедрения методов машинного обучения. Такая методика позволит легко выделить в трафике аномалии и в полуавтоматическом (с привлечением оператора) режиме классифицировать их на опасные и допустимые. Классический пример аномалии в трафике — атака «Christmas tree», детектирование которой при применении методов машинного обучения не потребовало бы каких-либо предварительных настроек подсистемы анализа. Единственный простой критерий, которым бы руководствовалась подсистема DPI на основе машинного обучения, — «таких пакетов с таким набором параметров не было никогда ранее».

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

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

2.3. Подсистема антивирусной защиты

Подсистема антивирусной защиты может быть выполнена на основе какого-либо заимствованного продукта без изменений, но с дополнениями по части способа обработки трафика. Как отмечалось выше, предобработку на уровне «LVL1» целесообразно выполнять на аппаратно реализованной логике с применением ПЛИС. В таком случае часть функциональности подсистемы антивирусной защиты на уровне анализа трафика можно перенести на уровень «LVL1», поскольку задачи сигнатурного поиска (базовый подход к обнаружению вирусной активности) легко конвейеризируются и реализовываются на уровне ПЛИС, снижая нагрузку на ЦП и ускоряя анализ одновременно. Подсистема антивирусной защиты должна присутствовать также на уровне «LVL2» в виде модуля «отведения» трафика (подпадающего под критерии необходимости дополнительного, сигнатурного анализа) на уровень «LVL1». На рисунке 2 выше обозначена зависимость этой подсистемы от модулей DPI и анализа трафика на уровне TLS / SSL. Именно полученный от этих подсистем трафик и предполагается дополнительно проверять на уровне модуля антивирусной защиты. Сигнатурный анализатор целесообразно выделить в особую подсистему (TSP) на уровне «LVL1» в реализации на ПЛИС.

2.4. Подсистема очистки трафика

Подсистема очистки трафика («TF»), являющаяся надстройкой над модулем выделения и обработки медиапотоков («MTP»), предназначена для очистки контролируемого исходящего трафика от «вторичной» информации, которой не должно там быть. Та может присутствовать, например, в составе аудио- и видеоданных. Естественно, блокировать весь трафик с нежелательной «вторичной» информацией нецелесообразно и неоптимально, так как определённую её часть можно исключить. Примеры нежелательной вторичной информации — автомобильные госномера, зафиксированные камерами наблюдения, публичные информационные сообщения (объявления), попавшие в голосовой трафик, и т. п.

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

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

3. Подсистема предварительной обработки трафика

Модуль этой подсистемы реализовывается на уровне «LVL1» и предназначен для:

1. конвертации магистральных протоколов передачи данных (например, MPLS) в трафик IPv4 / IPv6 для упрощения дальнейшей обработки;
2. проверки контрольных сумм заголовков протоколов, контроля целостности пакетов и исключения из трафика тех из них, чья структура не соответствует требованиям инкапсуляции (вредоносные пакеты);
3. дефрагментации трафика определённых протоколов;
4. предварительной фильтрации трафика;
5. предварительной служебной маршрутизации трафика между нодами обработки (интеллектуальный обход).

Пункт 2 предусматривает исключение из трафика тех пакетов, которые могут вызвать программные ошибки на низком сетевом уровне обработки данных. Например, некорректно сформированные пакеты могут иметь корректные контрольные суммы, но ссылаться на данные за пределами пакета. Сетевой стек ОС, конечно, производит подобные проверки, но нативные модули обработки трафика могут располагаться ниже их уровня и не содержать их в своём составе.

Пункт 3 предусматривает возможность аккумулирования данных фрагментированных протоколов на уровне подсистемы с их последующей передачей на уровень обработки в составе агрегированных пакетов. К таким протоколам относится, например, RTP, который может передавать трафик пакетами по несколько десятков байт. Дефрагментация подобного трафика на уровне «LVL1» (который предполагается реализовать аппаратно) сильно сократит ресурсоёмкость подсистемы обработки трафика («LVL2») как минимум за счёт сокращения количества аппаратных прерываний, генерируемых сетевыми интерфейсами.

В соответствии с пунктом 4 можно реализовать в составе NGFW возможность приоритетной обработки трафика на основе использования определённых опций ТСР (RFC 2385 и RFC 7413). Они позволяют сформировать первые пакеты установки соединения TCP так, что это даст возможность обрабатывать трафик в приоритетном режиме либо просто не блокировать SYN-пакеты в условиях массированной атаки типа «SYN flood». Опции ТСР, введённые в соответствии с RFC 2385 и RFC 7413, расширяют первый SYN-пакет дополнительными полями данных, которые позволят надёжно аутентифицировать отправителя. При этом, конечно, потребуется реализация собственного алгоритма проверки пакетов — фильтра на уровне «LVL1», поскольку упомянутые поля протокола станут использоваться не по назначению данных рекомендаций (RFC), хотя и не будут их нарушать. Последнее актуально для возможности трансляции подобного приоритетного трафика через интернет. Ниже приведена структура заголовка ТСР и показана возможность его расширения с поправкой на RFC 2385 и RFC 7413.

Заголовок пакета ТСР имеет структуру:

    0                   1                   2                   3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |          Source Port          |       Destination Port        |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                        Sequence Number                        |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                    Acknowledgment Number                      |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |  Data |           |U|A|P|R|S|F|                               |

   | Offset| Reserved  |R|C|S|S|Y|I|            Window             |

   |       |           |G|K|H|T|N|N|                               |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |           Checksum            |         Urgent Pointer        |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                    Options                    |    Padding    |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                             data                              |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле «Options» позволяет расширить пакет SYN дополнительными данными, достаточными для надёжной идентификации пакета (отправителя). Оба расширения протокола имеют следующую структуру.

TCP_MD5SIG:

             +---------+---------+-------------------+

             | Kind=14 |Length=18|   MD5 digest...   |

             +---------+---------+-------------------+

             |                                       |

             +---------------------------------------+

             |                                       |

             +---------------------------------------+

             |                                       |

             +-------------------+-------------------+

             |                   |

             +-------------------+

TCP_FASTOPEN:

                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                   |  Kind=23  |     Length=18     |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                                                               |

   ~                            Cookie                             ~

   |                                                               |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Каждое из расширений протокола позволяет помещать в пакет до 16 байт (18−2 без подзаголовка опции) идентификационных данных.

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

Под оптимальным распределением трафика подразумевается в том числе группировка пакетов по критерию принадлежности к одной сессии на уровне транспортного протокола. Подобную функциональность в базовом исполнении (с базовой прошивкой) поддерживают производители сетевых карт, реализованных на ПЛИС (например, Cisco Nexus K3P-S FPGA SmartNIC, см. описание в п. 3.1). Помимо оптимального распределения трафика между различными узлами обработки, подсистема предварительной служебной маршрутизации может выявлять неактивные (аварийные) узлы и автоматически задействовать резервные, предусматриваемые обычно в составе кластера обработки.

Специальное аппаратное обеспечение

При реализации комплекса обработки трафика на «магистральных» скоростях (от 25 Гбит/с) полезно применять специальные аппаратные устройства, которые позволят снять часть рутинных задач с ЦП и перенести их туда, где они будут решаться гораздо эффективнее. Например, как упоминалось выше, подсистему обработки трафика целесообразно разделить на подуровни, выполнив нижний уровень (предварительную обработку) на специальном аппаратном обеспечении на базе ПЛИС (FPGA).

Однако на рынке уже давно существуют специальные аппаратные решения (сетевые карты), которые позволяют реализовать эффективную обработку трафика на уровне FPGA. В дополнение к базовой функциональности на основе предустановленных прошивок в такие устройства можно загружать сторонние прошивки. Это обстоятельство важно, поскольку даёт возможность снять с ЦП часть рутинной обработки данных. Например, как было описано выше, на уровне FPGA может быть эффективно реализован сигнатурный поиск. Для этого в карту предварительно загружается база искомых сигнатур для проверки ресурсов (например, исполняемых файлов), передаваемых в трафике. 

Помимо ресурсов, которые передаются по магистральной сети, нужно проверять те, которые выделяются из терминированных сессий TLS на уровне «LVL2». Для этого надо обеспечить доступ уровня «LVL1» к ним. Очевидное, простое, но неприемлемое решение — их загрузка с уровня «LVL1» на «LVL2», задержка трафика на «LVL2» до получения результата проверки на уровне «LVL1». Но есть более оптимальный, простой и корректный (особенно с поправкой на протокол HTTP/2) способ реализации такой проверки. На уровень «LVL1» можно передавать не сами ресурсы, а полученные на этапе установки защищённого соединения TLS сеансовые ключи и реквизиты соответствующих сессий. Акцент на корректности в описании выше сделан по той причине, что в версии HTTP/2 ресурсы могут передаваться без предварительных запросов и уровень «LVL2» может не знать типов передаваемых данных на момент запроса. Именно по этой причине целесообразно передавать в «LVL2» сеансовые ключи, а не дожидаться запросов клиента и уже на их основе принимать решение о передаче процедуры проверки на уровень «LVL1». 

Рисунок 3 отображает взаимодействие модулей уровней «LVL1» и «LVL2» при реализации схемы передачи сеансовых ключей.

 

Рисунок 3. Передача сеансовых ключей TLS

 

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

Cisco Nexus K3P-S FPGA SmartNIC

С базовой прошивкой устройство может классифицировать потоки и на основе этой классификации перенаправлять трафик на обработку — на уровень пользователя либо на другой порт (порты) сетевого устройства.

 

Рисунок 4. Разделение трафика по потокам на уровне сетевого интерфейса

 

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

Silicom PE310G4FA2I71 Server Adapter

Это устройство также позволяет загрузить собственную FPGA-прошивку. Отметим, что данная сетевая карта доступна на российском рынке. Информация о ней доступна здесь.

Типовое ПО с открытым исходным кодом — MITM-прокси для SSL / TLS

При реализации продуктов наподобие файрвола, DPI или систем обнаружения / предотвращения вторжений (IPS / IDS) возникает необходимость анализировать зашифрованный трафик SSL / TLS, источник которого — контролируемая сеть заказчика. Типовое решение такой задачи — применение промежуточного прокси-сервера, работающего по схеме «внедрённый посредник» (MITM). Расшифровка и обработка (проверка) расшифрованного трафика по такой схеме происходят на рабочих станциях подконтрольной сети на основе предустановленных сертификатов шифрования.

При реализации схемы используют только ПО с открытым исходным кодом. На GitHub доступна пара решений такого типа, заслуживающих внимания: SSLsplit и SSLproxy.

Функциональность и кодовая база обоих продуктов схожи, поскольку SSLproxy — это развитие проекта SSLsplit, но есть и отличия, которые существенно облегчают интеграцию SSLproxy: запись реквизитов маршрутизации в первый пакет с данными, возможность ответвления расшифрованного трафика, поддержка TLS 1.3.

Добавление реквизитов маршрутизации в первый пакет позволяет осуществлять дополнительное ответвление трафика (помимо заявленного) и упрощает его реализацию. Наглядная схема на странице разработчика объясняет сущность дополнения (рис. 5).

 

Рисунок 5. Реквизиты транслируемого трафика в подзаголовке SSLproxy

 

Для трафика HTTP в соответствии с этой схемой SSLproxy расширяет список подзаголовков HTTP, дополняя его своим собственным, где перечислены все порты и адреса обработчиков расшифрованного трафика. IPS на схеме не имеет отношения к маршрутизации и лишь обозначает возможность прозрачного (без затрат на доработку) задействования какой-либо дополнительной системы анализа / обработки расшифрованного трафика — например, на уровне ядра ОС — при его передаче между обработчиками. Ответвление расшифрованного трафика (стрелки обозначены символом «р» — «plain») на обработчик («Program») здесь также представлено.

Выводы

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

В составе NGFW крайне целесообразно применять ряд программных и аппаратных продуктов (в том числе ПО с открытым исходным кодом). В качестве таковых могут быть привлекательными:

• кроссплатформенная библиотека для разработки агентской подсистемы проксирования трафика SSL / TLS — NetFilter SDK (исходные коды предоставляются по лицензии);
• отдельный компонент библиотеки NetFilter SDK — ProtocolFilters — для разработки подсистемы проксирования трафика на уровне прокси-сервера SSL;
• открытая реализация прокси-сервера SSL / TLS — SSLproxy / SSLsplit;
• сетевые карты с расширенными аппаратными возможностями (FPGA), например от Cisco, Silicom и др., которые позволяют загружать собственные прошивки;
• сетевые карты с аппаратной реализацией обходного (bypass) модуля на уровне самой карты, например от производителя Silicom (PE340G2BPI71 Bypass Card).

Также NGFW может быть наделён целым рядом полезных функциональных возможностей:

• расширенная подсистема контроля целостности ПО, реализованная на аппаратном уровне (не ассоциировать с имеющимися аналогами подсистем в составе схожих ПАК на рынке России, которые зачастую исполняют только маркетинговую роль);
• расширенная подсистема глубокого анализа трафика и его последующей очистки, а не блокировки, включающая обработку данных на уровне медиапотоков (изображение, звук и т. п.);
• подсистема узкополосного приоритетного канала данных (например, для нужд управления), функционирующая в условиях массированной flood-атаки (см. п. 2.3) на основе возможностей заложенных в RFC 2385 и RFC 7413.