Преимущества анализа приложений 7 уровня в межсетевых экранах. Часть 2. Безопасность
Новое поколение межсетевых экранов удобнее и безопаснее, благодаря новой архитектуре движка и новой идеологии управления сетевыми потоками.
Почему появилась эта статья?
Неоднократно приходил к коллегам-безопасникам, которые пользуются межсетевым экраном нового поколения и видел, что они продолжают писать правила по номерам портов. На мое предложение перейти писать по имени приложений, слышал «А вдруг так не заработает?». Если вам тоже «страшно» или непонятно зачем писать правила по приложениям, от эта статья для вас.
Начало статьи по ссылке Часть 1. Основы межсетевого экранирования
СОДЕРЖАНИЕ
L7 firewall проверяет содержимое поля данных, L4 firewall нет
Приложения изменились — изменился ли ваш firewall
Как работает обнаружение приложений в трафике
L7 Firewall удобнее
L7 Firewall безопаснее
Какие новые проблемы создает новый подход к написанию правил по L7
Ограничения технологии анализа 7 уровня
Заключение
L7 firewall проверяет содержимое поля данных, L4 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/
В базе данных приложений находятся тысячи приложений, поэтому по сути разбор форматов и алгоритмов каждого приложения — это долгая и кропотливая работа аналитиков. После того как поняли как приложение работает, начинают работать программисты, которые реализуют обнаружение приложения по трафику. И эти несколько тысяч приложений постоянно меняются. Соответственно, продукт должен постоянно поддерживаться, изучать новые приложения и контролировать изменения в старых и добавлять в базу измененные детекторы. Базу всех возможных приложений генерирующих трафик можно посмотреть тут: https://applipedia.paloaltonetworks.com/
Иногда вендоры 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 порт.
Часть 3. Расшифрование SSL в NGFW. (продолжение следует)
Всего хорошего!
Денис Батранков
denis@batrankov.ru
