Преимущества анализа приложений 7 уровня в межсетевых экранах

Основы межсетевого экранирования

Введение

Skype, TOR, Ultrasurf, TCP-over-DNS и еще несколько сотен приложений и туннелей спокойно проходят сквозь statefull inspection firewall и HTTP прокси. Многие средства защиты открывают соединения, но не проверяют, что ходит внутри них. Предлагаю разобраться, как контролируемо разрешать соединения приложений в новом поколении firewall, где правила пишутся по именам приложений, что соответствует 7 уровню модели OSI ISO. Такие межсетевые экраны имеют название Next Generation Firewall, межсетевой экран нового поколения или просто NGFW.

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

Существует несколько важных отличий в работе с трафиком, которые понимаешь лишь когда переходишь на реальное использование правил, где критерием является приложение 7 уровня модели ISO OSI:

  • ИТ администратор видит, что NGFW визуализирует сетевой трафик, то есть показывает содержимое поля данных пакетов, имена пользователей и какое приложение работает и какие файлы передает.
  • ИТ безопасность видит, что NGFW обеспечивают безопасное разрешение приложений, поскольку более глубокий анализ данных в пакете позволяет увидеть вирусы, подключить отправку неизвестных файлов в песочницу, проверить тип файла, ключевые слова для DLP, проверить категорию URL, проверить что идет внутри SSL и SSH, сравнить с уже известными всему миру индикаторами компрометации, включить DNS фильтр и другие современные техники.

Чтобы понять причины этого сравним журналы L4 и L7 firewall.

А) Сравните запись в журнале L4 firewall, который разбирает только заголовок транспортного (четвертого) уровня модели OSI ISO — в данном случае TCP:

Да, есть информация об источнике и получателе, можно догадаться по номеру порта 443, что внутри, с большой степенью вероятности (как говорят англичане) соединение SSL. Я лично не могу увидеть в этой записи какой-то инцидент. А вы?

Б) Сравните запись в журнале L7 firewall для того же самого TCP соединения, где разбирается еще и сам контент передаваемый в поле данных TCP/IP:

Здесь вы видите, что Иванов из отдела маркетинга выложил на Slideshare файл с пометкой «не для распространения». Это пример реального инцидента, где сотрудник выложил конфиденциальные планы развития компании на год в Интернет. Эта информация получена в L7 firewall на основе анализа того же самого соединения, что и выше у L4 firewall и сразу информации становится достаточно, чтобы понять, что был инцидент. И это совершенно другой подход к анализу трафика. Но, сразу предупрежу, что такой глубокий анализ накладывает серьезную нагрузку на процессор и оперативную память устройства.

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

Определения

Нужно подсветить термины, которыми мы будем дальше оперировать. У меня нет цели в деталях дать все определения.

Семиуровневая модель OSI ISO – это модель взаимодействия между сетевыми устройствами, которая гласит, что существует 7 последовательных уровней абстракции взаимодействия: первый — физический, следующий канальный, сетевой, четвертый — транспортный, затем сессионный, представления и седьмой уровень – приложений (см. картинку выше).

Каждое сетевое устройство работает на своем уровне абстракции: веб сервер и браузер – на уровне приложений (уровень 7 или кратко L7), маршрутизаторы — общаются друг с другом на канальном (2) и сетевом уровне (3), когда передают друг другу фреймы и пакеты.

Межсетевые экраны тоже являются сетевыми устройствами и могут быть в зависимости от своего типа и свитчами и роутерами и даже быть «виртуальным кабелем» с точки зрения сетевой топологии, но на эти сетевые устройства ложится дополнительная нагрузка: они должны анализировать содержимое пакетов.

И вот глубина анализа сетевых пакетов может отличаться. Анализируют ли они 4 или 7 уровень — в этом есть важное отличие.

Firewall

Межсетевой экран (МСЭ), Network Firewall– это сетевое устройство, которое делит сеть на сегменты с разными политиками безопасности и контролирует эти политики. Например, сегмент Интернет – там можно все что угодно. И сегмент вашего ЦОД – там можно работать только выделенному списку сотрудников по разрешенным приложениям. Внутри одного хоста VMware может быть несколько виртуальных сетей с виртуальными машинами и разными политиками доступа к ним.

Политика безопасности firewall содержит правила, которые приводит в действие программный код устройства, анализируя каждый фрейм и пакет пришедший и исходящий с firewall. В правилах firewall задаются критерии проверки (квалификаторы), по которым принимается решение пропускать или блокировать трафик. Примерами квалификаторов в правилах являются: адрес, порт, приложение, пользователь, зона. Межсетевой экран последовательно, правило за правилом, сверху внизу по списку просматривает критерии и если входящий трафик соответствует всем критериям правила, (логическая операция «И» между критериями) то применяется указанное действие: заблокировать или пропустить. Действие выполняется как для первого пакета, так и для всех последующих пакетов одного TCP/IP соединения.

Существуют разные типы и реализации firewall. Мы рассмотрим классификацию по степени используемой глубины анализа трафика: L3, L4 и L7.

L3 Firewall

L3 firewall – это межсетевой экран, который пропускает через себя трафик и анализирует только заголовки IP протокола, то есть адрес откуда и куда идет трафик. Такие межсетевые экраны называют пакетный фильтр. Правила имеют название «список доступа» или access-list (ACL) и этот функционал на сегодня работает практически в любом маршрутизаторе и операционной системе. Такой анализ не требует серьезной нагрузки на процессоры и память firewall.

L4 Firewall

L4 firewall – это межсетевой экран, который пропускает через себя трафик и проверяет заголовки протоколов 4 уровня: TCP, UDP, ICMP, то есть основными критериями проверки для пропуска трафика является IP адреса и порты TCP/UDP или сервисы ICMP.

Также в L4 firewall появляется понятие stateful inspection, когда каждый проходящий запрос запоминается и хранится состояние запроса для того, чтобы разрешать необходимые ответные соединения. То есть появляется понятие инициатора соединения, что логично в сетях, построенных на клиент-серверной технологии. Такой межсетевой экран тратит память на хранение данных о каждом соединении, то есть появляется ограничение на максимальное количество хранимых одновременных сессий в памяти. В L4 firewall уже не нужно писать ответное правило для обратного соединения, как это требуется в L3 firewall, потому что на основе состояния соединения, межсетевой экран автоматически разрешает обратные соединения. То есть L4 firewall удобнее, чем пакетный фильтр.

Современные L4 firewall хранят состояние не только TCP, UDP и ICMP, но и отслеживают взаимодействие некоторых L7 приложений. Например, состояние FTP, HTTP, SIP, и другие приложения, что уже зависит от конкретной реализации firewall. Нужно задавать производителю L4 firewall вопрос: какие конкретно приложения поддерживает их движок stateful inspection firewall.

L7 Firewall

L7 firewall – это межсетевой экран, который пропускает через себя IP трафик сети и проверяет и заголовки 4 уровня и сегмент данных каждого IP пакета, то есть понимает L7 трафик уровня приложений, вплоть до того какие файлы передаются и в каком направлении. Поскольку анализируется больше данных, то и критериев проверки в правилах L7 firewall больше: имя пользователя, приложение, URL категория, состояние софта на компьютере пользователя.

Нагрузка на L7 firewall гораздо выше, поскольку его процессор должен постоянно анализировать мегабайты поля данных, которые передает приложение, в то время как L4 firewall проверяет только несколько байт заголовка IP пакета с адресами источника и получателя и портами. Размер буфера для хранения состояния каждого приложения L7 требуется гораздо больше, поскольку данных на L7 передается больше, чем просто в заголовке TCP/IP. Из-за выросшего размера буфера при использовании анализа приложений, количество одновременно хранимых в памяти сессий у L7 firewall меньше L4 firewall при том же объеме памяти. Поскольку L7 firewall видит по контенту что за приложение идет по сети, то номер порта не несет особенного смысла и правила можно писать по имени приложения L7. Кроме того современные приложения генерируют много соединений и все эти соединения являются частью одного приложения. Этот вид firewall позволяет вернуть контроль за современными динамическими приложениями, работающими по любому порту, например, teamviewer, bittorent, tor, о которых L4 firewall ничего не знает. То есть L7 firewall в современных реалиях нужен, если в сети нужна безопасность.

Если после прочтения данной статьи вы продолжите использовать L4 firewall то, это значит, что на безопасность вам наплевать.

UTM

UTM – это сетевое устройство, внутри которого установлено несколько различных компонентов защиты, которые последовательно анализируют проходящий через устройство трафик. Ядром UTM является L4 firewall, система предотвращения атак (IPS), антивирус, анализ категорий URL в HTTP и HTTPS. Часто UTM еще реализуют функции VPN шлюза. Управление всеми этими компонентами как правило осуществляется из нескольких разных систем управления. Трафик внутри UTM последовательно проходит через модули фильтрации и на выходе остается чистый трафик, который разрешен политиками безопасности каждого модуля. UTM может быть использован как платформа для других функций: защита от вирусов, IPS, DDoS, QoS, DLP, DNS фильтр, базы индикаторов компрометации Threat Intelligence, защита от фишинга и так далее (зависит от производителя).

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

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

Цель UTM: реализовать на одном сервере как можно больше функций, чтобы удешевить устройство для пользователя.

Сейчас производители UTM стали ставить движки анализа приложений 7 уровня, чтобы говорить, что они NGFW, чем сбивают с толку потребителя. Однако это легко распознать, если посмотреть в политику безопасности: правила по-прежнему базируются на критериях проверки полей L4. А для фильтрации L7 приложений используется отдельный раздел настроек, то есть приложение L7 не является квалификатором, как должно быть в L7 firewall. Распознавать приложение L7 и использовать приложение L7 как критерий политики безопасности – это «две большие разницы».

NGFW

NGFW – это сетевое устройство, внутри которого реализован L7 firewall. Поскольку квалификатором основным становится имя приложения L7, то правила пишутся по новым критериям. В NGFW всегда работает динамическое сопоставление IP адресов пользователи сети, поэтому имя пользователя тоже становится квалификатором(критерием). NGFW включает в себя функции расшифрования SSL/TLS и SSH для распознавания приложений и атак внутри них, IPS, антивируса, URL фильтрации.

Термин NGFW сначала был придуман маркетингом компании Palo Alto Networks. Но постепенно прижился на рынке и все производители UTM сейчас тоже называют себя NGFW. И действительно, NGFW тоже выполняет несколько функций одновременно, почему же тогда NGFW не UTM? Отличие важно знать. Оно в том, что в NGFW функции безопасности приложений (IPS, антивирус, URL фильтрация) ускорены аппаратно. Существуют специализированные аппаратные чипы: IPS проверяет атаки на своем чипе, антивирус сигнутуры на своем, расшифрование SSL — на своем и так далее. Разделение функций по разным процессорам дает возможность запускать защитные функции параллельно и не ждать, когда закончит работать предыдущая функция, как в UTM. Для примера в аппаратных межсетевых экранах компании Palo Alto Networks установлено до 60
специализированных процессоров компании Cavium выполняющих ускорение функций безопасности, сетевых функций и управления. Важно, что NGFW содержат единый программный интерфейс управления всеми функциями одновременно.

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

По такой же схеме когда-то пошли производители компьютеров, которые вынесли функции математики и графики в отдельные математические и графические сопроцессоры. Поэтому в NGFW стоят отдельные процессоры под распознавание приложений L7, под расшифрование SSL/SSH, под проверку сигнатур антивируса, проверку сигнатур IPS и так далее. Это позволяет включить все функции одновременно, без деградации и задержки трафика в устройстве на время проверки. Почему компьютеры без графических акселераторов никто уже не покупает, а межсетевые экраны без ускорения покупают? Потому что ускорение не нужно на небольших скоростях, но когда скорости анализа трафика выходят за 1-5 Гигабит — реализовать все функции безопасности уже невозможно без ускорения.

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

Примеры

Пример политики L7 в Palo Alto Networks NGFW

Зачем может потребоваться URL категория, как квалификатор? Например, вы можете части сотрудников разрешить все-таки посещать вредоносные сайты браузером, но заблокировать им скачивание файлов.

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

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

Прокси-сервер

Прокси-сервер– это устройство, которое терминирует на себе трафик какого-то приложения, проверяет это трафик различными методиками и отправляет этот трафик дальше. Чаще всего используются в сетях прокси-сервера для протоколов HTTP и HTTPS. Поскольку UTM и NGFW анализируют потоки HTTP и HTTPS прозрачно, не требуя явно указывать настройки прокси-сервера у клиентов, то HTTP прокси постепенно исчезают из компаний.

Что такое USER-ID

В NGFW был придуман механизм идентификации пользователей. Алгоритм либо работает внутри, либо запускается на внешнем агенте. Буду называть это механизм USER-ID. USER-ID создает и поддерживает таблицу соответствия имени пользователя и его текущего IP адреса. Также бывает, что в таблице есть и значение и порта для данного пользователя, если пользователи работают через VDI (то есть пользователи идут с одного адреса и их можно различить только по портам).

Перечислю механизмы USER-ID в Palo Alto Networks

  1. Server monitoring: User-ID агент читает события Exchange Servers, domain controllers или серверов Novell eDirectory
  2. Client probing: User-ID агент опрашивает Windows клиентов по WMI
  3. Terminal services agent: TS агент раздает разным пользователям разные диапазоны TCP/UDP портов для работы с Windows/Citrix Terminal Servers
  4. Разбор сообщений Syslog: User-ID агент читает syslog соообщения об аутентификации от различных систем, wireless controllers, 802.1x устройств, Apple Open Directory servers, proxy серверов, VPN шлюзов, Сisco ISE
  5. Аутентификация через клиент GlobalProtect: логин и пароль на VPN + можно добавить MFA
  6. Аутентификация через через Captive Portal: Web traffic аутентифицируется по NTLM или AAA web формой (Captive Portal используется в Московском метро и кафешках. NTLM позволяет делать аутентификацию прозрачной)
  7. XML API: информация о входе и выходе передается User-ID агентом специальными командами через REST API firewall
  8. X-Forwarded-For: прокси-сервера заполняют это поле в HTTP запросе, чтобы было понятно кто там прячется за прокси

Чтение журналов с контроллеров Active Directory — самая часто используемая функция в USER-ID. Агент USER-ID выполняет периодически чтение сообщений из журналов AD, где записано какой пользователь с какого IP адреса авторизовался, именно из них USER-ID узнает о том по какому адресу пользователь и хранит это внутри NGFW, например для Windows 2008/2012 это сообщения:
— 4768 – Authentication Ticket Granted
— 4769 — Service Ticket Granted
— 4770 – Ticket Granted Renewed
— 4264 – Logon Success
Для чтения журналов агенту USER-ID нужен доступ с правами Even Log Reader.

Заблуждения о Stateful Inspection

Отдельную главу я должен посвятить этому святому каждому сетевому инженеру и безопаснику понятию. Нужно подчеркнуть и дополнить важные вещи, которые часто упускают на курсах по межсетевым экранам. Если вы уже изучали основы stateful inspection, то скорее всего у вас есть несколько заблуждений.

Есть одно заблуждение, которое я иногда вижу у коллег. Внимание! Stateful inspection — это не только про состояние соединения TCP, UDP или ICMP! Это еще и про состояние других более сложных протоколов и приложений: FTP, SIP, RPC, SMTP, SMB и так далее!

Пример.

Протокол FTP — это протокол уровня приложений. И в нем есть команда PORT, которая может назначать новое TCP подключение. Любой firewall, который позиционирует себя как stateful inspection firewall, должен контролировать команды FTP и видеть команду PORT и разрешать соединение на порт и адрес, который там запрошен. И это еще не все: firewall еще и должен подменять параметры команды PORT и вставлять правильный адрес, если FTP сервер работает за NAT.

То есть в любом современном L4 firewall есть компонент, который подглядывает за L7 уровнем. И такой протокол не один: еще есть HTTP, RPC, и другие… И такие анализаторы протоколов 7 уровня называются Application Layer Gateway (ALG).

Пример.

Самый «любимый» одновременно у сетевиков и безопасников – это ALG для SIP, с которым многие, кто настраивает SIP ALG на L4 firewall наелись проблем, и часто заканчивается его отключением.

То есть уже в L4 firewall есть зачатки анализа протоколов 7 уровня. L4 firewall отличаются друг от друга количеством реализованных ALG. Когда вы сравниваете обычные L4 firewall, то справедливый вопрос системному инженеру производителя будет: сколько протоколов и приложений поддерживает ваш движок Stateful Inspection? Как правило никто не отвечает.

Получается, что L7 firewall — это тоже stateful inspection firewall, но который анализирует и хранит статус ВСЕХ приложений, а не только выборочно, как L4 firewall.

Второе заблуждение вносят сами производители firewall. Возьмите любой datasheet, где производитель пишет такой параметр, как «число одновременных сессий». Вопрос к производителю следующий: сессии каких именно протоколов и приложений измерялись и был ли включен хотя бы stateful для TCP, не говоря уже были ли проверки для L7 уровня?

Мы знаем, что у каждого протокола или приложения есть состояние, которое помнит firewall. И для хранения этого состояния нужно выделить буфер в памяти устройства. По сути, параметр «число одновременных сессий» означает сколько буферов для хранения состояний можно уместить в памяти устройства. Нужно понимать, что для L4 firewall чаще всего измеряют этот параметр для голого TCP или даже UDP. То есть для TCP нужен буфер, в который умещается только IP и порт соединения. Однако в тесте для L7 приложений, например, HTTP этот буфер будет значительно большего размера, ведь хранить, например, параметры запроса GET внутри HTTP требуется больше памяти. А память не резиновая. Соответственно, если производитель пишет такой параметр как «число одновременных сессий», то он должен писать:

  • был ли это просто тест работы в режиме свитча/роутера, c выключенным stateful inspection,
  • был ли это режим L4, где он запоминал только заголовки TCP/IP,
  • было ли какое-то приложение L7 уровня взято для теста.

Правильно L7 firewall измерять на числе одновременных сессий HTTP, на пакетах разной длины: 64Кб, 44Кб, 16Кб, 1.5Кб. Понятно, что если каким-то производителем все измерения были сделаны на UDP 1518 байт, то скорее всего в вашу сеть такое устройство не подойдет, поскольку заставить ваших пользователей посылать только UDP пакеты длиной 1518 байт – не получится, а уж тем более заставить отвечать такими пакетами сервера HTTP. Нужно сказать такому производителю, что производительность L7 firewall нужно измерить хотя бы на трафике с протоколом HTTP. Из известных компаний, которые проводят такие тесты публично: компания NSS Labs.
Сами производители firewall проводят тесты на заказ в своих лабораториях, которым можно заказать свой профиль трафика, например: 30% трафика HTTPS, 10% трафика SMB, 10% трафика FTP и так далее.

Пример.

После проверки на генераторе трафика IXIA устройства одного из производителей UTM:

  • в режиме L4 firewall — 4 000 000 одновременных сессий,
  • в режиме L7 firewall — 200 000 одновременных сессий.

Это показатель того, что буферов для сессий L7 в памяти устройства меньше из-за их большого размера.
И, кстати говоря, также будет и с общей производительностью устройства: с выключенными проверками контента приложений межсетевой экран работает в 10 раз быстрее, чем с включенными. Использовать только анализ заголовков 4 уровня для ускорения устройства можно, но безопасности уже никакой.

Третий важный момент – работа в кластере. Все межсетевые экраны должны работать в кластере, потому что если один межсетевой экран перестает работать, то его задача «лечь грудью» и заблокировать весь трафик — такова теория построения защиты на базе межсетевых экранов. Пока «сломанный» firewall блокирует трафик, задачу по пропуску легитимного трафика должен взять на себя соседний firewall. А что же будет с соединениями, которые шли через первый? Скорее всего первый firewall передавал состояние всех соединений второму, но вот передавал ли он соседу только состояние IP заголовков или полностью состояние всех приложений L7 уровня: а ведь там были какие-то SSL соединения которые были расшифрованы и над ними трудился IPS и антивирус – они собирали пакеты в буфера, чтобы проверять содержимое. И тут оказывается тоже L4 и L7 firewall отличаются: передать состояние L4 не то же самое, что передать состояние L7. Это тоже важно понимать.

Существует еще одно заблуждение, что L7 firewall могут работать в кластерах более двух устройств — это неверно, поскольку объем передаваемых данных L7 растет экспоненциально с каждым новым узлом в кластере и обработка данных даже двух соседок превышает затраты по обработке данных своего же устройства. Именно поэтому кластеры больше двух устройств работают только обмениваясь заголовками L4, и при переключении кластеров все функции анализа приложений и защиты перезапускаются.

Поэтому нужно грамотно сравнивать L4 и L7 firewall, также как когда вы сравниваете подходит ли вам легковой автомобиль и танк на войне. L7 firewall для повышения безопасности вашей сети проделывает более сложную работу, гораздо больше работы идет на его процессорах и ему нужно больше памяти для хранения состояния ваших приложений! Все это нужно делать для безопасности.

Влияние L7 FIREWALL на безопасность

L7 firewall проверяет содержимое поля данных, L4 firewall нет

Если человек ставит Skype, то он не хочет звонить сисадмину и упрашивать открыть нужный ему порт на firewall – он хочет, чтобы, Skype сразу засветился «зелененьким». Программисты знают, что в сети часто есть HTTP прокси или открыт порт 80 для работы HTTP, порт 53 для работы DNS, порт 123 для работы NTP, а бывает для сотрудников изнутри наружу в Интернет вообще все открыто и соответственно этими разрешенными соединениями можно пользоваться.

У разработчиков есть термин User Experience – у клиента после установки загорелся Skype зелененьким = клиент счастлив. А то, что Skype прошел периметр компании нелегально по соединению, которое было открыто для работы только браузера по портам TCP/80 и 443 – L4 firewall игнорирует, потому что это не его задача смотреть в содержимое пакетов — ему важны лишь в их заголовки.

Проблема L4 firewall: port-hopping (туннелирование)

Туннелирование неразрешенных приложений внутри разрешенных соединений – это стандартная картина в современных сетях. Естественно, хакеры пользуются тем же приемом: они создают туннели в разрешенных соединениях. А безопасники даже не в курсе.

Пример туннеля TCP-Over-DNS

По собранным пакетам трафика на картинке видно, что идут соединения по 53 порту TCP, что обычно рассматривается как работа протокола DNS. Однако, если присмотреться, то видно, что в поле Text протокола DNS находится какой-то зашифрованный текст. Это реализация туннеля TCP-Over-DNS, которую я часто встречаю в корпоративных сетках. Слева список других туннелей, которыми могут воспользоваться и ваши пользователи или хакеры. Дает ли такую информацию L4 firewall? Нет. Поэтому, если нужно обезопасить компанию от несанкционированных туннелей, то нужно анализировать содержимое передаваемых данных и именно по ним разбирать какое же приложение в данный момент использует это TCP соединение.

Приложения изменились – изменился ли ваш firewall

Мир изменился и сегодня определять приложение по номеру порта недостаточно. Да, 20 лет назад договорились, что если в поле Port прописано 80, то это HTTP, если 53, то это DNS, но теперь это уже не так!

Нужно анализировать содержимое передаваемых данных и именно по ним разбирать какое же приложение в данный момент использует это TCP соединение.

Зайдите в базу данных приложений applipedia.paloaltonetworks.com. Посмотрите сколько приложений использует 80 и 443 порт.

Пример.

Приложения, использующие порт 80

Проблема многих средств защиты – игнорирование приложений на нестандартных портах

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

Как работает обнаружение приложений в трафике

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

Есть еще класс устройств, которые так умеют: Deep Packet Inspection (далее DPI). Такие устройства стоят сейчас у крупных провайдеров и позволяют манипулировать трафиком приложений: применять QoS или перенаправлять в нужном направлении. Иногда NGFW и DPI сравнивают. Разница: DPI предназначен для управления качеством трафика, а NGFW безопасностью, хотя в NGFW тоже есть функции QoS.

Методы обнаружения приложений в трафике отличаются.

  • Если нужно обнаружить приложение, которое не скрывает себя в трафике, например HTTP, то достаточно пользоваться обычными поисками соответствующих паттернов или сигнатур. И это активно применяют производители. Это проще всего.
  • Если нужно обнаружить приложение, которое намеренно скрывает себя, например, TOR, то тут нужен набор методик анализа статистики пакетов и поведения пакетов. Это сложно, это требует наличия исследовательской лаборатории, которая еще и должна вовремя отслеживать изменения в протоколе и реализовать новые алгоритмы поиска. Мои попытки заставить хоть одного разработчика рассказать, как же эти алгоритмы работают, натыкаются на ответ, что это все интеллектуальная собственность.

Бывает, что приложение уже поменяло алгоритм работы, а движок DPI или NGFW еще не успел измениться. Например, Telegram иногда меняет, потому что за ним ведут охоту. Возникают ложные срабатывания. Это важно проверять. Соответственно устройства и NGFW и DPI отличаются прежде всего количеством и качеством детектирования приложений. Здесь единственный метод: поставить NGFW на свой трафик и посмотреть. Если говорить о периметре, то самый сложный трафик, который я видел, содержал 715 разных приложений за месяц. В среднем же через периметр ходит 200-300 приложений разного рода. В этой визуализации трафика приложений можно это посмотреть: проводите мышкой надо каждым кругом:

http://researchcenter.paloaltonetworks.com/app-usage-risk-report-visualization/

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

Иногда вендоры L7 firewall пытаются меряться числом приложений которые есть у них в базе, но это больше похоже на профанацию. Включив критическое мышление вы понимаете, что вам в реальности нужно детектировать только приложения на периметре (в среднем это в районе 300 разных приложений), в ЦОД (10-15 штук), в ICS/SCADA сетях (2-3 приложения), между внутренними сегментами (возможно это всего несколько десятков). И если вам предлагают детектировать тысячи приложений — это всего лишь маркетинг и детект каких-то неизвестных приложений, которыми никто не пользуется.

Пример приложений в сети компании:

Внутренняя сегментация внутри компании – это постоянное требование стандартов ИБ, которое почти никто не выполняет. Между сегментами, где сидят программисты, финансисты, HR и бухгалтерия тоже ходят приложения. Как минимум нужно контролировать сеть Windows (протокол SMB), особенно это стало понятно после эпидемии криптолокера WannaCry, который распространялся именно по SMB. То есть во внутренних сетях тоже нужен анализ приложений 7 уровня и сопутствующие методики поиска вредоносного кода песочницей и IPS, да хотя бы контроля передаваемых типов файлов.

Самая частая проблема, которая заметна в сетях: межсетевой экран якобы 7 уровня, но в реальности детектирует приложения по портам. Как это проверить?

  1. Для теста повесьте FTP сервер на 25 порт. Если устройство ошибается и говорит, что это протокол SMTP, то это точно не L7 firewall.
  2. Или просто попробуйте написать правила для двух разных приложений, которые используют один и тот же порт. Сделайте для них разные правила: в одном блокируйте exe файлы, в другом разрешайте их. Если получается сделать, то значит правда сначала идет разбор приложения (а не номера порта), а потом работа с его контентом: блокировка файлов, проверка сигнатур вирусов, проверка IPS сигнатур и так далее.
  3. Еще один интересный тест для NGFW, когда нужно сделать два кастомных L7 приложения с разными свойствами на одном IP адресе. Этого не может L4 firewall, но может L7 firewall. Полное описание и сам тест здесь: http://basic.ngfw-test.com/

В России еще актуально, чтобы межсетевые экраны знали трафик русских приложений: 1С, Одноклассники, Яндекс.Диск, mail.ru, как выглядят обновления антивируса Касперского и так далее. Это тоже важный компонент обнаружения приложений, который нужен, чтобы безопасно разрешать эти приложения своим сотрудникам.

L7 Firewall удобнее

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

Автор этих строк закончил в 2003 году приличное количество курсов компании Cisco и поэтому представляет в чем особенности обучения именно сетевых инженеров: как правило, после изучения семиуровневой модели OSI ISO детально изучаются лишь первые 4 уровня. То есть все тонкости информационной безопасности сетевые инженеры познают лишь до уровня TCP/UDP/ICMP. Из уровня приложений рассматривается лишь несколько основных: HTTP, DNS, SSH, Telnet, NTP, FTP. Какой результат? И у сетевого администратора создается ощущение, что управлять прикладным уровнем легко с транспортного уровня!

Свежеиспеченному сетевому специалисту может показаться, что все можно сделать правилами на транспортном уровне, где нужно лишь разрешить нужный протокол и порт. Нужно разрешить браузер в Интернет? Открываем TCP/80. Нужно открыть DNS? Открываем TCP/53 или UDP/53. Нужно открыть RDP? Открываем TCP/3389. И написание правил на L4 firewall становится стандартом в компании.

Надо сказать, что многие ИТ специалисты в курсе про понятие statefull inspection. Но одновременно для многих является откровением, что разные firewall поддерживает satefull inspection для разного набора приложений. У меня есть определенная статистика, поскольку работал преподавателем курсов по Firewall в учебном центре компании Информзащита. Что же я вижу? Кто-то думает, что statefull inspection – это только про разрешение принимать обратно ответы протоколов TCP/UDP/ICMP. А как быть с более сложными приложениями? Например, как отследить два TCP соединения, которые делает протокол FTP на 21 и 20 порты — они зависят друг от друго? Там нужно не просто принимать ответ, так еще и второе соединение разрешать в зависимости от команды PORT внутри управляющего соединения на 21 порту. А сколько еще команд на открытие новых соединений внутри себя дают приложения? Резюмируя, в сетях сейчас используются и обычные access list, которые не понимают команду PORT внутри FTP протокола, и есть L4 firewall, которые разбирают команду PORT и автоматически открывают нужный порт, есть кто пошел дальше и смотрит в более сложные команды протоколов MS RPC или ICS/SCADA протоколов. Но все возможные приложения L4 firewall не смотрит и эти firewall тоже в общем-то отличаются количеством реализованных внутри Application Layer Gateway (ALG).

К чему я клоню? Убежденность, что достаточно помнить основные порты TCP/UDP – не работает.
В мире уже несколько тысяч приложений и все они пользуются компьютерными сетями. И никакой сетевой инженер не в состоянии помнить все эти порты.

Откровением для сетевых инженеров являются задачи открыть порты для приложения посложнее, например, VNC. Никто не помнит какие там порты и приходится уже использовать google.

При публикации первой части я провел опрос и вижу, что до сих пор люди готовы запоминать номера портов — мнения разделились 50 на 50: кто-то ответил, что готов помнить все 4 порта приложения VNC.

Пожалуй рекордсменом по числу портов является Lync (он же Skype for Business). Около 40 портов. Реально ли их запомнить?

Если вы заглянете в Microsoft TechNet, где описано, какие порты нужно открыть, то хочется написать правило permit any to any, потому что там порядка 40 портов и часть из них должны открываться динамически. А это катастрофически неудобно прописывать в L4 firewall.

Получается, что сетевому инженеру удобнее писать в правилах приложения L7 и нужно, чтобы firewall сам автоматически открывал нужные порты.

Нужно открыть VNC? Пишешь в правиле слово VNC и уже firewall понимает какие протоколы нижележащие нужно открыть. Это ведь удобно.

Пример. Отчет NGFW по отдельным категориям трафика.

В среднем доступом в Интернет из корпоративной сети пользуется 200-300 приложений. Межсетевой экран уровня приложений показывает какие это приложения и может эти приложения фильтровать для всех или для конкретных пользователей и фильтровать файлы по типам или контенту, которые идут в разрешенных приложениях у всех пользователей корпоративной сети. Также не забываем что в NGFW, параллельно работают функции безопасности: IPS, антивирус, anti-spyware, URL фильтр, DNS фильтр, Threat Intelligence и так далее. То есть мы не просто разрешаем приложения, а делаем это безопасно.

L7 Firewall безопаснее

У меня под рукой есть Palo Alto Networks NGFW. Я написал на нем три разных правила. Давайте разберем чем они отличаются.

Если вы настраивали когда-либо firewall, то вы видите, что для разных групп пользователей: vip, marketing и programmers я разрешил SSL тремя разными способами.

  1. vip пользователи смогут ходить по порту 443 и смогут пользоваться SSL внутри него, поскольку он является портом по-умолчанию для SSL. Если они попытаются пойти по 443 порту, например обычным telnet, то у них не получится – межсетевой экран проверит, что это не SSL и заблокирует. И это то что нужно!
  2. marketing может ходить по любому порту приложением SSL, потому что в поле Service, где указываются порты разрешен любой порт. Вопрос, хотел ли я чтобы маркетинг использовал SSL по нестандартным портам? Нет. Это частая ошибка настройки. Указывать порт как any логично, если правило запрещающее — то есть, если мы хотим запретить SSL по любому порту.
  3. programmers могут ходить по порту 443 любым приложением, что вообще-то является дыркой, потому что я изначально хотел открыть только SSL. И именно так и работают L4 firewall – он открывает порт и дальше ему уже все равно что там и какие приложение этим портом пользуются. Любой программист из группы programmers может воспользоваться любым туннелем.

Настройка application-default очень важна и позволяет сократить количество правил: вы можете в одном правиле указать нужные приложения в колонке Application и межсетевой экран сам откроет нужные порты для нужных приложений и пропустит по этим портам только те приложения, которые там должны ходить. Соответственно вам нужно одно правило, чтобы открыть несколько приложений.

Например, для правила ниже, где всем сотрудникам разрешено ходить в Интернет только по портам по-умолчанию, NGFW будет постоянно проверяться, что они хотят по 53 порту только DNS клиентом, а никак не TCP-over-DNS. И конечно же это повышает безопасность, ведь вы не просто разрешаете приложения, а контролируете, что по открытым каналам ходят только не приложения, которые вы разрешили.

Какие новые проблемы создает новый подход к написанию правил по L7

Нужно понимать, что определение приложения по контенту пакета очень нагружает процессора L7 firewall. Если обычный L4 firewall проверял только несколько байт заголовка TCP пакета и затем остальные мегабайты flash ролика пропускал без проверки, то L7 firewall должен считывать все что хранится в поле данных TCP/IP и постоянно проверять что за контент находится внутри соединения TCP/IP, вдруг оно изменилось или несет угрозу для компании. Поэтому, когда появился такой функционал, как анализ контента, то все устройства стали тормозить. Поэтому для анализа контента нужны более мощные устройства.

Ограничения технологии анализа 7 уровня

L7 firewall требуется больше памяти для хранения состояния одного соединения, поэтому параметр «число одновременных соединений» у L7 firewall всегда ниже чем у L4 Firewall при одинаковом количестве оперативной памяти в обоих устройствах, причем значительно, раз в 10. Это уже объяснялось выше в разделе Statefull Inspection. И это цена за безопасность ваших приложений. Поэтому если вы сравниваете L4 и L7 инспекцию, то задавайте вопрос производителю как он измерял параметр «число одновременных сессий»: с включенной безопасностью на 7 уровне или с выключенной.

То же самое и с производительностью: процессор L4 firewall проверяет лишь несколько байт заголовка пакета и затем уже сами данные передает на скорости маршрутизации без проверки, а L7 firewall проверят и заголовок и все те мегабайты данных, которые содержатся в последующих пакетах соединения. А это уже совершенно другая работа. Поэтому такую работу нужно делать на специализированных для этого аппаратных платформах, где ускорен анализ приложений, ускорена работа потокового антивируса, ускорена работа IPS и других функций безопасности. Лучше всех в создании чипов для ускорения безопасности преуспела компания Cavium, чипами которой, например, пользуется компания Palo Alto Networks. Кроме того использование специализированных чипов FPGA(ПЛИС) позволяет прошивать сигнатуры антивируса и IPS в сам чип и проверка сигнатур идет на аппаратной скорости чипа FPGA. Сейчас даже у личных компьютеров есть ускорение графических функций на выделенных графических процессорах, так что использование чипов для ускорения безопасности — логичное развитие технологий.

Заключение

Во-первых, управлять безопасностью на L7 firewall проще. Раньше вы долго читали документацию производителя приложения и открывали порты, что там перечислены. Теперь просто: указываете название приложения в правиле NGFW и нужные порты будут разрешаться автоматически в зависимости от состояния соединений данного приложения.

Во-вторых, вы сможете обнаружить и заблокировать туннелирование, поскольку L7 firewall безопасно разрешает только явно указанное приложение и если кто-то попытается туннелировать другое приложение по открытому порту, то сразу будет обнаружен и заблокирован.

В-третьих, вы можете разрешить нужное приложение по любому нужному порту и по этому порту будет ходить только нужное приложение, а не все сразу. Например, только веб-браузер будет использовать 80 порт.

Ответить

Вы должны быть зарегистрированы в для возможности комментировать.