Как работает брандмауэр
Практически все локальные брандмауэры представляют собой тривиальные пакетные фильтры, сидящие на интерфейсе и пропускающие сетевой трафик через себя. Методы фильтрации самые разнообразные. Некоторые материнские имеют интегрированную карту со встроенным брандмауэром, брандмауэр может быть встроен в wi-fi или DSL-модем, но чаще всего он реализуется как прикладной пакет, устанавливаемый на компьютер.
Начиная с Windows2000, в состав операционной системы входит примитивный брандмауэр, который был значительно усилен в Windows XP (особенно в SP2). Как маркетинговое средство он, может быть, и сгодится, но вот от хакеров практически никак не защищает. А широко разрекламированный Kaspersky Anti-Hacker этот совсем даже не брандмауэр, а вообще непонятно что.
Главным образом, мы будет говорить о "правильных" брандмауэрах, таких как SyGate Personal Firewall, Outpost Firewall, Zone Alarm и других, представляющих собой пакетные фильтры, встраивающиеся в стек сетевых драйверов — в одно или несколько мест на свой выбор.
Рисунок 3 "разрез" сетевой подсистема Windows NT в миниатюре
Упрощенная модель сетевой подсистемы Windows NT приведена на рис 3. На самом верху иерархии (или можно даже сказать вакханалии) находится библиотека ws_32.dll, реализующая функции Winsock (они же "сокеты") к числу которых принадлежат bind, connect и другие. Большинство приложений взаимодействуют с сетью именно через ws_32.dll, вызовы которой очень легко перехватить, достаточно, например, заменить штатную библиотеку на свою собственную или модифицировать таблицу импорта. Однако, это на фиг никому не нужно. Значительная часть трафика проходит мимо ws_32.dll! В частности, обращения к "расшаренным" ресурсам таким пакетным фильтром уже не обнаруживаются! К тому же зловредные приложения могут беспрепятственно вызывать функции нижних уровней, работая в обход Winsock. Тем не менее, перехват ws_32.dll все-таки используется в некоторых примитивных брандмауэрах и баннерорезках, к которым в частности принадлежат ранние версии SyGate Personal Firewall (далее по тексту просто SPF) и AtGuard (он же "гвардеец").
Ну банерорезалки — это понятно. IE, Лис, Опера — все они грузят баннеры через Winsock и такой меры вполне достаточно, но вот брандмауэр…
Рисунок 4 сетевой стек крупным планом от вершины до самого дна
Под ws_32.dll находится драйвер afd.sys (ancillary function driver – вспомогательный служебный драйвер), в котором реализованы основные операции над сокетами: создание сокета, установка соединения и т. д. Фактически, ws2_32.dll представляет собой высокоуровневую user-mode обертку, а afd.sys ее kernel-mode часть, образуя что-то вроде айсберга. Если быть совсем точным, то этих оберток целых две — между ws2_32.dll и afd.sys находится библиотека msafd.dll, на которую садятся некоторые брандмауэры, пытающиеся фильтровать трафик. Однако, это не самое удачное решение. Во-первых, как уже говорилось, часть трафика идет мимо сокетов, а, во-вторых, приложению ничего не стоит обратится к драйверу afd.sys напрямую!
Спустившись на одну ступеньку вглубь, мы обнаруживаем драйвер tcpip.sys, сосредоточивший в себе реализацию протоколов TCP/IP. Это так называемый уровень TDI (Transport Data Interface — Интерфейс Передачи Данных), так же называемый "транспортным" уровнем или уровнем сетевых протоколов. Здесь же расположен драйвер NWLNKIPX.SYS, реализующий протокол IPX и другие сетевые драйвера, давно отошедшие в мир иной и представляющий только исторический интерес. Когда компьютер работает в режиме маршрутизатора или шлюза весь трафик идет через сетевые драйвера (главным образом через tcpip.sys) и на верхних уровнях просто не появляется (впрочем, если сетевая карта поддерживает режим FFP, трафик может не дойти и до tcpip.sys). Зловредные программы прикладного уровня могут вызывать tcpip.sys напрямую (или через высокоуровневую обертку wshtcpip.dll), минуя ws2_32.dll. Для установки TCP/IP фильтра необходимо перехватывать все вызовы к устройствам \Device\RawIp, \Device\Udp и \Device\Tcp. Это достигается либо вызовом IoAttachDevice, либо прямой модификацией указателей таблицы диспетчеризации.
Следующей ступенькой ниже обосновался NDIS-драйвер (Network Driver Interface Specification — Спецификатор Интерфейса Сетевых Драйверов), представляющий из себя mini-port. Грубо говоря, это библиотека функций, позволяющая драйверам сетевых протоколов "гонять" сетевые пакеты, не вникая в детали реализации. Ниже NDIS находится только драйвер сетевой карты, поэтому брандмауэр, работающий на NDIS-уровне, перехватывает практически весь трафик, который только проходит через компьютер. "Практически" потому что, обращения к обратной петле (loop back) через NDIS не проходят и остаются незамеченными. То есть, если мы дадим команду ping 127.0.0.1, пакетный фильтр даже не пикнет. А это значит, что NDIS-брандмауэры хронически не способны обнаруживать подключения к локальным службам. Если на компьютере установлен Proxy-сервер (а он установлен практически на всех домашних сетях), любое приложение может свободно выходить в сеть и гулять по любым адресам, осуществляя информационный обмен во всех направлениях.
Рисунок 5 сетевой стек — это настоящий айсберг
К тому же на NDIS уровне один хрен разберешься что за приложение ломится в сеть, а без этого невозможно принять решение: пропускать его или нет. Грамотный брандмауэр представляет собой целый конгломерат пакетных фильтров разных уровней, сложным образом взаимодействующих между собой. Но это еще не подножье айсберга! Драйвер сетевой карты опирается на драйвер шины, через который проходят все "честные" вызовы. На уровне ядра, хакер может напрямую обращаться к карте через порты ввода/вывода или вклиниваться в PPP-драйвер, реализованный как WAN mini-port, а это пониже, чем NDIS будет, по крайней мере, формально. Практически же, весь Dial-Up (он же RAS — Remote Access Service, или по русски Сервис Удаленного Доступа) реализован на прикладном уровне и злоумышленник легко может вклиниться в него!
Рисунок 6 RAS – Сервис Удаленного Доступа, используемый на Dial-Up'е
Существует по меньшей мере три документированных способа для перехвата трафика на NDIS уровне. Это, во-первых, NDIS Intermediate Driver (Промежуточный Драйвер NDIS), который садится между NDIS-драйвером и драйвером сетевой карты. Методика так себе. Писать целый драйвер ради одного перехвата — решение из разряда тяжеловесных, к тому же для работы с Dial-Up'ом приходится очень круто извращается, поэтому особой популярности промежуточный драйвер не сыскал (разработки брандмауэров, как ни странно, тоже люди и ничто человеческое им не чуждо). На всякий случай, если возникнет желание познакомится с ним поближе, всегда можно открыть раздел " Intermediate NDIS Drivers and TDI Drivers" из DDK.
Вторым идет "Filter-Hook Driver" (Драйвер Фильтра-Ловушки), представляющим из себя обычный kernel-mode драйвер, фильтрующий сетевые пакеты на уровне IP и работающий из-под палки. Microsoft категорически не рекомендует использовать его для брандмауэров и вот почему: всего лишь одна ловушка может быть установлена в системе, причем устанавливается она довольно "высоко" и к тому же зловредное приложение может легко отключить фильтрацию. Вот, что по этому поводу пишет DDK: "A firewall-hook driver did not meet firewall requirements because it ran too high in the network stack…. To provide firewall functionality on Windows XP and later, you should create an NDIS intermediate miniport driver to manage packets sent and received across a firewall". (Firewall-hook драйвер не удовлетворяет требованиям, предъявляемым к брандмауэру, поскольку он работает на слишком большой высоте в сетевом стеке… Для обеспечения надлежащего функционала на XP и выше, необходимо создать NDIS intermediate miniport драйвер, управляющий отправкой и приемом пакетов через брандмауэр). Но ведь находятся же такие чуки, которые используют firewall-hook драйвер как основное средство фильтрации!
Третьим и последним способом перехвата остается NDIS-Hooking Filter драйвер (так же называемый Pseudo-Intermediate NDIS Driver — псеводо-промежуточным NDIS драйвером или сокращенно PIM), перехватывающий некоторое подмножества функций библиотеки NDIS для отслеживания регистрации протоколов и открытия сетевых интерфейсов, незаслуженно раскритикованный разработчиками Outpost Firewall'а.
Помимо надежности, к достоинствам данного метода следует отнести "прозрачную" поддержку Dial-Up интерфейса, на котором сидит больше половины всех пользователей. Конкретные методики перехвата достаточно разнообразны, но так или иначе они сводятся к патчу "родного" NDIS драйвера в памяти, что несравненно проще реализации промежуточного NDIS драйвера с нуля. К тому же грамотно организованный перехват не так-то просто отключить! Это лучший способ фильтрации из всех имеющихся, используемый во многих брандмауэрах! Однако, как уже отмечалось, обратная петля до NDIS уровня уже не доходит, да и pid процесса-носителя определить весьма затруднительно, поэтому одного лишь NDIS-фильтра для реализации персонального брандмауэра будет недостаточно.
Рисунок 7 псевдо-промежуточный NDIS-драйвер, используемый многими брандмауэрами
Разумеется, существуют и другие способы фильтрации трафика, но мы не будем всех их рассматривать. Главное, что таких способов великое множество и ни один из них сам по себе не безупречен. Хороший брандмауэр должен комбинировать прикладные фильтры с фильтрами ядерного уровня, но… ни один из них этого не делает, что позволяет хакеру легко обойти защиту. О том, как это сделать мы сейчас и поговорим.
