локальные межсетевые экраны: надежная стена или соломенная ширма?

Концепция межсетевого экрана (МСЭ) все еще представляется в виде непроницаемой кирпичной стены, непобедимого магического защитника всего хорошего. Реклама современных производителей только подчеркивает это, обещая полную автоматизированную защиту, стену, способную блокировать все опасности еще на стадии их возникновения, используя алгоритмы, еще два года назад возможно и не существовавшие. Но что если на самом деле МСЭ - это не стена, а всего лишь соломенная ширма?

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

Как это отразится на внутренней архитектуре? По каким критериям производится анализ данных? Итак, два этих вопроса являются основными при создании МСЭ и результаты их решения становятся двумя основными компонентами архитектуры программного межсетевого экрана.

Первый компонент работает на пакетном уровне (уровни 3 и 4 модели OSI). Его задача заключается в обнаружении подозрительных и некорректных пакетов, опознавании сканирования портов и принятии решения о пропуске пакета в стек протокола. Пакеты могут анализироваться в соответствии со следующими критериями: формальная корректность пакета, направление пакета (входящий или исходящий), хост и порт отправителя, наличие установленных флагов (это попытка установления соединения? пакет принадлежит уже установленному соединению? и т.д.).

Другой компонент МСЭ работает на более высоком уровне, имея дело с конкретными процессами. В его задачи входит определение, можно ли позволить процессу X инициировать соединение с данным хостом по данному порту, можно ли прослушивать данный диапазон портов и т.д. По сути своей, межсетевой экран будет являться совокупностью двух фильтров: на уровне пакетов и на уровне процессов.

Как это реализуется? Детали реализации изменяются от продукта к продукту, но функциональные принципы ядра очень схожи. Серьезные программные МСЭ (к ним не относятся практически бесполезные продукты, просто перехватывающие соответствующие системные функции) используют два драйвера для фильтрации на двух вышеупомянутых уровнях. Также обычно есть графический интерфейс, позволяющий изменять настройки, но основная работа происходит на уровне ядра, с использованием всего двух драйверов.

пакетный фильтр

Пакетный фильтр обычно реализуется одним из двух способов.
Первый способ основан на использовании драйвера NDIS (Network Driver Interface Specification) /* Здесь и далее имеется в виду платформа Windows – прим. ред. */. Этот драйвер будет находиться между драйвером сетевой карты и драйверами протоколов (TCP/IP и т.д.). В сущности, он станет виртуальным адаптером, являясь NIC-драйвером для драйверов протокола и наоборот. Так как каждый входящий и исходящий пакет будет проходить через этот промежуточный драйвер, это позволит осуществить атаку “man-in-the-middle - человек посередине” (в данном случае с благой целью). Другой стандартный способ реализации пакетного фильтра основан на внедрении в NDIS путем перехвата части функций библиотеки NDIS, используемых драйверами протоколов. Это означает, что пакетный фильтр будет находиться в самом NDIS, находясь между драйверами протоколов и чем-либо более низкоуровневым. Несмотря на то, что этот способ очень сильно отличается от предыдущего по реализации, функционально они подобны.

Теперь принцип работы пакетного фильтра должен быть понятен. Он анализирует каждый пакет в соответствии с критериями, указанными в наборе правил МСЭ, сохраненными в некоторой внутренней структуре данных. Осуществляется анализ таких параметров, как хост и порт отправителя и получателя, уровень фрагментации, тип протокола, флаги пакета, действительно ли пакет является частью уже открытого соединения и т.д. Например, если протокол – TCP, и пакет имеет SYN-флаг (попытка открыть соединение), фильтр в зависимости от правил разрешит или запретит соединение для данного исходного и целевого хоста. Если все же соединение будет разрешено, фильтр добавит его во внутренний список открытых соединений. Таким способом межсетевой экран следит за текущими соединениями, осуществляя непрерывную инспекцию пакетов. Если пакет удовлетворяет правилам или принадлежит соединению из вышеупомянутого списка открытых соединений, он пропускается. Пакетный фильтр передает пакет на следующий уровень – драйвера протоколов, если пакет входящий или драйвера сетевой карты, если пакет исходящий. Если пакет блокируется правилами, он никогда не будет передан на следующий сетевой уровень. В этом случае, опционально, для обратной связи с пользователем на экране может появиться предупреждение или запись в лог-файле.

фильтр процессов

Этот драйвер также присутствует во многих программных МСЭ. На уровне рассмотренного выше пакетного фильтра у нас не никакой информации о процессах. Работа происходит только с входящими и исходящими пакетами, вещами, которые с точки зрения прикладного приложения, происходят вне машины. Таким образом, для реализации фильтрации на уровне процессов, нужно создавать фильтр, работающий на более высоком уровне. Данный механизм будет работать на уровне ядра, являясь оберткой над TDI (Transport Driver Interface) и перехватывая функции, которые приложения и/или вспомогательные библиотеки (WinSock) используют для передачи данных между собой и драйверами протоколов.

Есть также и другие методы. Например, WinSock API, набор функций, использующийся большинством приложений для доступа к сети, основан на многоуровневой модели, позволяющей вставлять расширения (extensions) третьих лиц между интерфейсом приложений и базовым сетевым протоколом. Такое расширение можно добавить, реализовав Layered Service Provider (LSP) и вставив его в LSP-цепочку. LSP – это стандартная Windows DLL, соответствующая некоторой спецификации и имеющая специальную функцию, которая предназначается для вставки в цепочку WinSock протокола. Согласно модели WinSock, все сетевые данные проходят через эту цепочку, в которой каждый LSP принимает решение о пропуске данных на уровень выше (или ниже, в зависимости от того, являются ли конкретные данные входящими или исходящими), предварительно обработав или изменив данные в соответствии со своей функцией. Quality of Service (QoS) является примерно такого расширения, реализованного как LSP. Фильтр процессов может быть реализован в виде LSP, находясь в цепочке протокола и выборочно передавая данные к следующему элементу цепочки или блокируя их, руководствуясь собственными критериями.

Однако, описанный метод - не лучшее решение для реализации фильтра, так как он будет действовать только для приложений, использующих WinSock для передачи данных. Для обхода фильтра процессов, основанного на LSP, нужно всего лишь воспользоваться собственным драйвером для прямой связи через TDI c драйвером протокола, что позволить обойтись без WinSock. Первый способ, основанный на обертке над TDI, является лучшей альтернативой, так как работает на более низком уровне.

Задача фильтра процессов – анализ попыток создание соединений приложениями. Он смотрит на идентификатор (PID) процесса, пытающегося отправлять или получать данные и анализирует его характеристики на соответствие набору правил, используя более или менее сложный набор критериев, в зависимости от качества реализации фильтра процессов МСЭ. Но основной вопрос обычно выглядит так: разрешено ли приложению, создавшему этот процесс, выполнять те действия, которые оно пытается выполнить? Это задача сводится к проверки целостности файла, создавшего процесс, путем сравнения текущего хэша с известным, поиску файла в наборе правил, а затем проверка разрешения на выполнение соответствующих действий.

проблемы, связанные с фильтрами процессов

Существует несколько проблем, связанных с реализаций фильтров процессов. Например, неплохо было бы проверять, какие DLL присутствуют в адресном пространстве процесса и действительно ли они должны там находиться? Это имеет смысл, так как код загруженных модулей исполняется в контексте процесса, в адресном пространстве которого они находятся. Таким образом, злонамеренный процесс может загрузить EVIL.DLL в адресное пространство “хорошего” процесса X, и процесс X выполнит код из EVIL.DLL перед своим собственным. Решением этой проблемы будет нахождение всех загруженных модулей, поиск их образов на диске и затем проверка на наличие в таблице модулей, разрешенных для загрузки данным процессом. МСЭ часто осуществляют такую проверку и спрашивают разрешения на загрузку модуля, но очевидно, что это не лучшее решение проблемы.

/* Речь в статье идет главным образом о так называемых «пользовательских» файрволлах, защищающих отдельные хосты. Если углубляться в философию, понятие «межсетевой экран» не больно-то подходит к такому ПО, поскольку стоит не между сетями, а между сетью и хостом. Но мы сделаем вид, что этого не заметили. Читаем дальше :) – прим. ред. */

Межсетевой экран не может знать все возможные настоящие и будущие DLL, “плохие” и “хорошие”, поэтому пользователю приходится решать, разрешить ли загрузку данного модуля или нет. Другая проблема – был ли код процесса изменен в памяти (процесс может изменять память другого процесса, с целью изменения его поведения). Такое также возможно, если процесс был создан злонамеренной программой (которая имела бы возможность изменять поведение процесса). Это список продолжать можно долго...

Только некоторые из этих проблем адекватно решаются в современных МСЭ. Правда в том, что существует слишком много путей маскировки
злонамеренного кода, которые могут ввести в заблуждение фильтры и простых и сложных межсетевых экранов. Злонамеренный процесс может изменить в памяти код другого процесса. Можно использовать в своих интересах возможности легитимной программы, например, запустив из командной строки браузер, передав ему в аргументах указание загрузить злонамеренную страницу. Даже если фильтр отслеживает отношение родительский-дочерний процесс, можно использовать много уровней косвенности (злонамеренный процесс может запустить cmd.exe, которому приказано запустить другой cmd.exe, который в свою очередь запустит браузер с нужной страницей). Или враждебное приложение может применить агрессивную тактику против МСЭ, вообще его отключив, с помощью эмуляции кликов мыши, закрывающих предупреждения. Помните, все, что может сделать пользователь, может сделать и программа (в пределах контекста пользователя, конечно).

Все что написано выше, фокусируется на введении в заблуждение фильтра процессов. Совсем другие возможности открываются, если атакующему даже не нужно проходить через этот фильтр. Представьте, что информация о процессах, которую использует фильтр процессов, потеряна. Вся информация, которую в этом случае имеет МСЭ - это входящий и исходящий трафик, работа с которым ведется на уровне пакетного фильтра. Все, что нужно сделать атакующему – это использовать драйвер, который произведет инъекцию пакетов на уровень более низкий, чем уровень фильтра процессов, что даст возможность волноваться только о пакетном фильтре. Пока он будет использовать разрешенные порты (например, 80, 25 и т.п.) пакетный фильтр будет пропускать пакеты атакующего. О возможности работы под уровнем пакетного фильтра даже не будем упоминать...

обман межсетевого экрана: LSP-троян на 80 порту

Давайте рассмотрим один случай, в котором можно обойти функциональные возможности МСЭ. Путем внедрения злонамеренного LSP (Layered Service Provider) в стек протокола, нелегальное приложение может стать частью стека протокола, получив возможность отслеживать разрешенные соединения, инициированные разрешенными процессами и по желанию изменять входящие и исходящие данные. Отличный способ, позволяющий атакующему отправлять команды своему трояну и получать ответы, это открытие обычного разрешенного соединения, скажем через публичный HTTP-сервер, запущенный на целевой машине.

Чтобы осуществить это, все что нужно сделать атакующему – реализовать LSP и внедрить его в цепочку протокола Winsock. Такой LSP, также как и любой другой, может отслеживать, изменять и даже блокировать весь входящий и исходящий трафик. Что еще более интересно, можно генерировать поддельный трафик и передавать его на нижние уровни, как реальный трафик, пришедший от разрешенного приложения. Или можно передавать поддельный трафик на верхние уровни, как будто бы он пришел из сети. Таким образом, данный способ является очень подходящим для реализации атаки man-in-the- middle.

Рассмотрим следующий пример: корпоративная сеть, находящаяся за МСЭ, имеет публичный веб-сервер, доступный из внешней сети. Веб-сервер защищен и имеет все необходимые патчи. На сервере установлен локальный межсетевой экран, закрывающий все порты, кроме 80. Только процесс веб-сервера имеет право прослушивать 80 порт. Теперь предположим, что эта система была заражена самопальным трояном, работающим на уровне LSP, или модифицированной версией существующего, такого как Trojan.Riler.D или Daga.A, который следит за обменом данными через 80 порт. Может ли атакующий успешно осуществить двухстороннею связь с этим трояном через интернет? Ответ, скорее всего, будет положительным.

Каким образом? Используя обычные запросы браузера, находящего вне внутренней сети веб-сервера. Запомните, все сетевые данные анализируются LSP- трояном на сервере. Атакующий может соединиться с веб-сервером и отправить несколько HTTP-запросов, содержащих в себе зашифрованную команду, которая будет интерпретирована трояном (например, GET /index.htm HTTP%%givemeadmin%%/1.1). Так как это допустимый запрос на 80 порт, маршрутизатор передаст его веб серверу. На самом сервере, пакетный фильтр локального межсетевого экрана также увидит допустимый пакет, принадлежащий установленному соединению, и пропустит его. Фильтр пакетов на интерфейсе TDI определит, что этот пакет предназначается для порта, который прослушивается разрешенным приложением (веб-сервером) и также пропустит его.

Внутри стека протокола LSP-троян проанализирует данные пакета и распознает “%%givemeadmin%%” как команду к действию. Затем троян удалит команду из пакета и передаст пакет на верхние уровни протокола. После этого он начнет выполнять команду (например, в данном случае может начаться подбор паролей, хэши которых сохранены на компьютере). Когда пакет дойдет до веб-сервера, он увидит только корректную часть HTTP запроса: “GET /index.htm HTTP/1.1”. Ответом на этот запрос должно быть содержимое index.htm или информация об ошибке. Предположим, что сервер ответит "HTTP/1.X 404 Not Found". Он отправит эту ошибку через WinSock API, где ее перехватит наш троян.

Троян будет использовать данный ответ для передачи результата выполнения команды (например, подобранный пароль администратора). Перед пропуском пакета на нижний уровень стека протокола, он вставит зашифрованный результат выполнения команды в ответ сервера. Другими словами, выходные данные могут быть следующими: "HTTP/1.X %%thepasswordisGOD%%404 Not Found". Локальный МСЭ определит, что разрешенный процесс отправляет данные через разрешенное соединение и пропустит пакет. То же самое сделает МСЭ на маршрутизаторе. И что в результате? Радостный хакер и скомпрометированная сеть.

Естественно, это простейший пример. Более сложный вариант с использованием протокола с бинарной передачей данных (такого как FTP или HTTPS) и шифрованием передаваемых данных, очень сильно усложнил бы обнаружение скрытого канала. Даже если в сети используется МСЭ Checkpoint, шансы на то, что данный способ связи останется необнаруженным, будут очень велики.

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

пример из жизни - компрометация IIS с помощью скрытого LSP-трояна

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

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

В нашей корпоративной сети присутствует маршрутизатор, как первая линия обороны. На нем закрыты все порты, кроме действительно необходимых, а также блокированы исходящие ICMP-сообщения. За маршрутизатором находится Cisco PIX firewall. Этот МСЭ помещен за маршрутизатором для снижения его нагрузки.

Подключившись к маршрутизотору, мы получим доступ к главному свитчу, который в свою очередь контролирует несколько других свитчей и, в нашем случае, настройки DMZ (демилитаризованной зоны), как описано ниже. За МСЭ находится веб-сервер и сервер Microsoft Exchange. Кроме этого, в различных отделах находятся обычные рабочие станции и их внутренние LAN-серверы.

Атакующий, просканировав сеть, узнает, что порты 22, 25, 53, 80 и 110 открыты и, возможно, в сети работают сервисы, слушающие эти порты. Следующим шагом нашего хакера будет отправка одного SYN-пакета на 80 порт с целью определения ОС, под управлением которой работает сервер. Получив в ответ SYN/ACK-пакет и проанализировав такие параметры, как TTL, размер окна и др., он может определить, что имеет дело с IIS. Предположим, атакующий доработал существующий эксплойт для IIS и с его помощью получил доступ с правами системы. На этом этапе атакующий закачивает свой LSP-троян. Наш хакер понимает, что активность TFTP будет легко обнаружена, если на сервере функционирует система обнаружения вторжений, однако, он идет на риск. Как только LSP-троян и несколько вспомогательных bat-скриптов загружены, можно считать, что атакующий закрепился на системе. Несмотря на то, что атакующий имеет права системы на доступ к серверу, любую связь с компьютером ему нужно проводить максимально скрытно через LSP-троян, с целью снижения возможности его обнаружения в будущем. Скрытность – главная задача хакера.

необнаруженные атаки или кто следит за вашим IDS?

В контексте описанной ситуации, понимая принцип работы LSP-трояна, нам нужно ответить на вопрос: обнаружат ли атаку средства защиты этой сети? Как мы уже знаем, сам МСЭ не в состоянии обеспечить защиту от такого типа угроз. Однако, активность TFTP во время загрузки трояна была бы обнаружена любой современной IDS. Проблема в том, что многие из этих средств защиты редко контролируются. Это грустное, но во многих случаях истинное утверждение. Кроме того, даже если логи проверяются, существует немалая вероятность того, что человек, производящий мониторинг, не обладает необходимыми навыками и знаниями для адекватного анализа проверяемых данных. В некоторых случаях, в больших сетях каждый день в логах появляются сотни тысяч предупреждений.

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

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

В описанном случае, атакующий, используя существующее разрешенное соединение, обойдя возможности фильтров исходящего трафика, будет отправлять команды и скрытно получать ответы. Это стало возможно благодаря внедрению LSP-трояна в TCP/IP-стек. Стандартные методы обнаружения в данном случае бесполезны. Бесполезными оказались и МСЭ, и система обнаружения вторжений. В идеале, если бы производилось какое-либо простейшее шифрование команд и ответов на них, даже просмотр конкретных пакетов не выявил бы сразу наличие канала связи с трояном.

обнаружение атаки

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

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

Можно написать троян, который будет очень трудно обнаружить, или даже почти невозможно, если атакующий имеет достаточную квалификацию. Используя продвинутые методики можно создать исполняемый файл без какой-либо уникально опознаваемой сигнатуры. Таким образом, даже если копия трояна попадет в антивирусную компанию, будет очень сложно создать утилиту для его автоматического обнаружения. Хотя факт появления подобного злонамеренного ПО у аналитиков антивирусных компаний сам по себе маловероятен, так как хакеры, атакующие корпоративные сети, обычно создают программы только для себя и не распространяют их. Реальность такова, что если атакующий достаточно профессионален, все попытки его обнаружения закончатся неудачей.

Эта статья обращает внимание на соотношение уровня сетевой безопасности и удобства пользователей. Используя внутренние ресурсы, можно создать собственные сигнатуры для IDS, учитывающие большое количество разных методов обхода фильтров на высоком уровне. Однако, для этого потребуется много времени и знаний. Не каждая организация может позволить себе такое, не говоря уже о взятии дополнительного сотрудника и обучении его всевозможным методам обмана защиты. Решением может являться принцип глубокой защиты. Кроме стандартной межсетевой защиты и системы обнаружения вторжений, вашей компании нужна многоуровневая защита. Перспективной технологий является система предотвращения вторжений (IPS). Такая система плюс статистический анализ потока пакетов могли бы реально повысить обнаружение таких проблем как LSP-трояны.

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

выводы

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



Израэль Дж. Луго и Дон Паркер, перевод Владимир Куксенок, перевод впервые опубликован на SecurityLab.