Денис Батранков

Почему появилась эта статья?

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

Первая часть статьи Определения различных типов Firewall

Содержание

Часть 2. Влияние L7 Firewall на безопасность
L7 firewall проверяет содержимое поля данных, L4 firewall нет
Приложения изменились – изменился ли ваш firewall
Обнаружение приложений в трафике
L7 Firewall удобнее
L7 Firewall безопаснее
Какие новые проблемы создает новый подход к написанию правил по L7
Ограничения технологии анализа 7 уровня
Заключение

Часть 2. Влияние L7 Firewall на безопасность

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 отличаются прежде всего количеством и качеством детектирования приложений. Здесь единственный метод: поставить их на свой трафик и посмотреть. Если говорить о периметре, то самый сложный трафик, который я видел, содержал 417 разных приложений за месяц. В среднем же через периметр ходит 200-300 приложений разного рода. В этой визуализации трафика приложений можно это посмотреть: проводите мышкой надо каждым кругом:

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

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

Вы должны понимать, что вам нужно детектировать только ваши приложения на периметре (300 штук), в ЦОД (10-15 штук), в ICS/SCADA сетях (2-3 приложения) и остальные тысячи это всего лишь маркетинг и детект каких-то непонятных никому приложений, которыми никто не пользуется. А ведь внутренняя сегментация внутри компании – это постоянное требование стандартов ИБ, которое почти никто не выполняет. Между сегментами, где сидят программисты, финансисты, HR и бухгалтерия тоже ходят приложения, как минимум сеть Windows (протокол SMB), которые только начали контролировать после эпидемии криптолокера WannaCry, который распространялся по SMB. То есть во внутренних сетях тоже нужен анализ приложений 7 уровня и сопутствующие методики поиска вредоносного кода песочницей и IPS.

Самая частая проблема, которая заметна в сетях: межсетевой экран якобы 7 уровня детектирует приложения по портам. Для теста повесьте FTP сервер на 25 порт. Если устройство говорит, что это протокол SMTP, то это точно не L7 firewall. Или просто попробуйте написать правила для двух приложений разных, которые используют один и тот же порт.

Еще один интересный тест для 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. А как быть с двумя соединениями, которые делает FTP на 21 и 20 порты? Там нужно не просто принимать ответ, так еще и второе соединение разрешать. А сколько еще команд на открытие новых соединений внутри себя дают приложения? Резюмируя, в сетях сейчас используются и обычные access list, которые не понимают команду PORT внутри FTP протокола, и есть L4 firewall, которые разбирают команду PORT и автоматически открывают нужный порт, есть кто пошел дальше и смотрит в более сложные команды протоколов MS RPC или ICS/SCADA протоколов. Но все возможные приложения L4 firewall не смотрит и эти firewall тоже в общем-то отличаются количеством реализованных внутри Application Layer Gateway (ALG).

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

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

Следующим примером можно привести Lync он же Skype for Business. Если вы заглянете в 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 по нестандартным портам или ошибка настройки.

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 порт.